從持續傳遞看敏捷開發的自相似性（敏捷開發的心跳）

       作者：陳勇

       出處：blog.csdn.net/cheny_com

      

自相似性是指一個事物的局部與其更大的局部乃至整體具有相似性。

從大的方面看，敏捷開發具有重視客戶價值，提倡持續傳遞等思想。但一般而言，Product Owner常常具備相當好的客戶價值意識，而一線開發人員則比較關注技術本身，所以一旦僅僅停留在思想層面，在實際工作的時候就會發現有所背離。因此應該從自相似性的眼光看待敏捷開發的整體思想與局部實踐，從而做到年年月月日日事事均符合敏捷開發的思想。

本文只從“持續傳遞”這一個敏捷開發思想來分析敏捷開發的自相似性。

“持續傳遞？是不是就是每個衝刺結束都要有一個可啟動並執行版本？”是，也不是。

 

衝刺末尾的持續傳遞

敏捷最大的特色之一，就是階段性地交付可啟動並執行軟體，而不是一堆暫時無法使用的文檔。按照精益生產的思想，文檔只是一種“中間產物”，不但不容易寫好，還很難評審；即使在初期看到了完美的需求文檔，也很難保證最後能看到完美的軟體。因此敏捷開發決定只要可能（不是絕對的），就盡量繞開這個中間產物，而用可啟動並執行軟體來表明軟體的進度和品質。

在衝刺的末尾，Product Owner和干係人們不是看著文檔，而是看著一個可啟動並執行軟體進行評審，是這裡持續傳遞的核心目的。為了方便評審，被交付的往往是一組相關的故事群，而不是“當前最重要的需求”。

 

衝刺內的持續傳遞

衝刺期內看平靜，大家忙忙碌碌只待最後交付，其實不然。如果每個迭代都始自“需求分析”而終於“系統測試”，敏捷開發就變成反覆式開發法了。然而即使每個使用者故事都獨立開發，仍可能發生一堆故事都在“開發中”，但因為這些故事無法獨立成章因而無法形成可運行軟體的狀態。為了防止這種情況，好故事一般都獨立、可測試、完整地交付某個客戶價值，因而每當完成一個故事，都能形成一個臨時的可運行軟體。

若能遵循MoSCoW方法（另有博文詳述），則可以保證即使衝刺結束時無法完成所有Sprint Backlog項，仍能向Product Owner交付一個可用的軟體。

 

“日建立”的持續傳遞

“日建立（Daily Build）”因能在每天結束時都能交付軟體而聞名（這是微軟在開發Windows時的創舉），但對於小型軟體開發，已經能做到每人每次提交代碼在10分鐘後就能看到結果的能力。1000人在開發了1000天的軟體裡邊定位1，000，000個缺陷是不可思議的（平均1人1天1個缺陷），但每人在自己每天的代碼中定位一個缺陷卻是很現實的，前提是你能找到它，日建立就是這個邏輯。

一般常常提到的持續整合+自動化測試指的就是這個層面的持續傳遞活動，其目標是在提交代碼後最短的時間內形成可運行軟體，並確認是否存在問題。

 

版本間的持續傳遞

很多軟體看似越來越強大，但市場反響卻並不好（比如很多人安裝的“免費”Office都是2003的，也就是7年間完全沒有和MS做生意的打算），原因就在於這些軟體並沒有解決好一個問題：“下個版本到底面向哪個市場的哪類客戶？他們為什麼購買它？”這時軟體很容易跟隨公司領導的思緒夢遊，或者被一兩個大客戶牽著鼻子走，或盲目地試圖覆蓋競爭者的所有功能而迷失本性。

還是之前那句話：按照商業步調計劃版本內容，也就是每個版本出來後，都要滿足某些需求、擷取某些客戶、打敗某些對手、取代某些產品……如果能持續找到這些“某些”是誰，那麼下一個版本就能成功，如果找不到，興許產品已經到達退出市場的階段。如果不能持續找到市場和客戶，怎樣持續傳遞可啟動並執行軟體都是一件沒有意義的事情。

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》