如果您必须向企业提出采用或转向敏捷开发方法(如 SCRUM 或 XP 等)的案例，您会提出什么案例(您如何推销该概念)？
例如
编辑:我问的原因是我的一个 friend (他是一家公司的解决方案架构师)目前正试图决定如何就这个主题与他的管理层接洽，我已经给了他我能做的建议条款。很想听到那些成功提出转向敏捷对齐方法论的人的来信。
最佳答案
我的案例:该组织折腾了整整 2 年，但在最终加入敏捷潮流之前失败了......没有更好的选择(截至目前......个人意见)以世界的变化。你不能再用旧的方式做事了。有些人学得很辛苦。
房间里的大象:一个想法好并不意味着它会被接受。
逻辑参数:
- 反馈循环很短。客户可以在每个月/迭代结束时查看正在运行的软件，并尝试使用它...改进和调整以适应口味。不再有开发者吸了一年的面团，然后带着一头醉醺醺的大象回来给等马的顾客。
- 在开发开始工作之前，您不需要一成不变(神圣的 SRS)。随着时间的推移，您可以改变主意以反射(reflect)业务优先级/市场状况的变化。(开发人员不会发脾气)。
- 更好的沟通:不再是“这不是我想要的!”当无法挽救这艘船时。开发人员实时与真实客户交谈，以澄清疑问并验证他们构建的东西是否正确。责任完全在于客户 + 开发，以确保构建正确的产品......通过彼此交谈......一直。
- 人工流程:敏捷认识到软件是由人为他人开发的。这些实践促进了团队之间的互动、学习和尊重。也观察到更好的士气
- 遵循 TDD、自动化测试、结对编程等实践可带来质量更高的产品。传统上在项目结束时在“错误修复和搅动”阶段花费的时间被最小化。
- 易于维护。回归测试是一个 SNAP!如果做得对，构建的系统是适合/更容易更改/扩展的。开发人员重视简单而不是过度设计作为第二天性。 开发者不怕“进去改变它”与“我没有碰那个扭曲的东西......上次的伤疤还没有愈合。”
- 由于开发者的支持，更有可能在最后期限前完成。估算是根据实际团队速度而不是负责创建图表/mpp/计划的人员的直觉估算来修改的
- 可见进度 - 大而可见的图表(燃尽图等)可以准确地告诉您项目中发生了什么，而无需从神秘/不情愿/非常忙碌的人那里挖掘出来。问题是在你的脸上，不能被忽视/隐藏很长时间。开发人员不必每周一天切换到“进度报告”模式来为管理生成信息...轻松收集开发人员似乎并不介意的指标。
我是否打破了字符限制？:)
关于agile - 转向敏捷开发方法的最佳案例？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/200626/