[Editor's note] Misunderstandings and "best practices" can keep your team spinning and unable to produce code efficiently. This article focuses on 15 signs that an agile method is going astray, written by Steven A. Lowe. The article is compiled and presented by OneAPM , the domestic ITOM management platform .
It's common to fall into a ditch while trying to be trendy. This principle is especially evident in agile development. Many companies have turned to agile for its benefits - easy change, shorter cycle times, evolutionary architecture, etc. As a result, the company's best agile practitioners have left, and the remaining people have no ability to fix the problems in the development process. question.
The problem with most agile operations is not agile concepts, but agile methods. Agile isn't a methodology, and as it is, it mixes the development process with philosophy and culture, and doing so will just go back to the waterfall model, or worse.
Fortunately, it's not hard to spot the signs that agile methods are wrong, and actions can be taken to restore harmony. This article lists 15 signs that agile methods are going wrong, any of which can make your software development efforts go to waste.
1. Implement agile and agile practices
Agile starts with attitude. If your company emphasizes implementing agile rather than agile practices , you're going in the wrong direction in the first place. Agile is a paradigm, a mindset shift in software development methodologies. The specific techniques and rituals are discussed later and are of relatively low importance. The focus is on agile practices, embracing and using the concepts outlined in the agile manifesto, and you're "implementing" agile naturally.
Be sure to read the Agile Manifesto carefully. The content in it is carefully determined. Think about the implications: get rid of useless rituals, management, and paperwork, focus on code and quick feedback cycles, self-organize, self-check, self-optimize. This is change. Concrete actions to achieve the goals set out in the manifesto will need to evolve.
If you force all teams to follow a one-size-fits-all agile "process", you're doing it wrong. This idea of a "standard" agile process is contradictory because agile means continuous adaptation and improvement.
要想补救，不要忘了你们的主要目标是交付可用的软件，而不是遵循某个方法；没有方法是万能的，适用于所有项目和团队。因此，放手让每个团队自行操作，并修正和改进实践。
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