project-management - 敏捷、瀑布、Scrum……将团队转变为迭代开发有多难？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




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

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

Answer 1

我们做了什么:

向管理层解释一个计划(旨在预测 future )只是虚浮的、虚幻的、没有事实依据的一系列假设。

计划了一个冲刺列表。写了一个燃尽图。忘了总结估计。

开始在冲刺列表上执行。

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

当然，此时为时已晚。我们已经完成了一个 sprint，并且已经完成了第二个 sprint。马离开了谷仓。钟声已经敲响了。

所以管理需要一些东西。

总预算。我们说“把对你来说很重要的冲刺加起来。随便画一条线，在任何你开心的地方。这就是你的预算。”没有人喜欢这个，因为它控制太多了。 “你怎么能证明这一点？”他们问过。 “容易。我们按优先顺序 build ，直到你取消项目。”

我们必须添加的是每个 sprint 的暂定持续时间。我们的大小不一:2 到 4 周。 10 个冲刺的列表大约需要 26 周——6 个月。在那之后，我们不再记下数字。

“假设”列表。我们只是拒绝了这个。 “自己写”。他们自己也想不出什么。就是这样。

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

一个到期日。我们扭转了这一局面，并要求他们优先考虑对他们来说很重要的日期、预算和风险。我们不太关心什么顺序——这是他们作为经理的要求。

再经过两次冲刺后，他们停止提出“瀑布式”请求，并开始对燃尽图进行优先级排序和管理。

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

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