敏捷障碍论之“需求”

“敏捷障碍论”，话题铺的有点大，有危言耸听的嫌疑。不过，在敏捷概念和模式如火如荼的今天，障碍的确是存在的。

敏捷开发的概念至今已经提出近四分之一个世纪之久，虽然当时人们更喜欢叫它螺旋式开发或其他什么名字，而敏捷宣言从提出到现在也已经经历了十个年头，可是为什么一个备受人推崇和关注的开发模式依旧不能占据市场的主导，瀑布式开发模式依旧是行业内的不二选择呢？

问题太大了，还是一点点的说吧！

先说“敏捷”，敏捷开发模式中最讲究的几个关键点是迭代、小踏步、随机应变、沟通。

一个敏捷团队的项目经理几乎不会制定一个项目从头到尾的计划，他只会花费两个小时的时间去制定团队接下来一周的时间要做什么。所以，这个团队会小踏步的前进，而且可以随时调整状态，不会让最终目标偏离计划太远。而“迭代”则是敏捷开发模式中最为核心的环节，讲求的是循环演进，如果做不到这点，也便不能称之为“敏捷”。于是，敏捷开发模式中最大的问题便存在“沟通”之中。

要想做到敏捷，“沟通”必不可少。它可以分为两个关键点：

第一点：团队内部沟通——

团队内部沟通是对任何类型开发团队都至关重要的一点，它直接影响了团队解决问题的效率以及协作能力，直接影响了人和人之间的效应是“1+1>2”,还是“1+1<2”。所以，要保持沟通的效果，一个项目经理直接领导的人不宜超过六个，如果大于这个数字，大可以创建若干子团队，以保证沟通效果。而且尽量让相关人员都坐在一起工作，使得任何两个需要协作的人员都可以在几秒钟之内找到对方的脸。更多的时候，面对面的解决问题效果是邮件、聊天工具、电话沟通的几何倍数。

第二点：团队外部沟通——

这一点，与其说是外部沟通，说成是内部沟通的变化更为贴切。敏捷开发不同于传统流水式开发模式，它更希望最终用户、开发人员、测试人员坐在一起工作。如此一来，所有的问题都会透明化，从而达到从需求分析到设计，到开发，到测试都处在一种低沟通成本状态。同时，由于最终用户在场对功能即使进行修正，使团队的应变能力大幅的提升。毕竟，需求分析过程当中最大的问题就是“内行人与外行人的语言障碍。”

基于以上两点，应该能看出沟通成本对开发团队的影响，而之所以高效的敏捷开发模式不能取代瀑布式开发模式占据主导地位，原因正在与此。根本症结在于人性的自私。

中国人奉守中庸之道，换句话说，每个人都懂得明哲保身，都懂得如何自私。所以，任何形式的沟通都会有所保留，都会在确保自身利益的基础上再去付出。于是，敏捷开发模式中最重要的一环，最据弹性的一个环节——“沟通”，便顺理成章的成为最大的障碍。

很多人，或者说大多数人的处世之道是除非有百分百获得利益的可能，否则就不会主动做事，或者做了想方设法的把责任推卸到自己直接对应的下一层级上。比方说，需求分析人员怕承担某些责任，将需求定义的模棱两可，并对较为懦弱的设计人员说，你自己觉得合适着来吧！依次类推，设计人员也会将对应关系复制给下一层级，最终这些问题都会在开发过程中爆发出来，即最终的开发人员承担项目失败的苦果。

目前，我所在的开发团队属于非软件公司养着的开发团队，如果采用敏捷开发模式，可能会取得非常好的效果。但是，因为团队沟通不畅，使得这一构想终究成为梦幻，因为开发人员与最终用户坐在一起工作是不可能的，部门与部门之间的协调几乎处在一个让人疯癫的分隔空间里。而我头顶的“项目经理”（姑且这么称呼他），幻想着达到某一效果，而在最终用户与开发人员之间添加了至少三个层次需求调研与确认人员，这非但不是敏捷，反而得到了一个完全相反的效果——

“需求核爆”与“需求蠕变”：

需求核爆：举个夸张点的例子，我的客户想要造一辆汽车。这辆汽车要具备以下功能——

省油、能跑、能飞、能潜水、能穿越撒哈拉沙漠绵延的无人区、能横渡大西洋、能抵御火箭弹和地雷攻击、最好还能防御核辐射……

与此相似，诸多需求在同一时间爆炸出来，不分主次的爆炸出来，便是“需求核爆”。需求核爆的结果是从设计到最终交付的产物只会是一个繁冗、庞大、笨重没有用处的东西，而且伴随着巨大的延期；亦或者是项目进行的中途以惨烈失败告终。承担责任的人当然不会是需求提供者，因为他们会说：我们给出了需求，但是开发人员做不出来。

需求调研团队越是庞大，人员越是繁多，“需求核爆”的可能性越大。因为没有人会为了一件不影响自己利益的事去反对别人提出的一些无关紧要的要求。而这样的需求，很难做出取舍，很难排出一个主次关系，否则真的会的最很多人。除非，你是一个真正强势的项目经理。

当然，需求核爆也是逃避责任最好的手段之一。即便项目赔得底朝天，也没有人会有责任。

另外一个——

需求蠕变：需求蠕变的解释要比需求核爆简单的多，因为它只有一句话——

“嗯，你做的不错，目前的状况已经达到了我们之前预期的要求，不过，我认为如果可以在这个地方加上这个功能会更好！”

依旧是上面的例子：在这辆汽车可以强大到“需求核爆”的地步后，会有人说：“很好，不过它要是能变形就更好了！”

这样客气的套词，似乎很难让人拒绝！不是么？可是，这句话不会只说一次。N次之后，蠕变的结果便是一个需求永远也做不完。我的一位好友身处国内一家知名的中间件公司，他们接到的一单生意便面临着“需求蠕变”——项目当中涉及八条业务审批流程，在整整十三个月时间，项目经理经历了五任变迁，需求提供人换过至少十人，“需求”这条肉乎乎的虫子经历了数十次的蠕变，仅仅八条流程到现在依旧在蠕变，没有一条得以顺畅完成。那么，结论是什么呢？结论是：产品不够灵活！

无论是"需求蠕变"还是“需求核爆”，其诱因皆是人性的自私。这两种做法的结果都会使项目夭折，夭折的结果是产品不够坚实，开发能力有限，而很难怪罪到需求提供人身上。没有结果，便不必承担责任，不是么？至于，敏捷，更无从谈起。这也使得瀑布式开发模式仍然健康、健壮的活在软件开发的世界里，因为定期的交付物使得喜欢“核爆”和“蠕变”这两款游戏的人们，很难推掉责任。

当今社会，一个人能做的事情太少了，如果不能融入团队当中，那么也注定了很难做一番成就，即便成就感也很难得到。每天只能在“需求核爆”和“需求蠕变”的游戏当中挣扎。没有担当，又何来成就呢？