在之前的文章我首先講了1)敏捷的第一步-每日站立會(huì)，然后講了如何2)用看板管理項(xiàng)目或者管理自己的工作待辦，今天是第三個(gè)主題，講如何3)在實(shí)際項(xiàng)目中做任務(wù)拆解、估時(shí)和工作指派。

任務(wù)拆解和評(píng)估

任務(wù)拆解和評(píng)估是一項(xiàng)需要非常細(xì)致、需要經(jīng)驗(yàn)的活，通常一般由Team Leader來拆解、評(píng)估人天和指派人員。

有的人說你這是假敏捷。- 工作量要自己評(píng)估任務(wù)，不需要Leader評(píng)估；- 工作量要用故事點(diǎn)，不要用人天；- 任務(wù)要自己認(rèn)領(lǐng)，不需要用人指派。

你說的都對。但我們在實(shí)踐中通常看其實(shí)際效果決定是否采用。理論或者學(xué)說可以指導(dǎo)實(shí)踐，但是不能替代實(shí)踐。只有經(jīng)過實(shí)踐驗(yàn)證的理論也才是最有說服力的。這里我們之所以用人天評(píng)估工作且由Team Leader 指派工作是因?yàn)椋?/span>

• Leader 對整個(gè)項(xiàng)目整體架構(gòu)，模塊劃分、實(shí)現(xiàn)細(xì)節(jié)更了解，所以他來拆解也更合理

• Leader 了解每個(gè)人的實(shí)力水平和工作效率，已經(jīng)知道這個(gè)工作安排哪位同學(xué)完成更適合。人天是結(jié)合了故事點(diǎn)和執(zhí)行人員兩種因素后，在時(shí)間上/工作量上的評(píng)估，更容易理解和也容易跟進(jìn)。

• Leader 需要承擔(dān)項(xiàng)目整體快速推進(jìn)的職責(zé)，需要能指派團(tuán)隊(duì)成員快速完成工作，指派工作這種做法非常高效

經(jīng)過實(shí)踐后，我們發(fā)現(xiàn)這樣做是完全沒有問題的。

任務(wù)拆解原則

我們的任務(wù)拆解有兩個(gè)重要的原則 1）高價(jià)值優(yōu)先原則 2）粒度不要超過3人天。

高價(jià)值任務(wù)優(yōu)先拆解：拆解任務(wù)時(shí)，優(yōu)先拆解高價(jià)值的任務(wù)。始終優(yōu)先處理對最終用戶和產(chǎn)品的價(jià)值最大的功能和特性，團(tuán)隊(duì)和產(chǎn)品的價(jià)值才能最大化。

任務(wù)粒度要不超過3人天，也就是說如果一個(gè)任務(wù)需要三人天內(nèi)完成。三天內(nèi)沒有完成是一件非常嚴(yán)重的事情。如果是拆分的不合理，應(yīng)該第一天就需要反饋出來；如果是遇到了問題，也不應(yīng)該第三天才提出來，畢竟我們是每天站立會(huì)。其實(shí)工作中最怕的就是事先沒反饋、事中沒進(jìn)展然后在截止日期無法交付。

我們期望能保持小粒度的任務(wù)，每天都有進(jìn)展，而不是一個(gè)個(gè)巨大的任務(wù)分配下去后半個(gè)月都沒進(jìn)展，這樣會(huì)導(dǎo)致團(tuán)隊(duì)成員對任務(wù)沒有感知度，項(xiàng)目很大程度上會(huì)失控，最后交付日期出現(xiàn)「驚嚇」的結(jié)局。

本文小結(jié)

本文主要講了我們在敏捷開發(fā)實(shí)踐中的一些做法，包括 Team Leader 拆解任務(wù)、評(píng)估工作量和指派人員完成任務(wù)，我們認(rèn)為這樣做對于整個(gè)團(tuán)隊(duì)是最高效的、風(fēng)險(xiǎn)也是最小的；對于任務(wù)拆解，我們主要有兩個(gè)大原則：高價(jià)值優(yōu)先原則和粒度不要超過3人天。這樣做有助于讓我們保持聚焦，始終關(guān)注那些對用戶和產(chǎn)品價(jià)值最大的功能和特性上。

----

閱讀我的更多文章

DevOps｜研發(fā)提效-敏捷開發(fā)之每日站立會(huì)
DevOps｜研發(fā)提效-敏捷開發(fā)之任務(wù)看板
高效能敏捷交付團(tuán)隊(duì)反思：特性團(tuán)隊(duì)(FeatureTeam)+Scrum
研發(fā)效能組織能力建設(shè)之特性團(tuán)隊(duì)FeatureTeam（上）
DevOps | 互聯(lián)網(wǎng)、軟件公司基礎(chǔ)設(shè)施建設(shè)(基建)哪家強(qiáng)？