在之前的文章我首先講了1)敏捷的第一步-每日站立會，然後講瞭如何2)用看板管理專案或者管理自己的工作待辦，今天是第三個主題，講如何3)在實際專案中做任務拆解、估時和工作指派。
任務拆解和評估
任務拆解和評估是一項需要非常細緻、需要經驗的活，通常一般由Team Leader來拆解、評估人天和指派人員。
有的人說你這是假敏捷。- 工作量要自己評估任務，不需要Leader評估；- 工作量要用故事點，不要用人天；- 任務要自己認領，不需要用人指派。
你說的都對。但我們在實踐中通常看其實際效果決定是否採用。理論或者學說可以指導實踐，但是不能替代實踐。只有經過實踐驗證的理論也才是最有說服力的。這裡我們之所以用人天評估工作且由Team Leader 指派工作是因為，
-
Leader 對整個專案整體架構，模組劃分、實現細節更瞭解，所以他來拆解也更合理
-
Leader 瞭解每個人的實力水平和工作效率，已經知道這個工作安排哪位同學完成更適合。人天是結合了故事點和執行人員兩種因素後，在時間上/工作量上的評估，更容易理解和也容易跟進。
-
Leader 需要承擔專案整體快速推進的職責，需要能指派團隊成員快速完成工作，指派工作這種做法非常高效
經過實踐後，我們發現這樣做是完全沒有問題的。
任務拆解原則
我們的任務拆解有兩個重要的原則 1）高價值優先原則 2）粒度不要超過3人天。
高價值任務優先拆解：拆解任務時，優先拆解高價值的任務。始終優先處理對終端使用者和產品的價值最大的功能和特性，團隊和產品的價值才能最大化。
任務粒度要不超過3人天，也就是說如果一個任務需要三人天內完成。三天內沒有完成是一件非常嚴重的事情。如果是拆分的不合理，應該第一天就需要反饋出來；如果是遇到了問題，也不應該第三天才提出來，畢竟我們是每天站立會。其實工作中最怕的就是事先沒反饋、事中沒進展然後在截止日期無法交付。
我們期望能保持小粒度的任務，每天都有進展，而不是一個個巨大的任務分配下去後半個月都沒進展，這樣會導致團隊成員對任務沒有感知度，專案很大程度上會失控，最後交付日期出現「驚嚇」的結局。
本文小結
本文主要講了我們在敏捷開發實踐中的一些做法，包括 Team Leader 拆解任務、評估工作量和指派人員完成任務，我們認為這樣做對於整個團隊是最高效的、風險也是最小的；對於任務拆解，我們主要有兩個大原則：高價值優先原則和粒度不要超過3人天。這樣做有助於讓我們保持聚焦，始終關注那些對使用者和產品價值最大的功能和特性上。
----
閱讀我的更多文章
DevOps｜研發提效-敏捷開發之每日站立會
DevOps｜研發提效-敏捷開發之任務看板
高效能敏捷交付團隊反思：特性團隊(FeatureTeam)+Scrum
研發效能組織能力建設之特性團隊FeatureTeam（上）
DevOps | 網際網路、軟體公司基礎設施建設(基建)哪家強？