当前位置：
ScrumMaster、敏捷教练与项目经理的实用指南：《如何构建敏捷项目管理团队》
ScrumMaster、敏捷教练与项目经理的实用指南：《如何构建敏捷项目管理团队》
<dd data-toggle='tooltip' data-placement='top' data-original-title='添加时间：
13:52:00 &&'>
<dd data-toggle='tooltip' data-placement='top' data-original-title='作者： 潘仙芝 &&'> 潘仙芝
<span class='label label-warning' data-toggle='tooltip' data-placement='top' data-original-title=' 阅读：1260'> 1260
[美]丽萨·阿金斯著，徐蓓蓓 白云峰 刘江华译。
电子工业出版社，2012年06月出版发行。
本书结合作者的亲身经历告诉读者：如何建立一个高性能的敏捷项目管理团队，以及最终成为一名优秀的敏捷教练。
作者将敏捷教练定义为导师、协助者、老师、问题解决者、冲突领航员、协作指挥者，正是这种不同角色之间的细微区别才使敏捷教练的工作富有深度。&
例如，作为导师，总会向组员传授一些东西，如敏捷开发实践，但是作为绩效教练，则更应该鼓励团队成员去自行学习和领悟。
丽萨作为生活顾问的经验不仅赋予了她敏捷教练工作更多的内涵，同时使本书能从更多维度上理解教练角色的含义。目前很多敏捷“教练”更像敏捷实践的传授者，本书能够帮助他们成为更加有效率的团队表现激励型教练。
本书主要有三类读者：敏捷教练、敏捷开发团队领导和其他个人。
首先，对于任何认为自己是敏捷教练、培训师、导师或协助者的人来说，本书都是一部富含理念、实践和心得的著作，可以从书中获益并提升自身表现。
例如，丽萨提出这样一条发人深省的观点：“在团队中，ScrumMaster如果不仅能够贯彻敏捷思想，而且能够以追求更好的团队表现为己任，那么他实际上已经是一名敏捷教练了。”在第10章中，丽萨研究了“合作”和“协作”的概念，这两个不同概念的应用常常可以导致截然不同的团队业绩。每个诸如此类的新观点都为敏捷教练的角色增添了新的含义。
本书的第二类读者是所有敏捷开发组织中身处领导岗位的人——经理、产品负责人、ScrumMaster、教练、项目经理或过程管理人员。
虽然敏捷教练负有指导组员的直接职责，但其他团队领导人员的职责中也含有部分类似内容。关于自组织型团队已有很多定义和描述，但鲜有人给出此类团队的实际形成过程，或者告知通过何种途径可以促成此类团队的形成。领导者的风格通常会对工作环境产生影响，本书可以帮助他们培养出成熟的自组织型团队，更重要的是，可以让领导自身更加适应敏捷和灵活。
最后，任何希望成为高效敏捷开发团队一员的人都可以从本书中获益。
“想要更好地进行团队合作，首先要自我提高”，“我对项目团队中的各种关系都应负责”。这就意味着提升团队表现绝不仅仅是团队领导或教练的责任，所有团队成员都应做出贡献。丽萨的书能够帮助团队成员自我学习和提高关于敏捷开发的知识和认识，从而在提升自身的基础上进一步提高团队的整体表现。第3章对于团队指导和普通团队成员具有同等重要的教育意义。
青岛开发区武夷山路167号千禧龙花园9-1-101室传统项目与敏捷项目管理对比
我的图书馆
传统项目与敏捷项目管理对比
作者：阿木。作者授权早读课发表，转载请联系作者。编辑：Verna。欢迎投稿到早读课，投稿邮箱：软件项目管理的两大主流管理模式分别是传统项目管理和敏捷项目管理。传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。&一、管理流程完整的项目管理流程可以总结分为五个过程组：启动、规划、执行、监控、收尾1、传统项目管理传统的项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节的有文档输入和输出。比如，PMBOK 第五版对项目整合管理的过程组做了文档输入和输出的整理，如下图。&&但是，项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和干系人进行管理，每个环节都存在启动、规划、执行、监控和收尾过程。如果采用传统的项目管理模式，每个环节都必须要进行严格的规划，一旦出现规划以外的变更，都需要经过批准后才能执行改变。2、敏捷项目管理敏捷项目管理简化了繁琐的流程和文档管理，主张团队内部的面对面沟通和交流。以 Scrum 为代表，简单、持续集成、不断交付、价值优先、拥抱变化的原则在面对时刻变化的市场经济和不断发展的技术时变得十分友好。敏捷项目中，项目管理计划分不同的等级，可以用一个洋葱图来表示，也就是洋葱计划图，如下图。&&战略和投资规划在敏捷项目管理的最外层，由更广泛的组织管理系统来处理。由外往内，不断切分项目计划，最后实现最小周期的可行性版本迭代。对复杂或不明确的客户需求进行合理的分割，最终实现总体上的统一。&二、风险控制环节项目风险在任何项目中都存在不确定性，一旦发生，会对项目造成积极或消极的影响，如范围、进度、成本和质量。&1、传统项目管理：&传统项目管理要求项目在规划过程中规划风险管理、识别风险，并且对风险进行定性/定量分析，给出风险应对方案。虽然已知的风险可以在被识别和分析后采取应对措施，但正是因为风险的不确定性，要求项目风险管理必须给未知风险或者已知却又无法主动管理的风险分配一定的资源储备。&所以，传统项目管理会要求提供风险登记表，并且记录风险应对措施在处理已识别风险及其根源方面的有效性，完成风险再评估和风险审计，直到风险被降到最低。&2、敏捷项目管理：&敏捷项目管理不同于传统项目管理，开发评估是以工作量为导向而非时间导向。所以，在进行开发任务评估时采用的是相对估算而不是绝对估算，为风险留足了应对空间。同时，Scrum集合了一线人员的参与，经验分享，集思广益，将小型团队转化成独立的管理者，更有利于问题的解决。&敏捷项目管理在项目没有正式结束前，交付的可用软件是允许风险存在的，并且是根据风险的优先级来进行排期修复。&三、第三方业务风险控制服务企业项目管理分析1、项目管理模式：外瀑布内敏捷（有人称为“信封法”）&第三方业务风险控制服务行业目前还没有发展出固定的行业标杆，大家都在竞争中追求最大范围的满足行业需求。在这样的背景前提下，大部分项目都没有明确和长久稳定的需求，Scrum 管理模式很好的满足了这个行业的项目管理现状。&但是，作为行业客户，在大部分的商务场景下客户都会希望通过固定成本合同来实现自己的利益最大化，问题是现在合同双方都很难在项目开始时明确约定需求和最终实现方式。所以，在客户不能接受 Scrum 时，通常会选择外瀑布内敏捷的项目管理模式，满足双方的利益。2、举例：&如果把拍婚纱照作为一个项目，摄影师和新人作为项目主要成员，项目基本流程满足：选婚纱照的套餐（固定成本，确定基本需求）拍摄（项目启动）挑照片（提交测试，开始验收）根据底片修图（修复）拿到照片（项目结束）&>>>>以上就是顺序执行，瀑布式的结果。&然而，拍摄的过程中新人通常都会要求：&较短短时间内提出新增造型、内景换外景的要求（切换pose的任务）&配合摄影师完成拍摄环节的工作（通过迭代，完成项目）&>>>>以上就是内部快速迭代，敏捷式的结果。&很显然，新人在拍婚纱照之前并不知道自己最终拿到的照片穿的会是哪套衣服，摆的会是哪个pose；但是，很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，这套流程同时满足了内部和外部需求。&只是，为了项目顺利结束，可能在内部和外部需求时，并没有要求完全以相同的速度前进，就像你不能以你配合完成摄影的速度去要求摄影楼马上提供婚纱照。四、第三方业务风险控制服务企业产品服务流程其实，作为第三方风控服务的企业，项目服务流程基本上和拍婚纱照一样：&五、传统 VS 敏捷 ？ 适者生存敏捷项目管理只是一个灵活的实践框架，提供的是一套清晰游戏规则，根据不同的环境可以提供一系列不同的途径。&传统项目管理却是一套中央集权制管理法，要求按计划行事，任何环节发生变更都必须获准后才能进行改变。&我们知道的是，第三方业务风险控制服务行业目前还没有发展出固定的行业标杆，没有一套可称为标准的、行之有效的流程打通各个环节。更重要的问题——合同双方都很难在项目开始时明确约定需求和最终实现方式。&在市场经济不断发展、时刻变化的现代互联网环境下，适应变化、拥抱变化的第三方业务风控服务企业的项目管理，才是友好的、可行的管理模式。&六、阅读参考某博主po的一个很有趣的“敏捷和瀑布”对比例子，给大家作为阅读参考：&1、敏捷开发客人到餐馆来点菜（新项目）&不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）&根据图文菜单，客人点了是个菜（根据原型和设计稿，基本确定了需求）&后厨开始准备（项目启动）&配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）&上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）&到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更）客人吃完，很满意（基本满足了全部的要求）2、瀑布模型开发客人到餐馆来点菜（新项目）&不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）&根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）后厨开始准备（项目启动）&根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）再过了二十分钟，十个菜都一起上来了（项目最终一次交付）&客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）&这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）&于是，后厨只给客户加了盐，加了辣客人吃完，不是很满意，下次不来了（没有满足需求）作者：阿木，岂安科技项目经理 。基础开发出身，主要负责岂安科技安全Saas产品和项目的日常进度管理。
馆藏&15482
TA的最新馆藏与敏捷软件开发一样，敏捷项目是在叫做迭代的小型部门中完成的。每个迭代都由项目团队审查和评判;从迭代的评判中获得的信息用于决定项目的下一个步骤。那么敏捷项目管理误区有哪些呢?一起来看看!一：敏捷对人的要求很高很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么?软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。从另一个角度来看：过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显著的效果，甚至有些时候还有反效果;而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显著。敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。二：敏捷没有文档，也不做设计这个从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是“必要且意义重大”?这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写;再如，架构设计文档要不要写?复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人(比如lead)来决定。至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善(重构)，使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。三：敏捷好，其他方法不好有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题文章出自，转载请保留此链接！。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。四：敏捷就是XP，就是ScrumXP和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法任何企图统一所有项目过程的方法都是不正确的。同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不的。银弹从来就没有过，在有限的将来也不会存在。最近更新：免责声明：本文仅代表作者个人观点,与本网无关。看完本文，记得打分哦：很好下载Doc格式文档马上分享给朋友：?知道苹果代表什么吗实用文章，深受网友追捧比较有用，值得网友借鉴没有价值，写作仍需努力相关项目管理师：
48小时热门