【编者按】误解和“最佳实践”可能会让你的团队原地打转，无法高效产出代码。本文主要介绍预示着敏捷方法走偏的15个标志，作者为 Steven A. Lowe。文章系国内 ITOM 管理平台 OneAPM 编译呈现。

要赶时髦却掉沟里的情况很常见。这条准则在敏捷开发中表现得尤为明显。很多公司因为敏捷的好处——容易变更、周期缩短、进化构架，等等，而转投它的怀抱，结果最后公司最好的敏捷实践者纷纷离职，剩下的人员却没有能力修复开发过程中的问题。

大部分敏捷操作的问题并不在于敏捷概念，而在于敏捷方法(Agile)。敏捷并不是一种方法，把它当做方法，就把开发过程与哲学和文化混在了一起，这样做只会回到瀑布模型，甚至更糟的情况。

幸好，辨别敏捷方法出错的标志并不难，还可以采取行动重塑和谐。本文列出了敏捷方法走偏的15个标志，任何一个都可能让你软件开发的前期努力付诸东流。

##1、实施敏捷与敏捷实践 敏捷以态度为先。如果你的公司强调实施敏捷，而不是敏捷实践，那么你们一开始就走错方向了。敏捷是一个范例，是软件开发方法的思路转变。具体的技巧和仪式稍后再说，而且重要性相对较低。重点在于敏捷实践，拥抱和使用敏捷宣言中列出的理念，你们自然而然就在“实施”敏捷了。

一定要认真阅读敏捷宣言，里面的内容都是字斟句酌才定下来的。想一想其中的含义：去除无用的仪式、管理和书面工作，专注于代码和快速反馈周期，自行组织、自行检查、自行优化。这就是变革。实现宣言列出目标的具体行动则需要不断发展进化。

如果你们强制所有团队遵循一刀切的通用敏捷“流程”，这种做法是错的。这种“标准的”敏捷流程的想法是矛盾的，因为敏捷意味着持续不断地适应和改进。

要想补救，不要忘了你们的主要目标是交付可用的软件，而不是遵循某个方法；没有方法是万能的，适用于所有项目和团队。因此，放手让每个团队自行操作，并修正和改进实践。

##2、将故事分值当成目标 用户故事是敏捷的一个重要方面，从用户角度描述软件特征的需求。故事被赋予分值，以此来预估完成故事所需要的工作量。

这些故事分值既不是承诺，也不是目标。它们并没有本质意义或衡量标准，只是团队成员就项目复杂程度和团队能力达成的非正式共识。

你的团队的三分故事可能是其他团队的五分故事。将故事分值当做成功的衡量标准，破坏了它作为预估方法的价值，并且会导致“钻制度空子”来假装成功（已达到速度 X），实际上并没有成功（交付可用且有用的软件）。

解决方法很简单：与产品负责人（用户更好）在有用目标和衡量目标上达成共识。不要误将要估计的标准或要计划的规则跟“成功”混为一谈，只有交付了价值才叫成功。

##3、比较团队或成员的速度 沉迷于指标几乎是大部分程序员的第二天性。但是，如果你的团队将速度——迭代计划中团队所用的每次迭代的故事分值衡量指标——当做比较点，你们就错了。

再次说明一下，速度只是用于预估的中性指标。对比团队速度毫无意义，因为每个团队的基本单位（故事分值）“定义”不同。每个团队都是独一无二的，对比速度并无价值，而且还会引发负面行为和团队之间的竞争，而非合作。

同样的道理也适用于团队内部成员。个体对故事分值的贡献微乎其微。而且最重要的一点，故事分值本身并不是指标。比较同一团队成员的速度并无意义。唯一重要的指标是一个主观指标：在开发软件中交付的价值。

最简单的解决办法：停下来。否则只会事与愿违，浪费时间。

##4、写任务，而不是写故事 敏捷故事模板在构建某个特征对某个特定用户或角色的好处时很有用。这提醒了我们，目标是为交付能够满足某些人的使用期望的软件。如果你的“故事”大部分内容实际上都是任务，那么开发过程就会变成任务导向（做事情），而不是交付导向（创造价值）。开发团队与用户保持联系很重要，没有用户的软件一无是处。

这种问题的解决办法是平衡：总会有一些必须完成的类似任务的事项，但是故事的规模应该控制在单个迭代过程能够完成，因此把它分解成多个任务并没有意义。“完成”75%的故事毫无用处。要么做，要么不做，没有中间值可取。如果一个故事太过复杂，无法在一个迭代过程中完成，而且无法划分成几个故事，那就应该用几个过程来完成（见下一部分）。

##5、绝对不要重复故事 如果你把大的故事分解成几个小故事，只是为了能够符合一个迭代过程的时间长度，这样做是不对的。这种行为会产生几个联系更弱、任务导向的“故事”。与之相反，坚持更大的、更自然的故事，用几个迭代过程去完成。有始有终，从能够实现预期性能的最小功能“核心部分”做起，然后在后续的迭代过程中加入其它行为和元素。这样可以保证故事的完整性，从核心部分发展到可用性。

一旦核心部分完成，它的结构和性能可能会引发其它子故事，或者你会在下个迭代过程中发现优先级发生了变化，因此核心部分需要搁置。但是，如果你把故事分解成几个任务，以为把每个任务当成一个“故事”来完成会更容易，那么开发出来的软件就不会包含可识别的附加价值，因为任务倾向于专注不关联的部分，而不是相互联系的价值流。

在本文的第二部分，将继续介绍预示着敏捷方法走偏的另10个标志，敬请期待。

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

本文转自 OneAPM 官方博客

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