今天有人做演讲有关敏捷开发的。就演讲而言，讲得非常好，吐字清晰，语速适当，穿插例子，娓娓道来，将意思表达得非常清楚到位，是个很好的演讲。但就内容而言，我却有很大的异议，当中部分观点我认为是对敏捷开发的严重误导。
1）误导的敏捷开发例子：版本更新很快，甚至每天都有新版本。
我的第一个反应就是版本管理存在严重问题。但是仔细一想，即便版本管理存在严重问题，也断不至每天一个新版本。这种情况，最大可能是产品没有经过严格的测试，根本不稳定，就直接放出来，结果在实际使用中bug漫天飞，开发人员不断地推出版本来补窟窿。这种情况，别说商用版本，用户无法接受如此频繁的升级（升级毕竟耗时麻烦，而且流量是用户自己掏的钱），即便是内测版本，也绝不应该如此频繁和随意。
内测版本或试用版本也是经过开发人员验证和测试后放出来，通过实际使用情况，收集用户对功能和操作中的意见，并对实际使用中测试案例无法覆盖的可能异常情况进行验证。不是发现一个bug，就改一个，发布一个，而是收集反馈，统一修订后，再释放新版本（而这，通常时间是按周来计算的），除非这个bug是个极其严重，必须马上更正。
每天一个版本，混乱。在Android上，你可以自行发布更新，但如果基于iOS的，在Apple的App Store上发布，别说每天一个版本，就算每周一个版本，Apple的软件审核流程还没走完，你就又扔一个新的来，抓狂。俺如果负责审核的，直接加入黑名单算了，懒得理你。
将版本更新速度视为敏捷开发，是完全错误的。敏捷开发在于你能够准确抓住市场，在时间窗口内快速推出产品。由于移动市场的不确定性和用户喜好/需求的不确定性，用户通常不清楚需要什么，你先给他，他再去判断，这需要在需求-开发-市场验证中进行循环迭代，以用户为最终目标，而不是机械地将敏捷视为快，而判断什么为快，又机械地用版本推出速度来说明，每天推一个版本，只能说明开发流程出了问题，整个学生小作坊。
敏捷开发也仍然是和版本更新有一定的关系。但这个版本，不是小修小补的小版本，而是有新功能，新UI，新互动方式，在用户体验上有新的感受。这样的版本，不可能一两天就升级。另外，你推给客户的都应该是个稳定的版本。
2）误导的敏捷开发例子：开发团队没有任何文档，就直接交付应用
碰到这种情况，我估计要对着电话一通怒吼，或者很郁闷地找个人倒苦水。就工作量而言，不写文档，减少写文档时间，看起来确实可以加快开发速度，但实际会严重对伤害项目。
互联网应用开发不需要似传统大型软件开发那样，按照软件工程，花大量时间去写文档。不要为了写文档而写文档，而是为了开发而写文档。
例如需求文档（或者功能文档-可以含有版本信息，业务流程文档，互通操作文档），无论具体形式如何，需要清晰地给出你的应用针对什么，提供什么，解决什么。 需求文档有时也可以作为测试的指导。 如果是client+server，你需要给出本期目标的性能，可以简单到一两页纸，但是绝对不能缺。在迭代开发中，你不断地修改它，它是你开发的轨迹。
例如开发文档，不一定要什么概要设计、详细设计这类学院派的东东，但是你需要有文档能够清晰描述开发对象的架构，模块划分，client和server的交互流程，以及关键的核心技术，例如如何避免client和server中过多连接造成的server压力，为何采用长连接tcp而非upd（反之亦然），如何制定心跳，是否需要通过使用底层的socket进行特定优化等等。你至少需要从架构师的角度对产品进行梳理，描述实现的架构、采用的机制和关键技术。开发文档或繁或简，甚至可以在代码中通过注释说明，利用javadoc生产HTML，格式不论。开发项目不是一个Hello World的例子程序。
不要让文档成为开发的负担，而是成为帮助。现在工作的流动性很大，没有文档，当中一两个开发人员离职，如何后续处理。没有开发文档，在架构和关键技术上没有想清楚，贸然而上，开发的永远只是个demo产品。再罗嗦一句，不写文档，早期貌似可以加快速度。但最终对项目造成严重的伤害，我们不要为写文档而文档，我们要为开发写文档。
正是由于没有任何文档，才导致推出后，疲于奔命地修修补补，每天一个版本。敏捷开发是快，但是快不等于敏捷开发。将此敏捷开发的案例是严重的误导。
3）最后说说历史
不是名字刻在砖上，建筑质量就会好。你看到的依然伫立的砖头上刻着名字的古代建筑，是因为你
能看的是历经千年不倒的建筑，那些倒下早已经湮没在历史中，尘归尘，土归土。举个倒下的例子。玄奘在慈恩寺建塔，塔只矗立了30年便倒塌了，武则天决定重建，重建之后的塔，被命名为“大雁塔”。你看到了保存千年的塔，没有看到之前倒塌的塔。