敏捷，瀑布，Scrum ......将团队转变为迭代开发有多难？

Question

团队在企业氛围中从传统的非迭代，规范列表，甘特图，阶段相关团队转变为更加迭代的方法，有哪些挑战？

此外，在使用新的发展策略时，获得其他团体认可的成功方法是什么？

Answer 1

我们做了什么：

1. 向管理层解释，一项计划（旨在预测未来）只是一种虚假的，蒸汽，一系列没有事实依据的假设。

2. 计划了一系列冲刺。写了一张燃尽图。忘了汇总估算。

3. 开始执行短跑列表。

在前两三个人之后，管理层开始意识到“计划”只是一个燃尽的清单，没有“日期”，“风险”，“假设”或类似传统的瀑布项目计划。

此时，当然，为时已晚。我们已经完成了一次冲刺，并且大部分都在第二次冲刺中完成。这匹马离开了谷仓。钟已响了。

所以管理层需要一些东西。

1. 预算总额。我们说“添加对你很重要的冲刺。只要画一条随机线，任何你感到高兴的地方。这就是你的预算。”没有人喜欢这个，因为它控制得太多了。 “你怎么能证明这一点？”他们问过。 “很简单。我们建立优先顺序，直到您取消该项目。”

   我们必须添加的是每个冲刺的暂定持续时间。我们的大小可变：2至4周。 10个短跑的名单大约是26周--6个月。在那之后，我们停止了数字。

2. “假设”清单。我们刚拒绝这个。 “写下你自己的”。他们自己也想不出来。就是这样。

3. “风险”列表。我们再一次询问害怕他们的是什么。如果他们被某些东西困扰，那么也许他们应该改变燃尽的优先权来解决这个问题。

4. 截止日期。我们转过身来，要求他们优先考虑日期和预算以及对他们来说很重要的风险。我们并不太关心什么顺序 - 这是他们作为经理的呼吁。

经过两次冲刺后，他们停止发出“瀑布式”请求，并开始优先处理和管理燃尽。

有趣的是，他们从未询问范围蔓延。询问“你如何控制范围？”的经理人。正积极拒绝增量发展。他们试图不去拿它。

当管理者想要知道敏捷方法如何“防止”范围蔓延时，他们（a）将学习过程标记为“蠕变”（这是不好的）和（b）抵制学习导致范围变化的观点。你甚至拥有范围“蠕变”的唯一方法就是你承诺一个特定的范围而不管可能发生的任何学习。敏捷方法只承诺下一个sprint，而不是全面的范围。如果你没有提交范围，它就不会蠕变，因为它不存在。

Answer 2

我正在尝试立即这样做。我们有一个现场客户开发部门，我可以告诉你，他们是试图为迭代开发过程争取买入的关键。

关于这个问题的一些很好的答案here。

如果你已经有很长时间和超预算交付项目的记录，因为大量且无法管理的大块没有完成，这是说服你的项目的利益相关者获得变革的良好开端。

流程可以证明自己，但只有合适的各方支持它。你的关键是让其他团队成员看到你想要做的事情的价值。

对于我们来说，它归结为从客户的角度来看待事物。我们需要不断回到客户那里，以确保我们正在构建的是他们想象的。我们希望简化流程以停止浪费每个人的时间。

当然，现在，敏捷的不同部分适用于不同的组织，实际上使用敏捷流程的公司很少，这是纯粹意义上的。

通过反复试验找出适合您的业务，文化和团队的方法。没有任何迹象表明你不能逐步采用整个流程，而且会选择最适合你商业模式的部分。

Answer 3

根据我的经验，过渡团队不是问题。这是过渡管理。

Answer 4

你可能会对Lynn Manns和Linda Rising的书Fearless Change: Patterns for Introducing New Ideas感兴趣。它是将敏捷方法引入组织的经验汇编。

Answer 5

在这里，它始于一个团队，他们希望继续使用Scrum更加敏捷。这支队伍是“试点队”，并进行了几次冲刺（3个月）。他们是由已经阅读并了解Scrum的内部人员执教的。做一个“飞行员”而不是完全转换有助于获得管理层和屈光团队成员的认可。

拥有“让我们尝试”的态度确实有助于客户进入流程（这里的内部客户，但客户也是如此）。

为了坚持下去，你必须注意所取得的进步以及它给你和你的团队带来的好处（它可以是更好的表现，更好地与团队成员/客户沟通，更好的结果，更快乐的客户等等。）

Answer 6

从我的（公认有限的）经验来看，确保所有程序员都参与决定切换到敏捷/ Scrum /无论如何，并且他们全都赞成 - 或者至少不会积极反对它。当敏捷/ Scrum被认为是在没有他们同意/输入的情况下从上面强制执行时，我已经看到团队成员的阻力。重新培训管理者很难，而不必经常说服你的团队。