某項(xiàng)目組第一次采用敏捷方法進(jìn)行開發(fā)，確定了迭代周期為三周。該項(xiàng)目組投入的資源如下：

前端開發(fā)工程師一名；

后端開發(fā)工程師一名；

測(cè)試工程師一名；

PO一名；

SM一名；

前后端開發(fā)采用不同的技術(shù)，熟悉前端開發(fā)的工程師不熟悉后端的技術(shù)，后端開發(fā)的工程師也不熟悉前端使用的技術(shù)。

當(dāng)?shù)?周結(jié)束后，由于前端開發(fā)人員使用的是新技術(shù)，需要熟悉新技術(shù)，而后端工程師與測(cè)試工程師的投入都不到位，因此估算工作量與實(shí)際工作量差別比較大。咨詢顧問介入了解情況后，指出了本項(xiàng)目組在迭代策劃時(shí)的錯(cuò)誤，并指導(dǎo)項(xiàng)目組對(duì)后續(xù)開發(fā)活動(dòng)進(jìn)行了如下調(diào)整：

1.將三周的開發(fā)周期調(diào)整為一周一個(gè)迭代的開發(fā)周期。在不熟悉敏捷開發(fā)方法時(shí)，迭代周期要短，要及時(shí)總結(jié)經(jīng)驗(yàn)教訓(xùn)，進(jìn)行自我學(xué)習(xí)。

2.鑒于前期的迭代策劃做得不好，需要重新進(jìn)行迭代策劃。

3.鑒于團(tuán)隊(duì)的成員不是全棧工程師，因此將按角色分別估計(jì)工作量。

4.測(cè)試人員需要盡早參與開發(fā)，而不是到第3次迭代才進(jìn)行功能測(cè)試。

重新進(jìn)行的迭代策劃過程如下：

1.項(xiàng)目組全員參與了迭代策劃會(huì)議。另外包括：

項(xiàng)目組外部的測(cè)試工程師兩名；

外部咨詢顧問作為主持人；

QA人員負(fù)責(zé)實(shí)時(shí)在電腦上按照更新后的模板記錄估算結(jié)果，并投影出來；

其他多名觀摩學(xué)習(xí)人員。

2.首先請(qǐng)PO講解了每個(gè)用戶故事，然后依次讓前端開發(fā)工程師、后端開發(fā)工程師講解開發(fā)要點(diǎn)，包括設(shè)計(jì)思路、需要處理的需求要點(diǎn)、是否有歷史的復(fù)用功能、前后臺(tái)的接口等；接著讓測(cè)試工程師講解測(cè)試要點(diǎn)、澄清需要測(cè)試的需求細(xì)節(jié)。

在此討論中：

PO調(diào)低了某些用戶故事的優(yōu)先級(jí)；

PO刪除了一個(gè)用戶故事；

PO澄清了某些模糊的用戶故事；

前后臺(tái)的工程師指出了可以復(fù)用的功能；

前后臺(tái)的工程師對(duì)某些需求的實(shí)現(xiàn)方式做了溝通；

測(cè)試人員貢獻(xiàn)了很多澄清需求的想法。迭代策劃會(huì)議的一個(gè)重要工作就是做需求的溝通，要求項(xiàng)目組的所有成員要對(duì)需求達(dá)成一致的理解。通過填寫開發(fā)要點(diǎn)、測(cè)試要點(diǎn)、促使項(xiàng)目組成員對(duì)需求的理解進(jìn)行溝通、討論、確認(rèn)。

3.前端開發(fā)工程師、后端開發(fā)工程師、測(cè)試工程師分別選擇了一個(gè)故事作為基準(zhǔn)故事，設(shè)置故事點(diǎn)為1，然后估算剩余用戶故事的點(diǎn)數(shù)，從斐波那契數(shù)列中選擇一個(gè)最接近的點(diǎn)數(shù)，猶豫不定時(shí)，選擇偏大的點(diǎn)數(shù)。在做此估算時(shí)，前端、后端開發(fā)工程師、測(cè)試工程師都是背對(duì)背地、獨(dú)立地進(jìn)行估算。因?yàn)槊總€(gè)角色只有一個(gè)人，所以沒有采用策劃撲克的方法，并且充分信任每個(gè)工程師的估算結(jié)果。如果估算的結(jié)果不準(zhǔn)確，則在第1個(gè)迭代結(jié)束后，再調(diào)整估算結(jié)果。

4.三個(gè)角色對(duì)于選中的基準(zhǔn)故事，分別估計(jì)了自己的工作量，然后推算出其他故事的工作量，合計(jì)得到每個(gè)故事的總工作量以及每個(gè)角色的總工作量。

5.讓PO對(duì)所有的用戶故事劃分優(yōu)先級(jí)。首先請(qǐng)PO挑出最重要的一個(gè)需求，然后再挑選剩余故事中最重要的一個(gè)需求，如果不好區(qū)分優(yōu)先級(jí)，就定義兩個(gè)需求的優(yōu)先級(jí)同等重要。此時(shí)，其他團(tuán)隊(duì)成員可以提出自己的意見，直至大家對(duì)優(yōu)先級(jí)劃分的結(jié)果達(dá)成一致。在劃分優(yōu)先級(jí)過程中：

PO主動(dòng)刪除了一個(gè)可做可不做的用戶故事；

當(dāng)對(duì)所有的故事劃分完優(yōu)先級(jí)、并重新按優(yōu)先級(jí)順序排列后，PO又再次做了權(quán)衡，微調(diào)了優(yōu)先級(jí)；

對(duì)于成員質(zhì)疑的優(yōu)先級(jí)劃分，PO給出了解釋。

6.每次迭代周期設(shè)定為一周。列出每個(gè)工程師在未來兩周中每周可以投入到本項(xiàng)目的工作量（小時(shí)），表示開發(fā)能力。

7.根據(jù)每周可以提供的開發(fā)能力，平衡需要的總工作量與開發(fā)能力，如果不能滿足需求的總工作量，則裁剪優(yōu)先級(jí)最低的需求，否則就需要提升開發(fā)能力、增加人員。由于估算的總體故事的工作量為186.5人時(shí)，超出了實(shí)際的開發(fā)能力122個(gè)工時(shí)，因此SM和領(lǐng)導(dǎo)協(xié)商增加了一個(gè)迭代，并且由于前端開發(fā)的工作量估計(jì)與實(shí)際能力差別比較大，確定再增加一個(gè)前端開發(fā)工程師。

8.根據(jù)用戶故事的優(yōu)先級(jí)，挑選了第1周完成第1個(gè)故事。第1個(gè)故事比較大，但是無法再進(jìn)行細(xì)拆分為更小的故事，并且已確定再增加一個(gè)前端開發(fā)工程師，以確保第1個(gè)故事能夠在1次迭代內(nèi)完成，并將第1次迭代的周期確定為6天而不是5天。

9.在上次策劃會(huì)議中已經(jīng)將用戶故事拆分為任務(wù)，因此本次估算沒有再進(jìn)行任務(wù)的拆分。留待責(zé)任人自己進(jìn)行細(xì)拆分。

本次迭代策劃會(huì)議共耗時(shí)1.5小時(shí)。第一次迭代策劃會(huì)議估算了12個(gè)用戶故事，合計(jì)估算為186.5工時(shí)；本次迭代策劃會(huì)議估算了11個(gè)用戶故事，總估算工時(shí)也是186.5個(gè)工時(shí)，但是刪除了一個(gè)估算為17個(gè)工時(shí)的故事。雖然結(jié)果差別不是很大，但是估算的過程是不同的，上次估算并沒有進(jìn)行認(rèn)真的需求溝通，而本次根據(jù)不同的角色分別對(duì)需求進(jìn)行了充分地闡述，同時(shí)這是在能力平衡的基礎(chǔ)上做出的迭代計(jì)劃，項(xiàng)目組成員更有信心可以按照計(jì)劃實(shí)施！

本項(xiàng)目針對(duì)迭代策劃會(huì)議的敏捷實(shí)踐，打破了常規(guī)的方法，變通執(zhí)行，反而帶來了更好地效果。這也意味著敏捷軟件開發(fā)是經(jīng)驗(yàn)型過程控制，只要符合敏捷的原則，可以根據(jù)項(xiàng)目組的實(shí)際情況進(jìn)行變通。