由於公司要搬遷到幾十公里外更加遙遠偏僻的地帶，團隊有人員提出離職。主力開發盡失，這日子真是太黑暗了。於是匆忙新招了幾個同學。在新老交替的這幾個迭代，人員空前之多。新同學上手也很快，所以生產力反而一下提升了。這是黑暗前的黎明，閃耀這麼一下劃過天空。
開發產能提升了，但是需求分析與測試這兩個環節卻沒有變化。連我積累在隊列裏的彈藥都一下子被掃貨了。又趕上其他破事，東一個會議，西一個討論。Story分析與拆解都快沒時間了，原型就更不用說了。不過這倒促使我思考一下團隊到底怎麼配置纔是合理的比例。
從過去的歷史看，1個產品經理2周內能夠討論定稿的需求堪堪剛夠5個開發的工作量，1個web前端也僅僅是在迭代第一週保持較高的產出，第二週相對清閒許多，不時幫助開發搞一些調整。
測試在第一週以輸出用例爲主，夾帶進行一些Story的測試。第二週Story開始密集交付，測試也轉入以Story簽收爲主的活動。有些迭代只能完成90%+的Story，有些迭代又能夠在
第二個週四下午就完全交付了。從概率上看，這個抖動並不是很規律，說明“價格一直圍繞着價值波動”。每次的迭代需求包規模已經在團隊能力基線附近。團隊成員水平也有高有低，並不全是高手，粗心大意，思考不充分的現象也時有發生，整體水平中等。所以如果普遍水平較高的情況下，產品經理與開發、測試的比例有可能會下降到1:3:1。也就是說，1:6~1:3之間的是比較合理的配置。如果增加一個產品專員輔助，可以上調到1:7~1:8，實際數字可能是2:14:3。最後這個3因爲沒有資源所以沒有驗證過，不知道測試能否撐得住，如果要算上自動化測試的話，可能還要再加2~3左右。