敏捷曾经被认为是“只适用于小型团队和小型项目管理”。 现在它已成为全球软件开发团队广泛使用的学科，并取得了巨大的成功。 但是，敏捷真的能带来价值吗？ 这取决于你如何使用它。
自从我进入科技行业以来，我的团队和我一直在使用敏捷。 这并非一帆风顺，一路走来学到了很多东西。 学习的最佳方式是犯错误，所以为了帮助你进行自己的敏捷之旅，这里有我犯过的五个敏捷错误。
1. 错误：敏捷只发生在开发团队中
以下是将敏捷限制为仅限开发团队时会发生的情况。 您的业务团队编写项目的需求，然后将其发送给开发团队，并设定截止日期。 在这种情况下，开发团队不直接负责业务目标。
团队之间的沟通很少，更不用说谈判了。 没有人质疑业务团队提出的要求，或者是否有更好的方法来实现相同的业务目标。
这也会让开发团队感到沮丧。 当开发人员只负责填写代码以使机器工作时，他们与业务脱节。
最终产品变成了一个怪物，缺乏合理的抽象和设计。
解决方案：在您的组织中传播敏捷。 让每个人都从它中受益，无论哪种方式适合他们的部门，但最重要的是让它统一每个人的目标。
2. 错误：自动化测试的设置工作量太大
自动化测试（尤其是测试驱动开发 (TDD)）的作用经常被 IT 行业低估。 我认为，自动化测试是可维护和高质量软件的基石，甚至比生产代码更重要。
但是，如今大多数团队都没有能力进行自动化测试，或者有能力但由于时间限制而拒绝这样做。 如果没有自动化测试的保护，程序员就无法持续重构糟糕的代码。
这是因为没有人可以预测更改几行代码是否会导致新的错误。 如果没有持续的重构，您会增加您的技术债务，这会降低您对业务部门需求的响应能力。
手动测试速度慢，并且迫使您牺牲质量，只测试更改的部分（这可能很困难），或者延长回归测试时间。 如果测试时间太长，您必须分批测试以减少执行的测试数量。
突然间，你不再敏捷了。 你已经转换为瀑布模式。
解决方案：自动化测试的关键是让开发人员运行测试，而不是雇用更多的测试人员来编写脚本。 这就是为什么（由测试人员编写的）测试运行缓慢，并且只能缓慢地向程序员提供反馈。
提高代码质量所需的是对程序的快速反馈。 自动化测试编写得越早，运行速度越快，越有利于程序员及时获得反馈。
编写自动化测试的最快方法是 TDD。 在编写生产代码之前编写测试。 运行自动化测试的最快方法是单元测试。
3. 错误：只要它能工作，你就可以忽略代码质量
人们经常说：“我们时间不多了，快点完成吧。”
他们不关心质量。 许多人认为质量可以为效率而牺牲。 所以你最终会编写低质量的代码，因为你没有时间做其他事情。 此外，低质量的代码不会带来高性能。
除非你的程序像几行代码一样简单，否则随着代码复杂性的增加，低质量的代码会阻碍你。 软件被称为“软”，因为我们期望它易于更改。 低质量的代码变得越来越难以更改，因为一个小的更改可能导致数千个新错误。
解决方案：提高代码质量的唯一方法是提高你的技能。 大多数人无法一次性编写高质量的代码。 这就是为什么你需要不断地重构！ （并且您必须实施自动化测试来支持持续的重构）。
4. 错误：员工应该只专注于一件事
将人员划分为专业团队感觉很自然。 一名员工可能属于 Android 组，另一名属于 iOS 组，另一名属于后台组，等等。 危险在于，频繁更改的团队意味着专业化难以维持。
解决方案：敏捷中的许多实践都基于团队，例如团队速度、回顾性改进和员工流动率。 敏捷实践围绕团队和人员展开。 帮助您的团队成员多样化、学习新技能并分享知识。
5. 错误：编写需求花费的时间太长
正如俗话所说“垃圾进，垃圾出”，正式的软件需求是软件开发的“输入”。 没有明确的需求，就无法产生好的软件。
在科技行业，我发现优秀的产品负责人比优秀的程序员更稀缺。 毕竟，无论程序员编写的代码多么糟糕，它通常至少会运行（否则它就不会发布）。
对于大多数产品经理来说，没有标准来衡量其产品定义和需求的有效性。 以下是我多年来看到的一些问题
- 一些产品负责人专注于设计解决方案，而忽略了用户价值。
这导致了一堆代价高昂但无用的功能。
-
一些产品经理只能讲大故事，无法将需求分解为小的、可管理的部分，导致交付批量大，敏捷性降低。
-
一些产品负责人对需求分析不完整，导致出现一个又一个的错误。
-
有时，产品负责人不会对需求进行优先级排序，这导致团队将大量时间浪费在低价值的项目上。
解决方案：创建清晰、简洁且易于管理的需求，以帮助指导开发。
犯错误
我为您提供了五个避免犯错的技巧。 不过别担心，还有很多错误可以犯！ 将敏捷引入您的组织，不要害怕为了让您的团队变得更好而忍受一些错误。
一旦你采取了不可避免的错误步骤，你就会知道下次该怎么做。 敏捷旨在应对错误。 这是它的优势之一：它可以适应。 所以开始使用敏捷，准备好适应，并制作更好的软件！
3 条评论