為控制Scrum成本而追蹤時間？

　　Kevin Krac有一個問題，是關于在Scrum中追蹤完成任務所需時間的：

　　當開發人員A把自己的任務擱置一段時間(也許是一整天，甚至兩天)，以幫助另一位開發人員B對其任務做分析或者編碼……他們應該如何說明那個故事/任務的‘實際工作量’呢?

　　應該把總時間攤在他們一起做的那個故事/任務上，并乘以2嗎(因為他們是兩個人)?還是只記錄花費的總時間，并算在那個負責該任務的開發人員身上?抑或是這無關緊要?

　　為什么你想追蹤每個Scrum任務的實際開發時間?一個可能的原因或許是為了控制成本。Charles Bradley不喜歡這個想法：

　　試圖在Sprint任務級別做成本核算，是在試圖修改Scrum讓它做一些Scrum不應該做的事情。

　　如果你是出于其他原因去追蹤時間，那么你盡管去使用在了解Scrum之前所使用的方法就好了，但請不要亂用Scrum框架去那么做。此外，不要試圖拿耗費的時間(可計費的時間，或者其他什么時間)同在Scrum任務上花費的時間做比較。重申一下，我認為這是“濫用”Scrum框架。

　　事實上，Ron Jeffries把這個問題本身看作是一個危險信號：

　　我認為，控制成本是項目或組織運作不良的主要標志。產出的價值應該會明顯高于這種成本，做詳盡的成本核算顯然是浪費時間。

　　此外，我碰巧知道在幾乎所有的審計工作中，精確的細節并沒有價值。這一結論是我多年作為開發經理管理資本項目得出的。

　　[...]

　　隨著時間的推移，這種成本是團隊成本中不可或缺的。我知道，任何業務過程都沒有必要了解比這更多的細節。

　　但是，如果你的團隊時間分配給多個同時進行的項目呢?這種情況下，為了控制成本，需要追蹤單個任務的時間嗎?Ron的建議是要徹底避免讓團隊接手多個同時進行的項目：

　　別那么做。這會讓交付價值變得更慢，對所有客戶都會變慢。通常，對于不明智的想法，不會有人先站出來對你說“當心這個歪主意”。

原文轉自：http://kb.cnblogs.com/page/91947/