Scrum是迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。Scrum是一種產(chǎn)品開發(fā)過程的模式，包括了過程中的具體實踐和角色定義，它也是一種計劃管理方式。

本文主要介紹Scrum的核心概念和基本實踐，讓大家可以快速在團隊中開始運用Scrum的管理方式，并能初步看到采用Scrum的好處。

一、迭代式增量開發(fā)

迭代式增量開發(fā)是相對于瀑布式開發(fā)而言的。瀑布模型是由W.W.Royce在1970年最初提出的軟件開發(fā)模型，是一種老舊的計算機軟件開發(fā)方法。

瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計劃的需求分析、設(shè)計、編碼、集成、測試、維護的步驟順序進行。瀑布模型一般用于需求固定，開發(fā)周期較長的過程管理。

在互聯(lián)網(wǎng)項目中，首先不滿足瀑布開發(fā)的一個條件就是“需求固定”。一般瀑布模型的開發(fā)過程會持續(xù)半年或者幾年，如果互聯(lián)網(wǎng)早期項目采用傳統(tǒng)的瀑布模型，可能產(chǎn)品沒做出來，公司的錢就燒光了。并且一般的互聯(lián)網(wǎng)產(chǎn)品的需求會經(jīng)常發(fā)生變化，來自老板的、市場的、運營的等等。

瀑布式模型把開發(fā)的角色定義為單向流水線，但Scrum的開發(fā)過程如下圖所示：

[截圖1：Scrum過程管理]

完整的Scrum流程看起來還是很復(fù)雜，不過現(xiàn)在大家沒有必要完全看懂，只要知道Scrum是按照迭代周期（2～4周，也可以是1周）為單位制定開發(fā)計劃和節(jié)奏的。

二、從需求池開始

瀑布模型中認(rèn)為，需求需要事先完整地確定下來，然后形成文檔后交給開發(fā)進行架構(gòu)、數(shù)據(jù)庫、編碼的設(shè)計。需求文檔就是產(chǎn)品出來前的非常細(xì)致的產(chǎn)品文檔。

Scrum模型中認(rèn)為，需求是會隨時變化并且增加的，需求是用需求池（Product Backlog）的方式管理，每次的迭代周期從需求池中挑選當(dāng)前最重要的需求來實現(xiàn)，其他需求等到下次迭代再來處理。Scrum中的需求根據(jù)優(yōu)先級分層次進行管理。

[截圖2：需求優(yōu)先級]

[截圖3：完整的需求池]

關(guān)于需求池的管理，大家可以參考我的另外一篇文章《【十年老產(chǎn)品】教你管理需求池》。產(chǎn)品經(jīng)理將搜集的需求通過需求管理工具進行管理，需求池是進行下一個步驟的前提。

三、計劃會

在進入迭代周期前，首要確定的一件事情是更新自己的版本庫，確定這次即將迭代的版本號。

在每次迭代周期前的固定時間，團隊成員會開一次需求計劃會，這個會議會確定下一個迭代需要完成的任務(wù)的優(yōu)先級。建議參會的人員有：產(chǎn)品經(jīng)理（Product Owner）、Scrum主管、開發(fā)團隊、設(shè)計團隊、測試團隊。如果公司老板有時間，強烈建議讓老板參與計劃會，這是一個“培訓(xùn)”老板產(chǎn)品意識的好機會。

需求池中的需求分為：待處理、開發(fā)中、已驗收三個狀態(tài)。在計劃會中我們把所有“待處理”的需求按照優(yōu)先級排列。

開發(fā)人員確定周期內(nèi)可以完成的需求，將挑選出來的需求指定到新的版本號，這些需求的狀態(tài)會更新為“開發(fā)中”。

需求確定后，由Scrum團隊將需求進一步分解成具體的開發(fā)、設(shè)計、測試的任務(wù)，Scrum團隊成員按照任務(wù)列表進行后續(xù)的任務(wù)分配。

在做工期評估時一定要根據(jù)產(chǎn)品和團隊的具體狀態(tài)留出部分的bug修復(fù)時間。并且工期由Scrum團隊來決定，產(chǎn)品經(jīng)理（包括老板）只是確定優(yōu)先級，解釋需求內(nèi)容，一定不要強制給團隊安排開發(fā)任務(wù)。

1. MVP

MVP（minimum viable product，最小化可行產(chǎn)品）和常規(guī)產(chǎn)品不同，MVP更側(cè)重于對未知市場的勘測，用最小的代價來驗證你的商業(yè)可行性。舉個例子，如果你希望做一個圖片分享網(wǎng)站，那么作為產(chǎn)品原型，MVP僅僅包含最基礎(chǔ)的功能，形態(tài)或許就是一個提交圖片的按鈕以及圖片的展示。

需求分為核心需求、基本需求、擴展需求。MVP只會包含核心需求部分。一般的產(chǎn)品，在前一兩個迭代周期就應(yīng)該完成MVP的產(chǎn)品開發(fā)，讓市場運營人員投放給用戶使用。MVP應(yīng)該作為互聯(lián)網(wǎng)產(chǎn)品的一個起點，后續(xù)的迭代開發(fā)都是以它為內(nèi)核不斷擴展。

2. 需求鎖定

迭代開發(fā)的方式相比瀑布模型加快了開發(fā)團隊的節(jié)奏，其實對開發(fā)團隊的規(guī)劃、設(shè)計能力提出了更高的要求。但是迭代周期不要定得短于一周，需要給團隊留出一個相對完整的時間進行代碼結(jié)構(gòu)的整體優(yōu)化和調(diào)整。

并且這里需要特別指出的是，在進入迭代周期后，所有“開發(fā)中”的需求是鎖定的，不允許隨意增加和修改。當(dāng)然老板和產(chǎn)品經(jīng)理在遇到特殊情況時還是有一定的特權(quán)，但特權(quán)使用是在消耗團隊成員的信任，所以慎用?。?！

四、每日立會

每天早上，Scrum團隊會開一個15分鐘左右的立會（站著開的會，為了限制會議時間）。立會的工作就是將周期內(nèi)需要完成的任務(wù)清單列出來，由每個成員根據(jù)自身的情況來領(lǐng)取當(dāng)天的任務(wù)。所有的任務(wù)分解粒度必須在一天以內(nèi)完成，需要以小時為單位估算。

立會要求每個成員對自己的能力有足夠的認(rèn)識，確定自己能做到什么，是否能按時保質(zhì)完成。

每日立會是產(chǎn)品經(jīng)理不需要參與的。在開發(fā)周期內(nèi)，產(chǎn)品經(jīng)理需要做到的就是需求答疑，同時維護并分析需求池中的新需求。

五、評審會

在迭代周期結(jié)束的評審會時，Scrum團隊向產(chǎn)品經(jīng)理展示迭代周期的開發(fā)成果，產(chǎn)品經(jīng)理對需求進行驗收。

程序員和產(chǎn)品經(jīng)理對同一個問題理解往往是有偏差的，產(chǎn)品經(jīng)理貼近用戶、程序員貼近代碼。任何一個需求最后必須交由產(chǎn)品經(jīng)理驗收合格后才允許上線。

評審會代表迭代周期的結(jié)束，也是可以讓老板參與的一個重要會議。產(chǎn)品經(jīng)理讓老板理解開發(fā)過程，看到開發(fā)結(jié)果是非常重要的環(huán)節(jié)，能夠增強老板對開發(fā)團隊，產(chǎn)品經(jīng)理的信心。

小型團隊也可以考慮把評審會和下一周期的計劃會一起召開。

六、反思會

反思會是Scrum團隊內(nèi)部對上一周期的開發(fā)任務(wù)回顧的會議，產(chǎn)品開發(fā)計劃需要迭代，同時每個成員的成長也需要迭代。通過不斷的反思，逐步加強團隊成員對開發(fā)過程的理解，對自身開發(fā)能力的理解和提高。

Scrum是一套完整的產(chǎn)品開發(fā)理論，我們在剛開始實踐時只需要關(guān)注幾個重要的節(jié)點：迭代周期、需求池、版本庫、計劃會、每日立會、評審會、反思會，其他的地方可以根據(jù)團隊、產(chǎn)品的具體情況靈活變通。最關(guān)鍵的是建立起產(chǎn)品開發(fā)良好的節(jié)奏感和風(fēng)險控制能力。

在后面的文章中，我會進一步介紹Scrum的成員，以及Scrum實踐中必須打通的外部節(jié)點。

本文由 @未明 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。