迭代式开发进度控制..

迭代式开发进度控制..

ID:16152939

大小:34.00 KB

页数:4页

时间:2018-08-08

迭代式开发进度控制.._第1页
迭代式开发进度控制.._第2页
迭代式开发进度控制.._第3页
迭代式开发进度控制.._第4页
资源描述:

《迭代式开发进度控制..》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

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

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

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

4、确保当前开发模式的可复制性和当前版本的可重用性,目前的工作是为了将来修改的简易性。计划上报后获得通过,给项目组和客户(下属企业)都带来了压力,大家开始为共同的7个月的里程碑奋进。7个月的时间内我们又细化为两次迭代,每次的过程分为:需求分析、系统设计、代码实现、系统测试。组织阶段目标确定后,达到目标要完成的工作立即浮出水面,这样依据任务安排工作,人员调配的问题很快迎刃而解。“韩信用兵,多多益善”,根据我的计划,项目组的人员配置应该是足够的,可是经过几次人员安排的反复,我的结论是成功的关键并非兵精将广,而是项目组的每个人都能各司其职,完成份内的工

5、作。项目组最多时参与的人员达到15人之多,但根据项目阶段的需要、公司其他任务的安排以及IT企业员工的正常流动,每个阶段参与项目的人员数目都不相同,但直至项目基本完成,团队仍然保持着强劲的战斗力,保持了正常的动态平衡,项目没有因为人员问题影响进度。项目需求调研、分析阶段,共有9人参加,编为三个小组分别同不同部门就不同业务内容展开交流,并完成业务活动分析。9人中的4人成为项目后续进程中的核心力量,积极参与完成了项目。系统概要设计阶段有6人参与,完成数据库设计及界面风格、功能实现模式设计。详细设计由4人专职进行,主要任务为页面表现及功能逻辑设计,设

6、计成果以WORD文档方式向页面程序员与组件程序员下发。代码实现包括组件代码编写和前端页面编写、组件调用,6名程序员分为3个小组。单元测试由2名测试人员(非专职测试)在项目后期逐步完成,系统联调为项目组9人最终分担测试完成。人员组织中值得强调的经验是,“龙生九子,各不相同”,核心工作必须花大力气安排项目核心人员完成。EC项目中人员分工非常精细,设计人员无须编码,但他们的设计文档极其详尽,使编码工作变得简单、纯粹,大大减轻了工作量。设计人员同时又是功能实现的原始驱动,他常常要牵头主动与页面人员、组件实现程序员协作沟通完成工作。激励项目管理是软科学

7、,不是简单依据前面生硬的“三段论”就可以顺利把握,软件开发活动必须有良性的反馈。随着项目进程的展开,我琢磨出的经验是,阶段目标要设立明确,阶段成果要显而易见,不能模糊、抽象、泛泛而谈。这样才能真正激发人们的成就感,加强完成项目的信心,使对软件已完成部分的修正不至于寸步难行。以需求分析阶段举例来说。对定制型软件来说,客户需求调研、分析阶段的工作事实上是极其难以把握的。需求分析太深入,时间耽误太多影响后面工作,而且分析的结果还未必能用上,后期客户需求的改变会令对前期分析工作自信满满的系统分析员吐血。需求分析太浅薄,自然后期工作捉襟见肘,不说人们也

8、知道有多少坏处。我对需求分析阶段的最终成果的定义是完成类似于SAP实施的业务蓝图,统一图例。而此业务蓝图是在三天的小组成果报告会议中接受全体项目组成员质询,讨论通过

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。