转移到敏捷开发方法论的最佳案例?[关闭]

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

有时很难将敏捷销售给非技术人员,原因有两个:

• 不打算提前100%计划的概念并不是很直观。
• 很多人声称他们使用敏捷,不幸地失败了,给伟大的SDP一个坏名声。

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

如果你和已经和你一起工作的客户一起工作,通常会更容易。您可以很容易地显示它们,例如,随着时间的推移累积的所有变更请求,并显示它们如何影响计划和项目的成本。然后,您可以解释敏捷过程如何帮助处理这些案例。

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

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

我的情况是:这个组织苦苦挣扎了两年,最后失败了,最后跳上了敏捷的潮流……没有更好的选择(从现在起…个人意见)以世界变化的速度生产高质量的软件。你再也不能用老办法了。有些人学习很难。

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

逻辑参数:

• 反馈回路 是短的。顾客可以 参见工作软件 在每个月/迭代结束时,使用它…提炼和调整以适应口味。一年之内,再也没有开发人员在吸面团,带着一头喝醉的大象回来等着顾客的马了。
• 你 不需要把一切都变成石头 (神圣的SRS)在开发开始工作之前。你 可以改变你的想法 随着时间的推移,反映业务优先级/市场状况的变化。(开发商不会发脾气)。
• 更好的沟通 :再也不“这不是我要的!”当无能为力抢救这艘船时。开发人员实时与真正的客户交谈,以澄清疑问并验证他们构建了正确的东西。责任完全在于 客户+开发 为了确保生产出正确的产品…通过 说话 彼此之间……总是。
• 人的过程: 敏捷认识到软件是由人为他人制造的事实。 这些实践有助于团队之间的互动、学习和尊重。士气也有所改善
• 遵循诸如TDD、自动测试、配对编程等实践,可导致 质量好 产品。传统上,在项目结束时花在“错误修复和搅动”阶段的时间被最小化。
• 易于维护 . 回归测试很简单!所构建的系统易于修改/易于更改/扩展。如果做得对。开发者 价值简单性 把工程作为第二天性。 开发者并不害怕 “进去换一下”和“我没碰那个扭曲的东西”。上次的伤疤还没有愈合。”
• 更现实的达到最后期限的机会 由于开发商的收购。根据团队的实际速度而不是负责创建图表/MPP/计划的人员的初步估计来修改估计。
• 可见进度 -大的可见图表(燃尽等)可以准确地告诉你项目中发生了什么,而不必从秘密的/不情愿的/非常忙碌的人那里挖掘出来。问题就在你面前,不能被忽视/隐藏太久。开发不需要一周一天的上下文切换到“进度报告”模式来生成管理信息…易于收集开发人员似乎不介意的指标。

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

卖得好的东西是:

• 每次迭代后都可以测试、播放和发布的有形产品。(对于一个喜欢看他/她的钱买了什么的产品所有者来说很好)
• 它为开发过程带来了透明度,特别是在日常的站立过程中,因此减少了功能重复和混乱。
• 在每一次冲刺之后进行一次演示,让同事了解产品的发展方向、开发工作之后的可用性,并让他们讨论和思考什么会使产品变得更好。
• 经过十几次冲刺后,开发估计可以达到合理的精度。至少在对焦点因素做了一些修改之后。
• 提高开发人员在拥有特定功能时的认可度
• 成本 当使用敏捷时,产品的变化比使用瀑布方法时要小得多。

适合小型开发团队,但需要开发团队的认可。

如果没有特别提到旧方法的问题以及新方法将如何解决这些问题,几乎不可能引入新方法。

在现实中,你可能需要提供一系列的选择,然后以推荐你最喜欢的结束。准备好解释为什么它是你的最爱,并对你选择的方法论的弱点有很好的了解。

并且要确保你不会混淆你对自己论点力量的感觉,也不要试图把个人价值选择和文化附件作为客观的技术评估来传递。你的同事不蠢-他们 将 知道你是不是这样做了,他们会很快把你的大家伙给扔了。

如果你想从哲学上理解这一点,交流实际上并不取决于口才、修辞或表达,而是取决于所听到信息的情感背景。人们只能在他们向你移动时听到你的声音,而不是你的话在追求他们时。

根据我的经验,能立即将Scrum卖给非技术管理人员的一件事就是Burndown图表。有一个纸制的图表可以让所有人看到并很容易理解,它显示了每天的进步,这是一个立竿见影的胜利者。它很早就清楚地表明了一个项目是否如期进行。

由于积压工作、冲刺、每日Scrum等都需要使Burndown图表工作,因此首先要推销Burndown图表的概念,然后解释对Scrum其余部分的需求,最后指出在对进度影响最小的情况下对流程进行三周的试用是可行的。

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

我的boos是一个非技术人员,通常更喜欢列出一个新方法如何提高团队的生产力。所以,我们的职责是 并列争球 作为一个 管理 方法论,侧重于 进度可视性 , 更好的沟通 和 更快的反馈 .

所有其他的收益,事实上,对像我老板这样的人来说都是无形的。

从我所读到的和听到的术语来看,敏捷似乎得到了一个坏的说唱和吓唬人。从业务的角度来看,我认为归根结底就是我如何以更快速的方式提供业务价值。敏捷是一种支持快速交付业务价值的概念的方法。

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

我不建议他把xp或敏捷作为方法来讨论,而是引入一些简短的、可交付的集中会议(即scrum),然后尝试从中发展它。我觉得,如果你告诉企业,你可以更快地得到他们想要的,以一种更可预测的方式,你将在这个声明,你将得到认可的做法,使你达到那里。