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

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

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

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

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

一、实施敏捷与敏捷实践

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

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

若是大家强制全部团队遵循一刀切的通用敏捷“流程”，这种作法是错的。这种“标准的”敏捷流程的想法是矛盾的，由于敏捷意味着持续不断地适应和改进。

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

二、将故事分值当成目标

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

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

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

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

三、比较团队或成员的速度

沉迷于指标几乎是大部分程序员的次日性。可是，若是你的团队将速度——迭代计划中团队所用的每次迭代的故事分值衡量指标——当作比较点，大家就错了。

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

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

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

四、写任务，而不是写故事

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

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

五、绝对不要重复故事

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

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

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

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

本文转自 OneAPM 官方博客

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