最近的項目由于是新客戶的原因，客戶對我們團隊是沒有太多信心的。在接到項目的初期，客戶只表示，他們其中一個關鍵的OKR是9月底要完成XXX，能將該功能交給用戶使用，占領市場先機。
那客戶側對接的PO在我們開始進入交付之后，就開始一再詢問交付進度預測。他們需要看到目前團隊能到什么時候完成既定的功能需求。其實作為長期服務海外客戶的我來說，我又一次看到了海外客戶的人性化和講道理，哈哈哈哈。如果換做國內客戶，估計不會問你要預測，而是你作為一個乙方公司必須在他們需要的業務時間點上做完。通常這種情況，除了加人，就只剩加班。
為了完成這個預測，需要把目前計劃在上線范圍內的特性或者說故事卡整理出來，并且每個故事卡都有相應的估點，即團隊基于目前的技術棧和特性復雜度給出了相應的評估。那么你會得到一個總的點數，例如第一次上線的內容，55個點。
根據這個點數，我們需要考慮一下點來做大概的上線時間點：
- 團隊的請假概率，反面會得到團隊的可用時間
- 團隊里面TL寫代碼的時間分配，例如每天TL有很多技術的會議需要參加，也許只能花他個人時間的50%用來寫代碼。對于比較大的團隊，TL有可能完全沒精力寫代碼，時間都花在和比較Junior的dev進行結對，做分享，參與產品架構，方案討論等等。
- 團隊在初期估計的點數，隨著后期對業務和技術棧的進一步了解，會有一定數量的膨脹，不能指望團隊在初期就能考慮到實現層面的方方面面，做到全面估計。所以我們通常會根據最初的估算乘以20%左右的緩沖。這樣得到一個更合理的工作量。
- 團隊的人員數量，這個主要指團隊中直接貢獻進度的Dev數量。
- 根據團隊對新項目的了解和熟悉程度，會有一個漸進提升速率的過程，我目前所在的組織，會認為，第一個迭代團隊能拿出25%的時間進行實現，第二個迭代能到50%，第三個迭代75%，第四個迭代能全面開掛。作為任何一支新團隊，比較理想的是技術棧都非常熟練，不用花額外的時間學習，業務也是100%理解清楚，不用額外時間溝通。但現實經常是，團隊技術棧不熟練，業務也在持續熟悉中。因此這個百分比也是合理的。
有了以上的因素和變量，基本能得出團隊各個迭代的累積消耗量，便能得到累積的burnup 圖，也就得到了你的上線日期。
image.png
