記得很早在哪里看過一篇英文文章，介紹敏捷方法的由來凰慈。因為2000年左右的經(jīng)濟(jì)危機(jī)影響深遠(yuǎn)，客戶的IT投資驟減微谓，處于交付中途的軟件系統(tǒng)無法上線，只剩下成堆的文檔豺型，對于客戶而言一無是處买乃。軟件廠商陷入深深自責(zé)（沒錢賺才是真的）姻氨。行業(yè)被逼無奈剪验，創(chuàng)造了敏捷方法應(yīng)對再次可能的危機(jī)，顯著的變化之一功戚，就是以迭代增量的形式開發(fā)軟件，推向極致就是頻繁上線啸臀。這樣就可以確保，某種危機(jī)即便在任何時刻再度造訪乘粒，軟件系統(tǒng)至少以某種比例的完整度在運(yùn)轉(zhuǎn)著。自此可以保護(hù)客戶的投資灯萍，不會浪費(fèi)掉一分錢。
這消息不論真假旦棉，但多少反映了某一方面的真實：敏捷帶來的不止是新奇熊痴、改進(jìn)聂宾、優(yōu)雅（當(dāng)然也有痛苦）果善，即便容易被人忽視系谐，但它現(xiàn)實利益的一面的確也是存在的——讓客戶覺得物有所值。這也是我們常常提及的價值交付纪他。不是隨便喊喊的口號。
價值交付茶袒，必然需要體現(xiàn)在具體的行動上。一如敏捷中各類實踐作為整體的完整性薪寓，價值交付的思維也需要表現(xiàn)在軟件構(gòu)建的過程中。盡早上線，頻繁上線逸寓，哪怕開始只是簡陋的功能也直接交由用戶使用瘦黑，是最符合直覺的，因為和生產(chǎn)環(huán)境以及最終用戶有關(guān)幸斥。而更多需要表現(xiàn)在日常那些細(xì)致入微的活動中。故事卡的Kickoff睡毒，開發(fā)過程中頻繁的本地構(gòu)建和環(huán)境部署，Desk Check，迭代Showcase和Sign off供搀，都有盡早呈現(xiàn)的意味在里面游弋。它們只是各自有不同的粒度葛虐，以及需要區(qū)分的呈現(xiàn)對象。但無不是借助細(xì)致粒度的反饋屿脐，來彌合因為多人合作以及復(fù)雜環(huán)境所帶來的需求與溝通的罅隙宪卿，以及不確定性万栅。
在這些盡早呈現(xiàn)的過程中佑钾，檢驗需求的真實和市場的反饋是毋庸置疑的烦粒，團(tuán)隊還可以借此驗證自己的技術(shù)和能力的組合。方向正確了扰她，在此上迭代增量，每個人也會漸漸擁有堅定的信心徒役。
這對那些莫須有的需求存有天然的抑制作用，費(fèi)勁口舌去爭辯需求的合理性忧勿，不如盡快交由市場和用戶去判斷。預(yù)防開發(fā)者的過度設(shè)計狐蜕、自大以及添油加醋，也有順理成章的療效层释。
為了確保快速的呈現(xiàn)贡羔，交付上線，并應(yīng)對必然而來的反饋和需求變化猴蹂，代碼要有可讀性方便維護(hù)，測試覆蓋率要高確保修改安全磅轻，不可選用復(fù)雜的架構(gòu)設(shè)計，要足夠輕量聋溜，微服務(wù)顯然更有伸縮彈性，架構(gòu)不具有演進(jìn)性顯然會積重難返撮躁。對有效反饋的渴求，刺激著團(tuán)隊需要飽含輕量把曼、快速響應(yīng)、隨時優(yōu)化調(diào)整嗤军，以及不多不少的思維，然后體現(xiàn)在所有的開發(fā)活動中型雳。
想起那幅著名的價值交付的對比圖【兰螅客戶的需求是一輛四輪的豪車，而盡早呈現(xiàn)交付給他的是一個三輪腳踏車冤荆。看著不可思議钓简，但如果客戶的需求只是從一個地方到另一個地方，這是不是在當(dāng)下就足夠了呢外邓？
