转向敏捷开发方法的最佳案例？

Question

如果你不得不向企业提出关于采用或转向敏捷开发方法(如SCRUM或XP等)的案例,你会做什么案例(你如何出售这个概念)？

例如

您如何描述非技术人员的概念和好处？

如果您已成功完成,那么获胜的参数/案例/理由是什么？

编辑:我问的原因是我的一个朋友(他是一家公司的解决方案架构师)目前正试图决定如何向他的管理层确切地说明这个话题,并且我已经给了他我的建议.特别感到好奇的是听到那些成功地提出要转向敏捷对齐的方法论的人.

Answer 1

我的案例:这个组织在两年内徘徊了两年并且在最终跳到敏捷的潮流之前失败了......没有更好的选择(现在......个人观点)以世界的速度生产高质量的软件变化.你不能再以旧的方式做事了.有些人学到了很多困难.

房间里的大象:仅仅因为一个想法是好的并不意味着它会被接受.

逻辑参数:

• 反馈循环很短.客户可以在每个月/迭代结束时看到工作软件,玩它...精炼和调整品味.没有更多的开发商吮吸面团一年,然后带着醉酒的大象回来等待马匹的顾客.
• 在开发开始工作之前,您不需要将所有内容都设置在石头上(神圣的SRS).随着时间的推移,您可以改变主意,反映业务优先级/市场条件的变化.(开发人员不会发脾气).
• 更好的沟通:不再"这不是我要求的!" 什么都不能用来打捞船.开发人员实时与真实客户交谈以澄清疑虑并验证他们是否构建了正确的东西.正是在客户+开发上的责任,以确保正确的产品建立......通过彼此交谈 ......始终.
• 人为过程:敏捷认识到软件是由人为其他人制作的.这些实践促进了团队之间的互动,学习和尊重.也观察到更好的士气
• 遵循TDD,自动化测试,结对编程等实践可以获得更好的优质产品.在项目结束时传统上花在"错误修复和搅拌"阶段的时间被最小化.
• 易于维护.回归测试是SNAP!如果做得好,构建的系统可以更容易/更容易更改/扩展.开发人员将简单性与过度工程性视为第二天性.开发人员并不害怕 "进入那里并改变它"而不是"我没有触及那种扭曲的东西......上次的伤疤尚未愈合."
• 由于开发人员的支持,更符合截止日期的机会更加切合实际.根据实际团队速度而不是负责创建图表/ mpp /计划的人员的肠道估计来修改估算值
• 可见的进展 - 大的可见图表(burndowns等)告诉你项目中发生了什么,而不必从秘密/不情愿/非常忙碌的人那里挖掘出来.问题是面对面的,不能忽视/隐藏很长时间.开发不需要上下文切换到每周一天的"进度报告"模式来生成管理信息......很容易收集开发人员似乎并不介意的指标.

我打破了限制吗？:)