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

Question

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

e.g。

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

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

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

Answer 1

我的案例：这个组织在两年内徘徊了两年并且在最终跳到敏捷的潮流之前失败了......没有更好的替代方案（截至目前......个人意见）以高效率生产高质量的软件世界在哪变化。你不能再以旧的方式做事了。有些人很难学习。

大象在房间里：只是因为一个好主意并不意味着它会被接受。

逻辑参数：

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

我是否打破了限制？：）

Answer 2

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

---

出于以下两个原因，有时很难将敏捷销售给非技术人员：

• 不试图提前100％计划的概念并不是非常直观
• 很多人声称他们使用敏捷，惨遭失败，无法提供任何东西，并为伟大的SDP提供了一个坏名声

---

讨论敏捷过程处理变更的能力。

如果您与已经与您合作的客户合作，通常会更容易。您可以轻松地显示它们，例如随时间累积的所有变更请求，并显示它们如何影响计划和项目成本。然后，您可以解释敏捷过程如何帮助处理此类案例。

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

---

我还会谈到敏捷的质量方法。迭代期间的测试显着提高了质量。具有即时反馈的短迭代也是很有帮助的，请提及它们。

Answer 3

卖得好的东西是：

• 每次迭代后的有形产品，可以测试，播放和发布。 （对于喜欢看他/她的钱购买的产品所有者有利）
• 它为开发过程带来了透明度，特别是在日常站立时，因此减少了功能重复和混乱
• 在每个sprint之后进行演示，教育员工了解产品的发展方向，开发工作后可用的内容，让人们谈论和思考什么会让它变得更好
• 在十几次短跑后，可以以合理的准确度进行发展估算。至少在对焦点因素进行一些修改之后。
• 改善开发人员的支持，因为他们拥有特定的功能
• 使用Agile时产品更改的成本往往比使用瀑布式方法时小得多

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

Answer 4

如果没有专门提及旧方法的问题以及新方法如何解决这些问题，几乎不可能引入新方法。

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

并确保你不会因为你的论点的力量而混淆你的感情力量，并且你不会试图将个人价值选择和文化依恋作为客观的技术评价。你的同事并不愚蠢 - 他们会知道你是否正在这样做，并且他们会快速翻转你的bozo位。

如果你想对此有所了解，那么沟通实际上并不依赖于口才，修辞或表达，而是依赖于传达信息的情感环境。人们只能在向你移动时听到你的声音，而不是在你的言语追求它们的时候。

Answer 5

根据我的经验，将Scrum立即出售给非技术管理层的一件事就是燃尽图。有一个纸质图表 - 可供所有人查看和易于理解 - 的想法显示每日进展是一个立即赢家。它很清楚地表明项目是否按计划进行。

由于积压，冲刺，每日scrum等都需要使燃尽图表工作，首先出售燃尽图表的想法，然后解释需要Scrum的其余部分并最终指出它是可行的对该过程进行为期三周的试验，对时间表的影响最小。

Answer 6

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

Answer 7

我的嘘声，一个非技术人员，通常更倾向于关注新方法如何提高团队的生产力。因此，我们引入 SCRUM 作为管理方法的方法，专注于进度可见性，更好的沟通的收益并且更快的反馈。

作为事实，所有其他收益对于像我老板这样的人来说是无形的。

Answer 8

从我所读到的内容来看，敏捷一词似乎得到了一个糟糕的说唱并吓跑了人们。从业务角度来看，我认为它归结为如何以更快速的方式提供业务价值。敏捷是一种支持快速交付业务价值概念的方法。

我建议你的朋友不要用技术术语讨论它，而是建议你的朋友用商业术语来讨论它，并说明他有一些想法可以帮助他们更快地为最终客户提供商业价值。

我不会建议他讨论XP或敏捷作为方法，而是引入简短的，可交付的聚焦会议（即SCRUM），然后尝试从那里发展它。我觉得如果你告诉企业你可以更快地以更可预测的方式获得他们想要的东西，并且你在这个陈述中表达了你将会得到让你到那里的实践的支持。