SCRUM-燃尽图
敏捷开发之“燃尽图之谜”
敏捷开发之“燃尽图之谜”
我们在进行敏捷开发的时候，一般都要画燃尽图，在我们理想的思维里面，燃尽图很明白易懂的，而实际使用的时候，你慢慢发现不是这么一回事，这究竟是怎么回事呢？
1 燃尽图的起点是迭代当天还是迭代前一天？
画的燃尽图的起点是迭代开始当天，还是迭代前一天呢？终点是迭代结束当天，还是迭代结束的下一天呢？我们通过敏捷管理工具JIRA观察，发现JIRA工具将启动设置为迭代开始当天，而结束点设置为结束的下一天。如下，迭代周期为2009年10月20号到2009年11月16号，而燃尽图的起点设置成了10月20号，结束点设置成了11月17号。
由于JIRA是一个自动统计工具，所以这样画没有问题，但如果是我们手工画燃尽图呢？一般来说，我们画燃尽图，有两个时间点，一个是在早上，一般是干活之前，一个是在晚上，或下班前。我比如说在21号早上（或20号晚上），我们一般的习惯是会标志上20号的那个点上，而不是标志在21号上，否则可能让人觉得奇怪，为什么21号还没有过，就开始给它画上点呢？所以，应该说，手工画图，更合理的方式是设置起点为迭代开始的前一天，终点为迭代结束那天。
2 用工时还是故事点来计算剩余工作量？
JIRA工具提供两种燃尽图，其实就是纵轴计算单位的不同，一种是用工时来统计，也就是工作量的小时数；一种是用issue来统计，也就是还剩下多少个故事。
我们细心分析，就会发现这两种统计方式都是存在问题的。用工时来统计，这是我们一般常用的方法，但工时准确吗？根据我开发这么多年的经验，一般在开发初期估算出来的工时，不是一般的不准确，而是很不准确，开发人员一般带有很严重的乐观倾向，总觉得做某个事情很easy，两三天就搞定，结果一周还没搞定，加上敏捷开发需要测试和问题修改等，结果工时是严重的不准确。另外，工时的统计量过分细化，很难精确量化，比如说，昨天剩余900小时的工作量，今天5个人，每个人干了8小时，那今天就剩下860小时的工作量了？你如果这个统计，那好，你的图形基本是和符合燃尽图的虚线了，你却发现，工时用完了，还有大量的工作量没有完成了。比较合理的做法，是我们每天再来统计剩余工作的工作量，如果是用工时，那光统计工时都很耗工作量了，而且问题是，如何统计呢？这能靠开发人员嘴上说说，然后管理员一顿狂计算。从这点来说，人天还好一点，只是工时仍然是一个不准确的值而已。
用issue来统计，你会发现更离谱，因为每个issue的工作量不一样，相差还挺大，而且，一般来说，issue都是比较粗粒度的，如果按照issue来统计，你会发现一连很多天，可能都是一条横着的线。
所以我建议采用故事点做为纵轴，所以故事点，是一个虚拟的基准单位，是用来做相对统计的，比如说，我估计一个迭代中大概有30个故事点的工作量，那这30个故事点大概是多少人天的工作量呢？对不起，不知道，但我可以在迭代前给你一个大概估算的值，比如说，我估算了1个故事点大概是4人天，那30个故事点就是120人天的工作量了。好了，在迭代二，假设4个人开发了一周，也就是花了20人天的工作量，照理说应该完成5个故事点的工作量，结果发现只完成了3个故事点的工作量，那好，我马上修正每个故事点工作量的估值，我们初步定成6人天，那么30个故事点就变成180人天了。
故事点的大小要计算合适，我建议是以半天到一天（不是一人天）做为大概的估算点，比如说，4个人开发，那一个故事点大约包含4～8人天的工作量，那么我们每天画图能够平均往下画1~2个故事点，太多了觉得统计麻烦，太少了觉得每天都没有变化。
3 只统计开发任务还是包括测试呢？
敏捷开发其实是以故事为单位的，它的一个完成过程是包含了设计、开发、测试、返工的，那么我们画的燃尽图是应该包含这4部分，还是只有开发呢？你可能会脱口而出，认为肯定是包含4部分的，而实际使用中，你可能发觉并不是这么一回事。
下面是著名的《硝烟中的SCRUM and XP》一书中提到的处理迭代关系的一种方法，
它的意思大概指：我们在迭代一完成后，即进行迭代二的开发，迭代二中间优先处理迭代一发现的Bug。
仔细观察上面的过程，上图的红色部分，其实是迭代一的测试和返工部分。这其实是在告诉我们，迭代一的真正结束时间，其实是1.01那个点，而不是1.00，而我们如果以1.00做为结束点的话，那么必然是到最后结束点的时候，我们的燃尽图是不闭合的。如果你硬性将设计、开发、测试、返工都画到燃尽图中，那么比如画出的燃尽图，必然往上偏离参考线，那么以这个做为调整工作量的参考，还有意义吗？
然后在看最后一个迭代，它跟上图的迭代一不一样，它除了需要处理上一个迭代的Bug之外，还需要处理本迭代的所有Bug，因为已经没有迭代可以继续处理Bug了。
所以，比较合理的方案，我觉得应该是这样的，迭代一去掉上面红色部分的工作量；迭代二则加上红色部分工作量，去掉划到迭代三的工作量；最后一个迭代只加上上个迭代测试返工部分的工作量。
这里还有一个问题，就是设计的工作量，设计工作并不是有开发人员完成的，而是由设计人员（架构师、分析师等）在迭代开始之前就完成了的，我们把这个迭代开始前进行的设计工作叫做迭代0。如果是这种方式的话，我们在迭代中就不应该统计设计时间。
这里还有问题，迭代一的时候，前期开发人员在做设计开发工作，测试人员投入就少，后期随着故事一个一个被开发出来，测试投入的工作量就大了，那么其实迭代一的图形，理论上的参考线应该不是一条直线，而是一条微微向上突的曲线才对。
4 测试Story就是不能关闭？
上面说了这么多，但说到测试，头就大了。对于开发，我们可以估算今天开发了1/5，明天开发了2/5，到了周末，功能开发出来了。而对于测试呢，一切数据均是虚幻，你不知道测试情况如何，测试出来的问题单少，可能是版本的质量好，也可能是测试不充分，它很难找到一个衡量测试效果的方法。另外，敏捷开发是按照故事来进行的，对测试来说，如何保证这个测试的充分？比如说，预计某个故事需要测试1周，那好，开发完成了，将故事移交给测试人员测试了一周了，没有发现问题了，那么是不是这个故事就可以关闭了呢？我假设关闭了故事点，那后续这个故事还能不能测试呢？很可能这一周中，测试人员就对这个故事没怎么测试，然后你满心欢喜，以为质量很好，哪知道，等转SDV测试后，却发现测试部开始大量提交这个故事的问题单了。
另外，一般认为不能对测试逼得太紧，太紧了，很可能会导致测试不充分。
那么，是任由故事迟迟不关闭，一直处于测试状态吗？还有啊，测试发现问题，需要开发人员返工，然后测试又进行测试，这个周期经常很长，导致故事点经常是处于“测试中”。
我觉得，其实这相当于一个长尾理论，前面的测试工作很集中，而后面则拖着一个长长的尾巴，我们可以定一个范围，比如说测试完成了90%，则转入关闭状态，这样就可以把后面的尾巴砍断了。如果对这个尾巴还不放心，我们还可以设置一种状态，比如说叫“测试验证状态”或“后续测试状态”，主要测试工作完成后，就可以进入这个状态了。
另外，测试工作总是跟随在开发后面的，开发完成一个故事后，测试才能真正对功能进行测试，这就导致测试的工作是无法平均分配的，有时无东西可测，有时一大堆测试任务。针对这种情况，首先是开发的计划需要做得比较合理一点，尽量不要把所有故事都在同个时间完成；另外，测试人员最好能够动态调节，把测试人员分为两部分，一部分是纯粹的测试人员，一部分则是由开发人员承担，在测试任务比较空闲时，开发人员做开发人员，在测试任务比较忙时，部分开发人员则承担起测试的任务。
5 中途加班如何控制？
因为燃尽图是一开始就画出了时间点，所以如果出现中途加班的情况，那是没有办法，当天的燃尽图就不用画了。
6 进度变动怎么办？
一般的说法，敏捷开发的进度是固定的，是不能变动的，但是在中国，啥事都可能发生。如果进度变了，我们可能有下面几种方法来解决：
1、 重新那张纸来画刻度。
2、 原先的刻度就不是画上去的，而是拿着橡皮筋别上去的，现在重新移一下
3、 弃用燃尽图
7 敏捷工具自动画燃尽图可信吗？
想JIRA这样的工具，都是能够自动画出燃尽图的，不过嘛，我觉得，这样的燃尽图根本是没有作用的，理由如下：
1、 燃尽图需要每位员工的很忠实的记录工作日志，少记、不记都将影响到燃尽图的效果
2、 工作日志是写在每个故事上面的，这样就会少记很多工时，比如说，8个小时中，有6个小时是处理某个故事的，有2个小时是处理邮件、接电话等，我们在故事写上真实的时间，往往比我们真实的会少。
3、 燃尽图中途增加本来已经计划过的故事，结果的图形会往上走。
最重要的一点，就是燃尽图本来就是比较容易统计的一个指标，按照JIRA等工具进行统计，结果往往是花了很大的力气，图形的走势仍需是千奇百怪，无法正常知道开发。还不如在每天晨会的时候，花点时间了解大家的完成情况，就可以画出一个正常的燃尽图了。