? ? ?最近和同事討論敏捷開發(fā)如何在進度和文檔之間找到平衡?居然發(fā)現(xiàn)大家理解各異。什么是敏捷開發(fā)泳赋？敏捷開發(fā)是否意味著省略很多過程文檔净宵？具體如何實踐？我們一起分享下“知乎”中大家的心得晦墙。

以下是總結(jié)自知乎的高投票率回答

一、什么是敏捷和敏捷開發(fā)

@付聰肴茄，中國移動

首先晌畅，敏捷開發(fā)是一種過程控制論，通俗的說寡痰，就是一種做事情的方法抗楔。

1. 它適用于軟件棋凳，因為軟件是軟的，可以改谓谦。要是硬件贫橙，改起來就沒那么方便了贪婉；

2. 它適用于客戶不知道自己要啥的情況反粥，其實，這樣的客戶占絕大多數(shù)疲迂。因為客戶不知道要啥才顿，所以你需要不斷幫客戶弄明白他到底想要啥。換句話說尤蒿，你需要和客戶溝通郑气，合作，傾聽反饋腰池，持續(xù)改進尾组；

3. 它適用于競爭激烈的市場，這樣的情況下示弓，趕在競爭對手前交付一個不完美但至少能用的產(chǎn)品非常重要讳侨；

4. 它適用于快速變化的市場，你在埋頭造一輛汽車的時候奏属，客戶已經(jīng)想開飛機滿天飛了跨跨，這就需要你能一步步的把汽車改成飛機，還能按時交付囱皿；

5. 它適用于在一個地方辦公的小團隊勇婴，一般10個人以內(nèi)。這樣能使敏捷中主要的溝通方式“Face to Face” 是可行的嘱腥；

其次耕渴，敏捷開發(fā)是一套工具集，里面有形形色色的工具齿兔，你可以不搞敏捷橱脸，但可以用那么一兩個來提高工作效率。比如：

1. 站會：三個問題愧驱，簡潔有效的小團隊溝通方式慰技；

2. 看板：直觀反映工作進度，反映流程遵守情況组砚，反映流程缺陷吻商；

3. 演示，計劃糟红，反思會：適合于小團隊的協(xié)作和優(yōu)化反饋方式艾帐；

4. 用戶故事：站在用戶的角度講需求乌叶；

5. 持續(xù)集成：隨時高質(zhì)量交付的基礎(chǔ)，有利于應對變化劇烈的市場柒爸；

再其次准浴，敏捷開發(fā)是一種企業(yè)管理方式。比如：

1. 一線員工可以同時是架構(gòu)師捎稚，Scrum Master乐横，開發(fā)工程師，測試工程師今野，發(fā)揮了他的主觀能動性葡公，有利于創(chuàng)新和效率；

2. 敏捷不專注于敏捷團隊中個人的績效考核条霜，而更多的側(cè)重于整個團隊的績效催什，更好的避免了KPI驅(qū)動模式；

3. 把大項目拆分成小項目去做（每個Sprint都是一個迭代宰睡，需要輸出一個高質(zhì)量的版本蒲凶，相當于完成一個小項目），把bug的生存期控制在一個迭代以內(nèi)拆内，降低了風險旋圆，也減少了后期改bug的工作量；

4. 把數(shù)十人的大team 分成幾個敏捷團隊矛纹，這幾個敏捷團隊的Scrum Master/PO再組成一個更高一級的敏捷團隊臂聋，利用站會，反思或南，看板等等敏捷元素孩等，可以避免數(shù)十份郵件也不能解決一個小問題，大家互相踢皮球采够，溝通不暢的大企業(yè)惨薹健；

5. 老板可以是最大的PO蹬癌，他給下面的高管講idea(User Story)权她，定期檢查Demo，把控產(chǎn)品用戶體驗逝薪，負責和外界的溝通合作-----比如喬布斯隅要，360的周鴻祎等；

二董济、為什么需要敏捷開發(fā)

@何明璐步清，IT領(lǐng)域,網(wǎng)名人月神話

用兩個詞吧，一個是擁抱變化，一個是進度可視廓啊。

1.任何軟件類系統(tǒng)或項目欢搜，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求谴轮。有些需求注定會在設(shè)計實現(xiàn)或用戶使用過程中才逐漸出現(xiàn)炒瘟。要承認軟件開發(fā)中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發(fā)現(xiàn)第步，極大的增加了返工或變更成本疮装。敏捷思想里面通過短周期迭代，盡可能早的交付可用的迭代版本來擁抱和適應變化雌续。

2.任何一個軟件項目斩个，需求或設(shè)計做完我們并不清楚進度是否真正完成了60%或者更多，任何不是經(jīng)過測試通過的功能我們都很難把握真正的完成進度情況驯杜。因此在敏捷里面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點做个，如果有60個功能點全部完成并通過驗證和測試鸽心，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布里面較難以做到居暖。

(實際上顽频，敏捷是一種思路，敏捷開發(fā)是一種實踐太闺。適用于： 周期短糯景，人員較少，早期需求變化頻繁省骂，高風險的項目 蟀淮，不適用于： 行業(yè)需求較為固定，開發(fā)周期長钞澳，市場穩(wěn)定的項目怠惶；)

三、敏捷開發(fā)是否意味不用寫文檔

@何明璐轧粟，IT領(lǐng)域,網(wǎng)名人月神話

如果理解為敏捷開發(fā)后不用寫文檔是對敏捷開發(fā)很大的誤解策治。敏捷開發(fā)的重點是輕文檔，而不是不要文檔兰吟。而這種輕我原來也講過通惫，對于全新的系統(tǒng)開發(fā)最好是在有總體方案或架構(gòu)后再開始輕。

對于怎么理解輕文檔混蔼，我建議你好好看下scrum里面的product backlog和sprint backlog履腋。注意這就是文檔的一種形式，而且這種文檔包括了需求拄丰，業(yè)務場景府树，實現(xiàn)思路俐末，驗證和測試方法，估算等多個內(nèi)容的按user story的追溯奄侠。而不是按傳統(tǒng)軟件工程思路拆分為多個文檔卓箫。

@Blues，scrum sprinting

敏捷開發(fā)是重溝通垄潮，輕文檔烹卒。文檔要適度，既不能成為項目團隊的累贅弯洗，也要出現(xiàn)爭議的時候有具可查旅急。

先說需求文檔，分為兩部分牡整，一方面是框架性的需求文檔藐吮，對功能、交互方式逃贝、出錯或邊界情況的表現(xiàn)進行總體描述谣辞，這種文檔不需要過于細致，因為產(chǎn)品經(jīng)理組織語言寫文檔沐扳，開發(fā)讀文檔泥从，理解文檔都要消耗大量時間，最好是以總體概括的方式來做沪摄，開發(fā)在做需求設(shè)計時候與產(chǎn)品人員進行頻繁密切溝通躯嫉，最終一起形成完整文檔，這中間開發(fā)杨拐、測試人員對于文檔嚴謹性是有很大貢獻祈餐，不必要求產(chǎn)品經(jīng)理全部把邊界細節(jié)都寫出來。

另外一方面戏阅，作為良好的協(xié)作習慣昼弟，任何溝通產(chǎn)生的結(jié)論都應該存檔！郵件是一種比較好的形式奕筐。每次會議結(jié)束舱痘，問一句結(jié)論呢？誰出紀要离赫？不是說文檔不重要芭逝，而是通過見面溝通，把需要文檔描述很細節(jié)的內(nèi)容達成共識渊胸。

概要設(shè)計詳細設(shè)計旬盯，視需求邏輯難易，規(guī)模大小而定。邏輯復雜的項目胖翰，概要設(shè)計作為幫助開發(fā)理解需求的一種手段接剩。大型項目，詳細設(shè)計架構(gòu)設(shè)計不可避免萨咳。一句話規(guī)模的需求懊缺，隨便做做就算了。這其中都要不斷的當面溝通培他！前提是項目成員不能太死板鹃两，也有一定磨合，并能力較強舀凛。

四俊扳、敏捷開發(fā)如何實踐

@張碩，敏捷開發(fā)的尋路人

想一想我們做的項目有多少部分是做出來永遠不會有人用的猛遍，交付出來到客戶那兒才發(fā)現(xiàn)根本不是客戶想要的馋记，之后返工也好，客戶重啟項目也罷螃壤。

只要付出了努力抗果，卻沒能體現(xiàn)出相應的價值，那就是浪費奸晴。

敏捷宣言的那撥人我相信就是想著如何才能盡可能消除浪費，在湊在一起吃吃喝喝滑滑雪之后日麸，總結(jié)出來了4條消除浪費的方法：

可工作的軟件》完備的文檔

客戶協(xié)作》合同談判

個體與互動》流程和工具

響應變化》遵循計劃

畢竟宣言是需要落地和實施的寄啼，說得挺熱鬧的，但我們該如何響應變化代箭，如何客戶協(xié)作墩划，如何生產(chǎn)可工作的軟件，都是問題嗡综。

所以在統(tǒng)一了思想之后乙帮，接下來的實踐各有不同，scrum极景、精益就應運而生察净，我們采用迭代的方式響應變化和增進客戶協(xié)作，我們用持續(xù)交付持續(xù)生產(chǎn)可工作的軟件盼樟，我們用站會氢卡、看板來促進個體與互動。

上面說的東西都是改變生產(chǎn)關(guān)系層面的晨缴，生產(chǎn)力跟不上的話再好的生產(chǎn)關(guān)系都也是桎梏译秦。比如我們的開發(fā)流程就是很長，大家代碼質(zhì)量不高，所以無法做到每個迭代結(jié)束后都能有所交付筑悴，我們代碼結(jié)構(gòu)不好们拙，所以我們沒法做到快速響應變化。

為了提高生產(chǎn)力阁吝，所以又應運而生了一些技術(shù)工程實踐：測試驅(qū)動砚婆、領(lǐng)域驅(qū)動、結(jié)對編程求摇、持續(xù)集成射沟、持續(xù)交付、重構(gòu)等等与境。以上每一點都大得可以寫一本書验夯。

所以說，敏捷開發(fā)的核心思想就是消除浪費摔刁，讓我們付出的每一分努力都能有所價值挥转，之后的敏捷宣言和各種流程框架是提出了一種新的生產(chǎn)關(guān)系，用來適應大牛程序員們先進的生產(chǎn)力共屈，而如何提升生產(chǎn)力绑谣，又產(chǎn)生了很多技術(shù)工程實踐。這就是敏捷開發(fā)的體系拗引。