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