上一篇文章我们介绍了Scrum的背景，工具及大致流程。本次我们对估点及燃尽图进行详细讲解。
估点
具体操作为，先指定一个用户故事作为基准点数(1点，半点，或2点，一般不建议超过2点)。其他任务，跟这个用户故事作比较，进行评估。
为什么不按时间来估？
很明显，每个人能力不一样，同一个事情，基本上所有人需要花费的时间都不一样，难以统一； 而如果按相对难度来估，大部分情况下，应该都是差不多的，更容易统一。以下是估点的范围值：
无穷大和问号，都可以表示太复杂，难以估计，这时需要拆分任务。
为什么估点不是连续的？
这是为了减少估点难度，让我们聚焦于难易度，而不是纠结在点数上。比如一个任务，发现它比另外一个3分的任务要难一点，但比5分的任务要简单很多，则可以估为3分。EduSoho的做法是，超过5分的点，尽量拆分，让大部分任务都更容易预估。
如何进行确定一个任务的点数？
官方的估点方式是，各个组员把点数定好，统一亮出（防止互相影响），再看结果，最大的和最小需要进行PK，各自阐明理由，再新来一轮，复杂的用户故事往往会有很多轮（开发人员才会参与估点）。 估点是整个Scrum过程中执行起来最复杂，最费时的工具，5个人的小组，一周内容的迭代会中，估点要花2~4个小时。
EduSoho的做法是，最多2轮，第一轮亮出后，如果差别不大（只差一个级别），取投票最多的点数，相差如果很大，比如大部分为2，有一个是0.5，有一个是5，则由0.5和5分别说明，再投一轮，直接取第二轮中投票最多的点数。同时，Scrum Master事先和Project Owner讨论需求，将用户故事拆分，迭代计划会议上就不用做拆分操作，从而节约大量时间。
估点可以量化团队的交付能力。新团队前面几个迭代的估点非常不准，但估个3~4次，大家都有了共同的认识，每个迭代的估点就比较稳定，也就能知道团队大概能交付多少个点。同时，如果开发人员分职级，可以按照职级来要求每个程序员需要做多少点，当团队变动时，也可以根据变动人员的职级来调整团队的交付能力。
燃尽图
如上图，剩余故事点（估出来的点数，即故事点）的趋势图即为燃尽图。理想状态下，是一条线段，最后一天是0。通过画燃尽图，能让大家一眼看出是否有进度风险。但实际上，可能会发生需求变更，导致中途点数反而变多了。EduSoho的做法是，固定迭代中的点数，当有新任务进来时，Scrum Master估点，然后和Project Owner协商，移除一部分点数的任务，保证总量大致不变。
EduSoho额外引入的环节
项目启动会
一个项目启动时，整个团队会叫上相关的销售，市场，运营，由Project Owner和Scrum Master介绍需求，给出项目截止日期，仪式感很重要。
项目演示
整个项目结束后，整个团队面向整个公司做演示，并且提供直播，让全部小伙伴了解相应业务，同时给整个小组带来荣誉感。
EduSoho官网 https://www.edusoho.com/
EduSoho开源地址 https://github.com/edusoho/edusoho
我们正在寻找开发者