在一次敏捷課程上，有一些大量有意思的問題，例如 “通過敏捷會讓項(xiàng)目開發(fā)進(jìn)度更快嗎？”。其中一些也是幾年前我想問的，并帶著這些問題加入 ThoughtWorks。終于經(jīng)過各種海內(nèi)外敏捷項(xiàng)目，在一線開發(fā)有了對敏捷更為深刻的認(rèn)識，現(xiàn)在回過頭來聊一聊這些問題。

　　為什么要敏捷？

　　敏捷作為一種軟件開發(fā)方法，或者項(xiàng)目管理方法，很容易被說的玄乎。軟件開發(fā)一定要敏捷才行嗎？實(shí)際上很多項(xiàng)目是可以不采用敏捷開發(fā)方法的。

　　在很多年前的電信、銀行領(lǐng)域，銀行的軟件主要是給行內(nèi)內(nèi)部使用的。那個(gè)時(shí)候的軟件開發(fā)采用瀑布模型，把軟件開發(fā)過程劃分為需求、分析、設(shè)計(jì)、開發(fā)、測試等不同階段。這種開發(fā)方式同樣也能完成所有的任務(wù)，甚至這種開發(fā)方式延續(xù)至今。瀑布模型從出現(xiàn)到持續(xù)到現(xiàn)在已經(jīng)有很長時(shí)間，包括目前大學(xué)的軟件工程專業(yè)的課程內(nèi)容也主要采用這種方式。

　　另外一種開發(fā)方式被大家所忽略，就是一些創(chuàng)業(yè)公司或者小團(tuán)隊(duì)的開發(fā)模式是 “偽敏捷” 的開發(fā)方式。實(shí)際上，這種狀況是既不 “敏捷” 又不“瀑布”，是一種混亂或者無序的開發(fā)模式。用 CMMI 成熟度來描述可能還存在于 “初始級”，其軟件開發(fā)過程是無序的，對過程沒有定義，成功取決于個(gè)人努力或偶然。

　　幾十年前，隨著軟件復(fù)雜性日益增高，無序的這種開發(fā)方式不能滿足需要，于是有了瀑布模型；但是到了今天隨著互聯(lián)網(wǎng)發(fā)展，軟件的需求來源變得越來越不穩(wěn)定，原來的瀑布模型的一個(gè)過程太長了，于是敏捷開發(fā)方式出現(xiàn)了。

　　敏捷開發(fā)方式和瀑布都有過程上的定義和管理，并不是說“響應(yīng)變化”就瞎變化。而是通過迭代將瀑布模型分隔成更小的周期，從而實(shí)現(xiàn)迭代。

　　傳統(tǒng)和敏捷開發(fā)比較

　　在敏捷開發(fā)過程中，每一次迭代時(shí)間可能是 2 周。每個(gè)迭代都能都有交付的工件，如果交付物不能滿足市場或客戶需求。可以在下一個(gè)迭代再一次進(jìn)行分析、調(diào)整和開發(fā)，從而響應(yīng)變化。

　　敏捷會讓項(xiàng)目更快嗎？

　　答案是又不是。

　　先說不是的情況。項(xiàng)目更快不是那種開發(fā)方式來決定的，項(xiàng)目進(jìn)展快的另外一個(gè)意思是時(shí)間用的更少。項(xiàng)目管理有一個(gè)共識，就是項(xiàng)目的成本（投入資源的數(shù)量）、時(shí)間、范圍和質(zhì)量，構(gòu)成了一個(gè)矛盾的三角。

　　在相同的資源投入下，項(xiàng)目進(jìn)度由范圍、質(zhì)量影響。通俗的來說，當(dāng)一個(gè)項(xiàng)目人力資源匱乏時(shí)，一個(gè)人被當(dāng)做兩人使的時(shí)候，敏捷解決不了任何問題。

　　矛盾三角

　　甚至更糟糕的是，由于把一個(gè)長周期的開發(fā)過程，分割成了多個(gè)迭代，敏捷這種開發(fā)方法還要付出額外的開銷。本來只需要整個(gè)周期開一次的會議，變成了每個(gè)迭代都需要開一次；迭代與迭代之間的融合也有額外的開銷。如果適應(yīng)了瀑布方法的團(tuán)隊(duì)，切換到敏捷工作方式后，開會的習(xí)慣還是和原來一樣冗長就會是一個(gè)災(zāi)難。因?yàn)槠俨寄Ｐ褪且粋€(gè)從一而終的方法，所以必須要有完善的文檔和詳細(xì)的設(shè)計(jì)防止返工。但是敏捷團(tuán)隊(duì)按照同樣的方式做的話，就變成了 “白天搞敏捷，晚上修 bug”，敏捷不僅不能讓項(xiàng)目進(jìn)展更快，反而拖慢項(xiàng)目，甚至導(dǎo)致項(xiàng)目失敗。

　　再來說是的情況，敏捷這種開發(fā)方法確實(shí)能加快項(xiàng)目進(jìn)度。其中一個(gè)重要的原因是加快了團(tuán)隊(duì)互動(dòng)的頻率和資源調(diào)度。怎么講呢，在瀑布模型下，進(jìn)度的安排會依賴一種叫做甘特圖的工具。使用甘特圖來排期，有兩個(gè)問題：一個(gè)是某個(gè)人效率低下或請假會較大的影響整體進(jìn)度，另外一個(gè)是下游工作等待時(shí)間長。

　　甘特圖

　　在一個(gè)非常長的周期內(nèi)，瀑布這種模型會產(chǎn)生嚴(yán)重的資源閑置和浪費(fèi)。比如按照計(jì)劃 1 個(gè)月完成開發(fā)工作，1 周完成測試工作。那么測試團(tuán)隊(duì)需要一個(gè)月后才能接手測試工作，有很長的空窗期。敏捷方法把周期縮短了，那么測試團(tuán)隊(duì)就可以在迭代內(nèi)相應(yīng)的縮短空窗期，另外這個(gè)空窗期也可以拿來做一些準(zhǔn)備工作（比如測試用例的編寫）。

　　敏捷會讓項(xiàng)目提高效率嗎？

　　在資源投入不變的情況下其實(shí)上面的問題已經(jīng)反映了效率。另外在補(bǔ)充一點(diǎn)敏捷方法關(guān)于效率的討論，根據(jù)上面的聊到的，敏捷實(shí)際上不能平白無故的讓效率變高，也不能讓一個(gè)人干出兩個(gè)人的活兒。

　　在實(shí)際工作中我們發(fā)現(xiàn)，敏捷方法實(shí)際上是在看不見的地方提高了效率。最大的地方就是避免返工。

　　幾年前在一個(gè)比較大的上市傳統(tǒng)企業(yè)研發(fā)中心待過，我們嘗試過把一些工作進(jìn)行外包。實(shí)際上效果并不好，因?yàn)楣芾硗獍鼛淼某杀居袝r(shí)候還不如自己做。其中一次，我們把前端頁面外包給一個(gè)團(tuán)隊(duì)，我們負(fù)責(zé)出圖，他們負(fù)責(zé)寫出 HTML+CSS。這個(gè)團(tuán)隊(duì)隔一周就會給我們反饋進(jìn)度，一切都很正常。但是最終交付的時(shí)候我們拿到代碼傻眼了，這份代碼全是用 Table 布局的，對我們來說根本沒用，于是只能返工。

　　對于較大型的軟件項(xiàng)目來說可能更糟糕，一個(gè)大的瀑布模型，即使做了充分的設(shè)計(jì)、討論，最終返工的概率非常大。因?yàn)槠俨寄Ｐ褪菑膫鹘y(tǒng)行業(yè)，例如建筑業(yè)吸收而來，建筑行業(yè)的變化并不大、并且是一個(gè)可重復(fù)過程的行業(yè)，同時(shí)并不具備重構(gòu)和修改的能力。但是軟件行業(yè)完全不同，或者說以前的軟件行業(yè)可以按照這種方式做，但現(xiàn)在互聯(lián)網(wǎng)化的產(chǎn)品便不再適應(yīng)了。

　　敏捷軟件開發(fā)的核心邏輯是快速迭代，同時(shí)也具備了快速試錯(cuò)。那么敏捷能避免返工嗎？

　　當(dāng)然還是不能，但讓返工的影響降低到最低，就已經(jīng)是巨大的成功了。

　　創(chuàng)業(yè)公司適合敏捷嗎？

　　先說結(jié)論，創(chuàng)業(yè)公司更適合敏捷開發(fā)。

　　創(chuàng)業(yè)團(tuán)隊(duì)最大的優(yōu)勢是什么？船小好調(diào)頭，人少好溝通。那么創(chuàng)業(yè)團(tuán)隊(duì)的弱勢是什么呢？缺少戰(zhàn)略基礎(chǔ)，大部分時(shí)間在打游擊戰(zhàn)。因此創(chuàng)業(yè)公司適合一個(gè)靈活、輕量級的軟件開發(fā)方法。

　　敏捷是一種輕量級的開發(fā)方法和理念，輕文檔重合作，適合規(guī)模不大的團(tuán)隊(duì)，充分利用溝通成本低的優(yōu)勢 。通過迭代開發(fā)響應(yīng)變化，每一個(gè)迭代能快速上線驗(yàn)證產(chǎn)品設(shè)計(jì)是否合理。

　　所有項(xiàng)目都適合敏捷嗎？

　　不是所有的項(xiàng)目都適合使用敏捷開發(fā)，但趨勢是越來越多的項(xiàng)目適合使用敏捷，甚至不得不敏捷。

　　《大教堂與集市》中談到，我們以為軟件行業(yè)是制造業(yè)，實(shí)際上是服務(wù)業(yè)。和軟件行業(yè)中很像的行業(yè)有兩類，一種是能被重復(fù)的、不容易改變的、過程可控的，例如建筑行業(yè)。另一種是不能被重復(fù)的、可以改變的、過程不可控的，例如醫(yī)藥研發(fā)。

　　我們把這兩種行業(yè)概括為預(yù)定義過程控制和經(jīng)驗(yàn)性過程控制。而過去我們認(rèn)識的軟件可以適合預(yù)定義過程控制，也就是說，立項(xiàng)的第一天就能規(guī)劃到項(xiàng)目結(jié)束，例如 ERP 系統(tǒng)、薪資系統(tǒng)等成熟的行業(yè)方案。而另外一些軟件例如微信、京東等互聯(lián)網(wǎng)產(chǎn)品，毫無疑問是需要隨著經(jīng)驗(yàn)不斷調(diào)整的，這種是經(jīng)驗(yàn)性過程控制。

　　顯而易見，互聯(lián)網(wǎng)產(chǎn)品大多無法采用預(yù)定義過程控制，更加適合經(jīng)驗(yàn)性過程控制。敏捷開發(fā)方法是基于經(jīng)驗(yàn)性過程控制的，因此更加適合變化性強(qiáng)的，過程不可控的軟件開發(fā)項(xiàng)目。

　　軟件行業(yè)是一個(gè)新行業(yè)嗎？如果是的話，我們可以把行業(yè)劃分為金融業(yè)、電信業(yè)、軟件業(yè)。然而現(xiàn)在不是這樣的，軟件業(yè)充當(dāng)了所有行業(yè)信息化的角色，也就是說，未來所有的公司都是軟件公司。5 年以前的銀行可能一個(gè)項(xiàng)目需要 10 名工程師花費(fèi) 1 年的時(shí)間，然后 5 名測試人員花費(fèi) 2 個(gè)月的時(shí)間測試，然后等待領(lǐng)導(dǎo)審批最終交付給運(yùn)維上線。然而目前這種情況變得不能接受，所以越來越多的項(xiàng)目還是轉(zhuǎn)向到敏捷開發(fā)上來。

　　敏捷開發(fā)有什么缺點(diǎn)和不足嗎？

　　敏捷開發(fā)方法一點(diǎn)問題和缺點(diǎn)都沒有嗎？《兩個(gè)凡是》的教訓(xùn)告訴我們，任何優(yōu)秀的的思想和理論都不能迷信。實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)，敏捷這種方法在實(shí)際軟件開發(fā)過程中也會暴露一些問題，但是可以想辦法優(yōu)化流程，盡量降低這些問題的影響。

　　敏捷軟件開發(fā)的特征是增量的，因此每個(gè)迭代都會有新的業(yè)務(wù)分析，新的開發(fā)工作在進(jìn)行。這帶來的一個(gè)問題是，不會有一個(gè)統(tǒng)一的 PRD 文檔出現(xiàn)，最后在項(xiàng)目結(jié)束時(shí)候，交付物中沒有好的文檔。所以敏捷往往強(qiáng)調(diào)可交付的軟件更為重要，在代碼質(zhì)量上下功夫，做到代碼即文檔。

　　敏捷中參與人員都是根據(jù)團(tuán)隊(duì)劃分的，例如獨(dú)立的 PM、BA、DEV，不再存在管理部分、研發(fā)部門。帶來的矛盾是對個(gè)體的要求變高了，有時(shí)候往往一個(gè)團(tuán)隊(duì)中只有一個(gè) BA 或者 UI，對新人挑戰(zhàn)較大。

　　上面提到的敏捷是根據(jù)團(tuán)隊(duì)來劃分的，其組織架構(gòu)和傳統(tǒng)的公司部門形式提出了挑戰(zhàn)。如果企業(yè)的組織架構(gòu)沒有改變，敏捷團(tuán)隊(duì)的存在可能會出現(xiàn)組織架構(gòu)上的矛盾。

　　敏捷實(shí)踐中這么多會議怎么辦？

　　對敏捷這種方法論最大的質(zhì)疑就是會變多了，整體效率被拉低了。所以網(wǎng)友調(diào)侃 “白天搞敏捷，晚上寫代碼”。

　　會議變多的主要原因在前文已經(jīng)分析過了，迭代變多，原來只需要開一次的會議，現(xiàn)在每個(gè)迭代都需要開一次。我待過得一些敏捷團(tuán)隊(duì)中，確實(shí)有一些會議花費(fèi)的時(shí)間比較，敏捷開發(fā)中常見的會議有：每日站會、迭代計(jì)劃、項(xiàng)目回顧會議、產(chǎn)品展示會議等。

　　SPRINT

　　需要特別說明的是，看似這些會比較多，實(shí)際上我們使用瀑布的時(shí)候，項(xiàng)目初期甚至拿了全天的時(shí)間來開會。因此在敏捷中，我們每個(gè)迭代的會議是不是也要像迭代一樣被攤薄呢。

　　如果我們設(shè)定一個(gè)迭代的時(shí)間是兩周，那么迭代計(jì)劃開了一整天就沒有時(shí)間進(jìn)行開發(fā)和干活了。

　　因此各個(gè)會議的推薦時(shí)間是：

• 站會應(yīng)該咋 15 分鐘內(nèi)完成
• 迭代計(jì)劃會議不超過 2 小時(shí)
• 回顧會議不應(yīng)該超過 1 小時(shí)
• 產(chǎn)品展示會議不應(yīng)該超過 30 分鐘

　　如何做到把會議開到如此高效呢？這個(gè)就是對會議主持人的要求了，一些要點(diǎn)如下：

• 站會的目的是更新進(jìn)度和暴露開發(fā)中遇到的問題，不應(yīng)該討論具體的問題。
• 在開迭代計(jì)劃會議之前應(yīng)該準(zhǔn)備好所有的需求分析，如果遇到需求不合理應(yīng)該及時(shí)跳過，不應(yīng)該在會議中尋求解決方案。
• 回顧會議應(yīng)該把重點(diǎn)放到上一次行動(dòng)是否明確執(zhí)行以及需要改進(jìn)點(diǎn)上。可以通過投票討論優(yōu)先級高的改進(jìn)點(diǎn)。
• 參會人員應(yīng)該準(zhǔn)時(shí)到達(dá)。對遲到的容忍就是對準(zhǔn)時(shí)到的人懲罰。
• 每個(gè)會議必須有主持人、會議目標(biāo)、會議準(zhǔn)備，否則會議是冗長而無效的。

　　有了看板、站會、回顧會議就敏捷嗎？

　　敏捷是一種理念和價(jià)值觀，具體的軟件開發(fā)方法主要是 Scrum，那么采用了 Scrum 中的實(shí)踐就敏捷了嗎？

　　第一個(gè)問題中談到，敏捷的關(guān)鍵是迭代和響應(yīng)變化。那么我們把瀑布模型，拆分成多個(gè)迭代進(jìn)行，是不是也是一種敏捷方式了。這種“樸素”的敏捷方式可以沒有看板、站會、回顧。只有需求、分析、開發(fā)、測試這些過程，那么不能說不算敏捷吧。

　　如果我們沒了迭代，再看看我們的看板、站會、回顧會議還是什么：

• 看板，最早是出現(xiàn)于工業(yè)企業(yè)中。是一種在工業(yè)企業(yè)的工序管理中，以卡片為憑證，定時(shí)定點(diǎn)交貨的管理制度。在沒有迭代的情況下，看板只是一種過程可視化工具，對工作過程并沒有任何變化。
• 站會，大多數(shù)公司都有晨會的概念，用于向團(tuán)隊(duì)內(nèi)部同步前一天和當(dāng)天的信息。至于是否是站著開，并不重要。站著開只是為了讓會議更快結(jié)束。
• 回顧會議（Retro），回顧會議在英文中又叫 Retro，作用就是在一個(gè)工作階段后進(jìn)行反思和回顧的會議。這種回顧會議很多公司都會進(jìn)行，比較著名的形式有從美國陸軍流傳而來的 ARR （After Action Review）。

　　敏捷的實(shí)踐很重要，是團(tuán)隊(duì)重要的活動(dòng)，但并不意味著采納了一些敏捷實(shí)踐，團(tuán)隊(duì)就是按照敏捷的方式運(yùn)作。

　　更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks 洞見

總結(jié)

以上是生活随笔為你收集整理的为什么需要敏捷的7个问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。