Take you through burndown! ! !

In the use of agile company, we usually a few meters away from where you can see the team workspace various colors of notes, whiteboards, and other various charts. In agility we call these emission sources of information Information Radiator. It can be very good for communication projects, to present project status. One of these bending curve, called: burndown, it plays a very important role in our project, it can reflect the current sprint performance, schedule and risk. This is also agile coach and every team member needs to be able to "read" the map. So the question is:

What burndown? How to draw a burndown chart? Burndown common problem with typical and reflects the type of response? FAQ burndown on how and what process? There is no example of a practical project analysis? Above, it is here today to talk to share content.

Much gossip says Eric Batty please fasten your seat belts, older drivers to start up!

 

 

What burndown

Every day there are people moving bricks and bricks will be less and less. I.e. the total amount of work will be reduced over time every day, it will form a straight line (ideal state) extending obliquely lower right. High force grid point there is a similar representation of the geometric features of the pattern: y = kx + b (k <0, b> 0).

We usually express them in a coordinate system XY axis. Wherein, X-axis generally represents time (days), Y axis represents the remaining work. We named this: burndown.

Ideally, we are on time every day moving bricks, no soy sauce. Then it will be a straight line shape as shown below:

 

 

But in reality, how can we not fight soy sauce! So it will become a discount crooked, and will have a real curve say. We usually use the actual curve to identify the actual completion of the daily workload.

This is a good tool to show progress, and think about our project schedule before, either in the presence of PM's computer, or the existence of PM's mind ... not weeks PM briefed the meeting on the current schedule, the ghost know now schedule how the. Now we put this into burndown team workspace, so that everyone can see now the state of progress of the project. But also in the Daily Meeting will be updated simultaneously burndown chart, so you can give the team a sense of urgency. Transparency of information inside the team to bring self-stimulation, than the PM's instruction management is much better. So this is one figure burn a very important role.

How to draw burndown

We are meeting daily the Daily Meeting, each team member will introduce thing which completed yesterday, that these statistics is actually completed live, with the total amount - the actual completion of the work remaining to get the current time. Note that, Y-axis represents the current remaining amount of work done by 90%, and 1% do, do not call.

What are the common types of burndown

FIG Kane Mar will burn into seven case, the personal several modifications as follows based on the understanding and the actual situation:

Case1: perfect type. Wherein: a straight line. Graphics are as follows:

 

 

Unless this situation is God of your team, otherwise basically impossible to happen. If your team is a graph, it is likely to encounter a fake team: The burndown purely fictitious and any perfect purely coincidental!

Some Team leader overly concerned about performance, see burndown not perfect team being criticized. So the team will draw a perfect map, a look at the leadership, shouted: 666, this sprint we are working very hard, after work I went to dinner Hi skin!

 

 

Case2: beer belly. Wherein: arcuate, and has been over the actual curve above a line. Graphics are as follows:

 

 

The reason for this situation:

Preliminary demand estimate inaccurate. Team obstacles, team members limited capacity. The team has a strong self-adjustment capability, you can do a lot of extra work, not to complete the vision of goals did not come home. This situation should be noted, has been found early this question, we are in a high risk, it is likely that the sprint goal can not be achieved. In the mid-SM should be adjusted, such as:

当前需求,有没有其他优化方法可以实现。某一个人或某几个人在一个问题上卡住了,移除障碍。能不能跟PO协商,减少当前sprint承诺的内容,如果一定做不完那就跟PO协商,做高优先级的,其他的放到下个sprint。Case3:大S型。特征:前期啤酒肚,后期快速下降且在直线下方。图形如下:

 

 

这种情况说明团队的应变能力强,不断调整速度来完成目标。当然,也有一种可能是大家看到现在风险比较高,然后加班(多么痛的领悟,谁说敏捷没加班的,那得看是谁在做…),不把曲线降下来谁都别回家!!

 

 

Case4:小S型。特征:摇摆摇摆…我摇摆摇摆…… 图形如下:

 

 

这种情况属于正常情况,团队不断的在修正自己的速率,而且最终完成了目标。如果你的团队实际燃尽图与此类似,恭喜你。

 

 

Case5:TBD。特征:没终点,剩一些活做不完了。 图形如下:

 

 

可能情况:

领导压迫给活多,每天都有新需求。团队开黑打酱油去了,很少人做事。SM打酱油,无风险预估及处理能力。团队不能合理安排工作。遇到这种问题,还是要做风险预判。实在做不完的推到下个sprint,但千万别给这个sprint延长周期(比如2周调成3周)。规则一旦被打破,下次团队会不再遵守Timebox(时间盒),也就没有固有的节奏感了。

Case6:开挂。特征:直线下降,一直处于理想曲线下方。 图形如下:

 

 

可能情况:

需求被高估了,实际并没有这么多的活做。需求被删减了。公司来了新的鼓励师,程序员玩命工作,效率很高。这种情况最看不下去的就是PO,通常会鼓(ya)励(po)大家多领一些任务,同样,作为一名专(da)业(za)的SM,也应当鼓励团队多搬砖多领钱,这样才能给妹子买包包啊! SM要优化团队效率,保持稳定的节奏感。

Case7:上天了。特征:一直上翘。 图形如下:

 

 

这种情况曲线没有下降,反而一直上升,最可能的情况是每天都有新需求加入到当前sprint中。当然,也有可能是开发人员评估工作的时候太过于乐观,导致工作量不断膨胀,最后的结果是当前sprint必须终止。

以上情况描述了绝大多数情况下的燃尽图类型,SM要做的就是提前预判,风险预防,而不是等到了问题发生才去解决。

燃尽图常见问题

Q1:不知道怎么画

这种情况可能有:

团队成员都是新成员,没接触过敏捷,所以前期都是交由SM来绘制燃尽图,但是后期,最好是让团队成员来进行更新。没有工时估算,也自然就没办法知道做了多少活,所以最好是估算每个活动的工时。Q2:颗粒度大小问题

这种情况可能有:

一般来说Y轴常用小时数或者故事点数。颗粒度最好是1天可以完成的事情。这样不至于每天Daily Meeting都说同一句话:“我昨天做这部分的代码编写,今天继续……”。二来,可以更好的跟踪任务项,减少进度风险。这里面还有个问题是story数量的问题。如果story太少,我们画燃尽图的时候会发现折现非常明显,可能会让我们错误的认为当前速度及风险比较大。

Q3:测试背锅

燃尽图变成了Case5:TBD的情况,领导一问,开发同学异口同声:测试不给力,我们的活都干完了。

很多时候开发和测试是敌对的双方。研发小伙伴在sprint最后一刻才提交给测试,测试自然就没有时间来做测试的工作。然后就很无辜的做了背锅侠…

 

 

又或者,开发质量不过关,测试测出来很多bug,然后开发返工,导致sprint延期,开发小伙伴同声:你丫测试不给力,这么晚才告诉我有问题。测试同学继续背锅… 这种情况,我们最好不要把所有的故事都在同一个时间完成,同样,也要提倡团队跨职能发展,打造T型团队人才。

Q4:燃尽图日期加了1天

当还差1天的工作就可以完成这个sprint的时候(此时团队24h工作无休),你会怎么做?很多Team会在燃尽图加1天,这样就可以完美的抵达Y=0的点。

切记不可这么做!一旦规则被打破,团队成员也会认为这个时间都是可协商的,也会破坏固有的节奏感。这次加了,那下次还剩1.5天的工作量的时候,要不要加?

Q5:只统计某个工作量

燃尽图显示的是整个team的工作实际统计情况,而非单独开发或者测试的工作量(排除单一组件团队的特例)

Q6:燃尽图比较

如果公司有几个敏捷项目同时在运作,领导看到A组同学的燃尽图说到:“你看B组,他们速度多快啊,你们这速度太慢了,你们这周过来加加班吧,把速度搞上去…” 这种情况很明显是被 “懂”敏捷的领导给坑了。遇到个完全不懂的倒还好,最怕的就是一知半解的。

不同team甚至是同一个team,燃尽图都可能无法比较。比如有如下原因都可能导致燃尽图不同:

Story拆分的粒度是否统一。团队成员是否有变化。时间周期是否一致。story point的基准是否一致。燃尽图实例剖析

实例1:是否会画燃尽图?下图是某项目2天的执行情况,请问A B C三个点分别应该是多少?

 

 

分析:燃尽图中Y轴代表的是剩余工作量,掌握这个即可知道是多少数值。只有放到Done列表的,叫完成。

A=5+3+8+5+7=28 B=28-7=21 C=21-5-(8-3)=11,因为No.6这个编号的工作,8个点的活变成了3个点,所以剩余少了5个。再加上No.5完成了。故总计完成10个点的活。

实例2:截取了IT事业部某软件外包项目燃尽图实例,跟大家一起分享我们出了什么情况以及如何解决的。(2周为一个sprint,团队已经运用敏捷一段时间)

我们在每日站会上进行数据的收集和更新,然后根据SBI(sprint backlog items)来更新数据。

 

 

迭代1分析:

在2.27-28这一天实际曲线不但没有下降,反而上升。主要原因:(a)开始第一个sprint,需求梳理的不是很清楚,有新需求新增到SPI中(团队一开始是拒绝的,但PO比较强势,必须得加进来…)。

(b)工作项的分解不熟悉。task重新估算之后,用时有所增加。

此时项目已经出现了风险,而且有将近30个点新增。所以为了解决问题,符合预期。在2.28-3.1,我们采用了加班的方式。

 

 

3.1-3.2,仅下降了10个点,主要原因:(a)前一晚加班太晚,今天效率不高,还有几个同事休假。也可以看出,加班过猛也不是好事…效率最重要。

(b)有个技术坑阻碍了当前的项目进度,team研究好久都没搞定。

3.3-3.4 休息日。开发小伙伴顺便在周末研究了一下技术难题。3.5-3.9,从曲线的斜率可以看出,团队的实际速度高于理想速度,逐步贴近我们的理想曲线。到3.10号,我们还剩10个点的活没干完,只要原因:开发组将迭代版本提交给测试进行迭代系统测试导致。(a)开发将迭代版本提交给测试,遇到一些重要bug需要处理,导致待开发项也没有时间安排处理。

(b)估算存在一些问题,项目设置的冗余时间也已经用完。

 

 

迭代2分析:

鉴于在迭代1中最终有故事没有完成,而且团队在整个sprint中工作压力较大,所以我们在估算工作量总工时的时候,只挑选了400个点的工作,相比迭代1少了20个。这也说明在敏捷中,即使是同一个团队,每次能完成的工作量,也会有不同。3.17-3.20期间,从250点直落到150点,主要是由于抽调了部分的需求,放到下个迭代中。所以曲线直接掉到理想曲线下方。3.20-3.25,速率正常,3.25刚好完成所有的工作。总结

燃尽图作为敏捷可视化管理的工具,发挥着重要的作用。一叶知秋,作为敏捷教练应当能够从每一张图表、每一条折线,分析出项目背后的问题,防范于未然。燃尽图的数据来源于日常工作,出自于团队本身。所以数据的准确性,直接决定了燃尽图的价值。

怎么样的燃尽图才是有价值的呢?

数据要真实,统计全面。这样才能反映出task的执行情况。对于工作量的预估要尽量准确,这就对团队的技术水平有一定的要求。粒度的分解要尽量落实到每一天。太大的粒度无法跟踪,而且不利于工作的估计。

Guess you like

Origin www.cnblogs.com/xiebai/p/11494399.html