我的敏捷矛盾

现在越来越多的非研发岗位的领导、同事提到'敏捷'，快速迭代-这个新的神谕响彻从业务到开发，从测试到运营的整个过程。有些时候无奈的发现，词汇是如此的贫乏，以至于我们用着相同的语调、相同的词汇，却描述着完全不相同的意思。

敏捷，这个被赋予了太多含义的词汇，我在这里不想引用敏捷宣言，因为说着这个词汇的人也许完全不知道或者不在意它。敏捷还被赋予了哪些有趣却有无奈的含义：

• 摸着石头过河--我们最熟悉的一句话，充分反映在我国人民的工作、生活、伦理、法制、思维的个个方面；它的朴素原理是尝试；行不行、好不好，试试就知道了。它的重要作用是替代了理性、逻辑、经验；当产品告诉我项目要敏捷的时候，我经常看到的是粗糙、想当然的业务流程、不明确的或者根本就没有的运营、操作规范；

• 能用就行--当一个项目号称敏捷开发之后，产品定义是粗略的、需求分析是粗略的、设计省略、不考虑性能、不考虑系统容量、不考虑网络环境、单元测试省略；一切拜托测试保证能用就行，实在不行就先手工。这样的系统真的可以运行，临时手工很多时候就一直手工。这样还算是幸福的，为什么？请看下一条。

• 优化似乎是不需要成本的--很多系统在无完整产品定义或者需求、无完整的设计文档、无运营手册及培训的情况下上线了，很快就收到了N个优化需求，这是不可避免的。在快速迭代的幌子下，各种优化就像免费的宣传品被排上了日程表；虽然逼迫开发人员都离职显然不符合大家的利益，所以工期仍然是可以商量的，但是每次商量的结果基本上都是勉强够用；为了拼工期，很多时候是采用临时方案，造成的结果不言而喻。

通过上面的含义可以看出，使用这个词汇的潜台词是一致的：快速；至于能否迭代，也许吧。