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

Question

如果您必须向企业提出关于采用或转向敏捷开发方法（如 SCRUM 或 XP 等）的案例，您会提出什么案例（您如何推销这个概念）？

例如

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

如果你成功了，获胜的论点/案例/理由是什么？

编辑：我问的原因是我的一个朋友（他是一家公司的解决方案架构师）目前正试图决定如何就这个主题与他的管理层接洽，我已经给了他我能提供的建议. 很想听到那些成功提出转向敏捷对齐方法论的人的来信。

score 5 · Accepted Answer

我的案例：该组织折腾了整整 2 年，并在最终加入敏捷潮流之前失败了......没有更好的选择（截至目前......个人意见）以世界的速度生产高质量的软件变化。你不能再用旧的方式做事了。有些人学习艰难。

房间里的大象：一个想法好并不意味着它会被接受。

逻辑参数：

反馈回路短。客户可以在每个月/迭代结束时看到正在运行的软件，并使用它...改进和调整以适应口味。没有更多的开发人员吸了一年的面团，然后带着一头喝醉的大象回来为等马的顾客。
在开发开始工作之前，您无需将所有事情都一成不变（神圣的 SRS）。随着时间的推移，您可以改变主意以反映业务优先级/市场条件的变化......（开发人员不会发脾气）。
更好的沟通：不再有“这不是我想要的！” 当无法挽救这艘船时。开发人员实时与真实客户交谈，以澄清疑问并验证他们构建的东西是否正确。责任完全在于客户+开发，以确保构建正确的产品......通过相互交谈......一直。
人工流程：敏捷认识到软件是由人为他人制作的事实。这些实践促进了团队之间的互动、学习和尊重。还观察到更好的士气
遵循 TDD、自动化测试、结对编程等实践可以产生更好的质量产品。传统上在项目结束时在“错误修复和搅动”阶段花费的时间被最小化。
易于维护。回归测试是一个 SNAP！如果做得对，构建的系统是适合/更容易更改/扩展的。开发人员将简单性与过度工程视为第二天性。开发人员并不害怕“去那里改变它”与“我没有碰那个扭曲的东西......上次的伤疤还没有愈合。”
由于开发人员的支持，更有可能在最后期限前完成。估计是根据实际团队速度而不是负责创建图表/mpp/计划的人员的直觉估计来修改的
可见的进展- 大而可见的图表（燃尽图等）可以准确地告诉您项目中发生了什么，而无需从秘密/不情愿/非常忙碌的人那里挖掘它。问题是在你的脸上，不能被忽视/隐藏很长时间。开发不必每周一天切换到“进度报告”模式来为管理生成信息......易于收集开发人员似乎并不介意的指标。

我打破了字符限制吗？:)

score 2 · Accepted Answer

非技术人员对按时并在预算范围内高质量完成的项目感兴趣，并且在交付时能够满足他们的要求。您应该关注敏捷如何帮助实现这些品质。

有时很难将敏捷推销给非技术人员，原因有两个：

不尝试 100% 提前计划的概念并不是很直观
相当多的人声称他们使用敏捷，在交付任何东西时都惨遭失败，并给伟大的 SDP 一个坏名声

谈论敏捷过程处理变化的能力。

如果您与已经与您合作的客户合作，通常会更容易。例如，您可以轻松地向他们展示一段时间内累积的所有变更请求，并展示它们如何影响项目的进度和成本。然后，您可以解释敏捷过程将如何帮助处理此类情况。

沿着同一条线，您可以对“瀑布项目”进行初步估计，并将其与现实生活中的结果进行比较。

我还将谈论敏捷的质量方法。迭代期间的测试大大提高了质量。带有即时反馈的短迭代也很有帮助，请提及它们。

score 1 · Accepted Answer

卖得好的东西是：

每次迭代后可以测试、使用和发布的有形产品。（适合喜欢看他/她的钱能买到什么的产品负责人）
它为开发过程带来了透明度，尤其是在日常站立期间，因此减少了功能重复和混乱
在每个 sprint 之后进行演示，让同事了解产品的发展方向、开发工作后可用的内容，并让人们讨论和思考什么会使产品变得更好
经过十几次冲刺后，开发估算可以达到合理的准确性。至少在对焦点因素进行了一些修改之后。
提高开发人员在拥有特定功能时的认可度
使用敏捷时的产品更改成本往往比使用瀑布方法时要小得多

非常适合小型开发团队，但需要开发团队的支持。

score 1 · Accepted Answer

如果不具体提及旧方法的问题以及新方法将如何解决这些问题，几乎不可能引入新方法。

实际上，您可能需要提供一堆选择，然后以推荐您最喜欢的结尾。准备好解释为什么它是你的最爱，并且非常了解你选择的方法的弱点。

并确保你不会混淆你的感觉强度和论点的强度，并且你不会试图将个人价值选择和文化依恋作为客观的技术评估。你的同事并不愚蠢——如果你这样做，他们会知道的，他们会很快对你发火。

如果你想从哲学上理解这一点，沟通实际上并不依赖于口才、修辞或表达方式，而是依赖于听到信息的情感背景。人们只有在向你走来时才能听到你的声音，而不是在你的话语追赶他们的时候。

score 0 · Accepted Answer

根据我的经验，能立即将 Scrum 推销给非技术管理人员的一件事是燃尽图。有一个纸质图表 - 所有人都可以看到并易于理解 - 显示每日进步的想法是立竿见影的。它很早就清楚地表明了项目是否按计划进行。

由于积压、冲刺、每日 Scrum 等都是使燃尽图工作所必需的，所以先推销燃尽图的想法，然后说明需要 Scrum 的其余部分，最后指出执行 a 是可行的该过程的三周试用期对进度的影响最小。

score 0 · Accepted Answer

我认为企业的第一大卖点是他们决定你要做什么，所以他们将确定优先事项。

score 0 · Accepted Answer

我的嘘声，一个非技术人员，通常更喜欢列举新方法将如何提高团队的生产力。因此，我们引入SCRUM作为一种管理方法的方法，侧重于在进度可见性、更好的沟通和更快的反馈方面的收益。

All the other gains, as a fact of matters, seens intangible for people like my boss.

score 0 · Accepted Answer

From what I have read and heard the term Agile seems to get a bad rap and scares people. From a business perspective I think what it boils down to is how can I provide business value in a more responsive way. Agile is a method of supporting the concept of delivering business value quickly.

Instead of discussing it in technical terms I would suggest your friend discuss it in business terms and state that he has some ideas that could help deliver business value to his end customers more quickly.

我不建议他讨论 XP 或敏捷作为方法，而是介绍简短的、可交付的重点会议（即 SCRUM），然后尝试从那里发展它。我觉得如果你告诉企业你可以更快地以更可预测的方式得到他们想要的东西，并且你兑现了这一声明，你就会接受让你到达那里的做法。

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

8 回答 8

Related

Reference