预示敏捷方法走偏的15个标志——第2部分

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

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

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

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

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

##八、毫不结对编程（或者老是结对编程） 结对编程有人爱有人恨。兄弟们，它只是个工具，并非个信仰。它应该用在适合的地方，并且没错，某些时候它老是适合的。

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

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

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

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

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

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

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

##十二、手动测试（或缺乏测试） 测试对生产可操做软件很是关键，若是你没有将测试自动化，就错失了极大的效率性和准确度。相似行为驱动开发（BDD）的轻量级测试规格技术与敏捷故事搭配时效果绝佳。在瀑布式模型中，BDD 描述能够经过一张很是简洁的表格来定义用例、明确要求和接受度测试。

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

##1三、彻底跳过模型和设计阶段 开发软件优先于文档记录并不表明着“跳过全部模型和设计活动，只写代码”。须要避免的是花费无数个小时来制定详细的图表和规格这类投机性任务。毕竟，要了解一个模型或设计是否正确，惟一的方法就是经过写代码来进行测试。

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

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

##1四、避免 devops 若是某件事令你感到痛苦，多作这件事。这会激发自动化。

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

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

本文系 OneAPM 工程师整理呈现。OneAPM 能为您提供端到端的应用性能解决方案，咱们支持全部常见的框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，性能监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客

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