曾几何时，敏捷已经成为软件开发流程的标配了，软件开发管理必谈敏捷，不按照Sprint来展开进度都不好意思说自己有项目管理，不搞迭代式开发似乎就搞不了产品开发，不过，这个行业也该醒醒了。
敏捷这玩意，最开始就是所谓“定制软件开发”(Custom Software Development)界的人搞出来的概念，之后主导敏捷的大佬们，也都是这个圈子里人，那么什么叫“定制软件开发”呢？用大白话说，就是软件外包。
当然，外包也有高端和低端之分，低端被压榨得吐血，高端的知道怎么驾驭反复无常的客户，这种高端外包人士，往往有个名字叫做“咨询师”，嗯，是不是一下子高大上了很多！
这些咨询师在和翻脸比翻书还要快的客户打交道过程中，总结出了对策，他们意识到客户都难（shi）以（mei）给（yuan）出（jian）明（de）确（da）需（sha）求（bi），指望客户一次想明白产品怎么做是不现实的，所以，干脆这样，让客户一点一点提出需求，我们也就一点一点做，做出来一点东西，让客户看一看，也许客户很满意，也许客户终于想明白真实的需求，那我们慢慢改。
打个比方，客户说他想要造一座金字塔，你作为“咨询师”，认为这座金字塔要造10年，肯定不能指望一次设计好就一口气做完，于是问客户这个金字塔是要干什么？客户说要当坟墓，于是，你提出先做一个小坟墓的功能，能装木乃伊那种。客户同意了，你哐哧哐哧做了一个月，制造了一个小型地下墓室，演示给客户看，客户看了，一拍大腿，说看到这个墓室才想明白，其实他要的不是金字塔，要的是一个有排场的墓地，这样简陋埋在地下的墓室不够牛逼，于是你和客户达成第二阶段设计，做一个带兵马俑方阵来让这个墓地显得有排场，客户同意了，于是你又哐哧哐哧做了一个月，做了一个小型兵马俑方阵。客户看了兵马俑方阵，又一拍大腿，说这个方阵还真牛逼，但是能不能增加一些现代元素，把古代兵马俑换成现代装甲兵团，你于是又……
如此，周而复始，每个阶段只完成客户一个需要，当然，我上面只是一个荒诞的例子，但是你应该能够get到敏捷的含义。
最重要的是，客户虽然说不清最终的目标，但是同意每个小阶段的目标，也就是说，客户要为每个小阶段付钱。既然他愿意付钱，那他反复无常又怎样，毕竟，最后的产品是客户的，“咨询师”获得的是报酬。
敏捷开发就是这么一回事。
然后，不光是外包行业，是整个IT行业的开发者都发现，“产品设计者”和“客户”有很大的共同点，那就是，他们都是一样的无法一次描述清楚产品的最终形态，也一样的傻逼。
于是，可以用来对付无能客户的敏捷开发，也别用来对付无能的产品设计了。
既然产品设计者都讲不清楚具体需求，而且需求还总变，那就用敏捷方法哄你开心好咯，这也就是“敏捷”一下子流行起来的原因。
还好，这实际上还有明白人，《启示录》的作者Marty Cagan就觉得这是搞笑，如果产品设计者自己脑袋里都没有清晰的模型，那么怎么控制最终产品的形态呢？Marty Cagan一针见血地之处，敏捷开发也就能在定制软件方面糊一糊，真正合格的产品经理，必定会交给开发团队清晰严谨的产品说明。
当然，这世界上大部分客户和产品经理依然无能，他们达不到Marty Cagan的要求，所以，就继续这么得过且过吧。
我们也不要那么绝对，我们要接受这世界上有无能的从业者的事实，或者说，要接受这世界的复杂性和变化性超过了一些从业者的掌控能力，所以，敏捷开发依然有市场。
那么，大厂里是否可以用敏捷呢？
以我个人的体会，可以搞敏捷，但是很容易陷入“伪敏捷”的陷阱。
我在微软Exchange工作的时候，也是按照2周一个Sprint的周期前进，但是，并不是每个Sprint都有可demo的进度，产品设计者并不会根据sprint的反馈澄清不清晰的需求，每个team的燃尽图(burndown chart)都好漂亮，但是最后release却总是要delay……
咱们就别自欺欺人了好不好，对于超大型项目，你可以搞一些敏捷概念，但是别把敏捷当做挡箭牌，你需要敏捷之外的一些东西来保证项目做好。
让我更直白一点：
你不要甘心做一个无能的产品设计者，傻呵呵看每个demo的结果才想出新的需求，你一开始就应该对产品的最终形态有把握；你不要指望各自为政的Scrum Team真能把自我运转的很好，需要有一个制度来协调多个Scrum Team之间的关系。你不要指望一个sprint接一个sprint就能做出好产品，你必须要有一个大的长远计划。最早发现这些问题的，往往是大厂的人士，因为他们真正在实操超大型软件项目，他们真的能体会到所谓敏捷开发真的是一个虚伪的皇帝新衣。
