OK，敏捷哈。不争论什么是敏捷。我们来看一些现象，然后你来告诉我，你有没有遇到过这些问题。
没人提真正的Feedback
每个迭代结束之后，我都会做Showcase。但是从Showcase上收集到最多的，就是UI的问题，字体太小之类的。每个Release发布之后，项目都会部署一个试用版本。但就是不见真正的用户来“试用”，就更别提Feedback了。敏捷不是强调Feedback吗？客户（Customer）时间不够，同时他们也不是最终用户，提不出足够有深度的Feedback。而最终用户呢，压根就没兴趣。
架构咋弄啊
每个迭代都要被催着出东西，哪里有时间弄架构哦。一开始就一个劲的加功能。前几个迭代大家都很Happy，功能出来的特别快。后来就越来越慢了，团队情绪也很差。
客户说没有不是Must Have的
事情实在太多了，做不完呀。那让客户来排优先级吧，把哪些是Must Have的找出来。但是客户说了，这些都很重要，没有这个Feature，或者那个Feature系统就压根没有用处。
路漫漫其修远兮，我到底在往哪走
团队的成员越来越多地在抱怨，天天做Story。但是这些Story都是干什么用的呢？这做一点，那做一点，根本就整合不到一个Vision里去。客户说，我给了你Vision啊，你看这个Feature那个Feature，这些要做的东西就是我们的Vision啊（心里还在犯嘀咕呢，你们干活的吵什么吵）。
这些问题都有一个相同的最终根源。我们先来看最明显的Feedback问题。为什么客户和最终用户都不提Feedback？因为不关他们的事！做Showcase不过就是在眼前晃两下，有深度的Feedback不是那么容易及时地想到的。而Release又有多少是真正部署到产品环境的？最终用户一方面还用这旧的系统，天天忙着四脚朝天的，哪里有时间来试用我们的新系统呢？无论你是设置了一个测试机在他的桌子旁边，还是一天三次的发Email提醒。只要你的系统不是完成他工作必须的一部分，他就不会理你。
为什么Release出来的系统不能部署到Production环境呢？这不是很奇怪吗。是的，确实很奇怪。但是，假如你是客户，你被你的组织委任了一个替换现有系统的差事。现有的系统有100个功能，完全开发完这些功能可能需要两年。但是，每三个月都有一次绩效考核。你会不会希望每三个月，就让领导看到你都弄出了点了啥？于是你找到了一个号称可以做敏捷开发的外包公司，要求他们每三个月给你出一个版本。但是这个版本能真正上Production么？不能！现有系统有100个功能，那么多用户在用呢。你三个月弄出来的系统怎么替换这么大一个系统啊？一个“成熟的企业”，对于一个这样系统的GO OR NOT GO MEETING都要开三个月呢。
也许你要说，我们是真正的Green Field开发，彻底重头写的。那么有你开发的系统之前，这家企业是怎么运作的？至少有一个Paper Process吧。没有电子系统，人们就用纸笔，各种单据来工作呗。IT系统不过是Paper Process的自动化而已。再说了，这年头还真没几个请得起我们，而且现在还没有一个IT系统的，需要从Paper Process开始的？
除非你做的是非常有创新性的企业开发。通过创新性的IT系统，开发新的业务。比如通过新的交易应用来辅助新的Margin Loan产品的市场投放。大部分时间来说，我们都是被引入进来“替换”现有的Paper Process，或者现有的遗留应用的。
假设我们要替换的就是一个有100个功能的遗留应用，我们是怎么来“玩”敏捷的呢？基本上来说，我们假设了一个温室的环境。在这个环境里，你可以假设你做的是Green Field的开发。把100个功能，分成多个Release，每个Release又分成多个Iteration。在每个Release之后都会发布一个Pilot版本给测试用户试用。这样就可以迭代式地添加Feature，直到最后能够替换原有的系统。从我的经验看来，正是这种做法，部分导致了以上问题（甚至有些情况下是根源）。前面已经提到了，这样会导致缺少来自最终用户的，真正的Feedback。其次，由于少了一个Feature都无法替换旧的系统，客户很难做出优先级的正确选择。以替换旧的系统为目的，所有的Feature都是Must Have。同时这样会导致每个Release缺乏明确的，唯一的Goal。经常是这个Feature做一些，那个Feature做一些，Team会觉得没有明确的目标。
如果我们不以替换旧的系统为目标？那么应该以什么为目标？这个时候你可以去看看Eric Evan的Strategic Design。他说，你应该想想What drives you to spend million dollars on this project in the first place（你为什么在最开始要在这个项目上决定花上一百万美元）。这个背后一定是原因的。基于对这个原因的理解，我们可以选定一定的Feature来实现。然后就开始实现，然后把实现部署了让所有的用户去用。用这种策略，而不是前面那种策略，这样就逼着我们去做很多事情。而我相信这些事情，很有可能就有助于解决前面四个问题。特别是，其中的架构问题。为什么呢？架构是什么？架构就是对问题的一种分解方式。怎么样才能迫使我们去思考架构问题呢？在现有的系统上打个洞，然后挖掉一块，围一道墙，里面再把新的Feature做出来。没有对系统整体的了解，没有对模块的分解，没有对模块之间耦合依赖关系的分析，是不可能做到这些的。这样就迫使我们做出一个低耦合高内聚的架构！
把这种策略做到极致就是之前我说过的持续部署才是王道。不但每个Release都和旧的系统集成起来，然后真正的部署。甚至，我们可以做到每个迭代都部署。在Fred George描述的团队里，甚至都没有迭代。一个Feature开发出来就立马被部署了。
