本文,我們使用產(chǎn)品經(jīng)理和開發(fā)團隊Leader這兩個角色名。這兩個角色是目前互聯(lián)網(wǎng)企業(yè)和軟件產(chǎn)品企業(yè)常用的角色名。產(chǎn)品經(jīng)理負責產(chǎn)品的定義、規(guī)劃和需求,開發(fā)團隊Leader負責帶領(lǐng)整個團隊完成需求的交付和上線。

迭代會議的預先準備階段:

1:產(chǎn)品經(jīng)理應提前將特性、大顆粒的需求細化為單個迭代可以交付的多個UserStory。這是一個避免產(chǎn)品經(jīng)理被拍磚的良心建議,你如果拿著“我要做一個社交功能”的所謂Story去迭代規(guī)劃,估計場景會有點尷尬。其實迭代Backlog里面裝的只能是UserStory(有時候也可以裝上個迭代的遺留Bug)。

2:產(chǎn)品經(jīng)理和開發(fā)團隊Leader,提前從產(chǎn)品Backlog中挑選接下來迭代可以交付的UserStory的備選。產(chǎn)品經(jīng)理對需求的價值、優(yōu)先級和期望交付的時間比較清楚,而開發(fā)團隊的Leader通常對于需求交付的技術(shù)依賴,團隊的能力,團隊的人力管道容量比較清楚。產(chǎn)品經(jīng)理和開發(fā)團隊Leader互相交互意見,挑選出預期應該放到下個迭代交付的UserStory,也可以叫做備選的迭代Backlog。

這個階段,備選UserStory的工作量也應該做一個初略的估計,這個時候就是資深開發(fā)Leader和小白的區(qū)別了。同時產(chǎn)品經(jīng)理也應該將備選的UserStory都標明優(yōu)先級,比如使用Must-Cloud的方法,必須做的,可以做的,對應中文也也就是高優(yōu)先級和中優(yōu)先級。便于后面根據(jù)人力實際容量選擇最終的迭代交付內(nèi)容。

一般的迭代會議指導中,并沒有特別提到這個預先準備階段。筆者之所以特別強調(diào),是因為在華為之前的實踐中,直接進入迭代會議,會出現(xiàn)產(chǎn)品經(jīng)理和團隊成員耗費大量時間的問題。從產(chǎn)品Backlog中,確認哪些UserStory可以放到這個迭代中,迭代計劃會議通常是全員參加的,這樣會導致耗費全員大量的時間,特別低效。

之前在華為內(nèi)部,有過一種思路,覺得產(chǎn)品經(jīng)理無需進行溝通,直接指定優(yōu)先級和計劃時間就可以了,開發(fā)團隊無條件執(zhí)行。這是強產(chǎn)品經(jīng)理導向的,但是正如網(wǎng)上經(jīng)常看到的段子一樣,這樣容易導致產(chǎn)品經(jīng)理和開發(fā)人員矛盾激化,“動手拍磚”。

我們還是認為,產(chǎn)品經(jīng)理和開發(fā)團隊應該有一個雙向的溝通和理解,有些需求可能確實存在技術(shù)的難度。

3:開發(fā)團隊Leader應該預先了解團隊接下來迭代的人力容量,是不是有同學可能要請假,是不是有同學要調(diào)動到其他工作等等。上個迭代團隊的人力容量是多少,接下來的迭代團隊是不是有一些架構(gòu)、技術(shù)優(yōu)化方面的工作要預留,預計可以有多少人力容量可以投入到業(yè)務(wù)需求上。我們也非常推薦,每個迭代里面預留一定的人力容量用于技術(shù),架構(gòu)的改進,業(yè)務(wù)需求和架構(gòu)技術(shù)優(yōu)化保持一個比例,保持產(chǎn)品的的健康。這也是持續(xù)改進的體現(xiàn)。

大家要銘記一個事情:團隊的人力容量每個迭代一定是變化的,迄今為止,軟件的開發(fā)活動還是個智力指導下的雙手活動,團隊開發(fā)人員的心情也是會影響人力容量的。

迭代會議的輸入:

1.備選的迭代Backlog:一個經(jīng)過產(chǎn)品經(jīng)理和開發(fā)Leader預溝通的備選迭代Backlog,初步的需求優(yōu)先級排序。

2.迭代的目標:目標包括很多類型,是這個迭代的“教堂”,比如這個迭代要交付的重大特性,重大的市場發(fā)布等,讓全員能夠感知自己在這個迭代完成的UseStory的價值,迭代目標通常由產(chǎn)品經(jīng)理向全員傳遞。團隊自身架構(gòu)、技術(shù)的重大優(yōu)化,也可以是迭代的目標。團隊在質(zhì)量、效率上的改進目標,比如缺陷下降多少都可以是這個迭代的目標。

迭代會議的過程:

1.頒布會議規(guī)則,比如限定會議時間,別人發(fā)言的時候,其他人禁止講話,每人發(fā)言限時多長時間,

2.產(chǎn)品經(jīng)理首先給大家介紹備選的Backlong中,有哪些UserStory,這個迭代的重大特性及其價值,或者要交付的重大市場發(fā)布,或重點客戶,介紹Must的UserStory有哪些。

3.開發(fā)團隊Leader給大家介紹一下技術(shù)、架構(gòu),研發(fā)環(huán)境,獲取其他的團隊自我改進的目標。

4.團隊成員全員參加,從Must UserStory開始進行Story的工作量估計,對于有些UserStory,還可以進一步拆分為Task,給出每個Task的估計。

5.團隊成員全員參加,看看當前計劃的UserStory重估計和人力容量是否相配,不能超出人力容量的100%?；蛘邎F隊根據(jù)情況,定一個范圍,90%,80%都可以,因為畢竟工作量至少預估計。隨著團隊越來越默契,估計值越來越準,可以提升到100%。

6.如果有超出,產(chǎn)品經(jīng)理和團隊成員一起,重新調(diào)整,首先去掉Could的UserStory。這時,基本上這個迭代要交付的UserStory范圍就確定了。

7.開發(fā)團隊Leader帶領(lǐng)團隊成員,開始分配認領(lǐng)UserStory,我們建議鼓勵團隊成員主動的Pull(認領(lǐng)) ,而不是被動的接收Leader的Push(被動接收)。當然有些UserStory可能需要某些成員開發(fā)更好,團隊Leader可以再調(diào)整,我們也可以叫做Pull&Push。

8.開發(fā)團隊Leader統(tǒng)一審視每個成員的實際工作量,避免對有些成員的工作量不均衡,并進行相應的調(diào)整。

9.進行簡單快速的頭腦風暴,團隊成員發(fā)表自己對于接下來迭代的風險,對于是一般性的風險問題,快速記錄,團隊Leader會后解決,避免耽誤大家時間

10.全員對這個迭代的目標進行信心投票,5分信心最高,1分信心最低,如果平均分低于3分,應該讓投比較低的成員再講講他們的考慮,看看要不要再調(diào)整需求的優(yōu)先級。

11.會議結(jié)束,開始為這個迭代的目標而沖刺。

迭代會中的一些雷和坑。

1.迭代會議預先準備是非常關(guān)鍵的。團隊成員那么多,如果預先不進行備選UserStory的識別和排序,拿一堆顆粒度很大的需求直接去迭代會議,大概率要失敗,會議也會及其冗長。

2.工作量的估計方法。有絕對估值法(人時/人天),或者相對估值法(斐波那契數(shù)列的故事點,T恤 Size)。關(guān)于為什么比較流行使用斐波那契數(shù)列我寫了一個短文,詳情請登錄華為云官網(wǎng),在論壇中搜索“恒少”。

3.業(yè)界在各種敏捷,DevOps培訓中,用的比較多的是相對估值法,而且通常有個故事點估計的卡片。但是從我們的實踐來看,早期的迭代,團隊剛剛成立,團隊成員的能力和容量沒有基線,團隊成員對于產(chǎn)品,架構(gòu)、技術(shù)還在掌握中,研發(fā)環(huán)境和工具鏈剛剛搭建,還有些工作需要投入,這種狀況下用相對估值法更適合。當團隊磨礪一段時間后,團隊成員比較穩(wěn)定,團隊成員的能力和對技術(shù)架構(gòu)的掌握越來越好,團隊成員的估計越來越準,使用絕對值更接地氣,理解起來比較直接。

華為云DevCloud同時提供絕對估值法的人時/人天,用戶只需要選一個計量單位,系統(tǒng)會自動計算另一個計量單位的值,目前按不加班的1天=8小時的工作時間,是的,沒有算加班時間:),如下圖:

當然,我們也提供了相對估值法的故事點,如下圖:

4.? 關(guān)于Task的使用誤區(qū)。

a)把什么都當Task。Task是為這個迭代服務(wù)的,是必須有產(chǎn)出。學習了什么這個不可以算作這個迭代的Task。

b)把有些不當做Task。搭建環(huán)境,準備代碼庫或代碼分支,驗收,刷新自動化測試用例,這些都是要算Task的,不是只有寫代碼才算Task。

5. 準備會議時,Must的UserStory的總量不能超過備選Backlog總工作量的80%,如果備選Backlog都是Must的UserStory,失去了優(yōu)先級排序的意義了。

6. 準備會議時,Must的UserStory的總量不能超過團隊容量。

7. 整個迭代會議,建議使用專業(yè)的敏捷協(xié)同管理工具,大家看到內(nèi)容一致,大家刷新調(diào)整后的內(nèi)容也一致并即刻生成,會議結(jié)束的同事,一份本迭代的UserStory/Task列表就生成了,也不用會后再去整理。下面是我們所在的團隊最近的一個迭代計劃列表例子:

寫在最后的要點總結(jié):

1.迭代會議事先準備很重要。

2.過程中鼓勵團隊成員自主Pull,而不是一味著的Push。

3.相信團隊,相信團隊對工作量的估算,給團隊以尊重,工作量不要壓得那么慢,超出人力容量的迭代,質(zhì)量很難得到必要的保證。

4.如上的三個原則其實不僅僅適用于迭代計劃會議,其實也適用于軟件開發(fā)過程中的很多活動和會議。

xiesc