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

Question

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

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

Answer 1

我们做了什么:

1. 向管理层解释一项计划(打算预测未来)只是一种无所事事的假设,一系列假设.

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

3. 开始在sprint列表上执行.

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

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

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

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

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

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

3. "风险"清单.同样,我们问是什么吓到他们.如果他们被某些东西困扰,那么也许他们应该改变燃尽的优先级来解决这个问题.

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

经过两次冲刺后,他们停止了"瀑布式"请求并开始优先处理和管理燃尽.

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

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

Answer 2

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

在这一个有些伟大的答案在这里.

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

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

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

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

通过反复试验找出适合您的企业,文化和团队的方法.没有任何东西可以说你不能逐步采用整个流程,而且会选择最适合你商业模式的零件.

Answer 3

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