一个失败的案例

最近有一个新的项目团队在开发一个新的功能，并且决定尝试用Scrum，非常有幸被邀请加入，担任ScrumMaster。一开始的时候一切似乎都很顺利，我们召开了一次项目的启动会议，请负责的产品经理明确对结果的期望，并且进一步确定了PO的职责。更让我觉得好的是，由于这个项目的产品设计人员和专职的测试人员都在国外，为了确保质量，大家都同意本地的开发团队（都由开发人员组成，没有测试人员）不仅要关注代码开发，同时也要承担测试任务。国外的测试人员将作为PO的助手，帮助对结果进行验收测试，而产品设计人员帮助PO细化需求，为产品的Backlog。而且，一个初步的产品Backlog已经建立，包含了希望交付的功能，虽然不是标准的用户故事的格式，但应该还是OK的。一切看来，都很顺利，没想到，执行到第三个Sprint的时候，国外负责这个功能的产品经理突然要和PO，还有我一起开一个电话会议，提出项目在11月中旬需要发布一个版本，以便让一些用户能够尝试使用，给出反馈，这本身不是问题，真正的问题是，在会后，突然发出邮件，决定停止计划会议，每日例会，回顾会议等等，也就是停止一切Scrum的相关实践，作为ScrumMaster，从我的角度，这无疑是宣布了Scrum尝试的失败！

所以，我也花了一些时间反思这个项目，为什么会失败？

项目中影响Scrum实施的因素

有利因素	不利因素
一开始得到了高层管理层的支持 团队中有人参与过Scrum项目，有Scrum的经验 团队有4人组成，技术经验都很丰富 之前已经做了较长时间的技术研究，团队对功能的理解比较充分	除了一个人有过Scrum项目经验，其他人都没有参加过相应的培训，而项目开始后，也没有安排时间进行一个初步的介绍（非常失败） 团队里大多数人并不理解为什么要用Scrum，只是被要求用Scrum PO在另一个城市，而且很忙，没有足够的时间维护产品Backlog，和团队沟通 产品设计人员远在另一个国家，不利于具体需求细节的沟通

导致失败的原因

• 动机不清
  对于为什么要用Scrum，希望Scrum的实践帮助解决什么问题，或者对Scrum的期望是什么，没有想清楚，这样会导致当在项目过程中遇到困难的时候，对最初的决定产生怀疑；
• 职责不明
  对于Sprint的目标，产品Backlog中的优先级设置，除了PO，国外的产品设计人员也会进行调整，并且没有和PO进行充分的沟通，导致目标不清，需求不明，从而给沟通带来极大的混乱；
• 缺乏培训
  团队成员一开始的时候没有安排时间，接受有关敏捷和Scrum的基本培训，因此对于敏捷的价值观，Scrum的实践都不清楚，因此在项目执行过程中，经常会对一些敏捷的实践产生不理解和抵触的情绪；
• DONE定义不清
  由于目标不清楚，导致团队对于DONE的标准始终不清楚，因此计划会议总是效率不高，也经常造成很多的争论；
• 过度干预
  由于受到市场的极大压力，高层管理层对于Scrum开始实施出现的问题，即没有真正了解原因，也没有足够的耐心，只是简单的将原因归结于会议太多，效率不高，并移除所有的会议，终止了Scrum的实践，就像鸵鸟遇到危险时，会把头埋到沙子里，似乎看不见就不会有危险，其实真正的问题正是那些导致会议和沟通低效的因素，而不是会议本身；

经验教训

1. 任何团队在决定实施Scrum之前，一定要先想清楚，“为什么要实施Scrum？”，帮助我们真正了解我们的需要在哪里，让我们对于Scrum的实施有一个清楚的目标设置，这回帮助团队在实施过程中不断检视和调整，克服困难，同时也能够帮助团队保持耐心和信心；
2. 在开始实施前，一定要为团队以及相关的人员提供有关敏捷和Scrum的基础培训，了解敏捷的价值观，了解敏捷实践背后的驱动力，只有理解了“为什么要做”，才能真正达到敏捷实践的效果；
3. 找到合适的人做PO，不仅是这个人对于业务或者需求很清楚，同时这个人需要能够有足够的时间和团队一起工作，帮助团队理解需求，制定目标，同时需要对于敏捷的需求管理有足够的了解；
4. 从一开始就对DONE的标准有一个明确的定义，并让所有人，包括团队，PO和其他相关人员都清楚了解；

转载于:https://www.cnblogs.com/RelaxTintin/archive/2010/10/26/1861661.html