中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

迭代計(jì)劃會(huì)議是團(tuán)隊(duì)級(jí)敏捷的三個(gè)基礎(chǔ)會(huì)議形式之一，本篇文章作者以產(chǎn)品經(jīng)理的身份給大家提供一些開好迭代計(jì)劃會(huì)議的建議。

大家好，我是華為云DevCloud項(xiàng)目管理服務(wù)的產(chǎn)品經(jīng)理恒少，作為布道師和產(chǎn)品經(jīng)理，出差各地接觸客戶是常態(tài)，線下和華為云的客戶交流、布道、技術(shù)沙龍。

但是線下交流，覆蓋的用戶總還是少數(shù)。我希望借助線上的平臺(tái)，和用戶持續(xù)交流華為在研發(fā)效能提升上的思索和實(shí)踐。感興趣的朋友可以去華為云社區(qū)和我聊聊。

In preparing for battle I have always found that plans are useless, but planning is indispensable.

——德懷特·大衛(wèi)·艾森豪威爾

艾森豪威爾，在第二次世界大戰(zhàn)期間，擔(dān)任盟軍在歐洲的最高指揮官，同時(shí)也是美國(guó)第34任總統(tǒng)。他有不少經(jīng)典的名言，這句話的意思翻譯過(guò)來(lái)就是：計(jì)劃書往往是無(wú)用的，但是計(jì)劃的過(guò)程是不可缺少的。

艾森豪威爾的這句話，是很多文章里用來(lái)引述“計(jì)劃”的名言，我也不能免俗。哈哈。

我個(gè)人對(duì)《人月神話》這本書有著很強(qiáng)的執(zhí)念，早期堅(jiān)信軟件天生就有易變性，不可見(jiàn)性，軟件的計(jì)劃都是沒(méi)有什么實(shí)際意義的。但是時(shí)間累積后，我也終于悟出來(lái)，其實(shí)做計(jì)劃的過(guò)程是關(guān)鍵。

迭代計(jì)劃會(huì)議是團(tuán)隊(duì)級(jí)敏捷的三個(gè)基礎(chǔ)會(huì)議形式的一個(gè)，按軟件開發(fā)的時(shí)序，這個(gè)是第一個(gè)會(huì)議，我之所以放到最后講，是因?yàn)檫@個(gè)會(huì)議很重要，非常容易陷入誤區(qū)。（其實(shí)也是我懶，先挑簡(jiǎn)單的寫）

迭代計(jì)劃的初心：

1. 團(tuán)隊(duì)全員對(duì)接下來(lái)的迭代要做哪些UserStory、每個(gè)UserStory的責(zé)任人達(dá)成一致
2. 團(tuán)隊(duì)成員對(duì)本輪迭代的完成標(biāo)準(zhǔn)，計(jì)劃的開始結(jié)束時(shí)間達(dá)成一致
3. 團(tuán)隊(duì)成員更認(rèn)真的對(duì)待自己充分參與過(guò)的承諾。

一張圖看懂迭代計(jì)劃：

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

迭代會(huì)議的預(yù)先準(zhǔn)備階段：

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

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

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

一般的迭代會(huì)議指導(dǎo)中，并沒(méi)有特別提到這個(gè)預(yù)先準(zhǔn)備階段。之所以筆者特別強(qiáng)調(diào)，是因?yàn)?，在華為之前的實(shí)踐中，直接進(jìn)入迭代會(huì)議，會(huì)出現(xiàn)產(chǎn)品經(jīng)理和團(tuán)隊(duì)成員耗費(fèi)大量的時(shí)間，從產(chǎn)品Backlog中，確認(rèn)哪些UserStory可以放到這個(gè)迭代中，迭代計(jì)劃會(huì)議通常是全員參加的，這樣會(huì)導(dǎo)致耗費(fèi)全員大量的時(shí)間，特別低效。

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

我們還是認(rèn)為，產(chǎn)品經(jīng)理和開發(fā)團(tuán)隊(duì)?wèi)?yīng)該有一個(gè)雙向的溝通和理解，有些需求可能確實(shí)存在技術(shù)的難度。

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

大家要銘記一個(gè)事情：團(tuán)隊(duì)的人力容量每個(gè)迭代一定是變化的，迄今為止，軟件的開發(fā)活動(dòng)還是個(gè)智力指導(dǎo)下的雙手活動(dòng)，開發(fā)人員心情不好也是會(huì)影響人力容量的：）

迭代會(huì)議的輸入：

1. 備選的迭代Backlog：一個(gè)經(jīng)過(guò)產(chǎn)品經(jīng)理和開發(fā)Leader預(yù)溝通的備選迭代Backlog，初步的需求優(yōu)先級(jí)排序
2. 迭代的目標(biāo)：目標(biāo)包括很多類型，是這個(gè)迭代的“教堂”，比如這個(gè)迭代要交付的重大特性，重大的市場(chǎng)發(fā)布等，讓全員能夠感知自己在這個(gè)迭代完成的UseStory的價(jià)值，迭代目標(biāo)通常由產(chǎn)品經(jīng)理向全員傳遞。團(tuán)隊(duì)自身架構(gòu)、技術(shù)的重大優(yōu)化，也可以是迭代的目標(biāo)。團(tuán)隊(duì)在質(zhì)量、效率上的改進(jìn)目標(biāo)，比如缺陷下降多少都可以是這個(gè)迭代的目標(biāo)。

迭代會(huì)議的過(guò)程：

1. 頒布會(huì)議規(guī)則，比如限定會(huì)議時(shí)間，別人發(fā)言的時(shí)候，其他人禁止講話，每人發(fā)言限時(shí)多長(zhǎng)時(shí)間，
2. 產(chǎn)品經(jīng)理首先給大家介紹備選的Backlong中，有哪些UserStory，這個(gè)迭代的重大特性及其價(jià)值，或者要交付的重大市場(chǎng)發(fā)布，或重點(diǎn)客戶，介紹Must的UserStory有哪些。
3. 開發(fā)團(tuán)隊(duì)Leader給大家介紹一下技術(shù)、架構(gòu)，研發(fā)環(huán)境，獲取其他的團(tuán)隊(duì)自我改進(jìn)的目標(biāo)，
4. 團(tuán)隊(duì)成員全員參加，從Must UserStory開始進(jìn)行Story的工作量估計(jì)，對(duì)于有些UserStory，還可以進(jìn)一步拆分為Task，給出每個(gè)Task的估計(jì)
5. 團(tuán)隊(duì)成員全員參加，看看當(dāng)前計(jì)劃的UserStory重估計(jì)和人力容量是否相配，不能超出人力容量的100%?；蛘邎F(tuán)隊(duì)根據(jù)情況，定一個(gè)范圍，90%，80%都可以，因?yàn)楫吘构ぷ髁恐辽兕A(yù)估計(jì)。隨著團(tuán)隊(duì)越來(lái)越默契，估計(jì)值越來(lái)越準(zhǔn)，可以提升到100%。
6. 如果有超出，產(chǎn)品經(jīng)理和團(tuán)隊(duì)成員一起，重新調(diào)整，首先去掉Could的UserStory。這時(shí)，基本上這個(gè)迭代要交付的UserStory范圍就確定了。
7. 開發(fā)團(tuán)隊(duì)Leader帶領(lǐng)團(tuán)隊(duì)成員，開始分配認(rèn)領(lǐng)UserStory，我們建議鼓勵(lì)團(tuán)隊(duì)成員主動(dòng)的Pull（認(rèn)領(lǐng)） ，而不是被動(dòng)的接收Leader的Push（被動(dòng)接收）。當(dāng)然有些UserStory可能需要某些成員開發(fā)更好，團(tuán)隊(duì)Leader可以再調(diào)整，我們也可以叫做Pull&Push。
8. 開發(fā)團(tuán)隊(duì)Leader統(tǒng)一審視每個(gè)成員的實(shí)際工作量，避免對(duì)有些成員的工作量不均衡，并進(jìn)行相應(yīng)的調(diào)整。
9. 進(jìn)行簡(jiǎn)單快速的頭腦風(fēng)暴，團(tuán)隊(duì)成員發(fā)表自己對(duì)于接下來(lái)迭代的風(fēng)險(xiǎn)，對(duì)于是一般性的風(fēng)險(xiǎn)問(wèn)題，快速記錄，團(tuán)隊(duì)Leader會(huì)后解決，避免耽誤大家時(shí)間
10. 全員對(duì)這個(gè)迭代的目標(biāo)進(jìn)行信心投票，5分信心最高，1分信心最低，如果平均分低于3分，應(yīng)該讓投比較低的成員再講講他們的考慮，看看要不要再調(diào)整需求的優(yōu)先級(jí)。
11. 會(huì)議結(jié)束，開始為這個(gè)迭代的目標(biāo)而沖刺。

迭代會(huì)中的一些雷和坑:

1. 迭代會(huì)議預(yù)先準(zhǔn)備是非常關(guān)鍵的。團(tuán)隊(duì)成員那么多，如果預(yù)先不進(jìn)行備選UserStory的識(shí)別和排序，拿一堆顆粒度很大的需求直接去迭代會(huì)議，大概率要失敗，會(huì)議也會(huì)及其冗長(zhǎng)，那么多團(tuán)隊(duì)成員，時(shí)間嘩嘩的就流失了，研發(fā)不是請(qǐng)客吃飯，這是要讓你們老板傾家蕩產(chǎn)啊。

2. 工作量的估計(jì)方法。有絕對(duì)估值法（人時(shí)/人天），或者相對(duì)估值法（斐波那契數(shù)列的故事點(diǎn)，T恤 Size）。關(guān)于為什么比較流行使用斐波那契數(shù)列我寫了一個(gè)短文：https://bbs.huaweicloud.com/forum/thread-13153-1-1.html。

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

華為云DevCloud同時(shí)提供絕對(duì)估值法的人時(shí)/人天，用戶只需要選一個(gè)計(jì)量單位，系統(tǒng)會(huì)自動(dòng)計(jì)算另一個(gè)計(jì)量單位的值，目前按不加班的1天=8小時(shí)的工作時(shí)間，是的，沒(méi)有算加班時(shí)間：），如下圖：

當(dāng)然，我們也提供了相對(duì)估值法的故事點(diǎn)，如下圖：

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

a）把什么都當(dāng)Task。Task是為這個(gè)迭代服務(wù)的，是必須有產(chǎn)出。學(xué)習(xí)了什么這個(gè)不可以算作這個(gè)迭代的Task。

b）把有些不當(dāng)做Task。搭建環(huán)境，準(zhǔn)備代碼庫(kù)或代碼分支，驗(yàn)收，刷新自動(dòng)化測(cè)試用例，這些都是要算Task的，不是只有寫代碼才算Task。

5. 準(zhǔn)備會(huì)議時(shí)，Must的UserStory的總量不能超過(guò)備選Backlog總工作量的80%，如果備選Backlog都是Must的UserStory，失去了優(yōu)先級(jí)排序的意義了。

6. 準(zhǔn)備會(huì)議時(shí)，Must的UserStory的總量不能超過(guò)團(tuán)隊(duì)容量。

7. 整個(gè)迭代會(huì)議，建議使用專業(yè)的敏捷協(xié)同管理工具，大家看到內(nèi)容一致，大家刷新調(diào)整后的內(nèi)容也一致并即刻生成，會(huì)議結(jié)束的同事，一份本迭代的UserStory/Task列表就生成了，也不用會(huì)后再去整理。

下面是我們所在的團(tuán)隊(duì)最近的一個(gè)迭代計(jì)劃列表例子：

寫在最后的要點(diǎn)總結(jié)：

1. 迭代會(huì)議事先準(zhǔn)備很重要
2. 過(guò)程中鼓勵(lì)團(tuán)隊(duì)成員自主Pull，而不是一味著的Push
3. 相信團(tuán)隊(duì)，相信團(tuán)隊(duì)對(duì)工作量的估算，給團(tuán)隊(duì)以尊重，工作量不要壓得那么慢，超出人力容量的迭代，質(zhì)量很難得到必要的保證。
4. 如上的三個(gè)原則其實(shí)不僅僅適用于迭代計(jì)劃會(huì)議，其實(shí)也適用于軟件開發(fā)過(guò)程中的很多活動(dòng)和會(huì)議。

希望能幫助大家開一個(gè)開心，高效，信心滿滿的迭代會(huì)議。

至此，軟件迭代開發(fā)中三個(gè)最基本的活動(dòng)：迭代計(jì)劃會(huì)議，每日站立會(huì)議，迭代回顧會(huì)議，都介紹完了。感興趣的朋友可以到華為云社區(qū)看相關(guān)的文章。

相關(guān)閱讀：

《華為敏捷/DevOps實(shí)踐：產(chǎn)品經(jīng)理如何開好敏捷回顧會(huì)議》

《華為敏捷/DevOps實(shí)踐：如何開好站立會(huì)議》

本文由 @透明的魚 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。