我們使用各種敏捷軟件寫feature，流轉、跟蹤任務，言必談敏捷，然而我們是否真的走對了敏捷？
顯而易見，敏捷是絕對的結果導向，去文檔化，去流程化，高效溝通和合作是究極奧義。
去文檔，敏捷管理者需要維護更爲精細的需求池；去流程，口頭溝通成爲常態，對團隊的耦合度要求更高。
Product Backlog:
backlog 即需求池。待辦事項列表。
Backlog裏面寫什麼：
1.待開發任務。
2.任務優先級。
敏捷需要維護一份詳盡的需求列表。這份列表常常要求scrum持有人（一般是產品經理）對所有待開發事項有深入瞭解，並且能夠把待開發事項分解成更爲細緻的任務。
story board:
在開發領域，故事版是任務流轉的可視化窗口，一般有“待開發”“開發中”“待測試”“返工”“待發布”幾個區塊，所有任務由任務操作者負責流轉至於下一個步驟，這樣任何一個人項目成員都能看到任務的完成情況。
burn down chart（燃盡圖）：
一個sprint內，人/時是一個比較固定的值。在這個時間框架充分安排開發任務，每天進行時間結算，繪製時間燃盡圖。項目成員通過燃盡圖獲知時間進展，若項目燃盡所用時間與預期時間契合，則需求時間預估和安排合理，若不契合則需要在下一個sprint進行調整。
這些概念定義了敏捷各個環節的工作，這些流程和節點是敏捷開展的基礎和保障。
一個誤區：我們用了敏捷管理工具，就敏捷了
隨着敏捷在行業內的不斷融入，各種工具產品層出不窮。國外jira、redmine，Axosoft ，國內的leangoo、禪道，三大家則都有自研的工具，百度的icafe，阿里的aone，騰訊的tapd。
我們在敏捷管理工具上建迭代，建需求，研發、測試等着收到需求流轉的郵件之後開始幹活...任務在測試和研發之間流轉，bug提給研發，研發解決bug.....我們宣稱：我們敏捷化了！
我們習慣於敏捷軟件的便利，拉羣解決一切，然而卻喪失了敏捷的初衷，scrum的本意。
▲Jira的名字來自於哥斯拉
假設我們沒有任何項目協同軟件，敏捷怎麼實施？
設定一個環境，現在沒有任何協同工具可用，但是所有人都坐在一起。有人站起來說，既然這樣，我們不如敏捷吧！
敏捷路徑裏必須有一個項目持有者，制定規劃並把握項目走向。這位PM汪我看你骨骼驚奇，你就擔負起這個責任吧。
另外還有一個關鍵人物SM。SM全稱scrum master，中文稱敏捷教練。一般說來，SM需要由對技術開發以及當前項目明晰的技術經理擔任。
雖然缺少線上工具，但至少要準備一些簡單材料：一卷雙面膠+白紙或一沓便利貼；筆，一面平坦的牆或一塊黑板。
如果還有電腦可用，excel或者word，甚至寫字板都可以，沒有電腦那就白紙好了，總之你得找個地方寫下你的需求池（backlog）
需求池示例(任務名稱、平臺、詳細描述、優先級按照P0-PX逐漸遞減)
確定一個sprint週期的自然天。可以用月/旬/周等時間概念作爲週期，我們選擇一週（五個工作日）作爲一個sprint週期。
按照優先級，從需求池中拉出你認爲應該加入你們一窮二白的第一個sprint裏面去的需求，別太貪心，大概覺得差不多一週左右的開發量就夠了。拉上SM單獨開一次小會。當然不是讓你倆傻站着，你倆要開會。
你們一起通覽需求，SM根據經驗對需求先行分解一遍，比如某需求在開發層面需要分解爲ABC三部分，這三部分就形成三個開發任務。
分解完成後，你得到了一個比較詳細的待開發列表。
正式開始一個sprint開始之前，產品、研發、測試需要一同開一次scrum會議，共同討論本次sprint的功能點。
會上討論什麼：
1.需求討論或技術討論；
2.成員預估需求所需開發時間；
3.需求是否match人力時間，需求排入sprint；
4.交流一下感情。
▲每個任務的預估時間在最後由敏捷教練綜合判定
scrum會後你的工作：
1.整理這個sprint內的需求列表；
2.整理每個需求的預期開發時間；
3.撰寫故事版上的小紙條；
4.把小紙條貼到故事版上；
5.製作一個燃盡圖。
一個改良版的小紙條，寫明開發者、任務描述、預估時間和每日燃盡時間
故事版佈局如下：
一個標準的故事版：最開始所有的小紙條都在“待開發”一欄
到此爲止，你可以開始run起一個sprint。
以爲這就完事了？天真。
接下來你必須來參加每日舉行的項目短會。爲了縮減會議時間，我們一般站着開——所以也叫“站會”，早上上班後或晚上下班前，抽出十到十五分鐘時間，完成它。
▲每日站會
站會都有什麼人蔘加：
1.你（項目持有者）
2.SM
3.其他scrum成員
站會幹什麼：
1.昨天大家分別做了什麼事，遇到了什麼問題，如何解決或尋求解決方案；
2.昨天任務的完成狀態，剩餘多少時間，是否需要進行時間修正（增加時間或減少時間），把已完成的任務流轉到下一環節（把紙條從一個item內撕下，貼到下一個item裏去）；
▲任務進行中，小紙條的示例
3.功能測試後是否有返工；
4.交流一下感情。
站會之後你的工作：
繪製燃盡圖
▲sprint的任務時間隨着sprint的進程逐漸減少
周而復始，完成了一個sprint後，你們開了第二次scrum會。這時議題多了一項:覆盤上一個sprint。
任務未能燃盡；研發返工過多；測試需求淤積.....
針對問題討論解決方案，根據實際情況進行下一個sprint的任務安排。
自此，我們在沒有任何敏捷工具的幫助下，開始了敏捷的旅程。
敏捷了一段時間之後，產品進入正軌，項目拿到撥款，公司拿到投資，你們要擴大團隊規模，新入職的同事想了解下產品和技術細節，你告訴TA：
你要不翻下backlog看看？這個實現你要不看一下代碼？這個字段我也不記得有沒有了....你抓包看下？
新同事一臉懵逼，難道咱們沒有文檔嗎？你自豪地指出：
“我們是敏捷團隊。”
十幾個人八九條槍的階段之後，產品趨於穩定，團隊逐步擴大。無論從內部協調還是外部溝通上對產品流程的正規化和文檔化要求與日俱增。
從短期收益上看，文檔對於敏捷開發是非必須品，並且很有可能會拖慢進度。在一個sprint中，口頭溝通顯然效率更高，每個人都有精確到工時的任務，沒人有等待文檔更新的時間。強調文檔就等於放棄靈活性。
從長期和宏觀上看，文檔對於敏捷團隊和敏捷的實施利大於弊——節省在一些常規問題上的溝通成本，同時降低錯誤的發生概率。對於一個將要長期實施敏捷的團隊來講，文檔讓後續的工作效率更高。
那麼——誰來維護文檔，怎麼維護？
我們挑選其中一個重要的文檔：產品文檔
產品文檔：PM雖然維護backlog、跟SM分解需求、開scrum會、寫小紙條、開站會、畫燃盡圖、還有什麼外部溝通啊......但你要認真把這個文檔維護好。
▲對又是你
產品文檔包括：
1.需求；
2.加入日期；
3.開發版本；
4.呈現和詳細方案。
長久來看，文檔是提高效率的一大利器
文檔的時效性和靈活性遠低於口頭溝通，但卻有它實在的好處。
1.空間上，文檔傳播範圍更廣。規範化和常規化的內容形成文檔可以大大減少溝通成本。尤其在多個系統協作的情況下，跨scrum、跨團隊甚至跨部門的溝通時有發生，文檔的重要性和便捷性不言而喻。
2.時間上，文檔流傳性更好。團隊不是一成不變的，有人離開有人加入。更新換代中，新人快速瞭解系統，老兵傳承研發理念；在更大的時間跨度上，文檔的存在就是對產品歷程的完整追溯，你將不用他人幫助就可以瞭解到產品的大部分面貌甚至全貌。
看起來敏捷方法特別適合產品常規迭代。有一種可能性是，你的產品需要插入一個巨無霸模塊，與其說是模塊倒不如說它幾乎可以成爲一個產品了。你想了想，這麼大個項目怎麼說產品、設計、研發、測試全情投入也得個一兩個月。
還能走敏捷嗎？
注意你的項目時間。有deadline的scrum是帶着鐐銬跳迪斯科，時間節點關乎sprint的大小。
大項目敏捷之前，先得不敏捷幾步。
可能會發生一到多次需求討論會。
團隊必須不厭其煩地理解需求或修正產品經理“天真的幻想”，產品經理使用不斷完善的原型同團隊進行溝通。在最後這次評審邀請項目成員和所有協同團隊，除了敲定的產品功能，技術上需要得到一些初步結論（比如“能不能做”）。
大項目敏捷中：
1.將deadline之前的時間分解爲多個sprint。（deadline之前必須留出一定“出血時間”用以解決時間預估不足的任務、返工任務以及bug)
2.將所有需求分解成任務，開一次全局scrum會。預估時間之後，分散任務到各個sprint中。在時間較緊的情況下，sprint的容量就要相應增加。
▲一個需要加班的sprint
3.進入敏捷流程，常規scrum會、站會，燃盡圖，故事版。未完成任務在scrum會上重新預估時間，滾入新sprint內，以此類推（按時完成sprint內的任務是目標。實在不行我們還有“出血時間”呢）
4.別忘了文檔。
雖然被推崇備至，但敏捷並不是完美的開發方法。敏捷的最大的優勢是靈活，而造成敏捷問題的根源也正是靈活。
1.敏捷是一種流程、方法、理念，甚至信仰。
2 用了敏捷管理軟件不一定就是敏捷。敏捷的初衷是團隊成員能夠更加緊密地配合完成工作，線上的的流轉如果削弱了這種配合性，反倒背離了敏捷的本意。實際上只要有白板紙張和筆，你的團隊就能開始敏捷。
4.我們敏捷了，不是不要文檔了。在外部交流多、世代跨度長的情況下，文檔的必要性顯而易見。長期的面對面溝通最終會導致低效，這也是敏捷缺陷的根源。
5.大項目開發中可以走敏捷，具體問題具體分析，需要根據項目特點制定敏捷計劃。
文章來源：https://mp.weixin.qq.com/s/cJHijlkysR58l-EhD_Q5aw