1 任務(wù)拆解概覽圖

參考文章?JIRA配置之問題類型，我們知道了史詩，故事，任務(wù)分別是什么定義？

那么我們在實(shí)際敏捷開發(fā)工作中，如何將大的需求一步步拆解出來，再分配到研發(fā)團(tuán)隊(duì)成員名下，大家通過團(tuán)隊(duì)合作，最終交付可工作的軟件的呢？

如下圖所示：

2 工作事項(xiàng)的拆分

我們把工作事項(xiàng)分為四個(gè)層級，level1～4。

level1:史詩級需求，比如做一個(gè)網(wǎng)站的支付系統(tǒng)，這樣的需求不是一個(gè)人能完成的，也不是一個(gè)沖刺周期就能完成的，史詩級需求需要進(jìn)一步拆解。

史詩級需求應(yīng)該是產(chǎn)品經(jīng)理在做產(chǎn)品/項(xiàng)目初期規(guī)劃的時(shí)候就定義好的。

level2: 需求->故事，把史詩級拆解成可以更小的需求，需求再拆解成更小的故事

那么故事就是需求的最小單元，而且故事一定是在一個(gè)沖刺周期范圍內(nèi)可以做完的，一般來講一個(gè)5～8人的scrum team，一個(gè)沖刺可以完成6～15個(gè)故事。故事數(shù)量太少，就失去了敏捷的靈活性，故事數(shù)量太多，又使得團(tuán)隊(duì)分工過于復(fù)雜。建議10個(gè)左右是比較合適的。

需求/故事一般是產(chǎn)品經(jīng)理前置研發(fā)沖刺一個(gè)月的時(shí)間，就開始創(chuàng)建的。基于大的史詩級需求和用戶調(diào)研，競品分析等結(jié)果，漸進(jìn)明細(xì)地定義具體要做的故事。

故事是由產(chǎn)品經(jīng)理創(chuàng)建，沖刺啟動(dòng)后責(zé)任人轉(zhuǎn)移到研發(fā)人員，進(jìn)入測試后又轉(zhuǎn)移到測試人員名下，最后交付驗(yàn)收的時(shí)候，又轉(zhuǎn)移給產(chǎn)品經(jīng)理做最后的確認(rèn)驗(yàn)收。

故事拆解需要滿足 invest 原則

1、獨(dú)立的(Independent)

獨(dú)立性和傳統(tǒng)軟件工程的松耦合的概念有異曲同工之妙。強(qiáng)調(diào)用戶故事與用戶故事之間不要有太多的依賴，因?yàn)橛幸蕾嚨牟煌适?，可能?yōu)先級是不同，這就會(huì)給故事的工作量估計(jì)，以及故事在開發(fā)迭代的排期造成困擾。

2、可協(xié)商的（Negotiable）：故事是可以協(xié)商，故事卡是用戶功能的簡單描述，細(xì)節(jié)需要在客戶與開發(fā)團(tuán)隊(duì)的討論中產(chǎn)生。

3、有價(jià)值的（Valuable）

故事是以客戶或用戶的視角來書寫，通常是業(yè)務(wù)語言而非技術(shù)語言。在故事中自然體現(xiàn)這個(gè)功能具體給用戶帶來的價(jià)值是什么。

4、可估算的（Estimate）：每個(gè)故事都對應(yīng)估計(jì)的故事點(diǎn)數(shù)，即工作量應(yīng)該是可以度量的。開發(fā)人員可以根據(jù)所業(yè)務(wù)領(lǐng)域的知識和相關(guān)技術(shù)經(jīng)驗(yàn)來估計(jì)每個(gè)用戶故事可能對應(yīng)的故事點(diǎn)數(shù)?；诿總€(gè)用戶故事的故事點(diǎn)數(shù)的估算，確保納入每次迭代的故事的總故事點(diǎn)數(shù)不會(huì)超過開發(fā)團(tuán)隊(duì)的速率，即處理能力。

5、小的（Small）：每個(gè)故事可以小到在一次開發(fā)迭代中就可以完成。合適的故事大小最終取決于團(tuán)隊(duì)的速率，以及所使用的技術(shù)。我們可以考慮把一些大的史詩故事通過某些規(guī)則分解為更小的可在一個(gè)迭代中就可以完成的小的故事。

6、可測量的（Testable）：故事必須是可測量的，這個(gè)和每個(gè)故事必須對應(yīng)驗(yàn)收條件是息息相關(guān)的?？啥攘康尿?yàn)收指標(biāo)是不可少的，比如系統(tǒng)的可用性為99.99%，99%的情況下，打開一個(gè)頁面的時(shí)間不能超過2秒等。

level3: 研發(fā)任務(wù)，這里的任務(wù)可以是從故事拆解而來，也可以一些非需求類的任務(wù)，比如，接口升級，文檔，資源部署之類的事情。這里的任務(wù)拆分顆粒度是責(zé)任到人的，也就是說一個(gè)任務(wù) 是由一個(gè)經(jīng)辦人完全負(fù)責(zé)其全過程的（便于做研發(fā)效能統(tǒng)計(jì)）。而且為了保證評估的精確性，建議單個(gè)任務(wù)的工作量大小不超過2days（保證項(xiàng)目估時(shí)的準(zhǔn)確性）。在沖刺啟動(dòng)的第一天，就要根據(jù)產(chǎn)品經(jīng)理安排的沖刺故事去拆解和創(chuàng)建研發(fā)任務(wù)。

測試計(jì)劃，也是測試人員基于產(chǎn)品經(jīng)理安排的沖刺故事去做一些測試工作量的評估而創(chuàng)建的。

level4:?測試用例：測試用例一般是沖刺啟動(dòng)2～3天后，測試負(fù)責(zé)人根據(jù)具體要做的故事，定義出來的若干個(gè)測試用例，測試用例歸屬于測試計(jì)劃，同時(shí)又和故事有關(guān)聯(lián)關(guān)系。

缺陷：是當(dāng)故事進(jìn)入提測狀態(tài)后，相關(guān)的測試用例執(zhí)行失敗了，從而由測試負(fù)責(zé)人創(chuàng)建出來的，分配給研發(fā)人員處理的事項(xiàng)，一個(gè)版本缺陷的數(shù)量和千行代碼缺陷數(shù)用于衡量研發(fā)過程中的產(chǎn)品質(zhì)量。

故障：是指產(chǎn)品上線后，用戶發(fā)現(xiàn)的問題，故障通常和迭代的需求沒有關(guān)系，但是故障的優(yōu)先級又很高，需要立即處理。如果沒有明確的故障管理機(jī)制，就會(huì)打亂整個(gè)研發(fā)沖刺計(jì)劃，導(dǎo)致整個(gè)項(xiàng)目的延期。特別是對于第一次上線的產(chǎn)品，往往會(huì)產(chǎn)生大量的線上故障。這里的故障管理機(jī)制，可以參考文章?JIRA之變更處理

3 沖刺的拆分？

介紹完工作事項(xiàng)的四個(gè)層級，那么這么多的工作事項(xiàng)從時(shí)間的維度又是從何拆分的？

從圖中可以看到，從時(shí)間維度，劃分了三個(gè) sprint，

sprint1（week1～2）:史詩1的部分需求，需求1的故事1～n，需求2的故事1，以及這些故事對應(yīng)的任務(wù)，這個(gè)sprint的測試計(jì)劃，測試用例，缺陷，故障等。

sprint2（week3～4）:史詩1的需求2，史詩2的需求3，需求2的剩余故事，需求3的故事1～n，以及這些故事對應(yīng)的任務(wù)，這個(gè)sprint的測試計(jì)劃，測試用例，缺陷，故障等。

sprint3（week5～6）:史詩2的需求4，需求4的故事1～n，以及這些故事對應(yīng)的任務(wù)，這個(gè)sprint的測試計(jì)劃，測試用例，缺陷，故障等。

參考如下圖片

4 版本的拆分？

如上圖所示，V0.1.0的范圍包括：故事1～6，V0.2.0的范圍包括：故事7～11.

關(guān)于版本的定義和管理，參考文章JIRA之版本管理

版本和沖刺的關(guān)系？

版本是向客戶發(fā)布軟件的實(shí)際版本，當(dāng)一個(gè)沖刺結(jié)束的時(shí)候，可以有一個(gè)版本發(fā)布上線，也可以兩個(gè)沖刺合并一個(gè)版本發(fā)布，也可以一個(gè)沖刺發(fā)布兩個(gè)版本。版本的范圍通常也是由產(chǎn)品經(jīng)理來定義的。在實(shí)際敏捷管理中，為了簡化流程，通常會(huì)定義一個(gè)沖刺上線一個(gè)版本，把沖刺范圍和版本范圍劃等號，但是記住這不是必須的。