Scrum Agile敏捷项目管理归纳总结（小编整理）

第一篇：Scrum Agile敏捷项目管理归纳总结

D:iknowdocsharedatacur_work80505777.docx 《Scrum/Agile敏捷项目管理》归纳总结

前言

此文档是由我阅读《Scrum敏捷项目管理》Ken Schwaber著，清华大学出版社。归纳总结Agile项目管理的核心内容。

核心精髓

 20/80法则

20%交付功能代表80%的最终商业价值。

 敏捷团队组成

Scrum Master，产品负责人，团队。

 Sprint计划会议

此会议限时8个小时。分两部分，各4小时。第一部分挑选Backlog，第二部分准备Sprint Backlog 与会者包括ScrumMaster、产品负责人和团队。可邀请其他人员补充业务或技术领域的信息和建议，在信息提供完毕后离开。鸡类人员不可担任观察者。

产品负责人应在会议前准备好产品Backlog.如果缺少产品负责人或产品Backlog的情况下，ScrumMaster需要代理些职。第一部分会议

会议第一部分（前4个小时）团队的目标是挑选将承诺转化为潜在可交付产品功能增量的产品Backlog条目。团队将在Sprint结束时的评审会议上，向产品负责人和利益相关者展示该功能。团队可提建议，但由产品负责人制定Sprint产品Backlog。

团队负责从产品负责人制定的Backlog中挑选出期望在当前Sprint内完成工作。第一部分会议结束后立即召开第二部分Sprint计划会。限时4小时。第二部分会议

产品负责人必须出席，回答团队对产品Backlog可能的疑问。

团队必须独立决定如何将选定的产品Backlog转化为潜在可交付的产品功能增量，该过程中团队不接受外界指导。

第二部会议将制定出”Sprint Backlog”。是一张包括任务、任务预估及开发功能的工作分配清单。任务清单不一定完整，但必须反映团队全体成员的共同承诺，以顺利完成Sprint第一部分，在过程中团队可以为Sprint Backlog增加其他任务。

/ 2

D:iknowdocsharedatacur_work80505777.docx  每日Scrum简会

不论团队人数多少，每日Scrum简会限时15分钟。

在每个工作日的同一时间，同一地点召开每日Scrum简会。它是全天工作中的第一件事。

团队全体成员必须出席。如某位成员无法出席，则应参加电话会议或请其他成员代为报告工作情况。团队成员必须准时。不论出席情况如何，Scrum必须在指定时间开始会议。SrcumMaster请他（她）左边第一位成员开始汇报情况。团队每位成员仅回答3个问题。

1，自上次Scrum简会后的1天里你为该项目做了什么？

2，从现在到下次Scrum简会后的1天里你准备为项目做什么？

3，什么妨碍你尽可能高效的工作。

会议围绕上述3个问题展开，成员不得离题讲其它事宜、设计、讨论问题或闲谈。ScrumMaster确保成员轮流且干脆利落地汇报工作。

每日Scrum简会不得有人同时发言。发言人汇报工作情况，其它与会者是听众，不可在一旁私下谈话。与某位成员汇报的情况涉及其他成员兴趣或需要他们协助时，可在每日Scrum简会后立即召集有关人员开会。

鸡类人员不得讲话、评论等。并站在团队外围，以免干扰会议。若鸡类人员出席人员过多，ScrumMaster有权限制出席人数。确保会议有序、集中。鸡类人员不得在会后请团队成员深入解或向团队提供建议和指示。

不能遵守上述规定的猪类或鸡类人员将被禁止鸡类参加会议或把猪类开除出团队。

/ 2

第二篇：关于华为敏捷项目管理

华为公司项目管理

关于华为敏捷项目管理

IPD – 集成产品开发，华为花重金从IBM购买的一套产品集成开发流程，业界有一本书，PACE讲的就是这一套IPD流程，而IPD并不去讲你的开发要怎么做，IPD做的就是“投资决策、市场驱动”，更多的是决定做不做这个事情，做这个事情对于投资人员是不是受控的，所以在IPD里面会有DCP点（决策评审点），每个点上都会去考虑该不该做、值不值得去做，在引入这个东西以前，华为实际上是技术驱动的，并不是市场驱动的，就是说以前华为听说有个新技术，然后就开始做，做了很多这样的东西，但是后来都卖不出去，所以后来就引入了IPD，以市场驱动。在引入IPD后，是解决了做什么的问题，但是怎么做，还是按照自己的想法去做，后来就引入了CMM，引入CMM后对华为确实起了非常大的作用，其产品开发的质量确实是比起前提高了，所以在前几年，通过IPD+CMM使得华为走向了一个非常成熟的过程。在这个基础之上，关于质量管理、项目管理华为提出一些自己的体系，比如从项目的开始到项目的结束，有项目review、度量分析、根因分析、缺陷预防等一系列活动，在项目管理方面有风险管理、问题跟踪管理等活动，同时还会有质量审计以及相关的推动等事情，通过这些项目管理和质量保证使得IPD和CMM很正常的运作下去，但是现在行业已经发生了一些变化，比如需求变化快等方面华为也碰到了一些问题，以前产品质量是可控的，大多数产品的发布周期也是稳定的，比如对客户承诺什么时间提交产品基本上是有保证的，另外项目在管理层的进展也是非常清晰化的，你在向某某领导汇报的时候只用告诉他比方项目到了SRS阶段了，基本上这个项目的老大就知道这个项目还有多少事情需要去做，比如告诉他到单元测试阶段了，他就知道快搞定了，这样确实使得这个进展能够口头化。其实，流程存在的价值，就是能够给我们的管理层提供进展的可视化，所以从目前来看，对于客户、员工、管理层这三个利益相关人来讲确实达到了这样一个目的。

但是现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多么细，到交付产品给客户的事情，总是有这样那样的问题，这个时候就不得不去修改我们的软件，这是华为面临的一个挑战，如何解决这个问题？

软件开发中有三个要素：人、过程、技术和工具。对于一个软件项目成功来说，这三个要素都不可省，而在以前大家强调IPD和CMM，更多的是强调大家规范的把它运作起来，对于人、技术和工具基本上不提了，忽略了，所以后来就反馈出一个问题，就是很多项目，看起来那个过程做的那个漂亮，那个报告写得那个完美，但是交出去的产品那个烂，其实这三个因素是缺一不可的，你必须得均匀的发展，还有一个是人的方面，因为人是具备创造能力的，所以从华为的教训给我启发，过度的关注过程而忽视人、忽视技术和工具，我们就得要思考和反省了。

针对这些问题，华为也就提出了敏捷。华为在99年之前基本上都是土生土长游击队的做法，到了2001年的时候就引入了IPD和CMM，到2006年的时候，就发现了瀑布模型的问题，如交付周期特别长，就是每做一个客户的需求，然后一分析，这样一走半年就过去了，所以就引入了RUP，最初的想法就是加速我们项目的交付周期，能够快速的给客户响应，但是敏捷实际上已经进入了一个低谷期，所以当时就引入了迭代，实施了一年之后也发现，RUP里面的东西实际上也是挺多的，所以后来就接触了XP、SCRUM这些方法，这样就从07年开始向敏捷这个方向在走。

有一个图在业界流传比较广泛，也叫洋葱图，共分三圈，也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。XP为什么叫极限编程？如果你觉得这个软件开发的实践是一个好的实践，那么你就把它发挥到极致。比如，结对编程，一个在编，一个人在看，实际上看的人不会白看，其实起到了一个review的作用，既然review这个作用有效，那么为什么不把这个作用发挥到极致，所以就采用了结对编程将review这个作用发挥到极致。在敏捷中有一个8个字的原则：沟通、反馈、交流、勇气。它认为项目团队中的成员这个沟通是比较重要的，既然你非常重要，那么我也要把你发挥到极致，所以两个人一起在干活的时候就会不停的有交流与沟通，所以，结对编程是一个典型的把review、沟通交流发挥到极致的实践。另外，TDD也可以认为是那刚好够用的事情发挥到极致。我们以前传统的软件开发的做法是，先做好这个软件，然后去测，看看是不是实现了这样一个功能，但是我们总会发现这里面有很多代码其实是从来就没有用过的，只是在下代码的时候顺手就把它写了，在分析那些产品的时候发现有的产品这样的没用到的代码高达50%，而TDD的思想是，我既然要实现什么功能，然后我就先写对应的用例来验证它，然后在开发的时候就开始写代码，使得这个用例刚好通过，这样就使得我们写出来的代码是刚好满足这个系统的功能的代码，这样，前面出现的50%就可以不用做了，这就是把刚好够用发挥到极致。其他的就不一一讲了。XP在2001年到2003年之间非常的红火，过了之后又相对的沉寂了一点，现在又冒出来一个新的敏捷的方法论，就是SCRUM。XP是过分的强调将软件开发里面的实践发挥到极致，而这些实践都是同编程实践相关，但是在管理方面就比较弱，所以，在用了几年之后，大家发挥XP不是起到那么大的作用，所以就开始沉寂下来。这个时候就出现一个流派，就是SCRUM。SCRUM其实就是一个非常非常轻量的项目管理框架，基本上没有什么编码实践方面的东西，你说看到的都是管理上的活动，这个管理上的活动很多人就会有一种似曾相识的感觉，记得前不久，同华为的一个项目团队在聊，就谈到这个项目的backlog，一讲，项目团队的人就说其实他就是那样子做的，他以前也没与听说过什么SCRUM，就是把这些需求一条一条的列出来，镍镉优先级，估个工作量，一看，就是这个东西。SCRUM的核心其实比较简单，2分钟就能讲出来，就是3个3。

一、3个角色。Product Owner，负责决定产品要做什么，做成什么样子；保证项目能够遵循SCRUM的方式运作下来；项目团队成员，包含开发、测试、质量等等所有的人。

二、3种会议。迭代的计划会议、中间的站立式会议、迭代的评估会议，属于三个管理的活动。

三、3个交付件。待开发的任务列表、待修复的缺陷任务列表、项目的进度图。

SCRUM就是通过这3个3将项目非常简洁的管理起来，有一个思考就是关于PMP里面讲到的9大领域多少活动不一定对这种敏捷项目适用。那么大家可能提出一个疑问，就是项目的进度是不是就不可视了。其实，敏捷项目的进度可视很简单，就是通过一个白板（进度墙、任务看板），将每个人的进度情况这么一贴，这就是最简单最直接的管理方式，一看，所有人都知道，就算你去开发一些什么复杂的一些IT支撑系统，可能都起不到这个白板的作用。在华为关于敏捷的一些项目管理工具，用Scrumworks、Bingo这些管理工具也能够把项目的进度管理起来，但是你要做的就是必须得把电脑打开，要把浏览器打开，这样才能看到你的进度是什么样子的，而在办公区直接树一个白板就能够很简单、很方便的知道我的这个进度情况。所以，在华为，对于敏捷项目，管理的框架上是采用的SCRUM，指导如何编码实现上就采用了一些XP的实践，当然XP的实践不会全部去选，会根据项目的实际情况

去选一些实践，如果你把所有实践都选的话，实际上的效果是非常差的。那么如何来选择就得根据项目的实际情况去评价。华为在实践的过程中也引入了精益、消除浪费的思想。比如，在平时的工作中存在停工等活的浪费。什么是停工等活的浪费呢？比如我们开发在做开发的时候，我们的测试就会轻松一点，那么测试在做测试的时候我们的开发就会轻松一点，大家觉得这样也挺好的，但是你从整个组织角度去分析，实际上是停工等活的，开发时测试在等着，测试时开发在等着，如果你从精益的角度考虑的话，为何不通过迭代的方式把开发和测试等待的时候整合在一起来工作，使得效益得到提升。有很多项目团队自己去做了，确实效果比较明显。其实在2006年实践RUP的时候就感觉到这样的好处了是非常明显的。引入敏捷之后，自然而然的就会想到同公司已有流程之间的关系，原来是IPD+CMM，所以就有同事问到是不是我这个就不用了。分析可以知道，IPD是决定做不做，决定之后如何去做就可以采用敏捷开发，所以对于敏捷产品的流程就是IPD+敏捷的方式，所以有很多以前采用瀑布型的团队逐步的被敏捷代替了，还有些团队正在代替中，还有些团队就觉得原来那套玩得很流畅就继续采用原来的方式。所以目前在华为，项目团队是可以自己来选择采用哪种方式进行，现在可以发现，那些愿意选择敏捷方式走的往往就是原来那些顽固不化的烂项目，因为以前在推流程的时候，那帮人整天在那里叫，有问题，我不干，我不愿意做，实际上，后来做深入分析发现，他的那种模式并不适合按照瀑布型去做，但现在成了积极分子，所以每个项目的模式是不一样的。

在做敏捷的时候也存在一些容易做的事情和不容易做的事情。比如说SCRUM的项目管理是比较容易去实践的，就是3个3，对于那些想敏捷的，我建议可以先做这个，还有也会做一些结对编程、持续集成的实践。比较难的，有这么几点。华为从99年开始都是按照开发、测试等团队去运作的，团队与团队之间就会形成部门的墙（华为有一个外籍员工给起了一个名字叫Chinese Wall），对每个部门来说，希望把这个墙树高一点，这样能获取更多的资源非常顺利的开展工作，所以墙就会越树越高，很多部门甚至还有checklist，你只要给我什么东西，我就按照checklist打勾，打勾不通过的就要干啥干啥，这样通过约束管理层，罚款的制度就来了，而这个问题就很难搞，涉及到很多很多的人员，涉及到部门角色定位的问题，这是华为觉得最难的一点。第二难的问题就是TDD，在很多项目都试过，但是试过之后，很多项目都无疾而终，或者诉苦说这个我实在搞不下去，分析后发现，是涉及人做事情方法的改变，这个挺难的，以前写代码都是边想编写，就能写出来，现在你就得先想好、验证好等等，然后再想办法填进去，就发现这个很难，这是一个开发习惯的改变，这也是很难的一件事情。第三个，就是Customer Tester，就是要客户参与验证，可能对于互联网企业可以部署一个系统，用户参与测试就可以做起来了，但是对于华为而言，客户是电信企业，而电信是买方，买了之后再供他们的客户去用，这个里面客户就存在好几层，所以要客户真的参与进来还是比较难的。第四点，也是很难的，我们有一个团队，要到各个团队去宣传为什么做敏捷，这涉及到观念的转变，所以这也是非常难的事情。（一夜的引入，长时间的改变。）比如你说你这个团队敏捷了，明天就开始站立式会议，但是你最后会发现，要真正敏捷实际上是一个漫长的过程。

在华为实施敏捷的过程中，也有一些经验性的东西。第一个是QA从警察的角色转变到一个教练的角色。在以前，团队实施CMM的时候，QA更多的是一个警察的角色，他整天拿着一个checklist、报告什么的到处去团队里面看，你是否ok，不ok就要怎么怎么样，整天就干这个活，但是引入敏捷之后，QA就觉得有点失落，都敏捷了，我都不知道该怎么下手了，然后，在华为，就把QA转变了一下，将QA更多的充当教练的角色，充当的角色，他去指导项目团队该如何去开这个站立式会议，该怎么去做迭代的计划等等指导性的工作，这样QA也觉得挺好，这样他能参与到在不同的团队中去，这样他见得也多，所以在敏捷的实践里面是需要这么一些人来干这么一些事情。第二个就是要营造一个一体化的团队，也就是将所有有墙的部门通通打掉，直接按照项目型运作，把大家拉到一起，不要考虑你原来是什么部门，先把项目做出来再说，这就是在XP的外圈中的Whole Team实践，因为大家就真正是一条船上的。在很对项目中，总是存在这样的一些人，项目成功不成功对他们是无关紧要的，但是有些人项目不成功对他们是非常重要的，而真正的敏捷项目就要这些人来挂帅，并且这些人是站在一条战线上的，所以就叫拉到一体化的团队里面来，大家都对交付负责。第三个就是办公环境最好也能够随着改变。以前大家都是那种小格间的方式，但是这种方式是非常不利于做交流和做项目的。第四个就是现身说法。前面讲到有很多这样的人会到团队中去说敏捷怎么怎么好，但是如果你让一些对项目成功不成功都不相关的人去讲是没用的，因为大家一听，首先就会质疑50%，所以华为当初经常搞的活动就是让项目经理他们在讲，将他们当时是怎么开展敏捷的，这样别人一听才能理解到原来你是这么这么做的。

第三篇：浅谈敏捷项目管理和PMP

浅谈敏捷项目管理和PMP

敏捷项目管理方法一般适用于中小型研发项目，追求项目管理态度，方式上的“敏捷”，推崇“以构架为中心、用例驱动、迭代开发”，从而达到快速交付的目的。PMBOK的理念是项目应该具备完备的可持续改进的项目计划，并时时强调项目管理计划的更新持续于项目整个生命期。项目管理者联盟

敏捷项目管理声称要摆脱繁冗的流程制度文档，但是对于关键的项目文档，比如需求规格说明书等，也是要求必须具备的。所以，敏捷项目管理在项目流程制度上的管理可以看作是对一套完善的项目管理流程制度的裁剪，只不过这个裁剪的尺度较大，从而也对敏捷项目团队成员的适应性，自主性提出了较高的要求。项目管理者联盟

具体的敏捷方法(以SCRUM为例)在每个迭代周期中都存在立会制度，燃尽图、看板监控，计划发布等，这些和PMBOK中对项目生命期的五个过程组启动，规划，执行，监控和收尾的定义没有冲突矛盾。实际上，敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版，区别在于，敏捷项目管理的迭代周期时间很短，在其执行过程中，裁剪了许多规范正式的项目管理流程制度。项目管理者联盟

敏捷项目管理方法在IT研发领域取得了一定的成效，但是这种项目管理方法对项目团队的整体素质提出了较高的要求。同时，对项目管理者的团队建设水平也提出了较高的要求。敏捷项目管理追求的“敏捷”，虽然貌似在项目管理流程制度等项目管理建设金字塔的底层“硬件”部分要求不高，但是对项目管理软技巧这些例如团队建设，沟通协调，领导力，激励等项目管理建设金字塔的高层“软件”部分，提出了更高的要求。项目管理者联盟

个人认为，一个项目管理者如果具备卓越的项目管理能力，那么他首先应该精通项目管理建设金字塔的底层建设，只有系统掌握了项目管理体系理论，结合工作经验，项目管理者才能逐渐凝练出自己对于软技巧的总结，从而进行更符合实际情况的应用，才能做到有的放矢。没有系统知识体系的积累奠基，所谓的软技巧就如无本之木，无源之水。因此，作为敏捷项目的项目管理者，学习掌握专业的项目管理知识体系也是十分必要的。

第四篇：(讲座1)智慧的敏捷项目团队管理

报告题目：智慧的敏捷项目团队管理 报告人：DJ Ning

IBM Rational 中国区技术总监

讲座时间：2011年1月22日晚上（周六）5：30-8:45 讲座地点：交大徐汇校区工程馆212教室

一、大会主要内容

1月22日大会上，DJ Ning主要讲述了什么是敏捷方法、敏捷方法的提出、敏捷建模、敏捷开发的生命周期等内容。敏捷方法（XP、SCRUM、Feature－Driven Development、Crystal、DSDM、Agile Unified Process、Adaptive）是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付价值，努力在软件开发过程当中减少变化带来的成本。个人和交互代替原有的流程和工具，可运行的软件代替原有的复杂文档，与客户的协作代替基于合同按部就班的操作，快速响应变更代替原有的遵循计划。例如，XP使用快速迭代计划和开发循环尽早地产生最有价值的特性。另外，XP中的持续的、系统化的测试确保高质量，尽早发现缺陷和相应的解决方案。

二、听后感

现在，在IT预算被大幅度地削减的情况下，我们的IT管理人员的压力仍然在不断增大。同时，业务环境正以非常高的速度持续改变，这使IT艰苦奋斗，以便能够跟上这种变化速度。这些变化导致了以“快速发布和灵活而又高质量的维护为承诺”的敏捷软件开发方法论产生了很大的兴趣。

软件的项目管理目前面临诸多挑战，软件项目开发的进度难于预测，需求在不断变化，而且速度快，变化的范围同时也难于控制，团队协作不够，配置和变更管理不当等都造成我们曾经有些项目无法完成。

我认为，加强管理才是敏捷方法被成功采纳并应用的关键，然而传统项目管理方法学和工具却与这些新的敏捷方法缺少关联。而这种低关联性就是深层次问题的症状。这些深层次问题表现在：对于处理变化、控制、命令、组织、人员以及解决方案等方面的基本假设方面的不同。

结合日常的工作，采用敏捷开发可以更早地持续地交付有价值的软件，可以满足我们的需求，即使到了开发的后期，也能够适应变更；频繁交付可工作的软件，而可工作的软件是度量进度的主要标准；我们的业务人员和开发人员必须每天协同工作；围绕着激励起来的个人来构建项目；面对面的交谈是最有效和效率最高的沟通方法；提倡可持续的开发速度；持续的优化技术和设计；简单是工作效率最大化的艺术；最好的架构、需求和设计，出自自组织团队；定期总结回顾，思考我们的团队如何更加高效，并作出相应调整。

一个好的团队是项目是否成功实施的基础。高效的团队所具备的基本要素应该有：承诺使用统一方法，互相依赖、互相负责；少数成员要注重实效，容易分享和沟通，打造共同的团队价值观；技能互补，解决问题和决策，并且注重人际关系技巧；承诺为共同的目标而奋斗。

在敏捷项目中，我们的客户需求在整个生命周期中是不断变化的；我们单位在过去传统项目中，客户需求在一开始是被完整定义的和静态的，明确了高层次的需求，并进行优先级划分，往往时间是影响紧急业务需求交付的关键约束，资源又是固定的，并被有效管理以在指定成本内交付。项目交付周期从传统的瀑布模型转变为迭代式的敏捷项目生命周期，即将长的、复杂的项目周期变为短的、简单的迭代周期；明确项目的完成时间往往又不是一个时间点，而是一种可能性的分布。这样使用里程碑交付件作为一种有效的评测软件；提出合适的项目计划；尽早反馈和经常反馈；迭代地、增量地交付可工作的交付件。

第五篇：项目管理总结

1.项目是为提供某项独特的产品，服务或成果所做的临时性努力。

2.项目的特点：临时性、独特性、渐进明细

3.项目管理的核心：任务分解；传统管理的核心：持续改进

4.项目管理的十大知识体系：质量、范围、时间、成本、进度、沟通、风险、人力资源、采购、项目干系人

传统管理：计划、组织、领导、控制

5.项目管理四要素：范围、成本、进度、质量

6.项目存在优先级，pmo项目管理办公室负责安排优先级

7.项目管理的核心思想是平衡

8.项目五大过程组：项目启动，计划过程，监控过程、执行过程、收尾过程

不同项目阶段不同，但五大过程组相同，每个阶段都有五大过程组，阶段中不可能有监控，监控贯穿整个项目

9.项目管理共有44个阶段

10.项目经理要求平衡质量（最重要），范围、时间和成本，确定清晰能实现的目标，使技术规范、计划和方法适用于不同的需求与期望

11.产品的生命阶段是产品从产生到消亡的全生命阶段，包括概念、计划、开发、验证、发布、运维标准六阶段（构思+研制+使用维护）

12.项目的生命周期是从产生到消亡的全生命过程，由多个项目阶段的组合形成，包括CDIT四个阶段（项目立、项目启动、项目发展成熟、项目完成）

13.状况分析、原因分析、决策分析、风险分析

14.极其复杂的的研究阶段称为系统，即相互作用和相互依赖的若干个组成部分结合成的具有特定功能的游记整体，从属更大的系统（子系统）（系统—子系统—模块—单元）

15.系统思维是把观察、处理的对象看做一个系统，不仅要看到系统的组成要素，更要看到这些要素间的相互关系，从整体的角度把人、物、能量、信息加以处理协调。

16.所有复杂的系统背后是简单的原理，系统越复杂，原理越简单。若有冲突则是存在错误的假设，是人为错误

17.项目范围强调过程，产品范围强调结果

18.WBS（工作任务分解）是面向可交付成果的层次化分解，有机组织定义整个项目，将项目分为较小的，易管理的工作，每分解一层表示更详细的定义。

19.WBS底层必须是有明确责任人的工作包，先基于阶段，再基于成果，使用组织管理，满足80小时原则，大型项目可先分为子项目，再进行阶段和产出分解

20.总和最大的为关键路径，从开始到结束差为0，可能存在多条，对关键路径进行工期压缩要考虑次关键路径的产生，未考虑资源约束。

21.关键路径是有充分资源的情况下，关键链则是有关键资源的情况下

22.关键链法（1）项目缓冲 非关键路径至少挤掉50%，在最后留缓冲。

（2）接驳缓冲 放置在关键链末端的称为项目缓冲，其他的缓冲为接驳缓冲放置在非关键链和关键链的结合点，防止关键链受非关键链延误影响。

（3）关键路径 经过需要关键资源的所有任务（关键链）的最长路径

23关键链不管理总浮动时间，管理剩余的缓冲持续时间和剩余任务链持续时间之间的匹配关系，可以按可能的最晚开始时间和最晚的完成时间来安排活动

24.关键链法解决三大问题

（1）项目中所有环节的延迟会积累，提前不一定（延迟称为墨菲袭击）

（2）每个子环节都有巨大的缓冲，且会被浪费

（3）项目管理一定会延迟是因为不良多功？？

25.toc约束理论，业绩都受制于它的制约因素、局部改善不意味着整体改善、系统能力受瓶颈制约、进度计划因考虑资源瓶颈、因考虑改善瓶颈效率

26.我不知道

未知区 隐藏区 我知道 盲区 你知道 杰亨利窗框 开放区

你不知道

27.表扬针对行为、动机、期待，批评针对行为、后果、期待，要对未来提问

28.风险管理分为风险预测、风险预案（确定责任人）、补救性方案（确定启动机制）

29.项目经理在采购中的作用：必须参与到合同的创立过程中，确立控制地位，参与谈判，识别各种风险，通过合同来减少项目的风险，帮助合同适合项目，使采购符合项目进度，维护与卖房的关系。

30.项目经理的提升之路是使其能力与其面临的挑战相匹配。