技术开发 频道

软件开发项目管理的模式概述

    软件开发管理模式的简单介绍和比较

    Traditional(Waterfall)
    RUP
    CMM
    Scrum
    ASD
    Crystal
    eXtreme(XP)
    DSDM
    MSF(Microsoft Solution Framework)
    自scrum后为灵活性模式

    SCRUM

    由Ken Schwaber和Jeff Sutherland提出和倡导
    是一种极为轻型的灵活性模式的翻版
    非完整的:没有整个流程的定义
    采用所谓的"sprints",即一般是一个月为周期,来进行循环式的短期性的开发和发行管理
    每天进行15分钟的团队“scrum会议”
    采用每天进行项目的最新状态汇报,发表“burn down graph”
    适合于整个开发团队在同一个大房间里一块工作

    scrum本意是指橄榄球在开赛前的手拉手聚在一起商议进攻方案,在这里是指项目管理的模式,指每天在开始工作前要所有团队成员在一起开会,商讨当天的工作和遇到的问题。

    Adaptive Software Development(ASD)
    由Jim Highsmith提出和倡导
    也是一种轻型的灵活性模式,强调在混乱的边缘上争取平衡
    不要求执行者完全按照流程规则来做
    在项目周期里安排一个学习阶段,具体解决哪些是重要的开发任务
    将项目的历程分成3个阶段:思索、合作、学习(speculate,collaborate,and learn)
    讲究在合作阶段进行循环式的重复渐进,采取“时间盒”(TimeBoxed)的方法

    Crystal
    由Alistaire Cockburn提出和倡导
    灵活性模式的一种,尊重不同大小的项目在管理上需要有不同程度的正式性管理规章,强调在完成目前的开发项目的同时,要将眼光放在开发团队和企业未来的位置
    使用几个不同的管理方式:透明、黄色、桔黄、红色等模式
    采用轻型化的规章制度
    比较注重项目文档的用途,要求管理人员使用各种文件来帮助管理

    eXtreme Programming(XP)
    由Kent Beck,Ward Cunningham,Ron Jeffries提出和倡导
    在所有的灵活性管理模式中是最著名的
    使用所谓的故事卡进行项目的计划规划
    要求在开发过程中一直有客户的参与
    很短的开发周期:任何一个开发分段都不超过3个星期
    群体式负责制:任何人可以参与任何部分的开发
    使用重组(Refactoring)来进行渐进式设计
    采用TDD和连续性整合
    要求每周40小时工作时间

    Dynamic Systems Development Method(DSDM)
    是一个通常由来推动的管理方法
    将开发周期分成5个部分:可行性认证、商业需求认证、功能模式循环、设计和建造循环、以及最终的开发
    是一种偏向于繁重规章制度的模式
    开发的计划和设计采取渐进式的
    目前有一些商业工具可以用来帮助使用这种方法进行项目管理
    类似RUP,但是有明确的风险管理指南,能达到较好的灵活性
    这个方法不是很常用,与其他几种方式相比知名度较小,使用较少。

    MSF-Microsoft Solutions Framework
    由Randy Miller,Paul Haynes提出,微软倡导
    是基于传统模式的基础上发展起来的
    属于比较正式的模式,但最新版本包含了灵活性的模板,加入了使用者角色(Personals)的概念
    推行一个从角色到使用方案的设计流程
    开发过程采用循环型的3星期的周期
    要求单元测试的程序与开发程序的原代码一起提交
    要求100%的原代码执行测试(Code coverage)

    How Much architecting is enough?(到底应该做多少事先的构架设计和计划?)
    灵活性与纪律性(指规章制度的严肃性严谨性)的平衡,两位作者做了一个调查,发现了与crystal模式相似的结论,就是在项目管理实施过程中没有一个一成不变的规章制度,而要根据项目的规模的大小和开发团队规模灵活确定,当一个项目比较小时,事先的构架设计和计划就可以比较少,而当一个项目比较大时,事先的构架设计和计划以及规章制度就要相对增大,才能更有利于项目的顺利实施。

    管理流程设计的一些准则和指南
    团队成员之间的融洽交往是任何项目管理不可缺少的。有时非得用面对面的交流
    规章制度太多会变成繁重的负担。选择对开发的灵活性和软件质量最有利的规章去执行
    通常情况下大型的团队管理规章可以多些
    将自我调节的能力设计利用到流程管理中去

    总结
    不同大小的项目可以采取不同的、能够非常好的适合于它的管理方法
    灵活性模式有很多传统模式所没有的灵活性
    灵活性模式对建立团队文化很有效
    灵活性模式也有它的局限性
    采用时可以考虑逐步采取其中的一部分先执行,根据效果再做调整

0
相关文章