迭代式开发进度控制

1、迭代式开发进度控制计划计划定义的是项目的目标是什么，为什么？在这个职能的执行中，项目开发组的任务、目 标、具体目标和战略被确定。即使在软件开发领域之外，人们对于事物的处理总有惯用的思路。我的定式是：“我的目标是什么？我的起点是什么（包含拥有的资源）？从起点出发需要经过哪些途径可以达到目标？这个自觉的思维模式非常有效，无论项目大小，它包含了朴素的管理思想。公司资本雄厚，对于EC 产品的战略构想是，1 为地域分散（可能是全球）的分销企业提供提高业务管理效率的软件产品；2 该产品的应用是基于Internet ； 3 该产品的应用部署问题及安全问题与专业厂商协作解决，产品的核心竞争力在于业务处理。EC

2、 项目组组建仅仅3 个月，人员背景基本分为两部分：软件开发、视觉设计。软件实现业务以满足下属一IT 硬件分销企业为目标，该企业营运总监（ MBA 出身） 负责与软件事业部协调软件开发，事实上该企业业务量暴涨，分销渠道遍布全国，迫切需要一套网络管理软件。软件工程的“迭代式开发”已经逐渐取代“瀑布式开发”成为主流。所谓“迭代式开发”，根据我的理解说白了就是象爱因斯坦那样做小板凳，终极的理想板凳就是不断修正前面板凳错误的后一个板凳，“最好的是下一个”。 “迭代式开发”与 “瀑布式开发” 存在本质的不同，传统“瀑布式开发 ” 的出发点是务求各个开发阶段的成果都是最优成果，无需变更。而“ 迭代式开发”

3、则是假设各个阶段的成果都有优化、变更的余地。我们采取了“迭代式开发”， 当前工作围绕的核心是如何使未来的变更、优化变得容易。应用 “迭代式开发”，公司的产品战略是可以通过N 次迭代实现，问题是资本的耐心常常是有限的，产品经过趋向于无穷大的N 次迭代肯定会日臻完美，但我们必须使资本在每次迭代中看到利润。换句话说，产品的开发必须结合商业成功的良性循环中。经过以上分析，我确定了项目组的产品目标：5 个月完成软件的1.0 版本开发，7 个月后完成该产品在公司下属企业的上线运行。时刻谨记的核心任务是确保当前开发模式的可复制性和 当前版本的可重用性，目前的工作是为了将来修改的简易性。计划上报后获得通过，给

4、项目组和客户（下属企业）都带来了压力，大家开始为共同的 个月的里程碑奋进。7 个月的时间内我们又细化为两次迭代，每次的过程分为：需求分析、系统设计、代码实现、系统测试。组织阶段目标确定后，达到目标要完成的工作立即浮出水面，这样依据任务安排工作，人员调配的问题很快迎刃而解。“韩信用兵，多多益善”，根据我的计划，项目组的人员配置应该是足够的，可是经过几次人员安排的反复，我的结论是成功的关键并非兵精将广，而是项目组的每个人都能各司其职，完成份内的工作。项目组最多时参与的人员达到15 人之多，但根据项目阶段的需要、公司其他任务的安排以及 IT 企业员工的正常流动，每个阶段参与项目的人员数目都不相同，但

5、直至项目基本完成，团队仍然保持着强劲的战斗力，保持了正常的动态平衡，项目没有因为人员问题影响进度。项目需求调研、分析阶段，共有9 人参加，编为三个小组分别同不同部门就不同业务内容展开交流，并完成业务活动分析。9 人中的 4 人成为项目后续进程中的核心力量，积极参与完成了项目。系统概要设计阶段有6 人参与，完成数据库设计及界面风格、功能实现模式设计。详细设计由 4 人专职进行，主要任务为页面表现及功能逻辑设计，设计成果以WORD 文档方式向页面程序员与组件程序员下发。代码实现包括组件代码编写和前端页面编写、组件调用，6 名程序员分为3 个小组。单元测试由2 名测试人员（非专职测试）在项目后期逐步

6、完成，系统联调为项目组9 人最终分担测试完成。人员组织中值得强调的经验是，“龙生九子，各不相同”，核心工作必须花大力气安排项目核心人员完成。EC 项目中人员分工非常精细，设计人员无须编码，但他们的设计文档极其详尽，使编码工作变得简单、纯粹，大大减轻了工作量。设计人员同时又是功能实现的原始驱动，他常常要牵头主动与页面人员、组件实现程序员协作沟通完成工作。激励项目管理是软科学，不是简单依据前面生硬的“三段论 ”就可以顺利把握，软件开发活动必须有良性的反馈。随着项目进程的展开，我琢磨出的经验是，阶段目标要设立明确，阶段成果要显而易见，不能模糊、抽象、 泛泛而谈。这样才能真正激发人们的成就感，加强完成

7、项目的信心，使对软件已完成部分的修正不至于寸步难行。以需求分析阶段举例来说。对定制型软件来说，客户需求调研、分析阶段的工作事实上是极其难以把握的。需求分析太深入，时间耽误太多影响后面工作，而且分析的结果还未必能用上，后期客户需求的改变会令对前期分析工作自信满满的系统分析员吐血。需求分析太浅薄，自然后期工作捉襟见肘，不说人们也知道有多少坏处。我对需求分析阶段的最终成果的定义是完成类似于SAP 实施的业务蓝图，统一图例。而此业务蓝图是在三天的小组成果报告会议中接受全体项目组成员质询，讨论通过。而此份业务蓝图经过修饰，格式规范，简洁明了，转呈营运总监签字时获得好评。最令大家得意的是，营运总监在大区会

8、议上要求各大区经理规范业务时，就是拿着我们的业务蓝图在做演示。事实上，需求分析的真正成果是大家都成为某方面的“业务专家”，成为项目中活跃的一份子，能够积极从客户的角度参与后来的项目沟通。领导项目管理者必须完成领导的职责，我对此的理解是：1 决策； 2 保证决策意图的顺利执行。性能和成本永远是一对矛盾，项目经理因此常常陷入两难的境地，这种状况下常常能体现出项目经理出色的对大小、轻重、 缓急判断的均衡感。决策能力来源于项目经理的实践经验，是管理者厚积薄发的功力体现。对于第二项，人们最常说的是“领导是一门艺术”。艺术是发散的，与严谨的二进制逻辑是格格不入的，这常常构成了程序员向管理方向发展的恐慌。虽

9、然作为EC 项目的主管对我来说是硬着头皮上，但我始终是抱着学习的态度去面对困难，我一直的心态是“让暴风雨来得更猛烈些吧！ ” 。以我的经验来看，作为项目经理，一个半年的项目下来不吵个20 、 30 架是不称职的，说明项目的沟通存在极大的问题。我没有天生的领导魅力，依靠的只是自己琢磨的两件法宝：1 坦诚对待工作上的沟通；2 任务本位，区别于官本位。坦诚就是管理过程中坦率指出别人错误，同时也准备让别人指出自己的错误。这是解决问题变得简单，在项目组中一旦形成传统，大大有益于项目的进行。我始终没有试过威势压人、软硬兼施的领导手段，对其效果难以提出中肯的意见。我觉得交流的目的只是解决一个具体的问题时，交

10、流就会变得简单，当然，经过开始阶段的磨合，我认识到立刻要求别人和自己的思路合拍是不现实的，作为管理者应当宽容。控制软件开发项目的管理在我看来是一个比较复杂的领域，它的控制包含了定性和定量的成份，同时项目进程中特有的、大幅度的迭代构成了软件项目复杂性的另一个因素，即所谓的需求变化导致设计、代码变化。如何能按期、按计划完成EC 项目，一直是我考虑的重点。宏观地看，我在项目管理中自觉地用了两级控制。一、总体控制如前 “计划 ”中所述，项目进程安排两次迭代，而每次迭代过程又包括需求分析、系统设计、代码实现、系统测试四个阶段。总体控制的目标基本是大目标，采取定性控制的方法。但要说明的是，虽然需要达到的目标是定性的，但阶段成果的体现是具体的、明确的。比如需求分析阶段，完成的阶段性成果业务蓝图所描述的业务范围、业务深度是很难量化要求的，但业务蓝图本身的表达规范、“人人都是业务专家”的要求又是具体的。二、具体控制软件作为一种可以实际感受的产品，最终拿给用户的必须是经过量化控制的。