【编者按】误解和“最佳实践”可能会让你的团队原地打转，无法高效产出代码。本文的第一部分介绍了预示着敏捷方法走偏的前5个标志，下面将介绍另外10个重要标志。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

6、误将 Scrum 当做敏捷

Scrum 是一种过程管理方法，而不是软件开发方法。Kanban 也一样。Scrum 和 Kanban 如果缺少强硬的敏捷原则，最终只会回到瀑布模型。很多企业开发环境中的大量待办事项（使用瀑布模型，而不是渐进发展模型）和“标准化”敏捷实践更会恶化这一问题。

7、大量待办事项

如果你很关心功能的交付时间——一个想法从概念到生产完成需要的时间——毁掉这一切的最好办法就是列个长长的任务清单。不幸的是，很多公司仍旧按照大模块来计划、授权和执行软件开发项目，这样一开始就有一大堆待办事项，并且会保证排在后面的功能的交付时间绝对长得吓人。

假设你要去寻找此前听说过的一个隐秘湖泊。你会带上拥有的所有物品，还是只带上你需要的东西，以便快速前行呢？大量的待办事项跟这个情况很像，你希望能尽快发现或验证功能价值，却在一开始就负担过重。

项目并不是真实存在的事物，只是一种思维模型。我们发明项目这个词，来谈论一些模糊的工作，把它们当做一个时间和工作量的整体。项目并不存在，存在的只有产品。关键在于简化。按照一系列能够交付可衡量价值的功能来组织项目，然后再进行小规模、可衡量的改进“浪潮”。

8、绝不结对编程（或者总是结对编程）

结对编程有人爱有人恨。兄弟们，它只是个工具，并不是个信仰。它应该用在适合的地方，而且没错，某些时候它总是适合的。

结对编程能够将系统、工具、方法、技巧等知识传播到整个团队，增强成员之间的联系，支持成员之间的互相指导，而且在很多案例中能够比程序员独立工作的效率更高、质量更好。如果你看到一个故事时想的是“这个工作两个人来做应该比一个人好”，显然应该选择结对编程。如果团队中的某个成员能够完成这个故事，结对编程可能不会有很大帮助。跟所有的敏捷实践方法一样，结对编程只是个工具，应该用于有效的时间和环节。

9、没有重构

重构不仅能帮助改善代码的机械性能，还能帮助你从自己的代码中学到东西。通过重构，你能汇聚出更好的模型。现在你的代码能用，不过可能有些令人紧张，甚至有些脆弱。重构能够揭示内含的模型，告知你对该领域的理解。在测试导向的红-绿-重构（red-green-refactor）开发流程中，“重构”并非可选项，而是必选项，除非你累积了技术债务，并且未能从编码经验中吸取教训。

10、站立会议不能及时结束

站立会议本应该是个简短的团队分享仪式，但是很容易拖成耗时较长的会议。把谈话限制成整个团队应该了解的内容的简短发言——你昨天做了什么，今天要做什么，有什么问题，是否需要协助。另外，说一两句你学到的东西也很有帮助。这样就够了。你们可以采取循环制，“参照故事墙”，或团队喜欢的其他方式来进行。

站立会议并不是探讨技术、做出决策、提出设计方案、交换战争故事、重组迭代或其他任何与必要的团队协作沟通无关事情的场合。做好准备来参会，这样你就可以倾听别人做了什么，正在做什么，并且决定这些是否与你相关，而不是思考你要说什么。任何超出互相更新状态的内容都应该随后通过群聊软件或邮件来沟通。站立会议中，每个成员的发言时长应该控制在15到30秒之内。

11、缺少回顾

敏捷团队应该自行组织，选择适合团体行为的实践和仪式。这一点也应该定期检查，让全体成员都参与进来，探讨改进流程的方法，并采取相应的行动。这通常被称为“回顾”，是个中性方法，用于修正流程，避免浪费时间责备成员。

举个例子，某位团队成员注意到，产品用户的反馈来得太迟，他建议缩短迭代时间也许会有帮助。团队通过了这条建议，尝试缩短迭代时间，并在下次回顾会议上评价这样做的效果。通过这种方式，团队的流程不断得到改进。

通用的“敏捷”通常会导致团队跳过回顾环节，或者将该环节缩减为机械的仪式，无法获得任何有意义的经验教训。如果你注意到团队流程中存在问题，却不敢在回顾中提出来，你们的回顾环节就已经变成了机械仪式。未经检查的流程无法得到优化，应该多多鼓励团队成员提出意见建议。

12、手动测试（或缺少测试）

测试对生产可操作软件非常关键，如果你没有将测试自动化，就错失了极大的效率性和准确度。类似行为驱动开发（BDD）的轻量级测试规格技术与敏捷故事搭配时效果绝佳。在瀑布式模型中，BDD 描述可以通过一张非常简洁的表格来定义用例、明确要求和接受度测试。

将这些测试用例，还有“测试金字塔”（技术单元测试、功能集成测试、接口契约测试、用户接受度测试）的剩余内容自动化，提供了一种高效可靠的备选方案，不需要破坏任何东西，就能验证一个代码变更是否达到预期效果。自动化的测试是一张安全网，能给团队带来自信和勇气。

13、完全跳过模型和设计阶段

开发软件优先于文档记录并不代表着“跳过所有模型和设计活动，只写代码”。需要避免的是花费无数个小时来制定详细的图表和规格这类投机性任务。毕竟，要了解一个模型或设计是否正确，唯一的方法就是通过写代码来进行测试。

但是如果你需要解决一个特别难的问题，那就想尽一切办法来解决。低保真度的模型或设计可以在故事的测试用例中通过大脑进行测试，而且不同的设计可以迅速完成探索。你可能还会想基于故事规模来规定这个活动的完成时间：举个例子，5分钟用于审查一个一分值故事的基本流程和接触点，15分钟用于查看一个两分值故事是否隐含有复杂问题，等等。

你的模型或设计应该能够说明故事的好处，并推动你找到解决办法，后者应该在代码中进行测试。使用你的判断力来决定需要设计多少，按照什么样的保真度，使用什么方法，每个故事用多长时间，不要因为你要“实施敏捷”，就觉得你“不能”建立模型或设计。

14、避免 devops

如果某件事令你感到痛苦，多做这件事。这会激发自动化。

把机器当做牲畜，而不是宠物，使用 Ansible、Chef、Puppet 等工具实现基础架构自动化。启动测试，实施软件自动化，或者至少打开开关。解决基础架构问题，把它作为代码库的一部分合并进去，并使用类似 AWS 这样的自助服务平台。生产周期——从处理代码变更到产品发布所需时间——会被自动地大幅度缩短，因为反馈周期变短，相应的理解时间也会缩短。理解时间加快会带来更频繁、更优质的软件交付。

15、采取“最佳实践”

通用的“最佳”实践并不存在。适用于一个团队的方法可能并不适用于另一个团队，哪怕在同一公司，甚至是同一项目。我们建造的所有东西都是基于独一无二的设计和条件，每个团队拥有的个性、技能和环境也都是独一无二的。看一看别人觉得有效的实践方法，如果可行，就试用一下，但是不要因为某些权威人士说这些方法是“最好的”，就自动套用。别人的“最好的”方法也许会成为你的团队的负担。

本文转自 OneAPM 官方博客

原文地址：http://www.javaworld.com/article/3075443/agile-development/15-signs-youre-doing-agile-wrong.html