|
3 敏捷管理模式在软件开发项目中的应用项目管理者联盟
敏捷最早出现于1995年,相比于“分析—设计—实现”这种“重量级”(heavyweight)瀑布式软件开发方法,敏捷提倡“轻量级”(lightweight)的开发模式。“轻”与“重”的差异不是说敏捷丢弃分析、设计这些过程,敏捷要求分析和设计要适度而不是过度,而且敏捷更强调迭代,要求迭代的周期不要太长,通常是2~4周,这样软件产品是通过一次一次的较短周期迭代而成,每次迭代都有交付成果,而不是经历漫长的过程等待,等待软件最终的“破茧成蝶”。敏捷历史上最为重大的事件是“敏捷软件开发宣言”(Manifesto for Agile Software Development)的发表,宣言制定了4个核心价值观:项目管理者联盟文章
“我们正在通过实践和帮助其他人实践,揭示更好的开发软件的方法。我们的价值观是:项目经理博客
①人和相互交流胜于过程和工具;talent.mypm.net
②可以工作的软件胜于求全责备的文档;项目管理者联盟文章
③与客户协作胜于合同谈判;bbs.mypm.net
④随时应对变化胜于按部就班。也就是说,虽然右边的条目有价值,但我们更看重左边的条目。”项目管理者联盟
正如敏捷所提倡的,它的宣言也异常“轻量”。敏捷宣言强调在实践中揭示好的方法,并且认为人(开发者与客户)、可交付成果(软件)、适应变化这三者在软件开发中更为重要,它的核心是“变革”,也就是从“重量级”的过程式开发变革到“轻量级”的敏捷开发,对过程式开发过度倚重的过程、文档、计划进行精简,一个组织、一个团队、一个项目是否敏捷,判断的唯一依据 就是是否遵循这四条原则,敏捷的项目管理同样需要遵循这四条原则。项目管理者联盟
在软件开发项目中引入敏捷之后,将会引发管理上的一系列变革。首先,关注重点由过程转向人,过程是死的,人是活的,敏捷管理将充分调动人的自主能动性,对于依靠人这一最主要生产要素才得以实现的软件产品来说,敏捷管理的这一做法真正回归到了前面分析的“管理的本质”,即充分发挥各个组织以及成员的潜能,敏捷管理将关注客户与开发人员间的协作和交流,以及开发人员之间的协作和交流;其次,它将管理控制对象由项目计划转向项目的交付成果———软件,这一转变统一了客户方与开发方的期待,而不是象过程管理强调了计划却忽略了客户的期待和项目的最终目标,这种统一消除了双方内在隐含的“此消彼长”逻辑关系,成为促进项目成功的“共同动力”;training.mypm.net
再次,敏捷要求在软件开发过程中随时可以适应变化,甚至在项目快要结束的时候也能够接受变更,这种能力解决了软件产品由于“渐进认知”特点进而引发需求变更的难题,而且除了流程、技术具备这种适应能力之外,敏捷更要求开发人员拥有适应变化的正确态度,拥抱变化而不是拒绝变化,这种态度转变消除了客户方和开发方之间关于“变更”存在的矛盾,进一步扫清了项目成功道路上的“人为”障碍;最后,敏捷鼓励创新,创新不是去创造一件前所未有的产品,而是为客户“挖掘”新的价值,敏捷鼓励新思维、使用新技术,只有这样才能适应变化的环境,为客户带来价值,另一方面敏捷要求消除浪费,凡是不能为客户提供价值的合规活动———比如冗余的开发文档,这些活动就应该坚决摈除,消除浪费可以把更多开发重心放在为客户创造价值的活动上,这是一个“反向增值”的举措。training.mypm.net
因此,敏捷4个核心价值观的核心就是一个词:变革。敏捷宣言发起人之一的Jim Highsmith在《敏捷项目管理》中提出了几个重要观点:
①敏捷是促进变革并响应变化以便在动荡的商业环境中创造利润的能力;项目管理者联盟
②敏捷是平衡灵活性和稳定性的能力;③敏捷更多的是一种态度而不是一个流程,是一种氛围而不是方法。这几个观点给敏捷管理指出了方向:敏捷管理应该转变人的思维和态度,应该营造敏捷的团队氛围,应该培养敏捷的应变能力,转自项目管理者联盟
最终在多变的环境下创造利润,而转变的关键在于对灵活性和平衡性的把握。在软件项目开发中,敏捷的范围管理首先要做的是转变态度,去适应范围的变化,而不是去控制;对于变更,应该是乐于接受,而不是盲目排斥。项目管理者联盟
除了价值观作为指导,敏捷同时提供最佳的实践做法,比如测试驱动开发(TDD)、特征驱动开发(FDD),结对编程(Paring Coding)等,并且提供给软件开发组织各种敏捷的开发和管理框架,其中应用最为广泛的是SCRUM。项目管理者联盟
SCRUM的英文意思是英式橄榄球队,SCRUM这个开发框架将软件团队比作橄榄球队,有明确的最高目标,熟悉开发流程中所应具备的最佳典范和技术,拥有高度自主权,紧密沟通与协作,高适应性地迎接各种挑战,确保每天、每个阶段都明确地朝目标推进。SCRUM的实施过程是:项目管理培训
(1)制定产品Backlog,Backlog是软件产品的一个需求列表。项目管理者联盟
(2)将整个产品的Backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。Sprint意思是冲刺,代表一次迭代周期(通常为30天),开发团队需要完成一个制定的Spring Back-log,并且最终成果是一个增量的、可以交付的产品。项目经理圈子
(3)召开Sprint Planning Meeting,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。项目管理者联盟
(4)进入Sprint开发周期,在这个周期内,每天需要召开Daily Scrum Meeting(站立式会议)。
(5)整个Sprint周期结束,召开Sprint ReviewMeeting,将成果演示给Product Owner。talent.mypm.net
(6)团队成员最后召开Sprint Retrospective Meet-ing,总结问题和经验。转自项目管理者联盟
(7)这样周而复始,按照同样的步骤进行下一次Sprint。项目管理培训
从SCRUM实施过程可以看出,产品Backlog的制定对应于传统过程管理的范围定义(Scope Defining),产品Backlog是客户期待包含进项目的软件特征列表,在制定这个特征列表的时候,最需要注意的是确保这些特征能够彼此独立,这样的划分使得随时做优先排序或者进行变更成为可能。blog.mypm.net
作为项目管理者,有几点是在制定产品Backlog中要明确的:第一,产品Backlog SCRUM实施过程允许随着项目进展而进行变更,或者增加,或者修改,或者删减其中的一些特征;第二,产品Backlog的制定需要客户参与,并且由客户做出选择;第三,产品Back-log有一个拥有者,即Product Backlog Owner,这个拥有者可以是开发方的产品经理,或者直接来自客户,他拥有该特征列表的最终决定权;第四,产品Backlog的优先排序原则将取决于特征的价值,也就是说,如果不是现在就实现这个功能,会存在哪些风险,或者要丢失什么样市场机遇,应该根据价值原则做出决定;club.mypm.net
|
