简介许多职位空缺都会在职位描述中提到“敏捷过程”一词。如果您与网络中的开发人员或经理交谈，他们中的大多数人会告诉您他们的团队正在使用敏捷方法。如今，敏捷过程这个术语在软件行业很流行，在你的团队中使用敏捷过程就像在你的代码中使用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或Backlog中？如果任何故事不做DOD，您只是关闭该故事以标记工作量并为下一个冲刺打开一个重复的故事？您不重新审视每个故事并比较分配给故事的故事点和为故事投入的实际努力吗？改进建议：回顾会议必须包括以下内容：分析有多少故事比估计的努力花费了更多或更少的努力，以及为什么会这样。这有助于纠正未来冲刺中的工作量估计；如果有不完整的故事，分析背后的原因。例如，由于其他团队造成的延误，DOD不明确，实施变更时未知变更等。这有助于确定之前的哪个阶段（需求收集、设计等）需要改进；如果一些故事已经付出了一些努力但故事尚未完成，请更改DOD并创建另一个DOD不完整的工单。只有在包括项目经理和产品所有者在内的团队成员提醒后才能采取此行动。结论我试图解释遵循敏捷方法会导致团队效率降低的主要原因，并提供改进建议。如果您的团队没有犯这些错误，那么恭喜您，您正在按预期使用敏捷过程。如果您觉得您的团队没有遵循任何要点，请尝试按照提供的建议在该领域进行改进，我相信您会喜欢所产生的积极结果。译者介绍朱刚，51CTO社区编辑，2021IT影响力专家博主，阿里云专家博主，2019CSDN博客之星Top20，2020腾讯云+社区优秀作者，11年一线开发经验，曾参与猎头服务网站架构设计、企业智能客服及大型电子政务系统开发，主导建设某大型央企内部防泄密及电子文档安全监控系统，目前在北京途家从事医疗软件研发健康。原标题：WhatCanGoWrongWhileFollowingAgileMethodology，作者：AnantMishra
