從老板到項目成員,如何從燃盡圖中洞悉團隊工作?
燃盡圖可以預測團隊何時完成工作,也可以用于任何可測量的進度隨著時間變化的項目。無論是老板還是項目成員,都要學會從中獲悉團隊進度,預測團隊項目發展方向。
全文概要
- 什么是燃盡圖?
- Sprint燃盡圖要怎么看?
- 我是老板,初次看到燃盡圖,有點不適應。
- Sprint和Epic燃盡圖是怎么畫的?
- 還有什么方法可以衡量敏捷開發團隊的工作?
一、什么是燃盡圖?
燃盡圖(Burndown Chart)是:以圖表展示隨著時間的減少工作量的剩余情況。
工作量一般以豎軸展示,時間一般以橫軸展示。
燃盡圖對于預測何時完成工作很有用,燃盡圖可以用于任何可測量的進度隨著時間變化的項目,包括在敏捷軟件開發中,如:Scrum。
燃盡圖可以用在Sprint中,也可以用在Epic中。
燃盡圖可以清晰的呈現每個時間段有多少已完成工作,還剩下多少工作。以此,預測團隊在剩余時間中完成工作的可能性并為當下sprint和未來sprint做出規劃。
項目中的每個人都需要看得懂燃盡圖。
例子:
(圖片來源:http://www.agilenutshell.com/burndown)
- 橫軸:顯示工作天數 (星標點是當日時間。一般價值點數按日計算。)
- 豎軸:顯示剩余工作 (生產價值,在每個沖刺計劃會議的時候,團隊就應該估算出每個故事的價值,上圖例子中的160就是所有故事的價值總和。)
- 計劃剩余工作曲線:該曲線實際上是一條直線
- 實際剩余工作曲線:該曲線受團隊實際工作效率的影響在計劃曲線上下浮動
所以,這個表中我們可以看到:
- 有多少工作已經完成?
- 有多少工作需要完成?
- 每天都干了多少價值的工作?
- 當下的工作速度是否跟得上計劃?
- ……
二、Sprint燃盡圖要怎么看?
清醒一點,現實中的燃盡圖幾乎沒有辦法一步兩步按計劃走。
很多時候,會發現和想象的不一樣,比如:新的需求義無反顧的來了,理想太豐滿現實完不成工期了,再或者在老板的重壓下團隊效率大爆發了……
(圖片來源:http://www.agilenutshell.com/burndown)
這里我們來聊一聊幾款常見實戰燃盡圖,我們可以看到什么本質。
Dusan Kocurek給了一些比較好的分析,需要強調的是:同一個圖背后的故事千變萬化,Dusan的分析可以作為比較好的參考,但仍然需要根據實際情況分析。
1. 優秀團隊燃盡圖
優秀團隊:
這種燃盡圖說明該團隊可以組織好工作。
產品經理明白迭代的工作量,Scrum master 能夠幫助團隊完成任務。團隊沒有超負荷,并按時完成迭代工作。該團隊可以正確估算自己的能力,迭代過程中也不需要改正。
哎喲不錯團隊:
這是典型的工作進度燃盡圖,在很多有經驗的敏捷團隊的工作中都可以看到。該燃盡圖說明團隊可以按時完成任務,調整以適應迭代中的積壓任務,額外努力工作以完成任務。
該團隊需要自我反省,在迭代初期看到進度減慢就應該立即討論如何變動計劃。
2. 需要調整的團隊燃盡圖
“太快啦”團隊工作燃盡圖:
燃盡圖顯示團隊比預期早很多完成任務。那么有可能他們對自己的力量一無所知。
團隊完成了需求,也沒有繼續完成其他任務即使團隊有時間和精力這么做。這種情形下,需求可能被高估了,所以團隊提前完成了任務。團隊的工作速度沒有被合理的估算。
“太遲啦”團隊工作燃盡圖:
這種燃盡圖明顯在說:“你們沒有完成工作。”
這種團隊整個迭代過程都在遲到,沒能合理調整工作。燃盡圖還顯示出團隊沒有完成需求,這些需求應該被進一步分解,或者挪到下一個迭代中。
3. 新手團隊燃盡圖
“管理層要來了”團隊工作燃盡圖:
這種團隊可能沒有更新自己的工作進度。這里一種情況可能是產品經理增加了一些已經完成的工作,所以燃盡圖時機工作曲線是直線。比如:突然之間活兒有一段滑坡。理論上,是因為故事分的不夠清楚,或者估算不夠準確。
“上天”團隊工作燃盡圖:
團隊第一個迭代一般來說都是這種燃盡圖。
這種情況是成功之母,很明顯團隊沒有完成任務。每天都有需求或任務添加到跌倒工作中來,卻沒有記錄任何工作季度。另一個原因可能是迭代中的任務不斷地被重新估算。
三、我是老板,初次看到燃盡圖,有點不適應
初次嘗試敏捷開發的團隊,有一個難點是:怎么讓不怎么懂技術老板更舒服地敏捷開發和燃盡圖?
因為老板初次看到的燃盡圖,幾乎不會是優秀團隊燃盡圖, 而是需要調整或者新手團隊燃盡圖。
此時,他們的心理反應是:
- 一個沖刺過去了,KPI沒有完成……
- 一個沖刺過去了,KPI沒有完成……
- 一個沖刺過去了,KPI還是沒有完成……
請一定給老板打好預防針,燃盡圖是一個估算怎樣可以更高效產出的方式的參考。
估算這件事,可能需要5個沖刺左右才會開始慢慢接近起來。
事實上,不通過估算的KPI意義也不大。
因為稍微有點經驗的程序員,經過幾個沖刺的適應期,可以輕輕松松控制整個圖的走向。
我曾經合作的團隊,程序員曾經開始有意識地控制自己可以做的任務價值數量,在花一半時間做完任務后,每天關閉一個任務,燃盡圖是這樣的:
再來,太快了團隊燃盡圖,和太慢了團隊燃盡圖,看上去,是太快了提前完成了任務。但也有可能太慢團隊一開始估算了太多價值,即便產出了比前者更多的價值,看是沒有完成之前估算的任務。
所以,燃盡圖的定位不應該作為一個唯一/核心的KPI。
個人的經驗是:只要可以按時完成產出,團隊的工作安排合理,就可以關注其他的指標。
四、燃盡圖是怎么畫出來的呢?
9012年了,我們要學會用工具。
我們以功能齊全而復雜,速度不在國內也很慢的Jira為例。
1. Sprint燃盡圖
- 確定衡量方式:在J中,工作量可以用故事價值,工作時間來衡量。
- 估算每個任務/Issue:這一步往往在Backlog refinement的會議中由團隊一起討論確定。比如故事價值一般會用斐波那契數列, 1,2,3,5,8……來估算。Jira中,直接填在對應estimate位置。燃盡圖最大的挑戰正是怎么做估算!(所以在此挖個坑:估算這個坑)
2. 生成燃盡圖
在Jira中,選擇需要的Sprint, 點擊reports, 就可以可以輕松容易的生成燃盡圖啦。
3. Epic燃盡圖
此外,Jira還可以生成Epic燃盡圖:
- ?Epic 菜單。
- 增加的工作:深藍色區塊體現每個Sprint加到這個Epic的工作量。這個例子以故事價值來衡量。
- 剩余工作: 淺藍色區塊表示剩余工作量。
- 完成工作: 淺綠色區塊表示每個Sprint完成的工作量。
- 預測項目完成進度: 報表區域會根據已有數據,自動估算出完成這個項目,還需要多少Sprint才可以完成項目。
五、還有什么方法可以衡量敏捷開發團隊的工作?
敏捷開發關注兩項指標;
- 價值Value
- 流程 Flow
大部分市面上的衡量標準都圍繞著這兩項。
本文由@一條翅膀 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash, 基于CC0協議。
我的理解:燃盡圖是一把尺子,只是一個參考和一種項目進度管理手段。目的還是項目成功,不要本末倒置就好。
寫的很有趣,謝謝分享。
謝謝支持!