这很容易跳上花车，并在沟中结束。最能体现这一格言比敏捷开发更加明显。组织大量跳进敏捷地追求自己的优势 - 方便拥抱变化，减少周期时间，演化架构，等等 - 只有找到自己最好的敏捷业者离开公司，而其余的不安无法修复开发处理了问题。
与大多数方法灵活的问题是不是与敏捷的问题;它与敏捷，大写的方法论问题。敏捷是不是一种方法。把它当作一个混淆了哲学和培养过程，这是一个单程票回瀑布 - 或者更糟。
幸运的是，就不难认识到敏捷方法出了错的迹象，并采取措施恢复和谐。这里，我们研究15个标志你在做敏捷错误的。即使这些人能严重破坏你的软件开发工作。
这样做的敏捷与灵活之中
敏捷从态度开始。如果你的公司强调做敏捷而不是存在敏捷，你从一开始就走错了路。敏捷是一种范式，是你处理软件开发方式的一种思维转变。具体的技术和仪式是后来的，它们是最不重要的部分。重点是是敏捷;拥抱，并聘请敏捷宣言中列出的理念，你会“做”敏捷自动。
一定要仔细阅读宣言;它的用词并非偶然。想想它的含义:摆脱无用的仪式、管理和文书工作;关注工作代码和快速反馈周期;自我组织，自我反省，自我优化。这就是革命。如何实现《宣言》纲要的具体实践仍在继续发展。
如果您遵循的是所有团队都必须遵循的“一刀切”的敏捷“过程”，那么您就做错了。“标准”敏捷过程的概念是矛盾的——敏捷意味着不断适应和改进。
要纠正这一点，请记住，主要目标是交付可工作的软件，而不是遵循菜谱;没有什么诀窍对每个项目和团队都有效。因此，让每个团队采用他们自己的实践，并负责调整和改进它们。
治疗故事点作为目标
用户故事是敏捷的一个关键方面，从用户的角度获取软件特性需求。故事被分配点值来评估实现故事所需要的努力程度。
这些故事点既不是承诺也不是目标。它们没有内在的意义或尺度。它们是团队成员之间的非正式协议，反映了对项目复杂性和团队能力的共同理解。
你团队的三点故事可能是另一个团队的五点故事。使用故事点作为成功的度量会破坏它作为一种评估手段的有效性，并导致“玩弄系统”看起来成功(速度X达到)，而实际上却不成功(工作、有用的软件交付)。
解决方法是简单的：同意，并测量与产品所有者有用的目标（或更好，但用户）。请不要误会comformance对估计或合规性与计划的“成功”;成功是值传递。
比较团队或个人的速度
痴迷于度量几乎是大多数程序员的第二天性。但是，如果您的团队将速度(sprint计划中使用的团队级别的每个迭代的故事点的(平均)度量作为比较点，那么您就做错了。
同样，速度是仅用于估计的中性度量。比较球队的速度是没有意义的，因为基本单元（一个故事点）为每个团队“定义”是不同的。因为团队是唯一的，速度比较没有价值，而这样做可以鼓励消极行为和interteam竞争而不是合作。
组成团队的个人也是如此。个人对故事点的贡献是小的。而且，如上所述，故事点本身并不是度量。比较个体的速度，即使是在同一个团队中，也是没有意义的。唯一重要的度量是一个主观的度量:通过工作软件交付的价值。
造成这种情况的最简单的解决：停止。这是适得其反，浪费时间。
写作任务，而不是故事
敏捷故事模板对于根据特性对特定用户/角色的好处来构建特性非常有用。这提醒我们，我们的目标是将可工作的软件交付给那些期望从使用它中获得特定好处的人。如果你的大部分“故事”都是伪装的任务，那么开发过程就会以任务为中心(做事情)，而不是以交付为中心(创造价值)。对于开发团队来说，与用户保持联系是很重要的;没有用户的软件是无用的。
解决这个问题的方法是平衡:总会有一些必须完成的任务类项目，但是故事的大小应该足够好，以便在单个迭代中完成，所以把它分解成任务是没有意义的。一个75%“完成”的故事是没有用的。做或不做;没有部分的信用。如果一个故事非常复杂，不能在一次迭代中完成，并且它不能自然地划分为子故事，那么就多次播放它(见下一节)。
从来没有重复的故事
如果你分解大故事分成更小的故事，只是这样他们就可以在一个单一的冲刺完成，你就错了。这种做法的结果是一组的粘性少，任务导向型“的故事。”相反，坚持更大，更自然的故事，让它在多玩冲刺。攻击的故事结束到终端，从功能，使预期能力的最小的“行走骨架”，然后在附加的行为，并在以后的冲刺元素层。这使得故事保持不变，从步行骨架发展到可用性。
一旦行走的骨架就位，它的结构和行为可能意味着子故事，或者您可能会在下一次sprint中发现优先级发生了变化，在这种情况下，行走的骨架可以被放在一边。但是，如果您将故事分解成任务，因为作为“故事”来完成一个任务似乎更容易，那么结果软件将没有可识别的附加价值，因为任务往往关注于断开的组件，而不是连接的价值流。
误以为争球敏捷
Scrum是一种过程管理技术，而不是软件开发技术。看板,同上。没有强大敏捷原则的Scrum和看板最终会回归到瀑布式。在许多企业环境中，由于大量的初始积压(采用瀑布式设计而不是增量式发展)和“标准化”敏捷实践，这种情况更加恶化了。
巨大的积压
如果您关心功能交付时间(从概念到生产需要多长时间)，那么消除它的最佳方法是设置大型队列。不幸的是，许多组织仍然大规模地计划、授权和执行软件开发项目，导致从一开始就有大量的积压，并保证队列末尾的特性将有可怕的前置时间。
假设你要跑步去寻找一个你听说过的隐藏的湖。你会把你所有的东西都装在背包里，还是只装你需要的东西，这样你就能跟上节奏?巨大的积压就像这样;您希望尽快发现/验证特性值，但您的背包从一开始就超载了。
项目并不真正存在;他们的心理模型，而不是实际的东西。我们发明项目，这样我们就可以谈工作的一个模糊的数据流，如果他们的时间和精力，单块。有没有项目;只有产品。关键是要削减下来。组织围绕初始设置的功能，可以提供可衡量的价值，其次是小的，可衡量的改进“推波助澜”的项目。
从未配对（或总是配对）
结对编程受到一些人的喜爱，而另一些人则对此不屑一顾。这是一种工具，伙计们，不是宗教。它应该在合适的地方使用——是的，在某种程度上它几乎总是合适的。
配对系统的利差知识，工具，技术，技巧等整个团队;加强人力连接;支持相互指导;在许多情况下能够比单独的开发人员更快地生产出更高质量的软件。如果你看一个故事，并认为“两国元首会比一个好这一点，”然后配对是一个显而易见的选择。如果球队每个人都可以实现一个故事，然后配对可能没有帮助。像每一个敏捷实践，配对的工具;使用它时，和它是有效的。
不重构
重构不仅有助于提高代码的机械质量;它还可以帮助您从代码中学习。重构时，您将集中于更好的模型。现在，您的代码可以正常工作，但它可能感觉紧张，甚至有点脆弱。重构揭示了隐式模型，它可以帮助您理解领域。在红-绿重构的测试驱动开发周期中，“重构”不是可选的，以免积累技术债务而不能从编码经验中学习。
站立会议不结束
原本应该是简短的团队分享仪式的站立很容易变成长时间的会议。把谈话限制在整个团队应该知道的事情的简单陈述上——你昨天做了什么，你今天在做什么，以及任何阻碍因素或需要帮助。此外，一两句关于你所学到的东西也会有帮助。就是这样。您可以进行这种循环，您可以通过“走故事墙”或任何您的团队喜欢的方式来完成。
单人站不是进行技术讨论、做决策、提出设计方案、交换战争故事、重新组织一次sprint或做任何事情的场所，除了交流团队协作的必要内容。事先准备好，这样你就可以听听别人已经做了什么，正在做什么，然后决定这些事情是否与你相关，而不是考虑你要说什么。任何在相互状态更新之外出现的事情都应该推迟到碰头会或电子邮件。每个队员站立时间不应超过15 - 30秒。
没有retros
敏捷团队应该自组织，选择适合他们集体行为的实践和仪式。这也应该定期进行检查，让每个人都参与确定改进过程的方法，并采取相应的行动。它通常被称为“回顾”，是一种不浪费时间责备他人的修复过程的中立方法。
例如，一个团队成员可能注意到来自产品用户的反馈太迟了，因此建议缩短sprint可能会有所帮助。团队同意了，尝试更短的冲刺时间，并在下一次复古时重新开会，看看是否有帮助。通过这种方式，团队的流程可以持续地进行微调。
一刀切的“敏捷”通常会导致团队跳过回顾，或者将其简化为死记硬背的仪式，而没有可操作的学习。如果你注意到团队的流程有问题，但又不敢在回顾中提出来，那么回顾就会被简化成死记硬背。未经检查的过程不能被改进，团队成员必须感到安全并被鼓励这样做。
手工测试(或不测试)
测试对于生产可操作的软件是必不可少的，如果您没有自动化您的测试，您就会错过显著的效率和准确性。轻量级测试规范技术，如行为驱动开发(BDD)，是敏捷故事的最佳伴侣。在瀑布式术语中，BDD描述以一种非常紧凑的形式定义用例、指定需求，并且是验收测试。
这些自动化测试案例 - 用“测试金字塔”（技术单元测试，功能集成测试，接口测试合同，用户验收测试）的其余一起 - 提供了一个高效和可靠的选择，以验证代码更改按预期工作不破坏任何东西。自动化测试是一个安全网，为球队以信心和勇气。