傳統的軟件開發是瀑布式的，它提倡設定計劃，遵循計劃，按部就班的實施，其中一部分的重要產出就是大量完備的文檔。
但是敏捷宣言中明確的指出：工作的軟件高於詳盡的文檔！這並不是說，敏捷中文檔不重要，但在敏捷中有哪些文檔呢？只記錄結果文檔。
這又是問什麼呢？這就要與敏捷宣言中的另一句話：響應變化高於遵循計劃，一起結合着看！
進行過敏捷的團隊都瞭解用戶故事，用戶故事是在迭代計劃中團隊承諾的 feature，並會對用戶故事進行故事拆分和工時評估。並且，Scrum 迭代規定 Sprint 衝刺中不要打斷或更改團隊衝刺的故事。
但是，大多數團隊在進行中很快就變成是小迭代中的小瀑布！團隊在計劃會議中被要求完成多少個故事，大多數情況缺少前期調研和整理，任務拆分不是按照過程拆分（調研、設計、開發、測試），就是縱向拆分（頁面開發、邏輯層開發、接口開發）等。基本感覺就是要完成這些故事，瞭解個大基本，很多細節還要到迭代中進行梳理和整理。
這時，如果你面臨的第一個問題就是，如何保證在迭代內完成承諾的用戶故事？
如果你是這樣做的：爲了保證完成，開始制定計劃時間表和里程碑，爲了在開始在迭代前梳理清楚需求，要求有 PRD，並在迭代中規定不要輕易改變迭代內容等，那麼，你就真的將敏捷變成了小瀑布了。也許你會說，故事拆分就是爲了定義邊界，讓我們知道在迭代中做什麼故事。還有燃盡圖，就是要按照計劃的速度進行開發。
這樣做，你就真的理解錯了敏捷的含義！你做的就真的不是敏捷！
計劃會議固然重要，我們花費大量的時間進行故事評估、任務拆分。目的是什麼，快速迭代！這沒有問題，但同時還有重要的一條，敏捷是快速響應變化高於遵循變化。回到根本，爲什麼要快速迭代，就是因爲需求變化的太快。變化快到你剛剛評估完畢一個用戶故事，下一刻它有了變化。這時，難道你還要固守什麼迭代不要被打破或更改的規則麼？
團隊承諾、響應變化。就是因爲這一點，在敏捷中工作的軟件高於詳盡的文檔，並且敏捷中少有過程文檔，任何產品或故事都是以結果爲導向的。面對變化，敏捷是響應變化，而不是追蹤變化。
敏捷團隊的 wiki 中只有最終的結果文檔，並且往往是開發完成之後補的。這時，你也許會疑惑，那故事評估和任務拆分，以及燃盡圖統計還有什麼意義？如果故事拆分的任務沒有任何工作的指導性，那還有必要拆分麼？
回答這個問題，就要說下團隊。在敏捷中，團隊的積極性和自主性顯得格外重要，以及相互信任。害羣之馬一定要從團隊 T 除。
故事是如何進入到迭代中的？故事是產品細粒度劃分之後，按照優先級，被團隊評估和初步拆分任務之後放入迭代的。這就是計劃會議，其目的只有一個，統一願景！其餘所有的都是爲了幫助完成目標的實踐！
你會問，團隊承諾、響應變化，我們如何確信團隊能完成迭代中的內容？隨時可能變得需求和設計，時刻在變的計劃，在沒有完成之前又沒有任何文檔，如何保證團隊能完成？就只憑團隊承諾？對！就是相信！如果是你是領導者，你唯一能做的相信團隊，要做的就是保護團隊！
也可以說，敏捷就是如此激勵團隊的！相信團隊，讓團隊發揮力量解決問題，他們能搞定！你不用幹涉他們！所以，這也就是爲什麼說，敏捷中，領導只需要關注看板上空閒的任務，而不是空閒的人。
但是，你如何做到這點，如何激勵團隊，這在以後咱們會繼續討論！
所以，至此來回答前面的問題：計劃會議、故事評估、任務拆分、站立會議、回顧會議、演示會議，所有的一切，都是爲了讓團隊高效服務的！
可是，你還會問！如果團隊沒有實現承諾怎麼辦？首先，你要看，團隊是否真的有沒有全力以赴。如果有，你就要看看迭代的任務是什麼原因，是故事太多，是干擾太多，還是什麼問題。如果不是，你就要看看團隊出了什麼問題，如何能激發團隊的積極性。而這些你都可以在團隊的 Retro 上與團隊一起討論。
總之，如果團隊天天加班都沒有完成，那真的團隊承諾的太多了。遇到這個問題，要說的就是，敏捷提倡工作效率，而不是靠時間堆出來的虛假繁忙和過度勞累！
讓我們在回顧一下 Scrum 的由來：在橄欖球衝刺之前，教練指揮部署戰術、制定計劃，但是一旦開始之後，就是要靠團隊隨機應變，盡最大的努力完成目標，並不斷地總結每一次成功和失敗。
用最後一句話進行總結：敏捷讓團隊只做最有價值的！
ps. 你在決定讓團隊做一件事時，首先想想，這事情真的會給團隊產生價值麼？團隊會真的執行麼？如果拿不定主意，就讓團隊來決定吧！
—————————— 本文同步發佈於 ZHANGSR 我的個人博客 ——————————