对于那些在你的组织中实施Scrum的人来说,你最大的障碍是什么,如果你确实克服了它们,那又如何呢？
背景:2006年,我与一家大公司签订了合同,该公司在我抵达前几个月就采用了Scrum冷火鸡.该公司希望Agile/Scrum能够保存他们庞大的企业软件产品.在那里的一百多名程序员中,我与一个大约一年的团队密切合作一年,观察和参与他们的敏捷实验.
简介:我认为敏捷帮助的不仅仅是伤害.到今年年底,团队可以持续估计和生成功能,而以前他们的生产力相当不稳定.
实施:由于这是一个庞大的组织和一个大型产品,该项目是一个"scrums scrum".大约每15-20个开发人员就有一个scrum master,这些团队经常被分成较小的,紧密工作的scrums,大约6-8个人进行迭代.团队在很大程度上是独立的,可以调整他们自己的迭代频率(1个月到1周),并且在他们看到最好的时候给予了很多灵活性来实现敏捷.该公司定期引入敏捷教练(如Object Mentor)来帮助培训Scrum管理员,团队和管理人员.
障碍:很多.其中一些与敏捷有关,有些则没有.没有特别的顺序,这里有一些经验教训:
产品积压在开始时经常被修改.最终,团队和管理层花了几天的时间来检查所有功能,估算它们并确定它们的优先级.这是一个很大的打击,但它帮助很大.获得的经验教训:尽早获取产品待办事项并保持其状态.产品所有者必须清楚自己想要什么.
我们浪费时间尝试和处理时尚和炒作.当你开始时,你无法知道你是否正确地做事.有一种诱惑就是不断摆弄敏捷过程,将焦点从产品上移开.获得的经验:拥有经验丰富的敏捷教练确实有助于减少这种学习曲线.总会有人推迟任何实验.限制"尖峰"的数量.
一个好的Scrum大师是非常宝贵的.当然,在一开始,它是一个全职的职位.
这需要时间.在团队开始对这个过程感到满意之前,花了几个月的时间.
选择你的战斗.一些程序员可以理解为持怀疑态度,而另一些程序员则完全不喜欢并推动变革.允许一些灵活性.例如,强制使用产品积压和迭代计划,但不要求每个人都使用记事卡.对引入工具和编程方法(如结对编程或测试首次开发)特别敏感.
最后,保持沟通畅通并管理期望.
祝好运!
几年前,当我作为Delphi开发人员工作时,我设法让我的开发团队在一段时间内采用了Scrum.
整个过程对我们来说非常有效 - 让团队估计积压的优先任务给我们提供了有意义的目标时间框架,整个"管理工作就是消除障碍"非常棒.
最大的问题是这个过程总是被认为 - 并且被称为"Bevan的好主意".
虽然团队对我们获得的价值表示赞赏,并乐于继续使用Scrum,但团队并没有将scrum方法作为自己的方法.过了一会儿,我厌倦了"推动",我们"不再"遵循Scrum方法了.
经验教训:确保团队采用Scrum并拥有该方法.
京公网安备 11010802040832号 | 京ICP备19059560号-6 