从项目需求管理的角度来说,用户的参与可以有效降低需求的“二义性”(即用户对同一种需求有不同的理解),同时通过引入用户的参与可有效提升其满意度与项目的可视性。而敏捷非常强调用户的参与,经常要求干系人对项目成果进行确认,可消除需求二义性,并提升用户体验。training.mypm.net
二、什么是敏捷项目管理论坛
敏捷方法是一种能够容纳变更的产品开发框架。比如,通常对于复杂的产品开发工作,需求在项目开始的时候尤其是未知的或模糊的。所以,敏捷框架必须要有内在的机制使项目得以处理并减少这些不确定因素。项目管理者联盟
敏捷也意味着框架本身也是灵活的,并可以适应许多情况。因此许多人把敏捷方法描述成“经验性”(Empirical)的方法,因为项目本身必须适应其环境。pmp.mypm.net
敏捷源于敏捷宣言(Agile Manifesto)。敏捷宣言是2001年在美国犹他州的Snowbird滑雪胜地召开的一次会议提出的结果。17个与会者定义了敏捷过程并签署了宣言,这些成为了今后人们对敏捷的衡量标准。敏捷宣言只有短短的四句话,却为所有敏捷实施者提供了一个共同的基础:项目管理论坛
----个人和交互优先于过程和工具(Individuals and Interactions Over Processes and Tools)项目管理者联盟
----可工作的软件优先于完备的文档 (Working Software Over Comprehensive Documentation)training.mypm.net
----顾客协作优先于合同协商(Customer Collaboration Over Contact Negotiation)club.mypm.net
----响应变更优先于遵循计划(Responding to Change Over Following a Plan)blog.mypm.net
请注意每个句子的左边比右边更有价值。这并不意味着右边的没有价值,只是说左边的更有价值。因此每个敏捷项目团队必须找到团队的正确平衡点。blog.mypm.net
PMI-ACP全称Agile Certified Practitioner,是由项目管理协会(PMI)于2011年推出一门敏捷项目管理的认证。PMI-ACP涵盖了目前主流的敏捷方法论,包括Scrum、XP、Lean:项目管理者联盟
----Scrum:Scrum是Ken Schwaber和Jeff Sutherland在20世纪90年代开发的,他们将其定义为一种敏捷项目管理框架而不是一个敏捷过程。Scrum源于精益制造(Lean Manufacturing)、迭代-增量式开发(反复与渐进式开发)和Smalltalk工程工具。Scrum提供了一套简单的规则:首先,Scrum中有三种角色:产品所有者(Product Owner)、Scrum队长以及团队(Team);其次,使用两种不同的待办事宜(Backlog)来对范围进行管理:产品待办事宜(Product Backlog)-捕获产品的范围和冲刺待办事宜(Sprint Backlog)-包含当前迭代的详细工作。冲刺(Sprint)是Scrum称呼迭代的同义词,每次冲刺为4周时间。整个Scrum团队每天碰面15分钟,以便让每个成员之间相互快速更新信息。项目管理者联盟
----XP:极限编程(Extreme Programming,XP)是Kent Beck、Ward Cunningham和Ron Jeffries在20世纪90年代开发的一套动态编程实践。现在XP是高技术行业最常采用的敏捷方法。XP中最值得关注的实践是结对编程(Pair Programming)和测试驱动开发(Test-driven Development)。blog.mypm.net
----Lean:精益开发源于Bob Charette,它是精益制造在软件开发上的应用,它是由22个工具组成的工具箱,“消除浪费”就是精益开发中有名的工具。项目管理者联盟
三、敏捷工具与方法项目管理者联盟
敏捷有许多工具,像我们熟知的迭代-增量开发、测试驱动开发、持续集成、每日例会、自适应团队等等,虽然工具方法很多,但这些万变不离其宗,其本质思想都是不断拥抱环境变化,快速响应客户需求,以开放平等的精神进行团队协作,以及不断持续改进产品。下面我们介绍迭代-增量开发、每日例会、自适应团队这三个敏捷中最核心的工具和方法:项目经理博客
----迭代-增量开发:迭代-增量开发可以说是对传统项目管理的颠覆。它实施的是重复和半并行化的开发活动,而不是在整个项目中只对每个产品开发周期(需求、设计、开发)执行一次(这是传统的瀑布模式)。这意味着项目活动极为窄小而且相互之间极为接近,他们的顺序也可以变更。作为一个经验方法,迭代越短越好,这也是敏捷过程每个迭代只需要大约2-6周的原因。项目管理者联盟
这个工具中第二个方面是实际的增量。迭代带来项目的节奏,而增量说明了项目的实际进展。在敏捷中,进展以可工作的软件为衡量基准。敏捷项目管理有点像切蛋糕,项目必须切成块,我们在开始的时候不知道我们需要多少块,也不知道这个会是哪种蛋糕。我们会随着项目的进行,一块一块地弄明白。这样在一个迭代的末期,一个优先级排序比较高的需求中的一块,就完成了,这是迭代-增量开发的真正的亮点:在项目启动两周(一个迭代)之后,一项需求就被转化成了可工作的软件并且可以向顾客展示。而这种方法最大的有价值之处在于,我们为客户打开了一个项目早期的反馈环,客户可以在现在做出变更并且按照他们所期待的正确方向指引项目,而这是许多客户在传统项目管理模式中无法想象的。www.mypm.net
迭代开发不仅仅有上述优点,它的优势还在于:在早期的迭代中就可以减少或消除高风险;根据以往的迭代效果,可以越来越精准地预测完成日期的趋势;团队士气通过不断的客户反馈而增加,生产率成倍提高等等。项目管理者联盟
迭代-增量开发对于习惯于传统项目管理模式的人或机构来说是一个巨大的改变。然而,这种改变是值得的,因为它几乎可以立即带来不可估量的效益。项目管理者联盟
----每日例会:简短的每日例会是敏捷项目的常见惯例。在每日例会中,每个团队成员只对三个问题提供答案:PgMp.mypm.net
自从上次会议以来你都做了什么?bbs.mypm.net
到下次会议前你计划做什么?项目经理博客
你所面临的问题和阻碍是什么?项目管理者联盟
敏捷项目经理感兴趣的是可交付和切实可见的结果,这些通常来说就是每日例会最经常失败的点。因为我们都习惯于每周或每月的项目报告,所以我们会精心包装我们的成就以证明我们在项目中的存在和价值。但认真想起来,一个人在8小时的工作时间能输出多少切实可见的成果呢? 但每日的进展却让团队成员感受到成就感,因为这时每个团队成员的真实成就,而不是应付项目经理和老板的。项目管理者联盟文章
|