FAQ 怎樣將 sprint backlog 中高難度（如技術完全不了解）需求分拆成 task？

1樓：Blues

引入照明彈的概念。當你看不清路的時候，最好的方法是發射一枚照明彈，讓你起碼能看清最近要走的幾步路。

同樣，針對任務分解，首先制定乙個對新技術預研的計畫。當完成預研後，對任務的時間評估就會準確很多。scrum的敏捷方法本來就是固定時段內，能完成多少就完成多少，不作硬性要求。

更多的是靠開發

2樓：張克強

任務分解WBS是多麼熟悉和古老的詞語。

在當年的經典時代，利用強大的project server和client，協同整個團隊進行每日任務計畫和跟蹤。經過近4年的痛苦之後，整個組織總算明白「這沒有提高效率」，不再要求進行日顆粒度的任務分解和跟蹤。

在號稱價值交付的敏捷當中，竟然看見了小於8工時的任務分解，號稱這是基於承諾的估算。

估算時要花費時間，跟蹤時也要花費時間，更不堪的是小於8工時的估算難有可靠的估算依據，一般是不准的。基於這些細小的任務累計得到的工時燃盡圖完全就是乙個大笑話，每天在上面的跟蹤幾乎全是浪費。

我的主張是：

1，如果能夠有別的物件來表達進度和交付的價值，比如已經完成的故事點數、功能點數，那麼可以不作任務劃分，就算是Sprint週期稍長，使用者故事顆粒度不細；

2，如果就是使用了理想工時這樣的單位來表達進度和交付的大小，那麼任務劃分的最小顆粒度也應當保持在2人天以上，當然最大顆粒度也是要控制的，在短迭代的情況下，一般不超過5人天，不要對過於細小的任務進行劃分。敏捷講究信任，可以信任團隊成員會完成相關事宜，而不必要求他/她劃分得很細。