作者 | 耗子吳

最小可行化產(chǎn)品

硅谷創(chuàng)業(yè)家 Eric Rise 在其著作 《精益創(chuàng)業(yè)》 一書中提出了 “精益創(chuàng)業(yè)”（Lean Startup）的理念，其核心思想是，開發(fā)產(chǎn)品時(shí)先做出一個(gè)簡(jiǎn)單的原型——最小化可行產(chǎn)品，然后通過測(cè)試并收集用戶的反饋，快速迭代，不斷修正產(chǎn)品，最終適應(yīng)市場(chǎng)的需求。

假如時(shí)光倒流，來到了2007年，你要從零打造一個(gè)類似如今新浪微博的產(chǎn)品，有一系列需求擺在面前：

用戶注冊(cè)、登錄

• 發(fā)布 140 字的文字微博

• 發(fā)布帶圖片的微博

• 發(fā)布帶視頻的微博

• 發(fā)布投票
  

現(xiàn)在面臨兩個(gè)選擇：

1. 花費(fèi)6個(gè)月的時(shí)間，將以上的需求全部完成后上線，給用戶一個(gè)強(qiáng)大功能的社交網(wǎng)站體驗(yàn)。

2. 花費(fèi)2個(gè)月時(shí)間，完成用戶注冊(cè)登錄和發(fā)布文字的功能，讓用戶最快體驗(yàn)到這個(gè)功能相對(duì)較弱的全新社交產(chǎn)品，在接下來的時(shí)間里，根據(jù)用戶反饋，完善已有功能，同時(shí)開發(fā)上傳圖片的功能，一旦開發(fā)測(cè)試完成，就立即上線。以小步快跑的節(jié)奏不斷完成需求表格中的其他需求。

精益創(chuàng)業(yè)的思想就是采用第二種方案進(jìn)行漸進(jìn)式開發(fā)，這樣的開發(fā)模式有諸多好處：

• 最小可行化產(chǎn)品能在最短的時(shí)間內(nèi)完成開發(fā)，以最快的速度驗(yàn)證用戶需求

• 時(shí)間早意味著具有先發(fā)優(yōu)勢(shì)，方便更早地積累用戶，這一點(diǎn)在社交產(chǎn)品上尤為明顯，后發(fā)的同類產(chǎn)品往往需要背負(fù)“模仿”的帽子

• 能第一時(shí)間聽到用戶的聲音，最大程度避免了產(chǎn)品方向上的錯(cuò)誤

• 敏捷開發(fā)模式（Scrum）實(shí)際上是精益創(chuàng)業(yè)思想的實(shí)踐指南。
  

敏捷開發(fā)模式

敏捷開發(fā)采用循序漸進(jìn)的方法進(jìn)行軟件開發(fā)，把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，分別去完成，在此過程中軟件一直處于可使用狀態(tài)，具體流程如下：

1. 梳理產(chǎn)品需求（Product Backlog）

在開發(fā)之前，一定會(huì)有一個(gè)需求列表，定義了產(chǎn)品在接下來需要具備的特性和功能，一般由產(chǎn)品經(jīng)理來定義，在敏捷流程中，稱這個(gè)人為 Product Owner（PO）。定義 Product Backlog時(shí)，需要遵循INVEST原則，即：

• Independent 獨(dú)立的，盡量和其他需求沒有依賴

• Negotiable 可討價(jià)還價(jià)的

• Valuable 有價(jià)值的

• Estimable 可預(yù)估的

• Small 足夠小，拆分到一個(gè)迭代內(nèi)能完成

• Testable 可被測(cè)試的
  

定義需求的同時(shí)，Product Owner 還需要定義需求的優(yōu)先級(jí)，定義優(yōu)先級(jí)可以借助一個(gè)公式：功能帶來的的價(jià)值除以實(shí)現(xiàn)難度， 這個(gè)值越大則代表優(yōu)先級(jí)越高。

2. 制定迭代計(jì)劃

一般規(guī)定兩周（ 10 個(gè)工作日）為一個(gè)迭代，在迭代開始之前，需要召開迭代計(jì)劃會(huì)制定這一個(gè)迭代的計(jì)劃，把Product Backlog 按照優(yōu)先級(jí)排序，由 PO 為大家講解具體每一個(gè)需求，團(tuán)隊(duì)成員根據(jù)需求的復(fù)雜程度評(píng)估每個(gè)任務(wù)的工作量，當(dāng)前n個(gè)任務(wù)的工作量之和約等于團(tuán)隊(duì)總工時(shí)時(shí)，那么這個(gè)迭代就把 Product Backlog 中前n個(gè)任務(wù)作為這次迭代的任務(wù)，在敏捷中稱之為Sprint Backlog。

團(tuán)隊(duì)總工時(shí)的計(jì)算方法：如果團(tuán)隊(duì)有5個(gè)工程師，一個(gè)迭代的工時(shí)為5*10=50人日，考慮到工作效率和其他的意外情況，再乘以80%，那么最終實(shí)際用于開發(fā)的工時(shí)為40人日，有些團(tuán)隊(duì)會(huì)以小時(shí)作為單位，同理，只需將單位換成小時(shí)。

團(tuán)隊(duì)需要把Sprint Backlog和預(yù)估的時(shí)間寫在便簽紙上，把它們貼在白板上，白板劃分成三大塊：未開始、進(jìn)行中、已完成，當(dāng)然，所有Sprint Backlog的狀態(tài)開始都應(yīng)放在未開始那一列。

3. 迭代執(zhí)行

在迭代進(jìn)行期間，由大家認(rèn)領(lǐng)白板上的 Backlog，每天早上要開一個(gè)每日站會(huì)，時(shí)間在10分鐘以內(nèi)，由大家依次報(bào)告：

我昨天做了什么
今天計(jì)劃要做什么
遇到了哪些問題

每日站會(huì)強(qiáng)迫每個(gè)人向同伴報(bào)告進(jìn)度，迫使大家把問題擺在明面上，盡可能讓信息公開透明。報(bào)告進(jìn)度的同時(shí)移動(dòng)對(duì)應(yīng)的卡片到合適的位置，修改 Backlog 剩余所需要的工作量，Scrum Master 需要統(tǒng)計(jì)剩余所有的工時(shí)，更新到燃盡圖中。當(dāng)燃盡圖的走到 0 ，就意味著完成了這個(gè)迭代中所有的任務(wù)。

燃盡圖

4. 迭代總結(jié)
迭代的最后一天，還有兩個(gè)環(huán)節(jié)要做：成果展示和團(tuán)隊(duì)的內(nèi)部總結(jié)。

成果展示環(huán)節(jié)要求團(tuán)隊(duì)成員在這個(gè)迭代中自己完成的任務(wù)展示給所有人看，除了團(tuán)隊(duì)內(nèi)部所有成員以外，還可以邀請(qǐng)領(lǐng)導(dǎo)等關(guān)心項(xiàng)目進(jìn)展的人。內(nèi)部總結(jié)則只在團(tuán)隊(duì)內(nèi)部進(jìn)行，總結(jié)這個(gè)迭代中做的好的地方以及不好的地方，接下來如何改進(jìn)等。

以上是實(shí)施敏捷開發(fā)模式的大致流程，當(dāng)然，在實(shí)際執(zhí)行過程中會(huì)遇到或多或少的問題，一般需要幾個(gè)迭代的熟悉和磨合。

本文作者 耗子吳 授權(quán)PMCAFF產(chǎn)品經(jīng)理社區(qū)（pmcaff.com）發(fā)布，轉(zhuǎn)載請(qǐng)注明出處。

投稿請(qǐng)發(fā)送至郵箱：tougao@pmcaff.com

商務(wù)合作請(qǐng)聯(lián)系：xiaoxi@pmcaff.com

PMCAFF合作媒體：Chinaz

總結(jié)

以上是生活随笔為你收集整理的PMCAFF | 产品经理如何设计敏捷开发流程？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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