2.6 因转型不佳而表现出的问题
许多敏捷项目正源源不断地产出低劣代码。
几年之间，许多公司和团队都加入了迈向敏捷开发的转型行列。有些公司已经改头换面了。虽说有的公司仍然要坐在会议室里开一个小时会，但原先某些坐着开会的公司，现在已经改为开站会（stand-up meeting）了。燃尽图（burn-down chart）、迭代计划表（iteration backlog）、发行计划表（release backlog），都成了新的项目管理工具。用户用例变成了用户故事。项目经理也成了Scrum主管（Scrum master）。事实却是，对这些公司来说，敏捷两个字只不过是贴在旧工作方式上的新标签罢了。不过，有些变化还是比较明显的。看看转型之前与转型之后的工作照，你就会发现一些大的区别。现在的办公室是开放式的，员工之间的隔间（cubicle）没有了，好几个人围着一台电脑工作，到处都是白板。某些公司甚至整个墙面都是白板，上面布满了各色记事贴。这就是很多公司对敏捷的理解。白板上记事贴的数量成了衡量敏捷程度的指标。他们以为记事贴越多，就说明公司越敏捷。有的公司还采用各种颜色和尺寸的记事贴来表示不同事项，他们把这种公司视作非常成熟的敏捷公司。每个人都在来回挪移那些彩色纸片（有些纸片移动地相当慢，有些稍快一点，还有的根本就不动），并感到相当充实和自在。只要老板同意，每位团队成员都可以做自己想做的事，直到有一天，也许是几个月过后，也许是一年过后，沉浸在记事贴墙面中的团队和公司会突然醒悟过来，发现有一大堆令人头疼的困难正摆在他们面前，这就是向敏捷转型不佳所产生的不良反应（Agile hangover）。
他们发现转型完毕之后，仍然不能迅速交付足够好的软件。实际上，很多公司和团队依然没能解决那些转型前就已经有的问题。他们仍然需要花很长时间来部署软件产品。仍然积累了很多尚未解决的技术问题（technical debt，也称技术债务），一开始就采用敏捷来开发的项目竟然也是这样。开发者没有积极地运用敏捷开发方式。公司里仍然需要专门的质量控制（Quality Assurance，QA）团队。许多公司甚至在每轮迭代过后，还有一段可能持续数天或数周的测试期。修改这样的应用程序仍然十分困难。代码库一团糟，耽误了工作进度。bug列表也没有比运用敏捷开发方式之前更短。他们还是会写出那种没人看得懂也没人敢去修改的程序来。他们排除故障的主要方式，依然是调试程序并分析日志（log）。有些程序写出来才几年，管理者就不打算再用它了，因为那些程序既难于修改，又阻碍业务发展。
新的应用程序虽然采用敏捷开发方式构建，却与转型前的程序一样糟糕，依然设计得很差，依然非常复杂，而且依然有很多bug。要发展业务，就需要迅速地应对变化，而这些程序和它们的开发团队却做得不够，没能“拥抱变化”。开发者的工作流程确实比原来好了，他们之间也确实开始频繁交流了，然而他们所做的技术工作实际上和从前并没有什么区别。老问题依然摆在那里：技术水平停滞不前、士气低落、积极性不高、技术问题堆积成山、技术专长不够突出、发行流程不够可靠、系统不够稳定、bug发现不够及时、测试不够可靠、测试开销太大、“开发——调试——部署”周期不够高效、产品构建时间太长、对需求理解得不够透彻等等。看到这种情况之后，公司很诧异：到底哪出了问题？当初我们要的可不是这种效果啊！公司当初之所以要改变整个流程并采用敏捷开发，主要就是想通过软件获得更高的投资回报。