瀑布模式团队的故事

很多软件公司应该都熟悉W团队的故事。

这个团队属于某家电信IT公司，几年 前公司建立了一套以瀑布模式为主的软件开发过程体系，并通过了CMMI三级评 估。

W团队接手了一个周期一年的项目P，按照公司生命周期指南要求，他们选择了 瀑布开发模式。首先他们花了一个多月，试图搞清楚需求要求，并且把梳理出 的需求项写在需求规格说明书中，形成需求基线。

同时项目经理和项目核心人 员 一起，根据瀑布阶段及各阶段的活动，完成了WBS分解，排出以任务活动为基 础的详细计划，并将详细计划纳入微软Project系统中，作为监控的依据。然后 团队会花更多的时间进行设计工作，写出更长的设计文档。

经历了这些阶段 后，开发人员终于开始编码工作，这时4个月已经过去了。从项目一开始，各级领导就习惯性地下命令，指派具体工作任务。公司老总要 求部门经理在一年内完成这个项目，并纳入部门考核。

部门经理会经常参加项 目的会议、评审。部门经理有很强的技术背景，在他参加的会议中，往往由他 主导技术决策。用某位团队成员的话讲，是“一鸟入林，百鸟无声”。在每周的项目组例会上，项目经理会给每个团队成员分配一周的任务。只有当 成员完不成任务时，他才会在下周例会上提出来。有些任务也许3天就能完成， 有些则需要10天完成。团队成员已经习惯了接受任务，团队字典里没有“主 动”这两个字。

除了周例会，团队成员基本是各做各的事，很少有沟通。程序员 小王在考虑某个模块算法时碰到了困难，虽然邻座的小李做过类似的工作，但 小王并不知道。本来可以一天解决的问题，小王在一周内都没有完成。直到在 下个周例会上，小李才帮助小王解决了算法问题。

项目进入第6个月，部门经理在Project上看了项目状况，发现按当前的速度， 进度会延迟2个月。他马上把项目经理找来，对团队的工作热情表示了极大的不 满。他同时要求项目组必须更加努力，想办法（加班似乎是唯一的办法）赶上 进度。于是项目团队开始夜以继日地工作，每天工作10小时以上是常见的事， 大家也习惯了周末加班。

项目进入第7个月，团队还在紧张地进行开发工作。部门新接了个项目，且公司 老总认为其更重要、更紧急，于是部门经理要求借调团队的两个核心人员去参 与新项目的开发，同时他要求项目组自己想办法克服困难。团队刚刚形成的节 奏又被打乱，项目经理感叹道：如果领导能够对团队多些保护该有多好！到了7 月底，所有人都感觉团队承诺太多，压力太大，同时做的事情太多，大家都觉 得已经身心俱疲。就在团队根据项目前期确定的需求紧张工作时，客户（某省电信公司）也没有 闲着。

在项目进行到第8个月时，客户根据内部渠道用户的反馈及对竞争对手产 品的分析，对项目P又有了一些新的想法，这些想法通过需求变更申请提交给了 项目组。CCB（变更控制委员会）组按照流程要求进行了变更影响分析，变更工作量会大大超出合同要求，进度会延后5个月，于是客户这些需求变更要 求被拒绝了。 虽然团队通过加班追回一些进度时间，但为了按计划要求在第9个月将代码提交 给测试组，开发组只好减掉了Project中定义的一些工作。代码走查、单元测试 是自然的选项。测试组按流程要求，首先对开发组提交的程序做了冒烟测试。

结果可想而知，面对发现的缺陷数，测试员小张只能摇头。按要求开发组必须 重新修改代码，然后才能再提交给测试小组。经过几次扯皮后，为了保证进度 目标，部门经理决定直接开始测试阶段工作。

团队进入了更加混乱的测试阶段：开发和测试为每一个发现的问题是不是缺陷 争执不休；疲惫的开发人员在修复缺陷时又引入了新的缺陷；不断的回归测试 完全打乱了测试团队在项目前期制订的测试计划。眼看不可更改的交付日期越 来越近，测试组只能牺牲测试的覆盖深度，将一些难以修复的问题的严重程度 定为一般。

W团队终于按时将代码库提交给客户做验收及试运行测试。 客户的反馈让公司老总、部门经理十分失望：首先实现的产品特性不能满足用 户当前的要求，其次用户体验十分负面，更让客户不满的是提交的程序中还有 很多不该有的缺陷。这些反馈对团队打击更大，大家都感觉浪费了一年的努 力。

在团队按公司过程要求做改进总结时，客户做出了一个重要决定：将项目P的升 级工作给了公司的竞争对手。