本文要點
- 敏捷團隊通常會參與交付業務的重大里程碑，這種里程碑是業務在特定時間點所期望的，相關的預算也是商定好的。所以團隊需要做好預測，否則就可能會被指責"敏捷卻遲到"。
- 根據邏輯，項目延遲有六大可能的原因——也就是“邏輯六成因”。其中的三條因素是在技術團隊控制下的：低估工作量；缺乏可用的人才；並且缺乏團隊生產力。另外三條是發起人控制的：需求不明確；範圍變更；並且缺乏所需的持續投入。
- 有一些指標針對的就是這六條潛在的延遲原因——測量這些指標以提高預測的準確性是至關重要的。
- 這些指標需要從多個數據源中總結出來，因此需要端到端的交付指標/分析平臺，否則這些指標就很難評價。
- 然後可以使用這些指標創建紅色/琥珀色/綠色（RAG）根本原因進度報告——與發起人共享更準確的預測和明確的改善措施，並分配責任來實施已確定的改善措施。
我們合作的敏捷團隊有着多種多樣的規模和形態，而可預測性幾乎是所有主題的重中之重——因爲“敏捷”和“可預測”這兩個詞並不總是相輔相成的……
那麼開發團隊如何才能保持敏捷並提高交付的可預測性呢？做到這一點，當利益相關方問到關於可預測性的問題“我們是不是在如期推進？”，他們纔可以給出一個有意義的回答。
典型的敏捷團隊預測方法
基於產品的敏捷軟件開發團隊會頻繁交付小幅度的增量改進，可能很少花時間來操心預測的話題。
但是，敏捷團隊往往需要交付一些重大里程碑，這些里程碑是業務在特定時間點所期望的，相關的預算也是商定好的；因此團隊需要有效地預測，否則就可能被指責爲“敏捷卻遲到！”。
根據我們的經驗，敏捷團隊的預測往往很不準確，並且通常僅基於團隊本身對積壓、速度和口頭保證的簡單觀察結果。
我們認爲，真正有意義的預測需要更廣泛的經驗數據集，以反映會導致項目延遲的所有潛在因素。
像這樣的“項目”環境中是否適合使用敏捷軟件開發方法，還有另一場爭論，但這就是另一個話題了
“邏輯六成因”——項目延遲的六大原因
邏輯表明項目遲到可能有六條成因——也就是所謂的“邏輯六成因”。六成因中的三條是由技術團隊直接控制的：
- 任務的大小和複雜性被低估了
- 計劃中符合需求的工程師小組並不可用
- 交付團隊的交付效率不及預期。
其他三條由與技術團隊互動的業務發起人控制。這些是：
- 需求定義不清晰——內部客戶對他們實際想要的東西不夠清楚
- 範圍變更——業務目標內容變化（變更/新需求或優先級改變）
- 持續的投入——在需要的地方/時間缺乏利益相關者的投入而延遲了開發過程。
我們認爲，你需要收集跟蹤所有這六條槓桿的指標，否則你將永遠無法真正準確地預測，並提升交付的可預測性。
只有做到這一點，你才能真正瞭解一個項目是否可能“遲到”，以及需要做什麼才能使其回到正軌上。
"邏輯六成因"——項目延遲的六大根本因素
通過分析重要的交付指標來挑戰團隊的預測結果
那麼，與項目延遲的六大成因相關的測量指標都有哪些，它們對於交付的可預測性和預測準確性的提升是至關重要的嗎？
下表顯示了我們在每個領域中最喜歡的一些指標。我們鼓勵交付主管在與交付團隊負責人合作，重點關注這些指標，以做出更現實的預測。
概括來說，這些指標有：
- 人員可用性——顯然很關鍵。如果我們沒有所期望的工程師，我們將遲到。
- 團隊生產力涉及：
- 生產時間——另一大關鍵指標，考慮了工程師必須專注於編寫新功能的時間比例
- 流程效率——開發流程中的摩擦會破壞最佳的交付計劃。因此，真正瞭解這種摩擦的趨勢及其成因是關鍵
- 實現價值的速度和時間——瞭解我們的吞吐量和實現價值的時間如何隨着項目的進行而變化，是我們預測中的另一個決定性變量
- 估計精度——如果我們採用基於Scrum的方法，則衝刺的完成水平是衡量我們預測能力的很好指標。如果我們無法達到每兩週的衝刺目標，那麼我們就不太可能有效地估算工作量並進一步預測未來
- 可以使用從協作中心（如Slack）收集的量化工程師反饋來跟蹤需求定義、利益相關者的輸入和範圍變更。我們在內部經常使用這種方法來改進我們的預測，因爲它利用了實際工作人員的定量觀察能力。它通常會爲原本只在理論上的交付預測增添信心，並使人看清楚“邏輯六成因”中的三條（需求定義、利益相關者的投入和真實範圍變更）。
跟蹤導致項目延遲的邏輯六槓桿的關鍵指標
趨勢指標 | 相關性 |
|---|---|
可用的工程資源： - 活躍工程師人數（與計劃相比） | 顯然是關鍵——顯示我們是否有計劃的資源來交付工作。 |
生產時間 - 在新功能上花費的時間（%） - 花費在維護上的時間（%） - 與非產品相關的活動損失的時間（%） | 關鍵指標，用來了解隨着時間推移的趨勢變化。如果我們在非生產性任務上花費更多的精力，顯然這將影響我們的前進步伐。 |
流程效率 - 流量效率（%） - 返工（工作日） - WIP/開發人員 | 這些指標分析了開發過程中的"摩擦"及其隨着時間推移的趨勢。流量效率下降往往是一個可以解決的問題，因此它是改善預測的關鍵指標。返工顯示了處理未通過質量檢查的故障單所花費的累積時間趨勢。這是另一種形式的摩擦，可以改善（例如通過協助剛接觸代碼庫的工程師）。 注意：我們認爲，各個級別收集到的任何指標都需要直接參與項目的人員根據具體情況來查看。如果傳播範圍更廣，這些指標的評價可能會脫離上下文（具有破壞作用）。 |
實現價值的速度和時間 - 完成的功能門票 - 循環時間（工作日） - 交貨時間（工作日） | 速度指標存在自己的問題，但是在做出預測時，關鍵在於要對已完成門票的趨勢（以及每張門票的故事點/價值點）有着深度理解。對週期和交貨時間變化的理解也很重要。如果它們在延長，那麼做出準確的預測就很困難。 |
衝刺精度 - 總體完成率（％） - 衝刺總體完成率vs衝刺目標完成率（％） | 如果無法實現每兩週的衝刺目標，就很難做出較長時間的預測。因此，這些指標對於預測準確性而言至關重要。 |
量化工程師反饋 - 團隊士氣 - 衝刺效率 - 門票質量和要求定義 - 業務發起人的投入質量 - 與商定的範圍變更相關工作 | 一些指標平臺可以通過協作中心對工程師進行實時調研。這提供了以下定量數據： - 工程師對士氣和流程效率的看法；和 - 業務發起人的需求定義和持續投入的影響 - 團隊負責人對業務的利益相關方在原始範圍之外添加的故事的反饋。 |
收集重要的交付指標
關鍵交付指標需要從衆多來源收集數據，包括：工作流程管理工具、代碼倉庫和CI/CD工具——以及從工程團隊本身（通過協作中心）收集的定量反饋。
數據的複雜性和來源的多樣性使人工收集此類數據的工作非常耗時，需要端到端的交付指標平臺來大規模收集。
可行的交付指標平臺由以下內容組成：一個數據層，用於整理和編譯來自多個數據源的指標；一個靈活的UI層，用於創建自定義儀表板，以所需格式顯示指標。
使用根本原因RAG報告來改進你的交付預測和改善計劃
如果我們使用一些指標來跟蹤和分析影響項目進度的六大邏輯驅動因素，就能獲得更清晰的項目實際進度圖。也就是說：
- 更現實的交付預測
- 如果預測結果落後於時間表，我們可以致力於明確的改善計劃。
改進的預測和相關的改善措施可以在紅色、琥珀色和綠色（RAG）根本原因進度報告中一起顯示。
根本原因RAG報告要比傳統的RAG進度報告有效得多，傳統的RAG進度報告通常很少說明（具有所需上線日期）的項目落後於計劃的實際原因，以及需要做什麼才能回到正軌。
與傳統的RAG方法相比，根本原因RAG報告（請參見以下示例）清楚地顯示了：
- 我們最新的交付預測
- 支持我們預測的交付指標
- 我們的改善措施（基於驅動項目進度的邏輯六槓桿）——例如，需要減少用於維護的時間來增加生產時間；需要解決開發流程中的障礙（例如質量檢查等待時間）來提高流程效率； 或需要改進利益相關者的投入（如量化工程師的反饋所示）
- 爲了交付已確定的改善措施，在開發團隊和利益相關者之間分配責任的情況
能做得好的話，根本原因RAG報告可以是一種非常有效的方式，以利益相關者可以理解的方式呈現我們的（更準確的）預測，因此可以成爲減少延遲並使技術團隊與內部客戶聯繫更加緊密的重要步驟 。
但正如所討論的那樣，它依賴於對導致項目延遲的實際指標的理解，以及收集這些指標的方法。
根本原因RAG報告示例
作者介紹
Charlie Ponsonby在發展中國家開始了他的經濟學家生涯，隨後加入了安德森諮詢公司。他直到2007年一直擔任Sky的市場總監，然後在2007年離開公司，創立了Simplifydigital。Simplifydigital在《星期日泰晤士報》科技追蹤百強榜中三度登榜，併成長爲英國最大的寬帶比較服務。它於2016年4月被Dixons Carphone plc收購。2017年10月，Ponsonby和Dan Lee共同創立了Plandek。Plandek是端到端交付指標分析和BI平臺。它從交付團隊使用的工具集中挖掘數據（例如Jira、Git和CI/CD工具），以提供端到端交付指標來優化軟件交付預測、風險管理和交付有效性。Plandek的客戶遍及全球，其中包括Reed Elsevier、News Corporation、Autotrader.ca和Secret Escapes。
原文鏈接：
Agile and Late! End-to-End Delivery Metrics to Improve Your Predictability