Project management 敏捷、瀑布、Scrum。。。将团队过渡到迭代开发有多困难？

从传统的非迭代、规范列表、甘特图、阶段相关的团队过渡到更迭代的方法，在公司氛围中的团队面临哪些挑战

---

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

你可能对林恩·曼斯和琳达·瑞斯的书感兴趣。这是一份将敏捷方法引入组织的经验总结。

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

关于这个问题，有一些很好的答案

如果您已经有过由于大量无法管理的项目未完成而导致项目延迟交付和超出预算的记录，那么这是说服项目的利益相关者开始实施变革的良好开端

这个过程可以证明自己，但必须有正确的各方支持。你的关键是让其他团队成员看到你努力做的事情的价值

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

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

---

通过反复试验，找出适合您的业务、文化和团队的方法。没有什么能说明您不能逐渐采用整个流程，并挑选最适合您的业务模型的部分。

在这里，它是从一个团队开始的，该团队希望使用Scrum更灵活。这个团队是“试点团队”，进行了几次冲刺（3个月）。他们由一位已经在阅读和学习Scrum的内部人士指导。进行“试点”而不是完全转换有助于获得管理层和团队成员的认可

采取“让我们试试看”的态度确实有助于让客户也参与到流程中来（这里是内部客户，但客户仍然如此）

---

要想坚持下去，你必须注意所取得的进展以及它给你和你的团队带来的好处（可以是更好的绩效、与团队成员/客户更好的沟通、更好的结果、更快乐的客户等等）

以我的经验，团队转型不是问题。这是管理的转型。

我们所做的：

向管理层解释，一项计划（旨在预测未来）仅仅是一份没有事实依据的假设清单

计划了一系列的冲刺。写了一张燃尽图。忘了写摘要预算

开始在Sprint列表上执行

在前两到三次之后，管理层开始意识到“计划”只是一份消耗清单，没有“日期”、“风险”、“假设”或类似于传统瀑布式项目计划的任何内容

当然，在这一点上，为时已晚。我们已经完成了一次冲刺，大部分时间都在进行第二次冲刺。马已经出了马厩。铃已经响了

所以管理需要一些东西

总预算。我们说“把对你来说很重要的冲刺加起来。只要在你喜欢的任何地方随机画一条线。这就是你的预算。”没有人喜欢这样，因为这太难控制了。“你怎么能证明这一点？”他们问道。“简单。在您取消项目之前，我们将按优先顺序生成。”

我们需要添加的是每个冲刺的暂定持续时间。我们的大小不一：2到4周。10次冲刺的时间大约为26周，即6个月。在那之后，我们不再记下数字

“假设”清单。我们只是拒绝了。“写你自己的”。他们自己想不出什么。就是这样

“风险”清单。我们再次问是什么让他们害怕。如果他们被某事困扰，那么也许他们应该改变燃尽的优先级来解决这个问题

到期日。我们扭转了这一局面，要求他们根据日期、预算和对他们来说很重要的风险来优先考虑燃尽。我们不太在乎什么样的顺序——这是他们作为经理的职责

在两次以上的冲刺之后，他们停止了“瀑布式”请求，并开始优先处理和管理燃尽

有趣的是，他们从来没有问过范围蔓延的问题。问“您如何控制范围？”的经理积极拒绝增量开发。他们不想得到它

---

当管理者想知道敏捷方法如何“防止”范围蔓延时，他们（a）将学习过程标记为“蔓延”（这是不好的）和（b）抵制学习导致范围变化的想法。即使你有范围“爬行”的唯一方式，是当你致力于一个特定的范围，而不管可能发生的任何学习。敏捷方法只致力于下一个冲刺，而不是一个全面的范围。如果你不致力于某个范围，它就不会爬行，因为它不存在。

根据我（承认有限）的经验，请确保所有程序员都参与到切换到敏捷/Scrum/任何东西的决策中，并且他们都支持它，或者至少不会积极反对它。当敏捷/Scrum被认为是在没有得到团队成员的同意/投入的情况下由上级授权时，我看到了团队成员的抵制。在不不断说服团队的情况下对经理进行再培训已经够难的了

+1-链接不错。我对那件事了如指掌是啊，这可能很快就会成为我书架上的一本新书了！很好的推荐，很好的建议，很难找到客户