今天我們將從從產(chǎn)品目標到產(chǎn)品路線圖、從產(chǎn)品路線圖到發(fā)布計劃、從發(fā)布計劃到迭代計劃、從迭代計劃到迭代的落地執(zhí)行四個方面來全面解讀高效研發(fā)流程，這也是一套完整流程中的四個步驟。

準備好小本本聽課吧！

一、從產(chǎn)品目標到產(chǎn)品路線圖

滿足用戶訴求是產(chǎn)品的基礎(chǔ)功能，在此之上還有一個更高的期望，即產(chǎn)品的目標。通常情況下產(chǎn)品目標與產(chǎn)品的收益、市場份額、流水有關(guān)。在制定具體產(chǎn)品目標時，需要考慮產(chǎn)品的商業(yè)模式以及產(chǎn)品所處的階段。好的產(chǎn)品目標是具體的、可衡量的、相對穩(wěn)定的。

在進行產(chǎn)品目標階段性地拆解時，需要考慮拆解的維度與方法。除了根據(jù)階段性的時間維度進行拆分外，還可以根據(jù)產(chǎn)品的里程碑進行拆分。

二、從產(chǎn)品路線圖到發(fā)布計劃

在了解如何制定產(chǎn)品發(fā)布計劃之前，我們需要先了解一個工具：用戶故事地圖。用戶故事地圖實際上是一個完整的用戶故事。它可以幫助我們增強團隊協(xié)作、洞察真實需求、打磨優(yōu)良產(chǎn)品。

想要創(chuàng)建用戶故事地圖，首先要有用戶故事地圖的框架。它的核心是一條從左到右的時間線，然后從上到下按照歸納結(jié)構(gòu)分為三個層級。這一條時間線上方的一級粒度的功能需求，在工作中，我們稱之為Epic，也就是橙色卡片。這條時間線下方的第一行為二級粒度的功能需求，在工作中，稱之為Feature，是黃色卡片。在二級粒度功能下，藍色的卡片為三級粒度的需求，工作中，稱之為Story，是藍色卡片。

此處我們提煉出了用戶故事地圖創(chuàng)建中五個重要的步驟：
① 一步一步寫出你的故事
② 組織情節(jié)
③ 探索替代故事
④ 提取故事地圖的主干
⑤ 切分出能幫你達成特定目標的任務(wù)

我們通過一個“訓(xùn)練智能機器人小A從起床到出門”的簡單例子來更清楚的了解這五步驟。

首先我們使用藍色卡片按照步驟寫出每個任務(wù)，每張卡片只寫一個任務(wù)，任務(wù)以動詞開頭，如“睜眼”、“關(guān)鬧鐘”、“穿拖鞋”、“疊被子”等等。然后按照任務(wù)的發(fā)生順序從左到右的組織卡片擺放。

接下來第二步，對所有的任務(wù)進行提取，得到概括性的行為，把這些行為放到黃色卡片上，也就是feature。如：“睜眼”、“關(guān)鬧鐘”這些行為可以歸為“醒來”后要做的事情；“穿拖鞋”、“疊被子”這兩個行為可以歸為“起來”后要做的事情。

接下來進入第三步：探索替代故事。細節(jié)、替代、變化和異常構(gòu)成故事地圖的主題。比如：時間充裕可以睡個回籠覺，樓上裝修被提前吵醒等等可能發(fā)生的變化和異常。我們需要將這些任務(wù)補充進地圖。

然后進入第四步：將一系列類似的任務(wù)提取出來，形成更大的目標。在類似任務(wù)的上方，放一張橙色的卡片,也就是之前提到的Epic,卡片貼上一個動詞短語，使其足以覆蓋其下方所有任務(wù)卡片所要表達的意思。例如：“起床”可以概括“醒來”和“起來”；“如廁”可以概括“如廁”和“刷牙”。

目前已經(jīng)完成了較為完整的故事地圖。然后進入第五步，切分出能達成特定目標的任務(wù)。先確定本次迭代需要完成的特性/目標，使用切分來識別和特定相關(guān)的所有任務(wù)和細節(jié)。

在“訓(xùn)練智能機器人小A從起床到出門”這個例子中，分為了三個版本。在第一個版本15分鐘起床，回籠覺這張卡片明顯是不需要放到其中的。在這些的story中選出滿足15分鐘起床的事務(wù)并將其放入都第一個版本中。至此我們也就完成了一個簡單的用戶故事地圖的創(chuàng)建。

上面這張圖片是實際工作中對用戶故事地圖的應(yīng)用，可以看到在實際工作中完整的用戶故事地圖所包含的內(nèi)容非常龐雜。

完成用戶故事地圖之后，就需要制訂發(fā)布計劃。在創(chuàng)建用戶故事地圖的第五步中，我們切分出了達成特定功能的任務(wù)目標，每一個發(fā)布計劃都對應(yīng)著一個版本。具體的步驟如下：

①Big Story進行細化討論

②按照價值和重要程度進行版本規(guī)劃

③確定每個版本的期望達成目標

④確定每個版本的內(nèi)容

⑤團隊達成共識

通過以上步驟，就基本確定了用戶故事地圖的發(fā)布計劃。

三、從發(fā)布計劃到迭代計劃

第三部分主要講解集中發(fā)布式模式這一常用的模式，在集中發(fā)布式模式中，一次發(fā)布包含多次迭代；在迭代發(fā)布模式中，一次發(fā)布等于一次迭代。

很多大型項目都在使用這一模式，通常是每月發(fā)布一次，一次發(fā)布包含四個迭代，四個迭代之后，發(fā)布一次版本。

從發(fā)布計劃到迭代計劃共包括四個內(nèi)容。

1、用戶故事拆分

用戶故事的拆分對迭代速率有一定影響。對用戶故事的拆分要做到拆分出的故事盡量小，但是要適當，并不是越小越好。避免出現(xiàn)一個迭代內(nèi)無法完成的故事。

2、用戶故事優(yōu)先級

在完成用戶故事拆分后，需要對用戶故事的優(yōu)先級進行排序。用戶故事的排序其實是對需求的一個排序，優(yōu)先級排序有許多方法，如高中低、數(shù)字排序、衣服尺碼L、XL等方式。優(yōu)先級決定排入迭代的順序。

以一個兩周的迭代時間為例，假設(shè)我們有這樣一個需求，前面的數(shù)字是需求卡片的序號，后面的數(shù)字從100到45，這是項目優(yōu)先級排序的一個方式。每一次迭代能做4個卡片時，我們就會把優(yōu)先級最高的卡片放入迭代池。

而當?shù)诙蔚鷷r，需求發(fā)生了變化，出現(xiàn)了x和y兩個新的需求，x和y有著較高的優(yōu)先級，那么我們?nèi)匀粚?yōu)先級最高的四個卡片放入迭代池中。

第三次迭代中又插入了新需求z，需求z也有較高的優(yōu)先級，那么當我們進行迭代的時候，需求z就會頂替另一個需求被放入迭代池中。

通過以上的例子可以看到，在原本的迭代計劃中，12張卡片會被按順序放入迭代池中，而真實情況是插入了更高優(yōu)先級的需求，替換了低優(yōu)先級的需求，把低優(yōu)先級的需求放入了下一次迭代中。這就是優(yōu)先級排序?qū)Φ媱澋挠绊憽?/p>

3、用戶故事估算

在迭代之前，需要對用戶故事進行估算，用戶故事估算實際上是對工作量的估算。這個工作量體現(xiàn)的是團隊均值能力。

通常在公司內(nèi)有不同級別的員工，高級別的員工和低級別的員工完成同一任務(wù)所需的時間是不同的。所以在進行用戶故事估算時就需要規(guī)避掉技能的差異，根據(jù)團隊的均值能力來進行估算。

用戶故事估算通常參考是團隊的歷史數(shù)據(jù)，我們可以從歷史數(shù)據(jù)中進行合理的估算。而沒有這種歷史數(shù)據(jù)的團隊，可以參考一下類似團隊的數(shù)據(jù)。當這兩者都不具備時，就只能采用本能估算的方式了。

4、迭代計劃制定

當前面三步全部完成后，才能開始指定迭代計劃。

將已拆分好的用戶故事按照優(yōu)先級依次放入迭代池中，對每個要進行迭代的用戶故事進行估算，確定好迭代的時間期限。所以我們就制定出了迭代計劃。

當需求變更，團隊人員進行調(diào)整以及預(yù)估不準確時，我們需要對迭代計劃進行調(diào)整。調(diào)整方式有：范圍調(diào)整、需求置換；延期；加人、加班趕工三種方式。

我們推薦采用范圍調(diào)整、需求置換這一方式，也就是前面提到過的，插入高優(yōu)先級用戶故事，順延低優(yōu)先級故事到下一次迭代的方式。

四、從迭代計劃到迭代的落地執(zhí)行

對于一個團隊來說需要通過迭代計劃會、站會、需求評審會、迭代回顧會等會議對計劃進行分析和迭代，然后進行開發(fā)和測試。在整個過程中無論是開發(fā)還是測試都是以story的力度進行的。分析、開發(fā)與測試這三個步驟是并行的。

團隊可以使用卡片墻標注完成的任務(wù)和未完成的任務(wù)以及遇到的bug等。通過這種方式，能夠?qū)?zhí)行情況有清晰的認知，對執(zhí)行過程產(chǎn)生積極的影響。

點擊進入了解更多技術(shù)資訊~~

總結(jié)

以上是生活随笔為你收集整理的高效研发流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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