解讀敏捷 之 響應變化高于遵循計劃

傳統的軟件開(kāi)發(fā)是瀑布式的，它提倡設定計劃，遵循計劃，按部就班的實(shí)施，其中一部分的重要產(chǎn)出就是大量完備的文檔。

但是敏捷宣言中明確的指出：工作的軟件高于詳盡的文檔！這并不是說(shuō)，敏捷中文檔不重要，但在敏捷中有哪些文檔呢？只記錄結果文檔。

這又是問(wèn)什么呢？這就要與敏捷宣言中的另一句話(huà)：響應變化高于遵循計劃，一起結合著(zhù)看！

進(jìn)行過(guò)敏捷的團隊都了解用戶(hù)故事，用戶(hù)故事是在迭代計劃中團隊承諾的 feature，并會(huì )對用戶(hù)故事進(jìn)行故事拆分和工時(shí)評估。并且，Scrum 迭代規定 Sprint 沖刺中不要打斷或更改團隊沖刺的故事。

但是，大多數團隊在進(jìn)行中很快就變成是小迭代中的小瀑布！團隊在計劃會(huì )議中被要求完成多少個(gè)故事，大多數情況缺少前期調研和整理，任務(wù)拆分不是按照過(guò)程拆分（調研、設計、開(kāi)發(fā)、測試），就是縱向拆分（頁(yè)面開(kāi)發(fā)、邏輯層開(kāi)發(fā)、接口開(kāi)發(fā)）等?；靖杏X(jué)就是要完成這些故事，了解個(gè)大基本，很多細節還要到迭代中進(jìn)行梳理和整理。

這時(shí)，如果你面臨的第一個(gè)問(wèn)題就是，如何保證在迭代內完成承諾的用戶(hù)故事？

如果你是這樣做的：為了保證完成，開(kāi)始制定計劃時(shí)間表和里程碑，為了在開(kāi)始在迭代前梳理清楚需求，要求有 PRD，并在迭代中規定不要輕易改變迭代內容等，那么，你就真的將敏捷變成了小瀑布了。也許你會(huì )說(shuō)，故事拆分就是為了定義邊界，讓我們知道在迭代中做什么故事。還有燃盡圖，就是要按照計劃的速度進(jìn)行開(kāi)發(fā)。

這樣做，你就真的理解錯了敏捷的含義！你做的就真的不是敏捷！

計劃會(huì )議固然重要，我們花費大量的時(shí)間進(jìn)行故事評估、任務(wù)拆分。目的是什么，快速迭代！這沒(méi)有問(wèn)題，但同時(shí)還有重要的一條，敏捷是快速響應變化高于遵循變化?；氐礁?，為什么要快速迭代，就是因為需求變化的太快。變化快到你剛剛評估完畢一個(gè)用戶(hù)故事，下一刻它有了變化。這時(shí)，難道你還要固守什么迭代不要被打破或更改的規則么？

團隊承諾、響應變化。就是因為這一點(diǎn)，在敏捷中工作的軟件高于詳盡的文檔，并且敏捷中少有過(guò)程文檔，任何產(chǎn)品或故事都是以結果為導向的。面對變化，敏捷是響應變化，而不是追蹤變化。

敏捷團隊的 wiki 中只有最終的結果文檔，并且往往是開(kāi)發(fā)完成之后補的。這時(shí)，你也許會(huì )疑惑，那故事評估和任務(wù)拆分，以及燃盡圖統計還有什么意義？如果故事拆分的任務(wù)沒(méi)有任何工作的指導性，那還有必要拆分么？

回答這個(gè)問(wèn)題，就要說(shuō)下團隊。在敏捷中，團隊的積極性和自主性顯得格外重要，以及相互信任。害群之馬一定要從團隊 T 除。

故事是如何進(jìn)入到迭代中的？故事是產(chǎn)品細粒度劃分之后，按照優(yōu)先級，被團隊評估和初步拆分任務(wù)之后放入迭代的。這就是計劃會(huì )議，其目的只有一個(gè)，統一愿景！其余所有的都是為了幫助完成目標的實(shí)踐！

你會(huì )問(wèn)，團隊承諾、響應變化，我們如何確信團隊能完成迭代中的內容？隨時(shí)可能變得需求和設計，時(shí)刻在變的計劃，在沒(méi)有完成之前又沒(méi)有任何文檔，如何保證團隊能完成？就只憑團隊承諾？對！就是相信！如果是你是領(lǐng)導者，你唯一能做的相信團隊，要做的就是保護團隊！

也可以說(shuō)，敏捷就是如此激勵團隊的！相信團隊，讓團隊發(fā)揮力量解決問(wèn)題，他們能搞定！你不用干涉他們！所以，這也就是為什么說(shuō)，敏捷中，領(lǐng)導只需要關(guān)注看板上空閑的任務(wù)，而不是空閑的人。

但是，你如何做到這點(diǎn)，如何激勵團隊，這在以后咱們會(huì )繼續討論！

所以，至此來(lái)回答前面的問(wèn)題：計劃會(huì )議、故事評估、任務(wù)拆分、站立會(huì )議、回顧會(huì )議、演示會(huì )議，所有的一切，都是為了讓團隊高效服務(wù)的！

可是，你還會(huì )問(wèn)！如果團隊沒(méi)有實(shí)現承諾怎么辦？首先，你要看，團隊是否真的有沒(méi)有全力以赴。如果有，你就要看看迭代的任務(wù)是什么原因，是故事太多，是干擾太多，還是什么問(wèn)題。如果不是，你就要看看團隊出了什么問(wèn)題，如何能激發(fā)團隊的積極性。而這些你都可以在團隊的 Retro 上與團隊一起討論。

總之，如果團隊天天加班都沒(méi)有完成，那真的團隊承諾的太多了。遇到這個(gè)問(wèn)題，要說(shuō)的就是，敏捷提倡工作效率，而不是靠時(shí)間堆出來(lái)的虛假繁忙和過(guò)度勞累！

讓我們在回顧一下 Scrum 的由來(lái)：在橄欖球沖刺之前，教練指揮部署戰術(shù)、制定計劃，但是一旦開(kāi)始之后，就是要靠團隊隨機應變，盡最大的努力完成目標，并不斷地總結每一次成功和失敗。

用最后一句話(huà)進(jìn)行總結：敏捷讓團隊只做最有價(jià)值的！

ps. 你在決定讓團隊做一件事時(shí)，首先想想，這事情真的會(huì )給團隊產(chǎn)生價(jià)值么？團隊會(huì )真的執行么？如果拿不定主意，就讓團隊來(lái)決定吧！