转：胡思乱想的猫
我在ABC公司的第一个项目 －－ 编了个小故事，讲讲我理解的软件生命周期模型
1. 准备战斗
“恭喜你，你从今天开始就是我们ABC公司软件部的部门经理了。”人力资源小魏向我伸出了热情的手。我很兴奋，我知道凭借我过去几年的经验，尤其是最近认真学习了高质量软件工程课程和项目管理知识体系指南，在面试时的突出表现终于打动了ABC公司的老总，我对如何控制项目的需求，怎样在实际软件开发中应用各种软件生命周期模型来规避项目风险和保证项目质量的论述，一定给他留下了深刻印象。
但是同时，对方老总反复提到项目延期，需求混乱，人员流失等各种面试问题也让我感到了种种压力，似乎ABC公司内部软件开发流程和方法存在着很多问题。
无论如何，如果这是一场战斗，我准备迎接挑战，那么，开始吧！
2. 敌人已经出现了，你的武器呢？
我把销售奖励程序SBP建议书报告交给老总，建议书中描述了建议内容：单机版实现用来管理支付地区代理佣金的软件SBP，开发周期为一年。
老总看完后微微皱了皱眉头，很坚定的说，“单机版落伍了，做成网络版吧，业务部门会给你们提供具体的需求，另外一年时间太长了，6个月做完，别担心成本，你可以雇佣临时的高级合同工加入你的团队，给你配备最新的硬件设备，让大家都加加班吧，项目做完了支付高额奖金。”
我回到软件部，找到项目经理小杨，他在ABC公司多年，非常了解公司情况，我先跟他一起讨论这个项目情况，我们决定用报表自动生成工具来缩短开发报表的时间，使用C++来完成这个项目，小杨愁眉苦脸的嘟囔着：“虽然是这样，但是你看着吧！业务部门根本不知道自己要什么，中间需求会经常变，新来的合同工很容易就会做到一半离职，代码和文档又找不到，加班加点做出来的程序BUG一大堆，大家一定会互相抱怨，最后也许会有高奖金，但是这么累可能还会走一批人的，唉，我这个项目经理真是很难做啊！”
我非常理解的拍了拍小杨的肩膀，“别灰心，让我们明天好好想想怎么解决这些问题。”小杨半信半疑的看了看我，只能说“好吧，那明天我们讨论吧！”
3. 要选好武器，就要知道敌人的弱点
当晚我彻夜难眠……
我总结了到ABC公司后了解的情况以及结合小杨的抱怨，整理下思路，分析了目前ABC公司软件开发过程中的一些问题：
1、 配置管理混乱，代码和文档没有统一管理；
2、 需求控制有难度，业务部门的需求不清晰，也没有加强引导和挖掘；
3、 项目规划有风险，团队成员不稳定，项目工期盲目缩短；
4、 项目监控容易失控，项目经理不理解项目监控的意义，没有项目质量标准衡量
5、 风险管理基本没有
……
“应该为SBP选择什么软件生命周期模型呢？这是你应该解决的第一个问题。”耳边有个声音在提醒我。
那么首先，需求不明确，业务部门使用信息系统经验不多，软件部门需求分析人员又对业务系统不是很了解，无法做到比较完整和深入的引导和挖掘，所以一定要借助原型模型（Rapid Prototyping Model），最大程度的减少需求的变更，但是原型法也无法保证需求是稳定的，另外其他的不确定性因素也很多，所以也同时考虑增量/迭代模型（Incremental / Iterative Model），用增量迭代模型和原型法综合使用，来确保把风险降低，但是我知道，必须保证每一次增量或迭代都有明确的交付和出口的准则。
我把一切想清楚了以后，感觉放松多了，准备用我的方法来实施这个项目。剩下的就是具体执行的事情了，经过这么久的思考，我终于累了，沉沉的进入梦乡。
4. 有了武器，如何把它用好？
第二天我跟小杨又进行了探讨。
小杨说：“原型法？”
我点点头：“就是借助一些软件开发工具或环境尽可能快地构造一个实际系统的简化模型。”
我顺手在面前的纸上画了一个图形：
┌→ 需求分析 ←┐
│ ↓ |
│ 快速设计 |
│ ↓ |
│ 构造原型 ─┘
│ ↓
└─评审和修改需求
小杨继续问：“可是为什么要用原型法，我担心这样需求调研阶段的时间会拉长，为保证项目需求不变，我们可以让客户在需求上签字。”
“但是业务部门的人对信息系统的使用比较少,我们在调研阶段需要的是一个启发式的过程，而原型法就是做出一个用户能看到的模型来，这是很好的启发式方法,很直观的知道双方在需求理解上是否一致.否则即使双方都签字认可的需求往往后期也会有变更。”我进一步向他解释原型法的作用。
“嗯，听上去不错，可以这样试试，那增量迭代模型呢，我们应该怎么使用它呢？”小杨已经逐渐跟上我的思路。
“我们要讨论下是用增量模型还是迭代模型。我们可以把项目分成几期来完成，如果第一期只包含部分功能，然后第二期、第三期再逐渐增加功能就是用增量模型，如果第一期包括所有的功能，但是功能比较简化，然后第二期，第三期再逐渐增加功能复杂度，就是迭代模型。”
小杨想了想说“根据我对我们公司业务部门的了解，应该用增量模型比较合适。每次把一个模块讨论清楚还是有可能的。”
我对他的说法表示怀疑：“但是业务部门对需求不明确，如果用增量模型每个模块的后期还是风险很大，在进行下一个模块的时候前一个模块如果还有变动就更不好把握了。还是用迭代模型比较好。”
小杨点点头说“也是，但是原型法跟迭代怎么结合呢？也是迭代的做出每个版本的原型吗？每次都进行重复的需求调研？”
“差不多，但是不是重复的需求调研，而是每次都有在原来的基础上有新的内容，原型是有两种的，一个是抛弃型，一个是非抛弃型。第一个版本的调研是做出一个模型来，这个模型可以最后抛弃掉，我们就只用它来讨论需求，但是第二次迭代的原型却是非抛弃型的，我们用第一个版本的完成版，一个可以独立运行和包含基础功能的系统来做原型的基础，后期每次迭代都继续完善这个原型。”我进一步解释。
小杨也兴奋起来：“这样的确可以有效的控制项目需求的风险了。我们就按照这种方法作，那我现在应该作什么？”
“开始按照我们的想法作一个初期的总体项目计划吧，还有评估下在6个月内完成项目需要的资源。记得要保证每一次迭代都有明确的交付和出口。”
“好的！我这就去作。”
送走了小杨以后，我决定开始着手改善下公司的配置管理部分。于是我制定了一些配置管理的规范和准则，以及各种文档的模板和基准。（具体内容不在本文讨论）
5. 战斗进行中
5.1 项目启动，总体项目计划我满意的看着小杨提交给我的项目计划表：
n 将SBP项目分为4个版本完成；
n 工期为6个月，第一个版本2个月，第二，第三个版本周期为一个月，最后一个版本为2个月；
n 每一个版本都包括：需求调研->设计->开发->测试->交付五个阶段；
n 交付作为每个阶段的里程碑，交付之前的测试环节，为每个版本是否符合交付提供标准和验证；
n 而下一个版本也是以界面原型为基础的需求确认作为启动；
n 4个版本逐层强化了软件的功能，由简单到完善；
我正看着，小杨推门进来说：“经理，你看项目计划了吗？觉得怎么样？”
“很好，但是有一个问题我想说说，用迭代模型有几个注意事项……还是你先说说你的理解吧！”
小杨想了一会说：“嗯，我认为应该注意的是整个项目的架构设计了，不然用迭代模型反而有可能速度变慢。”
“为什么？”
小杨接着说：“因为功能由简单到复杂，中间还要有几次完整的展示成果，可能会出现第二版本的时候需要修改第一版本的某些代码，甚至有可能会需要重新写，所以一定要在代码级别注意抽象，多使用公共类，模块之间尽量松耦合。”
我接着小杨的话说：“所以，功能增强必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构，在项目初期的设计工作必须做全盘系统分析，也要求架构设计时要严谨”。
小杨明白了，马上说：“那我调整下计划，第一版本时间增加半个月吧！”
我笑了笑：“好，让架构师理解好整个项目的架构规划，在初期多做一些工作吧。也会避免一些风险。”
小杨说：“好的，我来总结下迭代模型的几个注意事项：
n 每个迭代周期要有明确的交付标准，这是为了避免迭代模型变成了边做边改模型；
n 软件要具有开放式的体系结构，以便功能增强时不需要重写或修改代码，不要影响进度
”
我接着说：“那我总结下迭代模型的几个优点：
n 逐渐引导客户需求，避免需求变更
n 增加工作效率，关注的焦点统一
n 激发团队斗志，定期出现可用成品，对客户和开发人员都有成就感
”
小杨笑着说：“呵呵，这些还真是我们现在遇到的问题，按照这个模型进行一定会顺利很多，对了，刚才你提到风险，这个怎么管理呢？”
我很高兴小杨已经开始理解项目监控的重要性了：“这就是项目监控的一部分了，来，你坐下，我们详细讨论下项目监控问题。”
……（具体内容不在本文讨论）
讨论后，我提醒小杨项目正式启动要有启动会，把我们的项目方式跟业务部门的客户沟通清楚。
5.2 执行阶段，解决问题的方式在小杨的定期周报中我看到项目进行的比较顺利，由于原型法的帮助，业务部门的同事已经通过原型看到了实际使用效果，需求提出的比较明确，虽然需求调研阶段的时间相比其他项目要长一些，但是后期的变更却很少了，需求调研以后，小杨又细化了项目计划，将需求调研的结果逐步分解到了WBS中，这段时间也同时充分利用了C++的优势，开发进度非常稳定。
第一个阶段在第二个月中旬结束时顺利完成了。用户签字确认了第一个阶段的成果，一个可以运行的简单功能的系统。
5.2.1 需求被激发过度怎么办
第二个阶段的需求调研开始了。
我收到了小杨的周报，发现需求调研速度延期了一些。于是我把小杨叫来了解情况，小杨说“因为用户在使用了第一版本以后激发了很多需求出来，又都是想尽快实现的。”
“噢，是这样，这很好啊，说明客户的需求已经被我们激发出来了，我建议你把收集到的需求记下来，然后分成这个版本和下一个版本两部分，这样下一个版本调研的时候可以直接使用，节省下一次调研的时间”
小杨点点头：“我知道了。”
接下来的工作也比较顺利，转眼到了第三个版本的后期。
5.2.2 项目遇到风险延期了，怎么继续迭代
有一天小杨找到我，直接说：“有麻烦了，我们请的高级合同工跳槽了。”
“噢？那你的风险计划里是怎么应对的？”
“新找一个高级开发人员。”
“嗯，有什么困难么？”
小杨想了想说：“找人倒是没什么困难，前一个合同工的代码也都在公共服务器中，他的代码也按照你制定的配置管理规范的要求写了注释，也写了相关的开发文档，交接会很方便。只是换人阶段会影响工期。”
“噢，这是我们最不想看到的，我建议可以这样，迭代模型是可以并行的，我们可以按照计划进行第四个版本的需求调研，跟第三个版本的后期并行，给新来的人一点时间赶上进度。”
小杨点点头：“这是个好办法，但是我们用的是原型法，没有第三版本的原型，怎么作第四个版本的需求调研呢？”
“只能通过建模工具先建出没有完成的功能了，我们要学会变通。”
小杨继续点头说：“那好吧，我知道怎么处理了。”
5.2.3 客户的需求改变了，是使用配置管理的需求变更还是使用迭代？
第四个版本刚刚启动，小杨又过来找到我，原来是业务部门通知新的销售奖励制度已经发布，必须修改第二版本和第三版本的部分程序，但是由于我们一开始的架构设计是开放式的，修改的内容不是很多。
我问小杨：“你认为这是需求变更吗？还是下一次迭代的新需求？”
小杨不解的说：“我也有点糊涂了，应该怎么归类呢？不同的归类有不同的应对方法。”
我笑了笑，跟他解释到：“迭代模型的另一个缺点，就是版本、模块之间的交互问题了，理想状态是逐渐升级功能，新功能是原功能的升级，而不是修改。这次的新的销售奖励制度是对原有已经完成的功能修改，不应该是下一次迭代的新需求，而是需求变更。”
小杨还是一副愁眉苦脸的样子：“是需求变更应该怎么办呢？”
“那就需要进一步跟客户说明这个问题了，需求变更应该按照配置管理中的需求变更流程执行，有需求变更就要增加相应的时间和成本。”
小杨似乎明白了：“那就是说我需要计算出这个变更所用的时间和资源，然后申请计划变更了？”
“是的，如果客户也认可增加时间我们就可以按照新的计划执行了。”
5.3 最终交付，还有其他问题吗？第六个半月的时候，项目终于顺利的按期完成了，小杨兴高采烈的过来向我汇报成果：“经理，用原型模型和迭代模型果然顺利的完成了项目，业务部门已经签字验收了最后一个版本。”
“恭喜你！但是没有其他问题了吗？”
“业务部门那边还有一些需求变更没有处理，已经记录了。”
“嗯，跟业务部门的客户沟通过吗？他们有意见吗？”
小杨低头笑了笑：“是啊，你怎么知道客户有意见的。”
“当然会有意见了，因为客户的需求还没有都完成啊。”
“那怎么办呢？”
“项目启动要有启动会议，项目交付当然也要有交付会议了，在交付会议上你可以跟客户讲清楚，需求是无止尽的，但是需要阶段性的实现，本期项目结束了，我们共同的收获除了这个可以运行的系统，还有一些收集到的需求。在今后的使用中可以陆续收集需求，作为二期开发的需求分析和调研的基础。”
小杨说：“明白了，下次项目我们还按照这两种模型来做！”
“哎？你这么说就不对了，每次项目要根据具体情况来选择不同的生命周期模型。”
我接着说：“对了，别忘了，按照配置管理规定对代码和文档进行归档。”
6. 庆功宴
项目结束以后，公司给每个团队成员发放了奖金，小杨组织大家吃了庆功宴。我作为特约嘉宾参加了庆功宴。
小杨向我敬酒：“经理，这次项目我学到了很多东西，谢谢你！”
我笑着说“是你让项目得到了很好的执行。别忘了，庆功宴不只是吃饭啊，最重要的庆功是总结这个项目的经验教训，形成文档，为以后的项目作借鉴。”
7. 后记 | 
免费注册
发表于 2010-11-26 16:48
