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

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

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

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

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

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

比如你在周末準(zhǔn)備花一天的時(shí)間給家里做大掃除，那你可能會(huì)先做個(gè)簡(jiǎn)單的計(jì)劃：

1. 清理全屋的如飲料瓶、紙團(tuán)、包裝袋等固體垃圾

2. 將屋內(nèi)凌亂的物件進(jìn)行重新擺放和收納

3. 清洗包含油煙機(jī)、空調(diào)等懸空的家電

4. 清理窗戶(hù)、窗簾、架子等其它懸空的家具和裝飾

5. 用強(qiáng)力清潔劑清理地面縫隙和廚房、衛(wèi)生間角落

6. 完成全屋地板的清掃和吸塵

7. 使用蒸汽拖把完成所有地板的殺菌清理

8. 替換床品四件套，并進(jìn)行洗滌晾曬

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

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

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

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

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

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

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

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

宣言的內(nèi)容包含12條基本的原則：

01.我們最重要的目標(biāo)，是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件使客戶(hù)滿(mǎn)意。

02.欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶(hù)的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化。

03.經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。

04.業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。

05.激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。

06.不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談。

07.可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。

08.敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶(hù)要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。

09.堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。

10.以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。

11.最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)。

12.團(tuán)隊(duì)定期地反思如何能提高成效，并以此調(diào)整自身的舉止表現(xiàn)。

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

1、個(gè)體和互動(dòng)高于流程和工具

2、工作的軟件高于詳盡的文檔

3、客戶(hù)合作高于合同談判

4、響應(yīng)變化高于遵循計(jì)劃

這就是敏捷的雛形也是核心思想，它的目的是樹(shù)立一種解決問(wèn)題的群體共識(shí)，而不是具體執(zhí)行的方法論或行為?？梢灶?lèi)比早年馬克思的《共產(chǎn)主義宣言》，用于塑造一套新的觀念和意識(shí)，來(lái)破除保守勢(shì)力的壓迫和封鎖。所以，當(dāng)學(xué)醫(yī)救不了中……不對(duì)，是當(dāng)瀑布式救不了當(dāng)今的項(xiàng)目進(jìn)度時(shí)，你就可以了解這些宣言?xún)?nèi)容，并以此為價(jià)值觀來(lái)重建項(xiàng)目的工作方式和流程。

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

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

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

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

“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.”

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

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

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

Scrum /skr?m/?這個(gè)詞是一個(gè)橄欖球術(shù)語(yǔ)，表示爭(zhēng)球的動(dòng)作，它沒(méi)有太官方或者大家普遍接受的準(zhǔn)確翻譯，所以一般直接用英文稱(chēng)呼它。

之所以用這個(gè)名字，是因?yàn)榘l(fā)明它的過(guò)程大量借鑒和使用橄欖球的比賽方式作為隱喻，球員需要協(xié)作爭(zhēng)搶到橄欖球，并帶球朝球門(mén)推進(jìn)。這個(gè)過(guò)程不僅需要運(yùn)動(dòng)能力，還需要見(jiàn)招拆招、團(tuán)隊(duì)協(xié)作、快速?zèng)_刺，用盡一切手段朝目標(biāo)邁進(jìn)。

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

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

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

在介紹 Scrum 的流程前，首先要了解 Scrum 將整個(gè)團(tuán)隊(duì)劃分成三個(gè)角色，每個(gè)角色要在正式實(shí)施前確認(rèn)：

• 產(chǎn)品負(fù)責(zé)人 Product Owner整個(gè)產(chǎn)品的直接負(fù)責(zé)人，制定產(chǎn)品的標(biāo)準(zhǔn)、交付日期和審核團(tuán)隊(duì)成果

• 敏捷教練 Scrum Master

  負(fù)責(zé)幫助團(tuán)隊(duì)成員實(shí)踐敏捷的流程，進(jìn)行相關(guān)培訓(xùn)和引導(dǎo)前期的實(shí)踐

• 開(kāi)發(fā)團(tuán)隊(duì) Scrum Team

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

除此之外，Scrum 還會(huì)應(yīng)用三個(gè)重要的項(xiàng)目工具：

• 需求列表 Product Backlog：記錄本次項(xiàng)目相關(guān)的產(chǎn)品需求列表，每一個(gè)需求包含對(duì)應(yīng)的用戶(hù)故事（User Story）

• 迭代列表 Sprint Backlog：挑選出優(yōu)先級(jí)高的要開(kāi)始執(zhí)行的用戶(hù)故事（Sprint）的面板，反應(yīng)進(jìn)行中的需求

• 沖刺燃盡圖 Sprint Burn Down：用于表示時(shí)間和剩余工作量關(guān)系的一個(gè)圖表，更直接的反應(yīng)工作進(jìn)度

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

項(xiàng)目背景：

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

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

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

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

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

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

看起來(lái)很簡(jiǎn)單，但實(shí)際上要完成的工作絕不只是把需求池的需求移動(dòng)到 Scrum 需求列表而已，還要考慮需求的 “顆粒度” 和用戶(hù)故事。

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

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

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

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

但如果加入用戶(hù)故事，那就是在需求下方還要額外增加一段：“用戶(hù)使用這把錘子可以在較狹小的位置打上固線用的墻釘”。當(dāng)這個(gè)要求一出來(lái)以后，應(yīng)該怎么做這把錘子的思路立馬就清晰了，因?yàn)槲覀円鉀Q的問(wèn)題更具體了。

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

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

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

Step2.進(jìn)行產(chǎn)品的需求評(píng)估會(huì)議

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

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

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

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

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

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

Step3.迭代的計(jì)劃會(huì)議

確定出迭代的內(nèi)容后，再進(jìn)一步就是迭代計(jì)劃會(huì) Sprint Plan Meeting。這個(gè)會(huì)議可以緊接著第一需求評(píng)估會(huì)議。目的是針對(duì)選出的 Sprint 做更進(jìn)一步的評(píng)估，包括工時(shí)、目標(biāo)、驗(yàn)收標(biāo)準(zhǔn)等等。還需要將每一條 Sprint 拆解成更細(xì)致的任務(wù)并記錄到對(duì)應(yīng)的任務(wù)列表 Sprint Backlog。

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

這些被分解出來(lái)的任務(wù)，團(tuán)隊(duì)成員就要協(xié)商并認(rèn)領(lǐng)相關(guān)的任務(wù)，展開(kāi)正式的工作。這個(gè)過(guò)程可以以看板的工具進(jìn)行記錄，包含待辦、處理中、已完成三種基本的狀態(tài)。

其中，這些任務(wù)要不要準(zhǔn)備用戶(hù)故事這點(diǎn)就不是硬性的，因?yàn)楹芏喙ぷ鞯男再|(zhì)并不一定是實(shí)現(xiàn)功能，要認(rèn)領(lǐng)任務(wù)的團(tuán)隊(duì)成員自己評(píng)估。而在任務(wù)分解出來(lái)以后，也就可以創(chuàng)建任務(wù)的燃盡圖 Burn Down Chart，用于在后續(xù)反應(yīng) Sprint 的進(jìn)度。

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

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

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

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

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

通過(guò)這種方式，完成整個(gè) Sprint 中的全部任務(wù)為止。

Step5.迭代成果的展示和評(píng)審

當(dāng)一個(gè) Sprint 完成以后，就要進(jìn)入迭代評(píng)審會(huì) Sprint Review Meeting 中，目的是將完成的 Sprint 更具用戶(hù)故事展示給產(chǎn)品負(fù)責(zé)人、產(chǎn)品經(jīng)理、相關(guān)成員評(píng)審。

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

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

在這個(gè)會(huì)議中，Scrum 團(tuán)隊(duì)就可以根據(jù)其他成員的反饋?zhàn)鲇懻?，?duì)需要修改的內(nèi)容創(chuàng)建出新的任務(wù)置入回對(duì)應(yīng)的 Sprint 任務(wù)列表中，回滾到迭代的實(shí)施和執(zhí)行中，然后迎接下一輪的評(píng)審。

只有當(dāng)評(píng)審徹底通過(guò)以后，該 Sprint 才能算完成，然后歸檔進(jìn)入后續(xù) Sprint 的實(shí)施。

Step6.迭代的回顧

除了評(píng)審?fù)猓€有個(gè)關(guān)鍵的會(huì)議叫迭代回顧會(huì)議 Sprint Retrospective Meeting，它和評(píng)審不同的是主要由 Scrum 團(tuán)隊(duì)內(nèi)部成員參加。目的是反思Sprint 過(guò)程中存在的問(wèn)題，類(lèi)似項(xiàng)目復(fù)盤(pán)，花半個(gè)小時(shí)到一個(gè)小時(shí)的時(shí)間討論有哪些地方做的好可以繼續(xù)，哪些地方做的不好需要改進(jìn)。

Sprint 回顧會(huì)議時(shí)間點(diǎn)比較難確定，有的團(tuán)隊(duì)會(huì)每周固定時(shí)間進(jìn)行回顧，有的團(tuán)隊(duì)則是每1-2個(gè) Sprint 完成以后再回顧。

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

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

形成復(fù)盤(pán)的習(xí)慣，才能獲得更好的表現(xiàn)。

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

但既然作為教練，這個(gè)角色的就不能是整個(gè) Scrum 團(tuán)隊(duì)成員中的一員，因?yàn)樗鳛閳F(tuán)隊(duì)成員本身的職責(zé)是和教練沖突的，不僅時(shí)間精力不夠，還容易在裁定上偏向自己不夠客觀。你不能既當(dāng)教練又下場(chǎng)當(dāng)運(yùn)動(dòng)員，所以敏捷教練通常是由外包人員，或熟悉敏捷的非 Scrum 成員擔(dān)任，缺乏敏捷教練的項(xiàng)目是很難有效運(yùn)作起來(lái)的。

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

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

想象一下在平坦的沙漠中駕駛，如果你指定了一個(gè)方向前進(jìn)，不回頭看你永遠(yuǎn)不知道自己有沒(méi)有走彎路……

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

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

如果沒(méi)辦法理解這些項(xiàng)目的問(wèn)題是怎么出現(xiàn)的，瀑布式是怎么變得不適用的，就可以看拓展閱讀下面的兩本書(shū)：

《鳳凰項(xiàng)目》

《敏捷革命》

結(jié)尾

針對(duì)敏捷的分享先完成了上半部分，老實(shí)說(shuō)重新理解敏捷的內(nèi)容花了很長(zhǎng)的時(shí)間，現(xiàn)在的流程和我快10年前掌握的有了很大的變化。同時(shí)因?yàn)槊艚莅舜罅康男g(shù)語(yǔ)名詞，還涉及到中英文翻譯和隱喻上的矛盾，所以解釋起來(lái)特別的費(fèi)勁。

而應(yīng)用敏捷的更多優(yōu)點(diǎn)，和敏捷如何與 DevOps 進(jìn)行結(jié)合實(shí)踐，我會(huì)在后續(xù)的分享中進(jìn)行總結(jié)。

又是我認(rèn)知突飛猛進(jìn)的一天，不知道你們有沒(méi)新的收獲，沒(méi)有也可以，隨便你 ……

我們下篇再賤！

第一期B端產(chǎn)品經(jīng)理入門(mén)課7.3開(kāi)課，剩幾個(gè)報(bào)名名額，還不快來(lái)變強(qiáng)！