敏捷、瀑布、Scrum...将一个团队过渡到迭代开发有多难？

Question

从传统的非迭代、规范列表、甘特图、阶段依赖的团队向更迭代的方法转变，在企业氛围中将团队转变为更具迭代性的方法有哪些挑战？

此外，在使用较新的开发策略的同时，什么是获得其他群体接受的成功方法？

Answer 1

我们所做的：

1. 向管理层解释说，一个计划(打算预测未来)只是一堆空洞的东西，一系列没有事实依据的假设。
2. 计划了一系列冲刺。写了一个燃尽表。忘了在sprints列表中汇总estimates.
3. Started执行情况。

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

当然，在这一点上，为时已晚。我们已经完成了一个冲刺，并且已经完成了第二个冲刺。这匹马已经出栏了。铃声已经响了。

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

1. 总预算。我们说：“把对你来说重要的冲刺加起来。随便画一条线，你喜欢的地方。这就是你的预算。”没有人喜欢这样，因为它有太多的控制。“你怎么能证明这是合理的呢？”他们问。“很简单。我们按优先级顺序构建，直到您取消项目。”我们确实需要为每个冲刺添加一个暂定的持续时间。我们的规模是可变的:2到4周。10个冲刺的列表大约是26周-- 6个月。在那之后，我们不再记下数字。
2. 列出了“假设”。我们刚刚拒绝了这个。“写你自己的”。他们自己也想不出什么办法。就是这样。
3. 列出了“风险”。再一次，我们问是什么吓到了他们。如果他们被某事困扰，那么也许他们应该改变工作压力中的优先级来解决这个问题。
4. A预产期。我们扭转了这一局面，并要求他们优先考虑对他们来说重要的日期、预算和风险。我们不太关心订单是什么--这是他们作为经理的决定。

在又进行了两次冲刺之后，他们停止了“瀑布”请求，并开始优先处理和管理崩溃。

有趣的是，他们从来没有问过范围爬行。问“你是如何控制范围的？”正在积极地拒绝增量开发。他们试着不去理解它。

当管理者想知道敏捷方法如何“防止”范围爬行时，他们(a)将学习过程贴上“爬行”的标签(这很糟糕)，(b)抵制学习导致范围变化的想法。当你致力于一个特定的范围，而不考虑任何可能发生的学习时，你甚至有范围“爬行”的唯一方式。敏捷方法只致力于下一次冲刺，而不是全面的范围。如果你不承诺一个作用域，它就不能爬行，因为它不存在。

Answer 2

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

在这个问题上有一些很好的答案，here。

如果你已经有了由于大块和不可管理的块没有完成而延迟交付项目和超出预算的记录，这是一个很好的开始，可以说服项目的利益相关者让变化滚滚而来。

流程可以证明自己，但只有在正确的各方支持的情况下。你的关键是让其他团队成员看到你正在努力做的事情的价值。

对我们来说，归根结底是从客户的角度来处理事情。我们需要不断地回到客户那里，以确保我们正在构建的东西是他们所设想的。我们希望简化流程，停止浪费每个人的时间。

当然，敏捷的不同部分为不同的组织工作，很少有真正使用敏捷流程的公司是在纯粹的意义上这样做的。

通过试验和错误，找出什么对你的业务、文化和团队有效。没有什么说你不能逐步采用整体流程，并精挑细选最适合你的业务模式的部分。

Answer 3

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