在整個sprint開發過程中要做到資源合理和充分利用，並給予st預留閒置時間。
1. 每天工作時間為8小時，可充分利用時間為80%~90%，即8*80%~8*90%=6.4~7.2小時之間。
一般的，如果整個團隊配合時間較長，可以考慮資源利用率在90%，如果是新團隊或者專案剛給啟動，建議資源利用率80%。在團隊成長過程中逐步增加資源利用率，最多不要超過90%。防止任務過多影響sprint交付。
2. 在sprint前確定有多少人，沒人多少小時可投入到開發中。例如請假、公休日要排除在sprint外。
在整個開發過程中請假是不可避免的，盡量在sprint開始之前確定請假計畫。如果在sprint開始後，出現請假，可以根據實際情況調整開發任務，合理利用閒置10%時間，做到sprint正常交付，如果出現突發大量資源異動，則需要請po和pm確認是否將部分story移到下乙個sprint。
正常情況下我們可以根據公休日的情況，將每乙個sprint調整為等長的工作日。特殊情況，例如多國合作開發，每個sprint會是相同的自然日，而非工作日，此時需要在sprint之前考慮公休日，按照實際情況接收相應的point
3. 一般情況下這個team是不包含測試的，如果包含測試人員需要將開發與測試分別考慮，建議測試與開發的配比為1:4
測試人員加入到team中，會影響整個後期維護，測試人員比例越高後期維護開發人員工作量越小。理論上有測試的介入，開發階段解決的bug會更多，測試階段bug會相應減少。
例如：以下為6個開發，無測試或1測試或2測試，建議開發人員可最大使用的資源佔比
無測試1測試
2測試dev
90%90%
90%sit
70%80%
85%uat
80%85%
88% 案例：
sprint 週期：21自然日
scrum team：1 sm， 1 tl，6 st
point：1pts = 8h資源利用率：90%
正常情況下
這個團隊可以接受的工作量為： 6 * (21 - 6) * 8 * 90% = 648hpoint 數為 648/8 = 81pts
理論上如果每個sprint接受81pts 的工作量，則這個團隊可以正常完成。
假設當前sprint遇上國慶長假：
這個團隊可以接受的工作量為： 6 * (21 - 6 - 3) * 8 * 90% = 518.4h
point 數為 518.4/8 = 64.8 pts理論上這個sprint接受64pts的工作量，則這個團隊可以過乙個完美的國慶假期
如果團隊中增加測試人員，理論上不影響團隊的整體工作量。
我所接觸的敏捷開發
自從進入這個專案以來，我們採用的是敏捷開發，本部有八個專案組成員，客戶那邊有乙個on site，剛開始專案leader進行資料庫設計，以及任務模組分配，每個人都分到乙個或者幾個模組，然後進行開發，從頁面做到資料庫，這樣子下來每個人都對整個專案結構有個大概了解，隨著專案的進行，隔著一段時間，發布乙個版...
我所認知的敏捷開發
實習的第乙份工作是在某一線遊戲公司做遊戲客戶端實習生，大的公司或許在管理制度上的確要更加完善先進，這是不可否認的，整整實習了一年，差不多是半年的客戶端實習生，半年的專案管理實習生，那麼談談我自己對敏捷開發的看法。一.每日站會 剛到公司的時候，每天早上我都發現旁邊的伺服器組準時在10點，所有人站在一起...
我眼中的雲計算2 計算資源
隨著雲承載的業務在增長，雲的規模也在不斷膨脹，但批逐次增加的硬體存在著效能差別 摩爾定律還在生效中 單位功耗下硬體的計算能力不斷提高 此處僅關注cpu本身的效能以及cpu與記憶體系統的頻寬，簡單看nehalem架構與sandy bridge架構同頻cpu的幾個對比測試 superpi wprime ...