一个失败的案例

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

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

项目中影响Scrum实施的因素

有利因素

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

导致失败的原因

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

经验教训

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