Chen：

您好，我看了您些的關于Scrum sprint plan中規模估算的一篇文章（http://blog.csdn.net/zhangmike/article/details/6980334），覺得梳理和總結的比較好。

在我所服務的公司中，也在大力倡導Scrum模式下的敏捷開發；基于我個人的感受，在sprint plan時，對于得到一個滿意的estimation，覺得有些糾結。 我們現在采用的是基于歷史數據作估算，對于前面幾個iteration的相應規模如果有較大的起伏，我們采取了一種取歷史上多個iteration規模取移動平均值的做法。 我注意到你在文中提到，資源利用率通常是在75%，對應的velocity似乎是6，我想這是個比較理想的利用率。在我所在的scrum team中，team size是4， 但是資源利用率看起來似乎是56%左右，velocity相當于是 4.5個 ideal person-hour每工作日。 在如何看待這些metrics指標的事情上，我個人覺得脫離應用場景單看指標的做法沒有太好的指導意義，就如同掙值算法中的cpi/spi。而實際我們嘗試提高velocity的時候，可能會導致最終在task估算時候，task規模估算結果難免摻水；最終velocity上去了，但是生產率實際沒有提高。同時團隊成員也不大情愿做這樣的事情，畢竟他們在這樣的模式下已經工作了很久（不否認他們的productivity，team size小，近距離的觀察表明了沒有明顯損失效率的工作習慣） 在遇到此類兩難問題時，我首先的立場是盡管velocity是4.5這個較低的水準，但是由于團隊對task的估算結果使用了”干貨策略“，而且即便如此也存在偶爾加班的情況，所以實際的生產率不會是4.5所體現出來的這么低；但是另一方面，4.5這個velocity在向PMO做匯報的時候，往往容易引起誤解。 不為提高velocity而提高velocity，畢竟目標是提高productivity。不過就上述情形而言，我們的項目組織和流程上，是不是也存在一些問題？ 我們現在用的是hours-burndown, 最近在看story point方面的內容，在這方面是否能夠找到改進機會呢?

最后，稍微表達一下歉意，在郵件中串了不少英文單詞，可能是因為習慣，很多時候覺得英文單詞的意思會更準確些。期待你的答復，祝工作順利！

Zhang：請問你們用什么來表示sprint的規模？ 是用理想人天吧，還是用戶故事點數？
由于Scrum/Agile中的不少詞沒有確切的中文，只能夾雜E文。

Chen：我們采用了理想人天的方式，例如velocity是4.5，

表示一個工作日相當于是 0.56 個理想人天 (?4.5/8), 以一個sprint兩周來計算的話，sprint規模的計算公式是： ?velocity * 項目人員數量 * 10個工作日 ， 這里的數量單位是： 人-小時數 由于現在的項目進度每日進度跟蹤現在非常依賴于 JIRA，而JIRA目前只提供了hour-burndown, 所以故事點數暫時沒有推行。

Zhang：敏捷是基于信任的，秉承的是Y假設。

敏捷本身不鼓勵外面給團隊設定velocity要求。
采用理想人天后，在技術手段上就更加沒有特別好的手段來從外面給團隊設定velocity要求。

什么算一個理想人天，由于處理的事情多種多樣，是很難歸納的，我猜想你們也許沒有一個恰當的定義。
我想推薦給你們的是 積累典型樣例（不知道你們是否已經這么做了？）。 什么樣的典型事務 算1個理想人天，什么樣的算5IMD。
有了這些積累后，理想人天就相對客觀。
當然這些積累不是不變的，隨著時間推移要變的，否則可能會出現資源利用率大于 100%的事情來，這個解釋起來更麻煩。
團隊有了相當比較客觀的基礎后，就可以在樣例和數字上做文章了。
以上也許只是數字的提高，
真實的提高是要靠真正提升團隊的能力、熱情和氛圍，敏捷團隊建設不是個快速過程，不能照著某些敏捷文章描繪的美妙場景馬上推進，小心敏捷的烏托邦。
如果采用Story point 或者 UCP，那么在技術手段上 會比IMD要多一些方法。你們可以看下。
但是不會改變敏捷的本質，如果你們開發團隊認為IMD用得不錯，只是PMO有點意見，那就沒有必要改。

對付PMO，相信你有很多辦法：）

Chen：謝謝您的答復，我得到了很多啟發 :) 相信我已經得到一個比較合適的思路和方向

Zhang：能告訴我 你的思路和方向嗎？
另, 可以把 你的問題和我的回答 放在我的blog上公開嗎？

Chen：完全沒有問題，我覺得把這個thread放到blog上，

能夠獲得更大范圍的知識討論和共享，對于各方來說都是件非常有益的事情。

關于思路和方向，在那個時間我當時的想法是針對于PMO的問題，我大致上可以有一些合理分析：首先是以什么樣的標準，來界定日常工作中的某個時間是劃分到ideal時間內，例如各個team是否統一這樣的一個共識，這樣橫向比較的結果才更加客觀。（例如A team，對于research的討論，不認為是ideal hour， 而B team則劃歸為ideal hour，這樣比較A和B的velocity，自然是不夠客觀。）基本上我認為這是個PMO需要澄清的問題。

現在我在想法上，更好的思路可能應該是，PMO提供支持和幫助，而對于上面提到的ideal標準問題，盡量避免嘗試推行一個“放之四海而皆準”一個客觀標準，因為這畢竟有X假設的傾向，而且不利于Scrum團隊的自組織，但是可以推行一個參考而非強制的標準。

沒有觀察就沒有發言權，如果你（PMO）有質疑，那么歡迎你抽出一些時間，作為chicken角色和觀察者，抽出一些時間來參與并幫助我們分析和改進實際的生產力；如果只是要velocity的report好看，這個通過投巧的辦法，實在是太容易做到了。

Zhang：PMO的X假設傾向 在有些組織里得到更高層領導的支持。
而且在以PMBOK為代表的項目管理理論上，并不排除X假設，并不全盤采用Y假設。感覺在PMBOK中，秉承的是中庸之道，XY各占一半。

PMO的X假設傾向做法雖然跟敏捷方法有抵觸，但從公司級管理看，不會沒有道理。敏捷的項目團隊需要適應這種環境。如果一味的強調"團隊決策自組織"，而與公司級管理措施抵觸，我以為是沒有必要的。

總結

以上是生活随笔為你收集整理的关于Scrum中sprint的规模估算的对话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。