本章重點：
- 靈活流程及其原則
- Backlog
- Burn-down
- Sprint
- Scrum方法論
- 各種軟體開發方法論的優缺點
- 選擇軟體流程的根據
1 靈活的流程簡介
在軟體工程的語境裡，“靈活流程”是一系列價值觀和方法論的集合。
1.1 與現有方法對比
現有的做法 vs. 靈活的做法：
| 現有的做法 | 靈活的做法 |
|---|---|
| 流程和工具 | 個人和交流 |
| 完備的文檔 | 可用的軟體 |
| 為合同談判 | 與客戶合作 |
| 執行原定計劃 | 響應變化 |
1.2 靈活開發的原則
- 盡早并持續地傳遞有價值的軟體以滿足顧客需求
- 靈活流程歡迎需求的變化，并利用這種變化來提高使用者的競争優勢
- 經常釋出可用的軟體，釋出間隔可以從幾周到幾個月，能短則短
- 業務人員和開發人員在項目開發過程中應該每天共同工作
- 以有進取心的人為項目核心，充分支援新人他們
- 無論團隊内外，面對面的交流始終是最有效的溝通方式
- 可用的軟體是衡量項目進展的主要名額
- 靈活流程應能保持可持續的發展。上司、團隊和使用者應該能按照目前的步調持續合作下去
- 隻有不斷關注技術和設計，才能越來越靈活
- 保持簡明-盡可能簡化工作量的技藝-極為重要
- 隻有能自我管理的團隊才能創造優秀的架構、需求和設計
- 時時總結如何提高團隊效率，并付諸行動
1.3 Scrum方法論
“靈活”下有多種軟體開發的方法論，Scrum是其中之一。
靈活流程圖：
靈活步驟：
| 步驟 | 階段任務 | 說明 |
|---|---|---|
| 第一步 | 找出完成産品需要做的事情 - Product Backlog3 | 産品負責人上司大家對這個Backlog中的條目進行分析、估計工作量等 |
| 第二步 | 決定目前的沖刺（Sprint）需要解決的事情 - Sprint Backlog | -團隊成員根據自己的情況來認領任務； -如果團隊成員能住到任務的估計和配置設定，他們的能動性就能得到較大的發揮。 |
| 第三步 | 沖刺 | -在這個階段，外部人士不能直接打擾團隊成員，一切交流隻能通過Scrum大師（Scrum Master）來完成）； -這一措施較好地平衡了“交流”和“集中注意力”的沖突； 沖刺期間，-團隊通過***每日例（立）會（Scrum Meeting）***來進行面對面的交流； -Scrum Master根據項目的情況，用簡明的圖表現整個項目的進度，如燃盡圖（Burn Down Chart）或看闆圖。 |
| 第四步 | 得到軟體的一個增量版本，釋出給使用者 | 然後在此基礎上又進一步計劃增量的新功能和改進。 |
2 靈活流程的問題和解法
| 步驟 | 遇到的問題 | 解法 |
|---|---|---|
| 第一步 | 怎樣在計劃（Backlog）中展現依賴關系 | |
| 第二步 | -把一個任務從産品層級的描述逐漸細化到技術實作層面，是很需要技術能力和交流能力的； -如果成員們任務認上司緻忙閑不均，怎麼辦？ | |
| 第三步 | 每日例會很可能會流于形式 | -定義好任務究竟是什麼； -在每一個任務中記載我們完成這個任務還需要多少時間； |
| 第三步半 | -當你說“任務都完成了”的時候，那隻是說，開發人員任務***該寫的代碼***都寫完了，但其實還有很多事情沒做完； -程式員寫完功能的時候，我們感覺好像項目完成了80%，殊不知後面的20%往往要花費80%的時間，靈活流程沒有明确表明到底何人何時以何種優先級來完成這20%的任務； -長期任務-軟體項目中一些比較艱難和底層的任務，完成這些任務需要超過Sprint所計劃的時間。 | -有靈活專家建議測試人員可以在一個沖刺中擔負起産品負責人（Product Owner）的部分責任，同時掌握驗收測試（Acceptance Test）流程，對産品的最終品質負責； -本書的“穩定和釋出階段”一章講到了“第三步半要做什麼事情”，它的流程圖可以作為Scrum/Sprint模型的補充。 |
| 第四步 | -得到了一個增量的軟體釋出，但是誰來驗證這個增量是否滿足了事先的計劃呢？ -如果程式員們在沖刺過程中發現了新問題，改進了原來的計劃，這是好事還是壞事？ | -每一次沖刺結束後，大家要放松一下，總結上一次的經驗教訓，争取下一次做得更好； -團隊通過多次總結和流程改進，逐漸提高團隊的效率，逐漸滿足使用者的需求。 |
2.1 燃盡圖
一個完整的燃盡圖，有三個每天跟蹤的時間值：
- 實際剩餘時間（Remaining Hour）：每個團隊成員所有任務的剩餘時間的總和；
- 預估剩餘時間（Projected Remaining Hour）：根據每個人每天的理論進度推算的剩餘時間；
- 實際花費時間（Completed Hour）：實際花費的時間。
3 靈活的團隊
Scrum/Sprint能成功實施的關鍵在于Scrum Master。
一個好的Scrum Master能在兩種語境（描述軟體需求的商業語境，描述實作細節的技術語境）間自如地翻譯和切換，事實上是一個強有力的項目經理（參見本書“項目經理”一章）。
靈活對于團隊的要求：
- 自主管理（Self-managing）：以前上司布置了任務，我們實作就可以了。現在要自己挑任務；每次Sprint結束之後，要總結不足，提出改進，并且自己要實施這些改進；“自主管理”不等于“沒有管理”；
- 自我組織（Self-organizing）：以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對項目負責，有人工作落後了還要幫助他改進，項目缺少某類資源還要自己頂上去；
- 多功能型（Cross-functional）：以前規格說明書有PM來寫 ，測試由測試人員來做。現在每個人都全面負責，自己搞定規格說明書，和别人溝通，同時自己搞定測試。
4 靈活總結
靈活的方法與品質控制理論的模型如經典的戴明環（Plan-Do-Check-Act/Adjust，PDCA）類似。
靈活的方法不是“銀彈”，不能解決軟體開發的所有問題。
極限程式設計：所謂極限程式設計，就是把一些認為重要和有效的做法發揮到極緻，在這層意義上，“極限程式設計”應該叫“極緻程式設計”。