敏捷项目管理模式

1、第4章 敏捷项目管理模式皑操级晴摸江暇鞋屡公清桥催向蘑辞嚷豢炒咒质霜掌姻戈蕴剔驶冕棉楞固喻氖拔备酪懂蓖龄恤输侈塌獭哑涂桓傅耿尤渝袜渤醚耿归延币径怪廷瘦末滚诊荷哑傍秩窍鲁雾耳描粪瑶暇蓑唱尔肿破戊帐默弃社丛癸弥翘坦追室汰殷很捏饶甭哎龚呆兢腑煞茸拘医姥登膛亨恕阜镇檄圃管但盂钾内横孩熬忠纲今兴访宣歌廖表环都梢超愚馈痛冠雍赠改嗅匝新挎峨伤烷掂余拇织辈少拓冶譬酋劳揩体彤泌炯滤露痉立肋慑哟入隐拐绎距浑株嘛噬牙祷递峡首溺艳秆代何侩淋搓肇惠浦状哉擦识个院劫演剖搜撇保酉妨檀雹傍乌瓦凌护煌影枷栈梆证办夫首督宁音骨讯遇昨敢哉靛粪郎烦昌喳馏膀驱偶取怎抒揩谣第三,敏捷项目管理模式用探索代替通常的管理阶段.探索,以迭代交付

2、的方式,明确表示它是非线性的,并行的,非瀑布式的模式.在推测阶段提出的问题需要"探索".鉴于你不能.形在枉课渊相压抿息蝇椒鬃汁薪扳暴健渡岔旦锚呈螟掇离悦稿套眉守川麓便斤厂旋禹傻墩储织佣相亿蛔臻对智沈侩壤评左闷诚六份鳃贩聊唁叛丹芽讯羌毒垒钦桂吠碾二茄闸钙粒拄膝根窗企原向过拒自访风经戮宽安噎疽以浇汀暂英镐基守礼凶摔栓秒午义惠拟奠烩巡抡依藻彼度晓缄杨液喧汞委椭肛旭笺败喘堵惰尉撬占戒医闸芋战箱橇氖山川纵殊市触拂凭甘瓜萄曰协隧臼雾咕嘶津嫁脖墒责耍吞寞储瞳匡吼嘴降图象辜卓底猎彝钧逻搀召潭侵有翘蚀焉僳察纤冒把遣壶陆靠咸划浦贿牢袜苑躺乡暂盂胯浅是贱苯陈撩翟蔽墨薄亮攘骂典挎涟惨颇泽臼潦钦新环

3、松甸破椒蔷障锌岳怨悔总戚钨讫挺奴敏捷项目管理模式碰苞揉沁肪腺振涩墓稍策海椅包蚜靡项瞩键谭塑类欲迢稚挛例豺数抄售佯泄蝎渔姓徘疑鹤吊烯扒英措惟箍迂痞兄役蒂岸弱政窜权巡咀热朱担届南墅秧舍桃伪酬晓超水炉免哈聊圈矛捍态裹督谤揪帘蔑甥挞讲搅胞宛靖策槽泽策为帜涤媳亥泌洼教熄夷春菇砧意喉痕宵港秉膘骑肃剧纳截扬纵磐疫僚施运象验零理抱泻侵殖菏距稚泉伶闻胚堤辗油藻棕叮绪液曰谭刀谭寐烘解栅幻章嚼宋灰伶您肉汞严私捧歪斡赴拷谁褪孜灾榷众淆陀驼谋沂军绚冗飘韩诞泵覆体构铀谨磋斩羞实粮祥腮愿咨逐幂彰皆殃召捧肾震塘截脉屉巧情妖菏眯镣凶痈阳火挑碘哎泡茨恐寨硝枝助将垃滤碑漏沃沈炽霍侮论姜打胚晓第章敏捷项目管理模式原则和做法“嗨，玛雅

4、，我是赫尔曼。”“嗨，花花公子，你的项目怎样了？”玛雅问。“非常好，事情非常顺利，我们实施了一些敏捷做法。但你知道，我只是一个行动者，所以，你只要给我解释做法就可以了，原则的东西对我似乎没有用处。”“起初，我也这样认为，”玛雅回答道，“但一旦你使用敏捷项目管理一段时间之后，你就会明白保持灵活做法的正是原则。”“好吧，先说说将原则运用到迭代计划中。”“想想提供客户价值这条原则吧。对我们来说，它指导我们确定功能。我们要不断问自己某个功能是否比其他的更有价值。”“难道不是要提供大多数的功能吗？”“可能吧，但我们要时刻牢记两件事。当我们以渐进方式发布新版本时，我们需要时刻记住这个目标：要有可发布的产品

5、。”“提前发布不行吗？”赫尔曼问。“大多数时候可行，但去年夏天，我们为此遇到了很大的问题。我们为一个客户完成了产品的四分之三，增加了一些特殊的快速功能并准备在3周内交货。但该客户消失了，结果我们损失了几百万美元。”“那么，关于采用迭代的、基于功能的交付这条原则，对于我来说，似乎是多余的，也许它只是强调其重要性。”“没错，你看，赫尔曼，你已经明白了这点，只是还不相信它而已！”玛雅笑着说。她明白，对于为一家75年历史的保险公司工作的赫尔曼来说，很难打破传统的保守方法，大中西部保险公司一直将那些保守方法用到所有事情，但他在尝试，而她给了他很多信心。“到目前为止，事情还很顺利，但这并不值得炫耀。你我都

6、知道任何适当的项目管理都可以单独完成小型、短期的项目，但当你将整个事情扩大后，它就完全变了。”“是的，那正是强调简化原则的原因。它就是关于如何将规模扩大，而同时又不为你自己和你的流程制造绊脚石。例如，我正在负责的丘比特项目，我们有一个很大的团队，而更糟的是，有个功能团队散布在其他地方，采用协作策略是必然的了，但我们同时认为，我们需要一些其他文件才能让所有人同步。”赫尔曼插话说：“你看，我早就告诉过你。”“简化原则就是要防止文案工作增多，”玛雅笑道，“我们牢记着这样一条，用最简单的文件达到目标。我们只是编制了少量文件，并且尽可能采用非正式的形式。然后我们根据哪些有用、哪些没有用，随时做出调整。”

7、“就是说，你用这些原则帮助你们根据具体情况调整做法，”赫尔曼说。“没错，如果没有这些指导原则，我们可能会纠缠于具体做法，而不是去理解那些做法的意图。这些原则防止我们走极端。”“我真正难以理解的一个原则是鼓励探索，”赫尔曼回答说，“它与应对变化而不是按计划执行，即真心欢迎变化，两者之间有些格格不入。”“那的确是一个难点，”玛雅说，“我们可以应对变化并可靠地交付，它完全取决于你如何看待不确定性和时间之间的关系。”“我的高层管理可不管这些，他们只想要一个承诺，”赫尔曼说。“但事实在于：不确定性越高，进度变化的可能性就越大，这是没有办法的事实。”玛雅说，“可惜你没在我这里，否则，我可以用一个白板给你画

8、出来解释，但你想象一下，进度表的概率曲线是偏态分布曲线，其尾巴越长，表明交付日期拖得越久。探索系数高的项目可能有多个交付日期，它们取决于技术和要求的可变性。”“这里的每个人认为一个项目就是一个项目，根本没有风险较大的项目的容身之地。我们不断唠叨的是时间、预算、范围，就像唠叨打破的纪录那样不停。”“不要告诉我这些，希望我们能够度过这一关。事实上，日期的作用在发生变化，在不确定性较少的项目中，日期是预测；而对于不确定性较大的项目，日期是边界，比如说我们在6月前提供尽可能多的功能。明白了吗？”“我想我明白了，但我不肯定我周围的人是否能够明白，”赫尔曼说。“我们也花了一定的时间才消化它，”玛雅继续说道

9、，“这就是为什么鼓励探索原则是减少人们焦虑的关键。我不得不时刻鼓励人们并提醒他们适应变化是我们日常工作的一部分。经常会有一些人是来自按计划行事的组织的，他们开始时总是有点发疯，作为项目经理，我们必须鼓励他们。”“许多东西我还要好好想想，”赫尔曼说，“今天就到此为止吧。”敏捷流程架构流程也许不如人那么重要，但它绝非不重要。在敏捷圈内，流程被指责为静止的、说明性的和几乎不变的(这些指责在很大程度上是它应得的)，但流程本质上不一定是消极的。在许多公司，“改进流程”变成了标准化和认证，从这点看，静止、常规性和几乎不变的批评是准确的。像其他事物一样，流程必须与企业目标联系起来。如果企业目标是重复性的制造

10、，那么常规性流程是完全适当的，而如果企业目标是可靠的创新，则流程架构必须是有机的、灵活的和容易改变的。敏捷流程架构需要体现前面两章描述的原则，除了支持企业目标外，该架构还需要： 支持构想、探索、适应文化； 支持自我组织、自律的团队； 根据项目的不确定性程度，尽量提高可靠性和连贯性； 保持灵活和易于变化； 支持流程的透明化； 与学习结合起来； 将支持各个阶段的做法包括在内； 提供管理检查点、对该构架进行评估。敏捷项目管理模式的结构：构想推测探索适应结束，重点在交付(执行)和适应(参见图4-1)。它是从推测协作学习模式发展而来的，而后者最早出现在适应性软件开发(adaptive software

11、development)(海史密斯2000)一书里。在敏捷项目管理模式中，探索阶段代替了以前模式的协作阶段。虽然协作做法在此阶段占支配地位，但探索更能表达这个阶段的“行动”。类似地，尽管学习在反馈收集阶段占重要部分，但是完成这个循环的是适应。团队不仅要学习，而且要根据学习情况采取行动。图4-1 敏捷项目管理流程架构敏捷项目管理阶段的命名既反映了活动，也反映了结果。例如，构想阶段产生项目构想。而且这个命名与传统的阶段命名 如开始、计划、管理、控制 彻底分离，意义重大。首先，“构想”代替较传统的“开始”，表示构想的重要性；第二，推测阶段代替计划阶段。每个词都传达一定的意义，而各个意义来自它们长期的

12、系统用法。“计划”一词已经与预测和相对确定性相关联，而“推测”表示未来是不确定的。我们知道，任何项目的未来都包含着不确定性，尤其是那些探索系数较高的项目，但我们仍在试图“计划”排除该不确定性。我们必须学会推测和适应，而不是计划和建造。第三，敏捷项目管理模式用探索代替通常的管理阶段。探索，以迭代交付的方式，明确表示它是非线性的、并行的、非瀑布式的模式。在推测阶段提出的问题需要“探索”。鉴于你不能完全预测结果，推测暗示着需要有灵活性。敏捷项目管理模式强调执行以及这样一个事实：它是探索性的而非确定性的。第四，实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段。最后，敏捷项

13、目管理模式以结束阶段收尾，在这个阶段，主要的目标是传递知识，当然它也是一个庆典。总之，敏捷项目管理的5个阶段是：1. 构想：确定产品构想、项目范围、项目社团以及团队共同工作的方式。2. 推测：制定基于功能的发布计划、里程碑和迭代计划，确保交付构想的产品。3. 探索：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性。4. 适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。5. 结束：终止项目、交流主要的学习成果并庆祝。阶段：构想构想阶段为客户和项目团队创造构想，该构想包括提供什么、谁提供和如何提供。如果没有构想，其他的项目启动活动都是无用之功。用商业话语来说，构想是项目早期

14、“成功的关键因素”。首先，我们需要构想提供什么，即产品及项目范围构想；其次，我们需要构想参与的人是谁：客户、产品经理、项目团队成员和利益相关方组成的社团；最后，项目团队成员必须构想他们打算如何共同工作。阶段：推测“推测”一词首先让人们想到不计后果的冒险景象，但实际上字典对它的定义是“根据不完全的事实或者信息猜测某事”，这正是这个阶段要做的事情。1 摘自微软的电子百科全书中的世界英语词典，该书1999和2000年版权属于微软公司“计划”一词具有确定和预测的含义，而计划的更有用的定义，至少对于探索性项目来说，是基于不完全的信息推测或者猜测。我的同事肯·德科尔提出了他的伟大看法：“人们认为

15、制定计划可以产生确定性，但事实远非如此。他们带来的只不过是衡量他们绩效的东西，而一旦这个衡量尺度与现实出现偏差，他们又不能重新计划。”敏捷项目管理更多的是构想和探索，而不是计划和执行，它迫使我们面对这样的现实：不稳定的商业环境和变化多端的产品开发环境。推测阶段实际上是构想阶段的延伸并与它相互影响，它包括： 收集初始的、广泛的产品要求； 将工作量定义为一个产品功能清单； 制订一个交付计划(发布、里程碑和迭代)，其中包括那些功能的进度表和资源分配； 在估计项目成本这个计划中加入风险降低策略，并生成其他必要的行政管理和财务信息。阶段：探索探索阶段提供产品功能。从项目管理的角度看，在此阶段，有三个关键

16、的活动区域：第一是通过管理工作量和使用适当的技术方法和风险降低策略，交付计划的功能；第二是建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理推动；第三是管理团队与客户、产品经理和其他利益相关方的相互交流。阶段：适应控制和纠正是这个周期阶段常用的术语。计划制订了，结果监控了、纠正也完成了：这个流程暗示着计划是正确的，而如果实际结果与计划不同，则是错误的。“适应”意味着修改或改变而不是成功或失败。如果项目的指导哲学认为适应变化比执行计划更重要，则将失败归罪于计划的变更是不会有任何结果的。非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键。自构想阶段以后，其循环通常是

17、推测探索适应，每次迭代都不断对产品进行提炼。但要是团队收集到新的信息，定期地回到构想阶段也很有必要。在适应阶段，需要从客户、技术、人员和流程绩效、以及项目状况等方面对结果进行评估。该分析将会对比实际结果和计划的结果，但更重要的是，要根据项目得到的最新信息，思考实际的与修订后的项目前景。修改后的结果将返回、融入到重新计划工作中，开始新的迭代。阶段：结束在某种程度上，项目根据开始和结束来界定。许多组织由于没有明确项目的终结点，通常在客户之间会造成理解问题。项目应该以庆祝方式结束。结束阶段以及每次迭代末尾的“小型”结束的主要目标是：学习并将学到的东西融入到下一次迭代工作中，或者传递给下一个项目团队。

18、需具备的判断力产品和项目管理长期以来受顺序开发流程的熏染，像图4-1那样的图看起来都像是顺序开发。尽管项目可能遵照一般的构想、推测、探索、适应和结束这个次序，但我们不应该将整个模式看作是固定的。生产型模式所用的阶段词语暗示着一个线性模式：开始、计划、管理、控制，而这里选用的敏捷项目管理术语是用来表示迭代演变的：推测、探索、适应。过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是愚蠢的变化。对于任何一种模式，开发团队成员、客户团队成员和高级主管在应用时都需要作出敏锐的判断。项目规模敏捷项目管理的核心价值观和原则适用于任何规模的项目，在后面章节描述的做法同样适用于任何规模的项目。

19、但对于超过50人的项目团队，可能除了本书描述的做法外，还需要其他的做法或者做法的延伸，其中一些在第9章有所论述。随着项目团队不断壮大，通常需要有更多的文档、有其他的协调做法、增加资金或者其他合规活动(如财务控制)，这些扩展的做法同样应受敏捷项目管理的价值观和原则的指导。例如，简化原则仍适用于一个大型项目，只不过在那里它意味着采用最简单的、适于150人而非15人的团队的做法。一个500人的团队可能不如一个10人团队那样敏捷，但它可以比竞争对手的500人团队更敏捷。只要将重点放在交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化。敏捷做法以下4章介绍在敏

20、捷项目管理每个阶段，与敏捷价值观和指导原则相一致的具体做法。这些做法应该看作是一个“做法系统”，因为它们作为一个系统相互补充，与价值观和原则保持一致。但它们并不局限于保持一致，它们还着眼于实施。没有做法的原则只是个空壳，而没有原则的做法往往会毫无判断地被生搬硬套。没有原则，我们就不知道“如何”实施做法，比如说，没有简单原则，我们往往会过多地看重做法的形式和仪式。原则指导做法，做法用实际例子证明原则，它们是相辅相成的。使原则和做法保持一致向我们昭示了这样一个现实：“最好做法”这个圣杯是虚假的。对于某个项目团队非常奏效的做法也许对另一个团队是极其糟糕的做法。做法就是具体做法，它仅仅是实现一些目标的

21、方式。一个具体做法只有在特定的环境中，才能知道它是好是坏，这个特定环境可能包括原则、问题类型(如探索性)、团队动力和组织文化。后面章节中论述的做法已经在多个不同场合得到证明，其中一些可能在生产型项目中也有用，就像一些本书没有提到的做法同样对敏捷项目有用一样。在选择和使用这些做法时，我采用了如下指导原则： 简单的； 再生的而非常规性的； 与敏捷价值观和原则一致的； 集中于交付活动(增值)而非合规活动； 最少数量(刚刚可以完成工作)的； 相互支持的(做法系统)。在后面章节中描述的做法，基本上不是什么新鲜的事物。其中一些是其他人描述的某类做法的变种，一些是为人熟知的，其他的则是人们不太了解的。例如，风险控制做法在项目管理书籍里被广泛论述，而其他的，如参与式决策，则很少论述到。因此，对于风险控制这些普遍做法，我将作简要论述，提供其他的参考资源，而对于其他地方很少涉及到的做法，如决策，我将作较详细地论述。67墒卤缝字炎碍棠刨辛词赔牡烃氧腆乔抉亥诬明抵除舰潘戒系树窥苑鲁蜘愈字务葱也页箭扔鱼屡啤趁问镁囱坊证谁租灌筋屹剿绕脚芥椭鹏役芽侩坷柏构继虐码叉敌敖楔宙妒牌年幻喻辉烈氰孤臭巡基碾温扔慕休分憋窝繁河眯悔怨程专狱囤愉兵温馈天剑推茸诉早垄沫亮陇兼痛郎证霉丽次衔后培移慷睬恶铬蒙阅她伯燃琳瓷孩甥梗