Scrum之Sprint

之前谈过了Story Points的一些基本概念和简单的估算方法，但是同时也留下了一个疑问，就是估算Story Points的作用到底何在。其实Story Points不是一个孤立的概念，要和Sprint配合使用，才能体现Scrum相对于传统方法的优势。

何谓Sprint

Sprint直译的意思是冲刺。放到Scrum的语境中，我们认为一个项目在时间域上可以分为若干个固定时长的“冲刺周期”，也就是若干个Sprint。在每一个Sprint开始的时候，我们都要制定当前Sprint需要完成的任务，然后努力在当前的Sprint中“冲刺”，即努力的完成既定的任务。

Sprint中的基本概念

Task

在每个Sprint的开始阶段都要定义若干个该Sprint中要完成的Task，即任务。这里的任务要和估算Story Points时用的任务的概念做一个区分。在估算Story Points中的任务是指一个相对大的功能，比如对学生成绩的增删改查。而这里任务是对其的细分，相当于子任务，比如对学生成绩的新增可以单独作为一个任务放在此处。当然，可以把估算Story Points中的任务直接放到当前Sprint中而作为一个任务，这样做的前提是任务足够的小，具有较高的可估算性。我所在的项目组一般都会将估算Story Points时涉及的任务进行进一步细分，再分发到不同的Sprint中来完成。

Effort

当前Sprint中的每一个Task都需要估算一个Effort。所谓Effort，就是完成一个Task所需要的工作量，其估算方法和传统的人/月方法类似，一般也是用人/时或人/天的方式来估算。当然Effort必须由Task的完成者自行估算，而不是由项目经理进行统一的估算。

如何操作Sprint

首先，既然一个Sprint是一个固定时常的周期，我们必须先指定一个Sprint的时长。通常一个Sprint的长度会被定义为10天到15天。假设确定了一个Sprint为15天，则未来的每一个Sprint都必须是15天，这是必须严格遵守的。同时要注意，这里的15天应该是指15个有效工作日，也就是说我们必须扣除掉周末以及法定节假日，同时还要扣除大家都无法进行项目工作的天数。比如整个项目组参加项目会议或者参加培训花费了一天时间，那么这一天时间也不能计算在这15天之内。

现在我们知道每一个Sprint都是15天，那接下来显然是在每一个Sprint开始的时候，定义当前Sprint需要完成的Task，以及每个Task需要多少Effort。假设我们设定一个Sprint为15天，那么在这15天之内我们可以完成多少个Task呢？问题的答案也这正是Scrum体现其优势的地方，我们举一个例子来说明。

假设我们现在有一个功能，需要实现对学生成绩的增删改查。这个功能通过前一篇文章介绍的Story Points的估算之后，被认为具有5个Story Points。同时项目组决定，该功能具有高优先级，需要最先完成。于是在整个项目的第一个Sprint中，我们就要着手完成这个功能。按照之前的介绍，我们应该对该功能点进行细分，很显然，我们可以将其细分为新增，修改，删除，查询四个子任务。那么，在即将到来的第一个Sprint中，我们应该安排哪些任务呢？Scrum对此的回答是，既然不确定，那就不确定吧！换句话说，Scrum并不纠结于一个Sprint应该完成多少任务，而关注一个Sprint实际完成了多少任务，只要项目组成员各自正常的工作，能完成多少，就完成多少。

按照Scrum的思想，我们回到上面的例子。既然关注的是实际完成的任务量，那就随便选两个先做着，能完成则完成，不能完成则不能完成。比如我们选择先完成新增与删除功能。决定了要完成哪些任务，接下来就是估算每个任务需要的Effort。假设项目组成员就A和B两个人，A做新增，B做删除。A估算自己需要10天可以完成，而B估算自己需要15天可以完成。所有的准备工作都结束之后，A和B信心满满的投入到代码的编写工作中。这里还要注意，估算出的Effort并不是一个摆设，它是用来对单个任务的进度进行追踪和管理的。也就是说，项目经理每天都必须和A，B两人确认各自任务的进度，并予以记录。

时间流逝，8天之后，A发现新增功能已经顺利完成了。于是他选择了修改功能来作为他的下一个任务。当第一个Sprint结束的时候，项目经理发现，4个任务中，新增和删除功能已经全部实现，而修改功能也已经完成了50%，查询功能还未开始实现。于是项目经理可以估算出，一开始对整个功能模块估算的5个Story Points已经完成了大概3.5个。换句话说，项目经理实际上掌握了项目的进度，即在一个Sprint中，项目组在正常工作状态下可以完成3.5个Story Points。在接下来的第二个Sprint中，项目经理就可以根据第一个Sprint所获取的数据来安排工作。

如果把这个例子推广到实际工作中，假设一个项目被估算出共有200个Story Points。按照上述方法经过一个Sprint后，完成了20个Story Points。那么我们可以大致的认为整个项目的开发速度为20Points/Sprint，即我们需要10个Sprint才能完成所有的工作。在经过第二个Sprint后，我们发现在第二个Sprint中完成了30个Story Points，于是我们对两次的速度做一个平均，认为我们的开发速度应该为25points/Sprint。这样我们需要8个Sprint来完成项目。以此类推，以后的每个Sprint都可以得出一个速度值，将此速度值加入平均值的计算，从而一步一步的得到一个稳定的速度值，进而较为准确的估算出完成项目所需要的Sprint数量，也就是完成项目所需要的时间。

总结

从这里我们可以看出，Scrum中存在两种时间管控体系。一种是Task与Effort之间的管控，另一种是Story Points与Sprint之间的管控。前者是用来保证在单个Sprint内部，任务可以按照既定的计划顺利的完成。而后者是从宏观的角度，估算出整个项目所需要的Sprint数量，从而估算出项目所需要的时间。

Scrum又是一种迭代的体系。从项目角度来说说，一个项目就是若干个Sprint的迭代，每一次迭代之后都可以用Story Points来估算出项目进度。从一个Sprint的角度来说，每一天也是一次迭代，每次迭代之后都能较为精确的把握单个Task的完成时间。