如今，敏捷流程这个词在软件行业中很流行，在你的团队中使用敏捷流程就像在你的代码中使用AI/ML一样酷。这个说法你是否同意?
如果你的答案是肯定的，那么这就是问题的开始。当某些东西很酷时，人们希望尽快采用它。正如我们所知，许多声称他们在代码中使用了很酷的 ML/AI 算法的公司可能在幕后使用 if-else 语句。敏捷也发生了同样的事情。在所有声称遵循敏捷流程的团队中，他们离流程已经够远了，只是停留在一个他们没有从敏捷中获得任何优势的地方。
先决条件
如果你了解敏捷方法，并且你的团队已经在使用敏捷流程，那么本文将对你有所帮助。
敏捷过程可能无法为你提供预期结果的原因
让我们讨论一下公司和团队在遵循敏捷方法时会犯的一些错误。如果你对以下任何问题的回答是肯定的，那么现在就是你需要努力改进团队中遵循的敏捷过程的时候了。
你是否跳到实施步骤而不重视之前的 SDLC 阶段?
进行小迭代并向客户发布更改是敏捷的关键点之一。这为客户的快速反馈提供了很大的好处，因此如果期望和结果之间存在任何一丁点差距的话，那么就可以在早期阶段识别出来。
然而，有时团队会误解这一点，并认为他们有能力快速获得反馈，因此他们应该开始着手实施，而不需要再在需求收集、分析和设计阶段投入太多的精力。
当随着时间的推移项目变得无法管理并且没有人知道需要做什么、有多少工作未完成以及完成了多少时，这将会导致灾难。
改进建议：
敏捷的 SDLC 规则是：
- 实施应该有一个明确定义的需求文档;
- 除 Spike 和 POC 外，所有其他用户故事都应由设计文档支持;
- 用户故事的 DOD 应该清楚地实现设计文档或需求文档中的一个目标。
负责任务的所有者是否决定该任务的故事点?
虽然它看起来很小，但不标准化故事点不仅会影响你的项目交付期限，还会从核心损害你团队的工作文化。
许多团队认为任务的所有者知道完成任务所需的工作量，因此他们是为任务分配故事点的合适人选。虽然这乍一看是正确的，但是也会引发问题，让我们通过其中几点来理解：
- 由于一个人分配的故事点对另一个人不起作用，这样的分配会在任务和故事点分配者之间产生高度耦合;
- 在某些情况下，A 可以在一天内完成一项任务，但 B 需要 5 天才能完成该任务。所以 A 的表现是 B 的 5 倍。但是如果双方都可以自由地为他们正在做的任务分配故事点，那么 B 将分配的故事点是 A 的 5 倍，并且如果没有适当的审查，那么你将永远无法发现 A 和 B 之间的绩效差异;
- 项目的完成将更多地取决于谁在处理项目，而不是项目的复杂性。
改进建议：
- 故事点分配不是一项单独的任务，而是一项集体活动;
- 最好的方法是让整个团队(或至少团队的关键成员)参与进来，并要求他们提供工时估计;
- 获得估计工时后，团队可以选择取所有估计值的最大值、最小值或平均值。
你是否认为密切监控故事/任务的创建和结束是浪费时间?
如果产品所有者和项目经理没有监控添加到 Epics 的新任务，那么它可能会导致 Epic 的混乱和无方向的进展。如果故事没有对完成(DOD)有正确的定义，那么这些只会有助于隐藏团队的低效率。
让我们了解你必须对故事创建和关闭进行监控的原因：
- 并非团队中的每个人都对 Epic 有相同程度的理解，未经审查的故事可能没有正确的背景、与其他故事的联系以及对完成故事有意义的定义。在评估 Epic 状态的积压梳理时，这些故事只会造成混乱;
- 如果多人在没有协调的情况下在Epic中创建故事，那么就有可能使用重复/重叠的 DOD 创建故事。这将导致团队成员重复工作;
- 尽管在理想的世界中，我们相信最好的意图，并认为每个人都想为团队和项目的成功而努力。但有一点我们要接受，并非团队中的每个人都会受到同样的激励。发现创建的故事没有明确的 DOD 或重复 DOD 的情况并不少见。这样的故事将被用来标记冲刺中的努力，而不是需要付出太多的努力。
改进建议：
- 所有正在创建和关闭的故事都必须由团队的项目经理或产品负责人进行审查。
你认为 Sprint 回顾是不必要的吗?
回顾会议对敏捷过程很重要，因为健康检查对我们来说很重要。如果你定期进行健康检查，你将能够在很早的阶段发现身体的异常行为并修正后，过上健康的生活。同样，如果你的团队认真对待回顾会议，那么你将能够在早期阶段发现敏捷过程中的任何异常。
如果以下任何问题的答案是肯定的，那么你可以认为你没有有效地使用这些会议：
- 如果某个故事没有在一个 Sprint 中完成，你的团队不再详细讨论原因，而是将其转移到下一个 Sprint 或积压中?
- 如果任何故事都没有完成 DOD，你只是关闭该故事以标记努力并为下一个冲刺打开重复的故事?
- 你不会重新审视每个故事并比较分配给故事的故事点和投资于故事的实际工作量吗?
改进建议：
回顾会议必须涵盖以下几点：
- 分析有多少故事比估计的工作量付出了更多或更少的努力，以及为什么会发生这种情况。这有助于在未来的冲刺中纠正工作量估计;
- 如果有不完整的故事，请分析其背后的原因。例如，由于其他团队造成的延迟、不清楚的DOD以及在实施变更时会出现未知的变更。这有助于确定之前的哪个阶段(需求收集、设计等)需要改进;
- 如果有些故事已经付出了一些努力但故事尚未完成，则更改 DOD 并创建另一个具有不完整 DOD 的票证。只有在得到包括项目经理和产品负责人在内的团队成员的提醒后才应该采取此行动。
结论
我试图解释为什么遵循敏捷方法会导致团队效率降低的主要原因，并提供了改进建议。
如果你的团队没有犯这些错误，那么恭喜你，你正在以预期的方式使用敏捷过程。如果你认为你的团队没有遵循任何一点，那么请尝试遵循提供的建议以在该领域进行改进，我相信你会喜欢产生的正向结果的。
译者介绍
朱钢，51CTO社区编辑，2021年IT影响力专家博主，阿里云专家博主，2019年CSDN博客之星20强，2020年腾讯云+社区优秀作者，11年一线开发经验，曾参与猎头服务网站架构设计，企业智能客服以及大型电子政务系统开发，主导某大型央企内部防泄密和电子文档安全监控系统的建设，目前在北京图伽健康从事医疗软件研发工作。
原文What Can Go Wrong While Following Agile Methodology，作者：Anant Mishra
