Scrum敏捷项目管理

公司开始采用Scrum流程已经有一年多的时间，每个team实施的效果都不一样。有的scrum小组感觉到开发效率的提高，也有听到另外一些scrum小组抱怨采用scrum后的混乱。Scrum流程看似简单，因为它只是一个框架，如果使用时缺乏正确的规则，那么流程的变革所引发的混乱和冲突也是在所难免。

花了两个晚上看了Ken Schwaber的《Scrum敏捷项目管理》，第一章让我温习了Scrum的原理。Scrum是经验性过程控制。“在过程运行根本机制相当简单易懂的情况下，典型做法是采用预定义的理论的建模方式。若过程复杂度超出预定义方式的能力范围，便应选用经验性方式”。实验性过程控制方法有3大支柱：可见性，检查及适应。Scrum的基础就是授权于项目开发团队，保证项目所有信息的共享于可见，短期（一个sprint）review，并根据结果对下一个sprint进行调整，以满足客户需求。

Scrum的优点在于它极大简化了Scrum管理中的责任与权力问题，其难点是Scrum的管理角色难度较高。

ScrumMaster这个角色类似PM，但是他没有控制和管理的权力。Scrum Master的权力通常是间接的，主要源自ScrumMaster对Scrum规则和实践的认识，以及他们为确保团队的遵守而付出的努力，ScrumMaster只是项目的推动者（felicitator）。作为一个ScrumMaster容易犯错的是对这个角色的认知错误，不能正确认识到ScrumMaster不是控制者而是建导者，不是上司而是教练。作为ScrumMaster不能玩忽职守，需要让团队感受到ScrumMaster的全心全意的关注并在任何情况下都能得到提供的保护和支持。ScrumMaster还有一个重要的职责是在Sprint过程中保护团队免收干扰，但也要灵活对待。（我们经常在一个sprint中，从Product owner或其它职能经理那边得到新的任务或影响当前sprint某些功能的变更，此时ScrumMaster要站出来对这些人说，需要团队变更的事项或新加的任务可以在下一个sprint开始之前大家再讨论，而有些时候，ScrumMaster不能保护团队在Sprint过程中收到干扰和干涉，所以造成当前的sprint的混乱状态）ScrumMastser必须保持所有事项都可见，并确保每个功能增量都具备潜在可交付性（比如功能经过测试是完整的，而不是开发只完成了代码的check in）。

产品负责人要规划项目总体需求，投资回报目标和发布计划。利用产品的backlog，督促团队优先开发最具价值的功能，并在其基础上继续开发。团队和产品负责人要保持合作，有效的沟通，沟通方式中面对面的交流远比文档有效。

在Scrum中团队自行寻找生产力最大化的方法，计划和执行任务完全由团队完成。ScrumMaster只是提供指导，建议和信息，还要克服管理团队的欲望，团队必须承担自我管理的责任。团队成员要保持工作同步，必须准确了解已完成和未完成的任务。

规划Scrum项目过程设计三个问题的解答：

·         项目投资人希望项目结束时能取得哪些成果？

·         每个Sprint应做出哪些进展？

·         如果使项目投资人相信该项目使有价值的投资，以及项目申报者有能力交付预期的收益？

启动Scrum项目所需的最监狱计划包括：一份愿景及产品的Backlog。愿景描述项目开发的原因和预期目标。产品的Backlog分解为潜在的Sprint和delivers。

Scrum的项目报告必须保持可视性，只有在全部事项对频繁检查和调整可视的情况下，Scrum才能有效运作。ScrumMaster必须清楚项目的状况，否则其他人更难以了解。