简介

概述

当然，组织在实施敏捷方法时，并不会立即实现和平与和谐。从传统模式转向敏捷的过程充满挑战。不同的组织采取不同的路径，有些能够快速转型，而另一些则需要数年时间。

我们反复看到这些问题持续出现，完全避免这些问题是不可能的。然而，可以在项目初期就识别出所谓的反模式，从而最大限度地减少其负面影响。

反模式：降低负面影响

我们观察到以下反模式：

• 前期过度设计：在以敏捷方式开展开发和测试之前，完成全面且详尽的分析与设计工作。这被称为前期过度设计。

• 缺乏前期设计：完全没有分析与设计，仅进行开发和测试。
• 将敏捷作为借口：在一些项目中，敏捷被用作跳过必要工作的理由。
• 教条主义导致失败：敏捷的流行导致经验丰富的教练严重短缺。缺乏经验的教练在应用敏捷时往往过于教条，这可能直接导致项目失败。
• 试点项目选择不当：许多组织选择那些本就成功率极低的项目作为首个敏捷试点项目。
• 重构架构：敏捷中的架构是演进式的。但这一理念常被滥用，成为不建立架构的借口，最终导致大量返工。
• 一刀切的敏捷：复杂项目或企业级项目常常采用过于轻量的敏捷方法。不存在适用于所有项目的“万能”敏捷方法。有时，中等重量级的方法反而更合适。
• 逆向规划：例如，要求在10周内每轮冲刺完成15个用户故事。
• 过度规划：许多敏捷项目的项目经理沿用传统项目中那种详细的规划方式。
• 评审过多：对工作项频繁进行评审往往会引发问题。如果团队在最初创建这些工作项时协作更充分，很多评审本可避免。
• 抛弃有利做法转向不利做法：实施敏捷并不总是简单顺利。组织首次尝试敏捷项目时，往往不如预期成功。不要急于下结论，回到过去的做法。
• 单一职能团队：许多组织在转向敏捷时，初期会组建跨职能团队。但随着项目规模扩大、涉及多个团队时，往往倾向于按职能拆分团队。
• 兼职敏捷：尽管敏捷要求接近全职投入，但在某些组织中这并不现实。这会影响项目的进度和效率。
• 敏捷手册化：随着敏捷的普及，越来越多组织开始将敏捷方法编写成手册，却忽视了敏捷所蕴含的创造性以及团队自我学习的能力。