敏捷(Scrum)采用--进展如何？

Question

对于那些在你们的组织中实现Scrum的人来说，你们最大的障碍是什么，如果你们确实克服了它们，是如何克服的？

Answer 1

背景：2006年，我与一家大公司签约，就在我上任前几个月，这家公司采用了Scrum的冷火鸡技术。该公司希望Agile/Scrum能够拯救他们庞大的企业软件产品。在那里的数百名或更多的程序员中，我与一个大约12人的团队密切合作了一年，观察并参与了他们的敏捷实验。

总结：我相信敏捷带来的帮助大于伤害。到了年底，团队可以始终如一地估计和生产功能，而在此之前，他们的生产力相当不稳定。

Implementation：由于这是一个大型组织和大型产品，该项目以"scrum of scrum“的形式运行。大约每15-20个开发人员就有一个scrum主管，这些团队通常被划分为更小的、紧密合作的scrum，每个迭代大约有6-8个人。团队在很大程度上是独立的，可以调整自己的迭代频率(从1个月减少到1周)，并获得了大量的灵活性来实现他们认为最好的敏捷。该公司定期引入敏捷教练(如Object Mentor)来帮助培训scrum大师、团队和管理人员。

障碍物：很多。其中一些与敏捷有关，另一些则与敏捷无关。以下是一些经验教训，没有特别的顺序：

产品待办事项在一开始被修改得太频繁了。最终，团队和管理层花了几天的时间来检查所有的功能，评估它们，并确定它们的优先级。这是一部轰动一时的电影，但也带来了极大的帮助。学到的教训:尽早把你的产品待办事项安排好，并保持它。产品所有者必须清楚地知道他们想要什么。

我们浪费了时间去尝试和处理时尚和炒作。当你开始的时候，你没有办法知道你做的事情是否正确。有一种诱惑，那就是不断地摆弄敏捷过程，把焦点从产品上移开。经验教训:有一位经验丰富的敏捷教练确实有助于减少这种学习曲线。任何实验都应该总有人反对。限制“尖峰”的数量。

一个好的scrum大师是无价的。当然，在一开始，这是一个全职职位。

这需要时间。团队花了几个月的时间才开始适应这个过程。

选择你的战斗。可以理解的是，一些程序员会持怀疑态度，而另一些人则会完全不喜欢并逃离这种变化。允许一定的灵活性。例如，强制使用产品待办事项和迭代计划，但不要要求每个人都使用笔记卡。在引入工具和编程方法时要特别敏感，例如结对编程或测试优先开发。

最后，保持沟通畅通，管理预期。

祝好运!

Answer 2

几年前作为Delphi开发人员工作时，我设法让我的开发团队采用了Scrum一段时间。

整个过程对我们来说工作得很好--让团队评估积压的优先任务，给了我们有意义的时间框架来实现目标，整个“管理工作就是消除障碍”非常棒。

最大的问题是，这个过程总是被认为是“Bevan的好主意”。

虽然团队欣赏我们获得的价值，并很高兴继续使用Scrum，但团队并没有将上的scrum方法论作为自己的。过了一段时间，我厌倦了“推动”，我们也“闹翻”了Scrum方法。

经验：确保团队接受Scrum，并拥有这种方法。

Answer 3

我们主要在客户现场做scrum项目。在我的经验中，最困难的部分是在客户组织中找到一个好的产品所有者：

• 太多人认为他们应该成为产品负责人，
• 产品负责人很难跟上团队的步伐
• 产品负责人很难获得团队需要的所有详细信息
• 将项目移动到产品积压中以添加更高优先级的内容是difficult
• etc.

培训内部团队使用scrum是可行的，引入自己的scrum大师也是可行的，但一个好的产品所有者应该是客户组织的一部分。训练这个外在的人会更难。有一个代理产品所有者，他与客户产品所有者一起工作确实有很大帮助。