8000字掃盲干貨！互聯(lián)網(wǎng)人必須掌握的敏捷工作方法

今天討論的話題，也是一個作為互聯(lián)網(wǎng)人繞不開的東西 —— 敏捷。多數(shù)互聯(lián)網(wǎng)團隊都會去搭建敏捷型的項目流程和管理模式，以期獲得更好的投入回報。但是，多數(shù)情況下搭建的敏捷流程都不是非常有效，既不能解決效率的問題，往往還制造了更多問題。

尤其作為非開發(fā)崗位的產(chǎn)品、設計、運營，更是沒辦法搞明白敏捷是什么，只能機械的依據(jù)開發(fā)團隊提出的流程執(zhí)行，全程一頭霧水。而且敏捷是目前面試環(huán)節(jié)中出現(xiàn)頻率越來越高的一個詞匯，在執(zhí)行或想要執(zhí)行敏捷流程的團隊，都希望新招募的成員熟悉這些內容，可以快速融入團隊的文化和流程之中。

所以，這篇分享就是作為敏捷的掃盲，用最簡單的你們能理解的方式來解釋它是什么。

更多掃盲干貨：

一、敏捷 Agile 的基本認識

敏捷的英文原文是 Agile，是本世紀初興起的一種新的項目管理方法論。敏捷不是一個憑空出現(xiàn)的構想，而是基于現(xiàn)實缺陷提出的解題思路，理解敏捷就必須理解它是如何產(chǎn)生的。

首先我們知道，軟件開發(fā)這個行業(yè)在歐美從上世紀 60 年代就已經(jīng)興起了，到 2000 年的時候已經(jīng)經(jīng)歷了快半個世紀的發(fā)展。而在這個階段中，大多數(shù)軟件的開發(fā)都是使用最傳統(tǒng)的 “瀑布式” 流程。

瀑布式指的就是像瀑布一樣從上到下傾瀉落地的過程，它的本質是將項目的待辦工作進行“有序”的規(guī)劃，并依次完成。

比如你在周末準備花一天的時間給家里做大掃除，那你可能會先做個簡單的計劃：

1. 清理全屋的如飲料瓶、紙團、包裝袋等固體垃圾
2. 將屋內凌亂的物件進行重新擺放和收納
3. 清洗包含油煙機、空調等懸空的家電
4. 清理窗戶、窗簾、架子等其它懸空的家具和裝飾
5. 用強力清潔劑清理地面縫隙和廚房、衛(wèi)生間角落
6. 完成全屋地板的清掃和吸塵
7. 使用蒸汽拖把完成所有地板的殺菌清理
8. 替換床品四件套，并進行洗滌晾曬

這就是瀑布式的管理模式，將所有待完成的任務羅列出來，并將它們以必要、合理、有序的方式進行排序。比如清洗懸空的家電、家具必然要在地面清理之前，不然先清理干凈的地板等等又得被弄臟，還要花額外的精力再清理一次地板。

所以一樣的工作目標，如果沒有經(jīng)過合理的計劃就會產(chǎn)生很多工序上的矛盾，制造額外的工作量和時間，降低實現(xiàn)的效率。瀑布式的貢獻，就在于完成指定目標時，能把所有工作內容都分解出來，并制定出合理的流程，提升執(zhí)行的效率，減少所需的時間成本。

這種做法的好處有不少，目前很多行業(yè)也依舊在應用這樣的方法，比如建筑施工、工業(yè)生產(chǎn)、大宗貨運等，都會制定出清晰的瀑布式流程來確保項目的執(zhí)行。早期的軟件行業(yè)當然也使用這樣的流程驅動，先進行需求規(guī)劃，然后設計，再進行開發(fā)，完成測試后發(fā)布。

在早期，軟件項目一方面規(guī)模較小，另一方面發(fā)布很多時候是需要刻錄進軟盤或光盤中，形成一個穩(wěn)定、完整的版本進行備份和流通的。所以項目會有一個比較清晰的工作目標，圍繞這個目標開展項目的規(guī)劃和執(zhí)行，那么自然瀑布式就會成為首選。

但這種做法隨著整個 IT 行業(yè)的發(fā)展開始越來越受限，核心的原因隨著項目規(guī)模越來越大，瀑布式開發(fā)的問題的弊端就越來越明顯，那就是——軟件開發(fā)不是建筑施工，做不到對多數(shù)工程細節(jié)的準確計算和規(guī)劃。有大量的項目在進入到中后期階段才發(fā)現(xiàn)非常基礎的 BUG、漏洞、架構問題，導致項目要推倒重來。而這在正規(guī)的建筑施工中是不允許發(fā)生的，都要封頂了才發(fā)現(xiàn)地基打得不夠深或低樓層承重柱數(shù)量設計少了……

還有一個問題，就是軟件從立項到發(fā)布，能不能實現(xiàn)預期的效果也有非常大的不確定性。一方面用戶不一定買賬證實了項目的方向就是錯誤的，另一方面互聯(lián)網(wǎng)加快了整個市場的發(fā)展節(jié)奏，促使產(chǎn)品需要進入更高頻次的迭代和更新以適應市場的需要。

總結起來就是產(chǎn)品規(guī)模變大項目開發(fā)周期越來越長，而市場又需要越來越短的更新時間和迭代周期的矛盾。這個矛盾從上世紀末到本世紀初愈演愈烈，讓各行業(yè)的開發(fā)工程師都苦不堪言。

于是，在 2001 年 2 月 11 日到 13 日，17 位美國程序界大佬舉行了一次會晤，共同探討軟件開發(fā)的方法和經(jīng)驗，其中最重要的成果，就是起草了敏捷軟件開發(fā)宣言（Manifesto for Agile Software Development），后續(xù)還有幾位成員繼續(xù)合作建立了敏捷聯(lián)盟（Agile Alliance）。

宣言的內容包含 12 條基本的原則：

1. 我們最重要的目標，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意。
2. 欣然面對需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，敏捷過程掌控變化。
3. 經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。
4. 業(yè)務人員和開發(fā)人員必須相互合作，項目中的每一天都不例外。
5. 激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖俊Ｌ峁┧璧沫h(huán)境和支援，輔以信任，從而達成目標。
6. 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
7. 可工作的軟件是進度的首要度量標準。
8. 敏捷過程倡導可持續(xù)開發(fā)。責任人、開發(fā)人員和用戶要能夠共同維持其步調穩(wěn)定延續(xù)。
9. 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
10. 以簡潔為本，它是極力減少不必要工作量的藝術。
11. 最好的架構、需求和設計出自自組織團隊。
12. 團隊定期地反思如何能提高成效，并以此調整自身的舉止表現(xiàn)。

而這 12 條原則可以用 4 個基本的價值觀概括，它們是：

1. 個體和互動高于流程和工具
2. 工作的軟件高于詳盡的文檔
3. 客戶合作高于合同談判
4. 響應變化高于遵循計劃

這就是敏捷的雛形也是核心思想，它的目的是樹立一種解決問題的群體共識，而不是具體執(zhí)行的方法論或行為。所以當瀑布式救不了當今的項目進度時，你就可以了解這些宣言內容，并以此為價值觀來重建項目的工作方式和流程。

當然，不管你是宣言、價值觀、原則還是方法論，都只是一些模糊的概念，需要建立一些更具體的明細方針用于執(zhí)行，否則就只是空喊口號。而在敏捷為基礎或基于敏捷做出改善的項目協(xié)作方式就陸續(xù)被提出，如極限編程（XP）、自適應軟件開發(fā)（ASD）、特征驅動開發(fā)（FDD）、動態(tài)系統(tǒng)開發(fā)（DSDM）和 Scrum 等。

之所以提出不同的方式，是因為不同項目場景的情況差異巨大，在這個項目適用的不代表其它項目也能適用。雖然大家的目標相同，但自有國情在此，蘇聯(lián)走城市包圍農(nóng)村路線，而我們走農(nóng)村包圍城市的路線。

同時，上面提到的幾種最常見的協(xié)作模式，也不代表它們百分百適用于你的項目，要都覺得不合適，團隊可以創(chuàng)建獨立的流程，如果選擇了其中一種模式，也可以根據(jù)項目的實際情況做調整。

比如微軟就在官網(wǎng)就寫到他們的敏捷模式：

“At Microsoft, one such organization uses Agile to build products and services shipped under the Azure DevOps brand. This group has 35 feature teams that release to production every three weeks.”

翻譯過來就是他們在 Azure 這款產(chǎn)品的開發(fā)上就實踐敏捷，將整個項目劃分成 35 個功能團隊，并每三周發(fā)布一次產(chǎn)品。感興趣的還可以在看完本章內容后去訪問下面地址去查看原文，建議用英文原版閱讀或使用 GPT 翻譯不要看官網(wǎng)自動機翻的版本（根本看不懂）。

https://learn.microsoft.com/en-us/devops/plan/scaling-agile

了解敏捷，光知道這些概念肯定不行，所以下面我們肯定要具體學習某一種敏捷方法的細節(jié)，來建立更具體的概念。其中，Scrum 作為敏捷中最有代表性的的方法，是我們主要的學習目標，而其它敏捷方法就需要你們有興趣的話自己去了解了。

二、Scrum的基本介紹

Scrum /skr?m/ 這個詞是一個橄欖球術語，表示爭球的動作，它沒有太官方或者大家普遍接受的準確翻譯，所以一般直接用英文稱呼它。

之所以用這個名字，是因為發(fā)明它的過程大量借鑒和使用橄欖球的比賽方式作為隱喻，球員需要協(xié)作爭搶到橄欖球，并帶球朝球門推進。這個過程不僅需要運動能力，還需要見招拆招、團隊協(xié)作、快速沖刺，用盡一切手段朝目標邁進。

Scrum 這個詞是在 1986 年被兩個日本管理學者竹內弘高和野中郁次郎首次用于形容企業(yè)的管理上，但那時僅僅是描述了某種團隊管理的理念，且不是針對軟件開發(fā)流程。而后來這則信息在 90 年代被 Scrum 的主要創(chuàng)始人杰夫·薩瑟蘭看到（敏捷宣言起草人之一），就用來命名自己所建立的團隊協(xié)作方法上。

在隨后的幾年中，杰夫·薩瑟蘭持續(xù)優(yōu)化 Scrum 的內容和細節(jié)，直至敏捷宣言提出，它自然而然也就成為了敏捷的主要方法，然后才被廣泛認識和應用。

我們目前學習的 Scrum 方法，是經(jīng)過近 30 年改良和驗證的版本（現(xiàn)在和我最早看到的版本就有很大的不同），其中有很多看似沒有道理或者多余的步驟，都有充分的存在理由與必要性，需要抱著開放的心態(tài)去理解它們。

在介紹 Scrum 的流程前，首先要了解 Scrum 將整個團隊劃分成三個角色，每個角色要在正式實施前確認：

產(chǎn)品負責人 Product Owner

整個產(chǎn)品的直接負責人，制定產(chǎn)品的標準、交付日期和審核團隊成果

敏捷教練 Scrum Master

負責幫助團隊成員實踐敏捷的流程，進行相關培訓和引導前期的實踐

開發(fā)團隊 Scrum Team

產(chǎn)品的相關執(zhí)行人員，以開發(fā)成員為主，也可以適當引入其它崗位

除此之外，Scrum 還會應用三個重要的項目工具：

需求列表 Product Backlog：

記錄本次項目相關的產(chǎn)品需求列表，每一個需求包含對應的用戶故事（User Story）

迭代列表 Sprint Backlog：

挑選出優(yōu)先級高的要開始執(zhí)行的用戶故事（Sprint）的面板，反應進行中的需求

沖刺燃盡圖 Sprint Burn Down：

用于表示時間和剩余工作量關系的一個圖表，更直接的反應工作進度。

光看這些東西肯定是很讓人費解的，所以下面我就要具體來介紹 Scrum 的執(zhí)行流程了。

項目背景：

開發(fā)一個電商管理系統(tǒng)，產(chǎn)品經(jīng)理們已經(jīng)和領導、業(yè)務人員確定完相關的需求和明細，羅列了一大堆的需求出來，全部做完所需的時間至少需要半年起。在開始 Scrum 前，確定了其中一個產(chǎn)品經(jīng)理作為 Scrum 的項目負責人，一個運維作為敏捷教練，參與的所有設計師和前后端程序員都是 Scrum 團隊成員。

Step1.搭建 Scrum 產(chǎn)品需求列表

首先第一步，就是創(chuàng)建本次 Scrum 中的產(chǎn)品需求列表 Product Backlog，而這個產(chǎn)品需求列表和上面說的整個項目的需求列表是不同的。

原因是 Scrum 是有一定時間和范圍限制，如果工作量過大，所需時間過長，會對整個流程造成很多負面的影響，且不利于敏捷本身的特性。所以項目負責人需要和其他產(chǎn)品、敏捷教練、主要負責人共同商議，從總的需求列表中拆分出一部分需求作為本次 Scrum 完成的對象。

通常，第一個 Scrum 要完成的工作肯定是項目中最重要的模塊，可以以維持核心業(yè)務運作的標準進行篩選，比如創(chuàng)建商品、創(chuàng)建分類、用戶管理、交易管理、物流管理等。而社交、網(wǎng)站統(tǒng)計、優(yōu)惠券、分銷這類功能就可以留給下個 Scrum 來完成。

產(chǎn)品負責人要把這些篩選出來的需求進行整理，放到一個列表中，作為本次 Scrum 的全部需求。可以是現(xiàn)實世界的任務看板，也可以是線上的表格工具。

看起來很簡單，但實際上要完成的工作絕不只是把需求池的需求移動到 Scrum 需求列表而已，還要考慮需求的 “顆粒度” 和用戶故事。

顆粒度指的就是需求的規(guī)模，需要耗費多少人力去完成。在原始的需求中，往往有一些需求的顆粒度很大，絕對不是一兩天或一周內能完成的。比如實現(xiàn)物流管理模塊，就得包含物流列表、查詢篩選、物流詳情、物流進度、費用結算等一系列操作和服務。

所以，產(chǎn)品負責人要在這個階段直接對這些顆粒度很大的需求直接做拆解，把它們拆解成較小的需求，或者將一些非常零碎的需求合并成一個較大的需求，每個需求的顆粒度就應該是 2-5 天可以完成的級別。

然后就是整理這些需求的“用戶故事”，這是 Scrum 中最重要的特性之一，即每條需求在具體應用場景中所實現(xiàn)的服務和功能。這里最大的思維挑戰(zhàn)就是已經(jīng)有了需求，為什么還需要用戶故事？

原因就是需求僅僅只是一種死板的任務描述，比如要造一把錘子，以需求描述的話就是做個鐵錘頭，把它固定到木手柄之上，作為執(zhí)行人我只要實現(xiàn)這個要求就可以了，至于后面錘頭穩(wěn)不穩(wěn)，好不好用，是用于大型鉚釘還是小圖釘?shù)膱鼍熬筒粴w我管了。

但如果加入用戶故事，那就是在需求下方還要額外增加一段：“用戶使用這把錘子可以在較狹小的位置打上固線用的墻釘”。當這個要求一出來以后，應該怎么做這把錘子的思路立馬就清晰了，因為我們要解決的問題更具體了。

而用戶故事的應用在這里同理，雖然產(chǎn)品經(jīng)理在一些需求描述中會提供非常具體、清晰的描述，但不可能覆蓋所有需求。而產(chǎn)品負責人在整理 Scrum 需求列表時，就要確保每條需求都有清晰的用戶故事并做出記錄。比如使用表格工具管理需求列表，那就可以增加一個 “用戶故事” 的表頭，將每條需求對應的用戶故事填寫進該列。

用戶故事是每條需求的存在的價值，也是后續(xù)分配任務時每一個團隊成員所要完成的具體工作——不是把需求上的功能做完，而是實現(xiàn)用戶故事中描述的內容。

完成上述內容以后，就可以進入到下一步環(huán)節(jié)中。

Step2.進行產(chǎn)品的需求評估會議

第二個環(huán)節(jié)叫需求評估會議，在產(chǎn)品負責人整理完產(chǎn)品需求列表以后，就需要邀請團隊成員一起來探討本次 Scrum 的所有需求了，和產(chǎn)品經(jīng)理的需求評審會議有點類似，但不完全相同。

這個會議的主旨，一方面是產(chǎn)品負責人和所有團隊成員展示和說明需求列表中的所有內容，另一方面，需要團隊成員針對需求的可行性、優(yōu)先級、工作量、用戶故事發(fā)表建議，并挑選出下階段要解決的需求有哪些。

在開發(fā)項目實施中，并不一定需求本身的權重最高優(yōu)先級就最高，有時候一些看起來不重要的模塊不做完，后面的其它需求就無法實現(xiàn)。所以哪些工作應該優(yōu)先開展，就需要團隊成員共同參與進來討論。

而需要篩選出來的需求數(shù)量也不能太多，必須是馬上能夠開展的需求，而不是一下選了一籮筐出來進行積壓，這樣會擾亂團隊成員執(zhí)行的關注和效率。

同時，每一條要開展的需求，就可以統(tǒng)一稱呼它為一個 Sprint，Sprint 直譯叫沖刺，也是橄欖球的一個術語，含義是要準備沖刺去完成的工作。但這個工作的完成不是一次線性的實踐而已，而是在后續(xù)的流程中加入檢驗，從而讓工作進行回滾、修改、優(yōu)化的多次調整，再實現(xiàn)最終的目標。

所以，在 Scrum 的環(huán)境中，每個 Sprint 也會被稱為是一個迭代，不管是沖刺還是迭代指的都是 Sprint，盡量在學習和溝通中使用英文原單詞，才不容易混淆。

Step3.迭代的計劃會議

確定出迭代的內容后，再進一步就是迭代計劃會 Sprint Plan Meeting。這個會議可以緊接著第一需求評估會議。目的是針對選出的 Sprint 做更進一步的評估，包括工時、目標、驗收標準等等。還需要將每一條 Sprint 拆解成更細致的任務并記錄到對應的任務列表 Sprint Backlog。

比如物流進度更新這個 Sprint，就包含前端的樣式實現(xiàn)、物流訂單的創(chuàng)建、倉庫系統(tǒng)接口匹配、物流公司接口匹配、完結歸檔等多個功能模塊。每個功能模塊的顆粒度都應該在 1 天內完成，如果有明顯要超出 1 個工作日都完成不了的，就需要做進一步的分解。比如物流公司接口匹配之前沒有經(jīng)驗，還需要拆解成：選擇方案、查看第三方文檔、實現(xiàn)接口聯(lián)調等。

這些被分解出來的任務，團隊成員就要協(xié)商并認領相關的任務，展開正式的工作。這個過程可以以看板的工具進行記錄，包含待辦、處理中、已完成三種基本的狀態(tài)。

其中，這些任務要不要準備用戶故事這點就不是硬性的，因為很多工作的性質并不一定是實現(xiàn)功能，要認領任務的團隊成員自己評估。而在任務分解出來以后，也就可以創(chuàng)建任務的燃盡圖 Burn Down Chart，用于在后續(xù)反應 Sprint 的進度。

Step4.迭代的實施和執(zhí)行

既然手上已經(jīng)認領了項目，那么接下來就要正式進入項目實踐環(huán)節(jié)了。每個團隊成員同一個時間段手上應該只有一個任務在執(zhí)行，在完成后再切換到下一個任務，而不是在每次執(zhí)行前思考自己應該做哪個任務，也不會一個任務做一半輕易就切換到其它任務上去。

同時，實施環(huán)境里還要開展每日的站會 Daliy Scrum Meeting，每天早上（最好是早上）到公司后，用 15 分鐘的時間相互分享當前工作的狀態(tài)，包含昨天完成了什么，今天準備做什么，有什么問題需要協(xié)助，如果手動沒有具體的任務，可以簡單討論下一個任務做什么。

站會的作用不是變成官僚式的日報應付領導，而是有效的反應自己的工作進展以及發(fā)出需要求助的信號。這樣其它成員才能知道你的工作產(chǎn)出（是否對自己的工作有影響），并了解你需要哪些幫助可以提供給你，促進團隊成員的溝通和協(xié)作，而不是僅僅使用線上工具讓每個成員都成為孤島，不符合敏捷中個體和互動高于流程和工具的原則。

每一次 Sprint 的執(zhí)行，就是完成其中全部的任務，而燃盡圖在這個階段的作用就是幫助我們監(jiān)控進度，每天站會產(chǎn)品負責人都可以簡單展示和匯報下燃盡圖的狀況，讓團隊成員對進度有大致的了解。

通過這種方式，完成整個 Sprint 中的全部任務為止。

Step5.迭代成果的展示和評審

當一個 Sprint 完成以后，就要進入迭代評審會 Sprint Review Meeting 中，目的是將完成的 Sprint 更具用戶故事展示給產(chǎn)品負責人、產(chǎn)品經(jīng)理、相關成員評審。

這是個非常重要的環(huán)節(jié)，也是 Scrum 和瀑布流最大的區(qū)別，在過去軟件開發(fā)的評審通常是最后階段才進行，但 Scrum 中將評審提早到完成每一個需求模塊完成后，開發(fā)團隊就需要交付并進行演示用于評審。這么做的目的就是為了提早能發(fā)現(xiàn)問題，而不是把每個模塊積累下來的問題合并到最后再解決。在編程項目中，如果問題積壓過多，就會導致修改難度指數(shù)級上漲，所以要盡量避免這種不可控的風險。

同時，提早評審還有個非常大的優(yōu)點，就是可以發(fā)現(xiàn)需求本身的缺陷，很多產(chǎn)品需求在構思的時候是一回事，真的落地演示時感受到的是另一回事，所以就產(chǎn)生需要修改和優(yōu)化它的建議，讓這個需求可以更完善。

在這個會議中，Scrum 團隊就可以根據(jù)其他成員的反饋做討論，對需要修改的內容創(chuàng)建出新的任務置入回對應的 Sprint 任務列表中，回滾到迭代的實施和執(zhí)行中，然后迎接下一輪的評審。

只有當評審徹底通過以后，該 Sprint 才能算完成，然后歸檔進入后續(xù) Sprint 的實施。

Step6.迭代的回顧

除了評審外，還有個關鍵的會議叫迭代回顧會議 Sprint Retrospective Meeting，它和評審不同的是主要由 Scrum 團隊內部成員參加。目的是反思 Sprint 過程中存在的問題，類似項目復盤，花半個小時到一個小時的時間討論有哪些地方做的好可以繼續(xù)，哪些地方做的不好需要改進。

Sprint 回顧會議時間點比較難確定，有的團隊會每周固定時間進行回顧，有的團隊則是每 1-2 個 Sprint 完成以后再回顧。

同時，Sprint 回顧會議可以和需求評估、迭代計劃會議做合并，每次完成回顧后，確定后續(xù)要完成的 Sprint，并拆解任務進行分配。

不管用什么形式還是頻率，回顧流程是必不可少的。

形成復盤的習慣，才能獲得更好的表現(xiàn)。

以上就是 Scrum 的基本流程了，經(jīng)過這么長的解釋你們肯定會想這也太麻煩了，光靠記住這流程就很困難了，遑論落地執(zhí)行。所以，前面提到的角色——敏捷教練 Scrum Master 就是用來解決這個問題的，敏捷教練本身存在的目的，就是要協(xié)助用戶執(zhí)行敏捷的流程，提醒團隊成員每個階段應該做什么，在流程的執(zhí)行上有什么問題并給出改進建議，確保敏捷流程能正確有效的應用起來。

但既然作為教練，這個角色的就不能是整個 Scrum 團隊成員中的一員，因為他作為團隊成員本身的職責是和教練沖突的，不僅時間精力不夠，還容易在裁定上偏向自己不夠客觀。你不能既當教練又下場當運動員，所以敏捷教練通常是由外包人員，或熟悉敏捷的非 Scrum 成員擔任，缺乏敏捷教練的項目是很難有效運作起來的。

最后，總結一下 Scrum 的特點。不管它有什么樣的條例還是原則工具，說到底它的本質就是將整個項目切割成多個模塊，且做一部分，就檢查一部分，一邊做一邊發(fā)現(xiàn)問題改進問題，這樣能盡可能提升項目交付的效率和質量。

而瀑布流雖然看起來在流程方法上簡單，但是把檢查工作留到最后在軟件行業(yè)是不可行的，在沒看見開發(fā)團隊交付可演示的版本之前，你永遠不知道他們會開發(fā)出什么東西，生產(chǎn)什么樣的問題或 BUG。也不會知道上線前的修復和測試要浪費多少額外的精力和時間。

想象一下在平坦的沙漠中駕駛，如果你指定了一個方向前進，不回頭看你永遠不知道自己有沒有走彎路……

敏捷的方法是反直覺的，因為它是在大量項目挫折中摸索出來的一種解決方式，是完全根據(jù)真實的軟件開發(fā)場景定制的。而很多企業(yè)的管理者在使用傳統(tǒng)的項目管理經(jīng)驗照搬到軟件行業(yè)，就會發(fā)現(xiàn)完全行不通，這也造成了傳統(tǒng)企業(yè)開發(fā)軟件的效率極其低下，這在 B 端領域尤其嚴重。

很多時候并不是這些企業(yè)的開發(fā)水平差，而是沿用過時的項目管理模式，就只能以犧牲開發(fā)效率為代價。

如果沒辦法理解這些項目的問題是怎么出現(xiàn)的，瀑布式是怎么變得不適用的，就可以看拓展閱讀下面的兩本書：《鳳凰項目》、《敏捷革命》

結尾

針對敏捷的分享先完成了上半部分，老實說重新理解敏捷的內容花了很長的時間，現(xiàn)在的流程和我快 10 年前掌握的有了很大的變化。同時因為敏捷包含了大量的術語名詞，還涉及到中英文翻譯和隱喻上的矛盾，所以解釋起來特別的費勁。

而應用敏捷的更多優(yōu)點，和敏捷如何與 DevOps 進行結合實踐，我會在后續(xù)的分享中進行總結。

又是我認知突飛猛進的一天，不知道你們有沒新的收獲，沒有也可以，隨便你 ……

我們下篇再賤！

歡迎關注作者的微信公眾號：「超人的電話亭」