? ? ?最近和同事討論敏捷開發如何在進度和文檔之間找到平衡?居然發現大家理解各異。什么是敏捷開發？敏捷開發是否意味著省略很多過程文檔？具體如何實踐？我們一起分享下“知乎”中大家的心得。
以下是總結自知乎的高投票率回答
一、什么是敏捷和敏捷開發
@付聰，中國移動
首先，敏捷開發是一種過程控制論，通俗的說，就是一種做事情的方法。
1. 它適用于軟件，因為軟件是軟的，可以改。要是硬件，改起來就沒那么方便了；
2. 它適用于客戶不知道自己要啥的情況，其實，這樣的客戶占絕大多數。因為客戶不知道要啥，所以你需要不斷幫客戶弄明白他到底想要啥。換句話說，你需要和客戶溝通，合作，傾聽反饋，持續改進；
3. 它適用于競爭激烈的市場，這樣的情況下，趕在競爭對手前交付一個不完美但至少能用的產品非常重要；
4. 它適用于快速變化的市場，你在埋頭造一輛汽車的時候，客戶已經想開飛機滿天飛了，這就需要你能一步步的把汽車改成飛機，還能按時交付；
5. 它適用于在一個地方辦公的小團隊，一般10個人以內。這樣能使敏捷中主要的溝通方式“Face to Face” 是可行的；
其次，敏捷開發是一套工具集，里面有形形色色的工具，你可以不搞敏捷，但可以用那么一兩個來提高工作效率。比如：
1. 站會：三個問題，簡潔有效的小團隊溝通方式；
2. 看板：直觀反映工作進度，反映流程遵守情況，反映流程缺陷；
3. 演示，計劃，反思會：適合于小團隊的協作和優化反饋方式；
4. 用戶故事：站在用戶的角度講需求；
5. 持續集成：隨時高質量交付的基礎，有利于應對變化劇烈的市場；
再其次，敏捷開發是一種企業管理方式。比如：
1. 一線員工可以同時是架構師，Scrum Master，開發工程師，測試工程師，發揮了他的主觀能動性，有利于創新和效率；
2. 敏捷不專注于敏捷團隊中個人的績效考核，而更多的側重于整個團隊的績效，更好的避免了KPI驅動模式；
3. 把大項目拆分成小項目去做（每個Sprint都是一個迭代，需要輸出一個高質量的版本，相當于完成一個小項目），把bug的生存期控制在一個迭代以內，降低了風險，也減少了后期改bug的工作量；
4. 把數十人的大team 分成幾個敏捷團隊，這幾個敏捷團隊的Scrum Master/PO再組成一個更高一級的敏捷團隊，利用站會，反思，看板等等敏捷元素，可以避免數十份郵件也不能解決一個小問題，大家互相踢皮球，溝通不暢的大企業病；
5. 老板可以是最大的PO，他給下面的高管講idea(User Story)，定期檢查Demo，把控產品用戶體驗，負責和外界的溝通合作-----比如喬布斯，360的周鴻祎等；
二、為什么需要敏捷開發
@何明璐，IT領域,網名人月神話
用兩個詞吧，一個是擁抱變化，一個是進度可視。
1.任何軟件類系統或項目，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求。有些需求注定會在設計實現或用戶使用過程中才逐漸出現。要承認軟件開發中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發現，極大的增加了返工或變更成本。敏捷思想里面通過短周期迭代，盡可能早的交付可用的迭代版本來擁抱和適應變化。
2.任何一個軟件項目，需求或設計做完我們并不清楚進度是否真正完成了60%或者更多，任何不是經過測試通過的功能我們都很難把握真正的完成進度情況。因此在敏捷里面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點，如果有60個功能點全部完成并通過驗證和測試，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布里面較難以做到。
(實際上，敏捷是一種思路，敏捷開發是一種實踐。適用于： 周期短，人員較少，早期需求變化頻繁，高風險的項目 ，不適用于： 行業需求較為固定，開發周期長，市場穩定的項目；)
三、敏捷開發是否意味不用寫文檔
@何明璐，IT領域,網名人月神話
如果理解為敏捷開發后不用寫文檔是對敏捷開發很大的誤解。敏捷開發的重點是輕文檔，而不是不要文檔。而這種輕我原來也講過，對于全新的系統開發最好是在有總體方案或架構后再開始輕。
對于怎么理解輕文檔，我建議你好好看下scrum里面的product backlog和sprint backlog。注意這就是文檔的一種形式，而且這種文檔包括了需求，業務場景，實現思路，驗證和測試方法，估算等多個內容的按user story的追溯。而不是按傳統軟件工程思路拆分為多個文檔。
@Blues，scrum sprinting
敏捷開發是重溝通，輕文檔。文檔要適度，既不能成為項目團隊的累贅，也要出現爭議的時候有具可查。
先說需求文檔，分為兩部分，一方面是框架性的需求文檔，對功能、交互方式、出錯或邊界情況的表現進行總體描述，這種文檔不需要過于細致，因為產品經理組織語言寫文檔，開發讀文檔，理解文檔都要消耗大量時間，最好是以總體概括的方式來做，開發在做需求設計時候與產品人員進行頻繁密切溝通，最終一起形成完整文檔，這中間開發、測試人員對于文檔嚴謹性是有很大貢獻，不必要求產品經理全部把邊界細節都寫出來。
另外一方面，作為良好的協作習慣，任何溝通產生的結論都應該存檔！郵件是一種比較好的形式。每次會議結束，問一句結論呢？誰出紀要？不是說文檔不重要，而是通過見面溝通，把需要文檔描述很細節的內容達成共識。
概要設計詳細設計，視需求邏輯難易，規模大小而定。邏輯復雜的項目，概要設計作為幫助開發理解需求的一種手段。大型項目，詳細設計架構設計不可避免。一句話規模的需求，隨便做做就算了。這其中都要不斷的當面溝通！前提是項目成員不能太死板，也有一定磨合，并能力較強。
四、敏捷開發如何實踐
@張碩，敏捷開發的尋路人
想一想我們做的項目有多少部分是做出來永遠不會有人用的，交付出來到客戶那兒才發現根本不是客戶想要的，之后返工也好，客戶重啟項目也罷。
只要付出了努力，卻沒能體現出相應的價值，那就是浪費。
敏捷宣言的那撥人我相信就是想著如何才能盡可能消除浪費，在湊在一起吃吃喝喝滑滑雪之后，總結出來了4條消除浪費的方法：
可工作的軟件》完備的文檔
客戶協作》合同談判
個體與互動》流程和工具
響應變化》遵循計劃
畢竟宣言是需要落地和實施的，說得挺熱鬧的，但我們該如何響應變化，如何客戶協作，如何生產可工作的軟件，都是問題。
所以在統一了思想之后，接下來的實踐各有不同，scrum、精益就應運而生，我們采用迭代的方式響應變化和增進客戶協作，我們用持續交付持續生產可工作的軟件，我們用站會、看板來促進個體與互動。
上面說的東西都是改變生產關系層面的，生產力跟不上的話再好的生產關系都也是桎梏。比如我們的開發流程就是很長，大家代碼質量不高，所以無法做到每個迭代結束后都能有所交付，我們代碼結構不好，所以我們沒法做到快速響應變化。
為了提高生產力，所以又應運而生了一些技術工程實踐：測試驅動、領域驅動、結對編程、持續集成、持續交付、重構等等。以上每一點都大得可以寫一本書。
所以說，敏捷開發的核心思想就是消除浪費，讓我們付出的每一分努力都能有所價值，之后的敏捷宣言和各種流程框架是提出了一種新的生產關系，用來適應大牛程序員們先進的生產力，而如何提升生產力，又產生了很多技術工程實踐。這就是敏捷開發的體系。
