敏捷价值_您是否忘记了敏捷价值？

敏捷价值

前一阵子我写了为什么有时候敏捷会失败。 在本文中，我将重点介绍敏捷价值的具体误解。 当人们问您是否敏捷时，他们基本上会认为：

• 你有站立姿势吗？
• 您有回顾展吗？
• 你有故事吗？
• 你用黄色的帖子吗？
• 等等

这些想法属于称为Scrum的敏捷过程，这是最受欢迎的敏捷过程，但并非唯一。 还有其他过程：看板，RUP，XP等…您不一定必须是Scrum。

对我来说，敏捷最重要的是实际的宣言 。 每年年初和每个项目开始时，从事软件工作的每个人都应阅读它。 然后，应该在团队成员之间进行讨论，并应该鼓励人们给他们提供有关宣言中详述的价值观和原则的具体示例。 在此博客文章中，我们将看一下这些值。

8个强调4的价值观

有四个要点详细说明了清单中的8个值

1. 个人与流程和工具之间的互动
2. 通过全面的文档工作软件
3. 客户合作而非合同谈判
4. 响应计划变更

然后有一个非常重要的句子：“就是说，尽管右边的项目有价值，但我们更看重左边的项目。” 值得一说两次。 可能需要三遍……四遍……无论花费多少，因此您都不会忘记它。 为什么？ 好吧，让我们一一介绍。

个人与流程和工具之间的互动

那么这是否意味着如果您是敏捷者，您就不再担心流程了吗？ 否。没有过程，任何项目都不会成功。 从敏捷的角度来看，这意味着您重视流程，但您更重视个人和互动。 例如，假设您在一个过程中花费了大量的工时，但并没有真正为项目或客户增加价值。 当您批评地看待过程的这一方面时，是因为开发人员和测试人员不会互相交谈。 相反，他们有一个复杂的过程，因此他们认为当生产缺陷发生时，他们可以互相指责。 很多工作时间都花在了这个上。 但是，如果他们定期互相交谈，然后又不需要进行一些麻烦的过程，那将会更有效率。 因此，挑战是双重的：

• 确保人们经常互相交谈
• 确保流程高效

因此，例如，定期进行演出并告诉他们什么都没有互动，并在最终希望获得大量客户满意的情况下进行大量交付，这是一个很有意义的过程，因为过程很漫长。 旨在使个人成为您流程中的核心。

通过全面的文档工作软件

这是班上的误会。 有人想要有关某些复杂功能的全面文档，而开发人员则反驳：“嘿，Dinasour，这不是瀑布，不需要详细的文档”。 错误。 仍然需要文档。 这里的要点是，使用Agile， 当您的软件布满错误时 ，您不应该在文档上花费大量的工时。 您的软件可以正常工作更重要。 这意味着应该花更多的时间在具有足够功能覆盖范围的出色的自动化测试上。 这并非总是容易做到的，但是您应该这样做。

客户合作而非合同谈判

第三，您是否停止与客户就项目进行合同协议。 不。这里的要点是，您花在与客户合作上的会议上的工时多于与律师签订的合同。 您无需花费大量时间来批准大型项目，而应在项目的整个生命周期中进行协作，将其分解成很小的增量，吸收反馈并共同努力以实现一个共同的目标：项目成功。

响应计划变更

最后，您是否停止计划？ 当然不是。 但是，再次重申，如果您什至无法响应变化，那么规划计划的关键是什么呢？ 您能想象一个客户要求对UI显示数据的方式进行微小的更改，而开发人员团队会回答：“ 对不起，这不是我们6个月的计划 ”？ 至关重要的是，架构可以促进合理的变更，如果不能，那么该项目将很难真正拥抱敏捷哲学。

摘要

敏捷实际上是要对软件方法施加更多约束 。 以此类推，REST体系结构样式对您的体系结构施加了约束，例如统一接口，无状态和缓存功能。 然后，坚持这些约束（这是一项技术挑战），您就会从中受益。 对于REST，您的体系结构将具有更大的可伸缩性，可扩展性，并为API使用者带来更高的开发人员生产力。 对于敏捷而言，通过坚持评估8个关键概念的约束，而将重点放在4上，您的项目将有更大的成功机会。

翻译自: https://www.javacodegeeks.com/2018/01/forgetting-agile-values.html

敏捷价值