中小项目敏捷实践之二（关于Spirit短计划）

**开发方法是一个系统工程，需要所有项目活动的相互配合。**

本心得是基于近两年两个中小项目(一个2000 Manday, 一个1500 Manday)的实践总结，希望能与大家一起探讨和进步。

- 用Spirit的方式分段计划
- 不得轻易修改执行中的Spirit计划 (项目总结)
- 每个Spirit的合理周期是3-4周
- 每个Spirit都定义出一个具体任务以外的目标，如：Zero Bug, 消灭加班，等等
- 保持稳定、合理的工作节奏，使团队进入“流”状态（推土机感觉）
- 使用Burn Down Chart追踪Spirit状态 (未实践)
- 白板(实践中断)
- 设置进度警报，如延时30%(未实践)《灾难拯救让软件项目重回轨道》P25


Spirit短计划

敏捷，要求项目组能够积极地拥抱变化。在实际项目中，唯一不变的东西就是变化。所以，项目开始时准备的大计划在两三个月后很可能已经与实际情况大不一样了。所以，与其为两三个月后准备一个没用的计划，不如将项目计划做粗点。每次只为接下来的一两个月做详细在计划。我们可以称之为Spirit短计划。每个项目由很多的Spirit短计划组成。直到开发完成。

之所以要定义短计划，不只是因为拥抱变化的原因。从目标设定的角度来讲，总是应该定义那些踮一踮脚就够得着的目标，在三四个礼拜之内就就让团队享受一下成功的喜悦，在接下来的三四周内再次享受一下成功的喜悦，在接二连三的成功的刺激下，团队的士气会出奇的高。从风险控制的角度来讲，每个Spirit结束都是一个Check Point，如果出现不正常状态，如超期，则应当及时采取措施，避免不正常的状态从一个阶段延续到另一个阶段。也就是说，应当将不正常状态尽量控制在特定的时间范围之内，从而保证其它阶段的正常进行。这和程序设计中的封闭性原理是一致的。

说白了，当某个团队成员由于个人原因不能完成既定的Spirit目标时，就需要他加班完成他的部分了，这是他的职责。当然，如果团队成员提出了合理的解释证明了不是个人原因造成的Delay时，项目经理就需要考虑是不是同意将这部分任务调配到下一个Spirit中。需要视具体情况而定，而不是粗暴地要求加班了。

其实，如果团队运转良好，每个团队成员都会尽心尽责地完成项目，加班就是变得主动，而加班也从苦差变成了一种追求。之所以这样说，是因为我们团队就出现好多次程序猿主动通宵，主动周末加班的情况，而我也只是后来从其它同事那里了解到的。能有这样的团队成员，夫复何求呢。

敏捷中的项目经理有责任维护当前Spirit的稳定性，例如，不得随意修改进行中的Spirit计划。不得随意在进行中的Spirit中加入新的任务。如果非加不可，则应当从当前Spirit中移除一些与新任务工作量相妨的任务。

我们曾经在项目中出现这个情况。

第一天：业务人员要求开发团队将系统从A改成B。
第二天：业务人员要求开发团队将系统从A改成C。
第三天：业务人员通知开发团队，改动取消了!

所以，更加坚定了我们进行强硬的变更控制信心。需要提醒大家注意的是，变更控制不等同于抵制变更，需要把握一个合适的尺度。

当项目组成功地完成了两个Spirit后，就会形成Group Flow。Group Flow是指整个团队作为一个整体进入了流的状态。

流 (Flow)，定义于心理学家米哈里(Mihaly)，指一个将个人精神完全投入在某种活动上的感觉。流产生时，会有高度的兴奋感和充实感。区别于Group Flow，Flow是一种个人状态。

当团队良好运转后，就会体现出一些自组织的特点，如主动要求任务，主动进行团队沟通，主动改进，等等。关于这一些，会在后面的团队部分详谈。

当然，做项目除了需要实现用户需求，也得在枯燥的编码生活中有一些其它目标，或者有一些趣味性。这时，我们可以给每一个Spirit设定个简短的目标，如实现共产主义，消灭加班，等等