C项目敏捷实施(2)-第一次迭代

就这样，C项目组糊里糊涂的开始了敏捷之旅。在第一个迭代完成后：

基本情况

2011年2月21日-3月4日，项目组成员每天站在白板前进行每日站立会议。如果发现了需要讨论的话题，就在会后进行讨论。

2011年3月4日，项目组进行了第一次回顾会议。没有评审会议了，因为项目组仅完成了预估工作的不到一半，仅提供了一个Demo。

第一次回顾会议

团队在白板前进行第一次迭代回顾，会议总耗时一个小时。会议结果如下：

1. 做得好的

a)         成功完成Demo，所有Bug都修复了。

b)        每日站立会议对团队有很大帮助，可以清楚知道团队其他成员在做什么。团队协作比以前更好了。

c)         感谢美国团队的及时响应。

d)        感谢团队成员的认真负责，开发和QA联手解决了浏览器兼容问题，开发把Silverlight的单元测试集成到每日构建中。

2. 需要改进的

a)         UI是个瓶颈，开发流程不顺畅，有时会等待。

b)        没有完成工作计划。

c)         会议太多，时间太长。

3. 改进计划

暂略。

分析与思考

纠结的目标

第一次迭代是相当纠结的一个迭代。完成既定的任务，遵照Scrum的流程和建立自组织团队，这三个目标交织在一起。在其中还混杂着，证明敏捷优于以前模式的压力，这部分压力承载了证明自己的期许，公司管理层的期待和团队参与者们的期望。

残酷的现实

从很多方面来看，第一次迭代都不能算成成功。团队承诺的过多，甚至算不上团队承诺，而且不能顺利完成。工作流程中暴露出很多问题，瓶颈变得显而易见。

从乐观的角度看，也有些进步。团队在持续解决工作中出现的问题，合作与沟通也在进步中。

怎么办？

很多团队都是在第一、二次迭代中不能顶住压力，最后只好回归以前的工作方式。

1. 意识灌输

在暴露出的各种问题面前，团队显得无助，怀疑论正在成长。作为敏捷推动者，要知道“坏消息就是好消息”，不停询问团队“这样的问题在以前的模式中能够发现和解决吗？”让这些问题暴露出来，这本身就是敏捷实施的成果。

2. 顶住压力

不管怎样，项目交付的压力持续存在，而管理层因实施敏捷对团队的关注，导致压力持续增大。作为敏捷推动者，在这时候要顶住压力。一个好办法是告诉团队，管理层对团队当前的工作进度并不满意，让我们一起来想想办法解决这个问题。

3. 培养信心

作为敏捷推动者，不要过于强调我有好办法，要注意发掘团队的闪光点。这是培养自组织团队最有效的一种办法，认可和表扬团队的闪光点，培养团队自主改进的信心。