项目管理修炼之道-读书流水

　　花了两天时间把《项目管理修炼之道(精简版)》读了两遍，不愧是获得软件业奥斯卡-Jolt奖的大作，加上郑柯先生翻译的相当传神，文笔优美流畅，在感叹作者功力的同时，

读这本书本身也成了享受。我把书中关键的概念都摘抄了一下，在这里再贴一遍，算是个简单的回顾，今天下午京东买的完整版也到了，准备明天开始花上一周时间好好学习一

遍，到时候写个系列的读书笔记出来。

1   成功项目必备要素：项目章程、工程计划、项目计划、明确的角色和职责、明确的开发流程、恰到好处的度量标准、发布条件、参加Beta测试的客户。。。

2   每个项目都是独一无二的，你必须评估项目的情境（项目、团队、所在公司），然后再实事求是地判断，看看哪些技巧和实践是可行的。

3  你必须运用各种方法和技巧来减少项目的风险，这其中就包括在每个项目中使用敏捷方法。

4  管理风险是项目管理的核心内容，识别风险是管理风险的前提，使用适当的方法可以帮助我们识别风险。

5  没有针对所有项目都正确的绝对真理，也灭有针对所有项目普适的最佳实践。

6  项目是一个非线性系统。早先所作的决策会影响项目如何结束，甚至可能会影响如何启动下一个项目。

7  项目：一个独特的任务或者系统化的流程，其目的是创建新的产品或服务，产品和服务的交付完成标志着项目的结束。项目都有风险，并且受限于有限的资源。项目经理负责管理风险。

8  产品：项目产生的一系列可交付物称为产品，产品是每个项目的核心。

9  项目经理：负责向团队清晰说明完成的涵义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。

10  管理项目的关键驱动因素、约束和浮动因素。

　　10.1 期望列表：从客户的角度：功能集合、发布时间、缺陷等级

　　10.2 约束列表：环境是什么样子、能否灵活安排团队的位置、必须遵守什么流程、手下有哪些人、他们能做什么、预算多少，这些约束决定了项目的规格（持续时间和质量）。

　　10.3 项目成功的必要因素：选择其一，如发布时间，这就是识别出来的关键驱动因素。

　　10.4 列表中剩下的：功能集合、低缺陷率、发布成本等，客户和出资人会在这些方面上对项目形成限制，从中选择两到三项，称之为项目约束。

　　10.5 剩下没有选择的条目，他们有很大的调整余地，称之为浮动因素。一个项目至少要有三个浮动因素。

　　10.6 这时，项目的关键驱动因素、约束、浮动因素就都识别出来了。三个约束的项目，团队要付出超乎寻常的努力，才能保证项目成功。

　　10.7 作者经验：如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它成功的几率还是不小的。浮动因素越多，项目就越容易管理。

　　10.8 理想情况：关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。

　　10.9 受到过多限制的项目难以逃避失败的厄运。过多的关键驱动因素意味着没有人知道成功的条件时什么。过多的约束，意味着组织中没有人原因去判断孰轻孰重。

11 项目中的驱动因素：发布日期、功能集合、发布成本、人员分配、时间分配、将要采取的技术和实践、工作环境等等。

12 有了项目的关键驱动因素，我们就可以定义出项目的成功条件，并且选择适合项目的生命周期了。团队可以指定出发布条件，并根据驱动因素合理地安排各自的工作。

13 获取关键驱动的问题：这个项目要怎么样才算成功？？？？？

14 编写项目章程，共享现有决策：

　　14.1 项目章程会明确记录项目的需求和约束，可以帮助项目经理思考如何进行项目规划。整个团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。

　　14.2 章程模板：

　　　　14.2.1 远景：用描述远景的句子向大家说明项目的价值。

　　　　14.2.2 需求：某些情况下，项目的唯一需求就是要在某个特定日期达到前发布某些功能，而不是单纯的功能列表。

　　　　14.2.3 目标：目标不同于需求，它不一定要必须交付，如针对瀑布式开发，通过重新设计解决技术债务、添加更多的自动化测试、设计冒烟测试等等等、这些都是可能的项目目标。也可以是客户中途提出的新功能点。

　　　　14.2.4 成功标准：围绕客户基于完成的产品能做什么给出的定义，成功的标准只关注能力，不涉及缺陷。

　　　　14.2.5 ROI估算：投资回报率

15 有了章程后，卡是做些有目的的规划和日程安排工作，二者是不同的：

　　15.1 规划是指指定带有发布条件的项目计划，它把团队成员的注意力凝聚到预期的项目产出上来。规划不必完美，只要让项目启动起来就可以了。

　　15.2 日程安排则时对工作项目的有序描述。

　　15.3 时间盒是指特定的时间长度，个人或团队用它来完成某项特定的任务。个人或团队在这段时间内完成的工作量，就是接下来工作的基础。

　　15.4 模板：

　　　　15.4.1 产品意图：基于项目（或工程）的规模和持续时间，每个项目团队（或子项目团队）都有其自己的意图。这个意图应与工程章节的愿景在大方向上保持一致，但又不完全相同。

　　　　15.4.2 历史记录：如果是在管理后续版本，需要复查之前的历史发布记录，包括记录中的发布频率、发布后发现的缺陷数、客户报告的问题，以及会影响到项目经理对质量的定义、对项目管理方式的任何内容。

　　　　15.4.3 发布条件：详细列举项目产品的关键可交付物，要将功能、性能、质量要求都涵盖在内。

　　　　15.4.4 目标：产品目标、项目目标、 团队目标、 组织目标

　　　　15.4.5 项目组织：要明确说明团队在项目中的职责分配，指明项目经理如何使用生命周期组织项目工作，要采纳哪些关键实践，以及是否有决策人可以影响当前项目。

　　　　

　　　　15.4.6 日程总览：其中标有主要的里程碑，还要说明人们从这些里程碑处可以得到什么。可以让领导知道项目的实际进展。

　  　　 15.4.7 人员配备

　　　　15.4.8 建议日程

　　　　15.4.9 风险列表

16 人生不如意十之八九，项目也是如此，发布条件不可能总是能够达成的。发生类似的情况时，要坦诚面对。

17 给我一块石头：识别和避免日程安排游戏：当投资人总是希望项目更快交付，但是不告诉你何时需要或者为什么的时候，就开始“给我一块石头”游戏。

18  拒绝女王：管理成可能认为拒绝现存为题或潜在问题可以鼓励团队，其实这反而总对团队形成障碍。

19  把灰扫到地毯下面：不要忽略为了项目成功中途所作的一切调整和修改。如关键的功能优先级调整。

20  幸福日期：有善于口舌的管理层，他们或威逼或利诱，或用权力来“说服”项目经理以及团队，让他们相信可以满足管理层对“幸福日期”的要求。这种所谓的“说服力”加上逃避困难话题的文化，导致了幸福日期的日程安排游戏。

21  分散注意力：如果项目经理所在的组织经常“分散注意力”，那就准备采用一周一次的迭代吧。将需求打散层足够下的部分，他们可以在一周内取得工作进展。

22  屁股着火：当管理层害怕或者无法一次将经理集中在一件事情上之时，就会发生。

　　22.1 按小时间盒迭代，在每个迭代边界都开始新的工作。迭代周期要足够短。

　　22.2 如果无法管理迭代，就按功能逐个实现，使用按阶段交付。

　　22.3  将采取这种策略的成本告诉管理层，让他们选择是要解决时间上的危机，还是要付出经过计算的额外成本。

　　22.4   策略确定后，帮助公司检查相应的具体措施。可以这样问：“根据该策略，我们会得到这样的结果。这真的是我们想要的吗？”

23  日程安排不是预研，仅是猜测而已。

24  掌控项目：掌控项目意味着要寻找风险和管理风险。通过组织项目来发现它的节奏，这是一种发现风险的方式。任何扰乱节奏的事情都是已经出现的风险，任何可能扰乱节奏的事情都是潜在风险，项目经理可以保证项目不会偏离正确的轨道。

25  下面这些是打断项目正常节奏的问题：

　　25.1 不知道先要完成哪些需求：指定带有优先级的待办事情列表。

　　25.2 允许项目的需求收集阶段持续过长时间。

　　25.3 允许GUI随时发生变化，而GUI相关人员在项目中不知该如何是好。

　　25.4 没有架构的整体描述，不知道各个部分如何构成。

　　25.5 无法及时向项目中加入必要的人员，使得他们很难取得成功。

26 敏捷式生命周期项目需要在每个迭代结束时举行回顾。

27 指定维护不断变化的需求日志：产品待办事项列表。如果可能，只要一听到需求就应该对他们排序。

28 如果项目中必须由明确的需求阶段，就用时间盒限制它。

29 用时间盒限制初始的需求相关活动，并持续收集更多的需求。使用不超过项目总体时间的10%来收集最重要的需求。

30 也可以使用时间盒来处理所有的需求相关的工作，此时项目团队会与需求相关人员一起收集、整理和细化需求。到时间盒结束时，团队实现了已经完成的需求，而且只实现了已完成的需求。这种方式最适合于短期项目，而且必须是使用顺序式生命周期的项目。

31 是用迭代式开发时，出现了问题可以把迭代周期一分为二，便于发现导致延迟的问题。原因在于更短的迭代周期可以产生更频繁的反馈。迭代周期越短，要是项目可以因此达到特定的里程碑，那就很容易知道应该如何启动和结束一个迭代，这也有助于保持项目的节奏。

32 使用波浪式规划和日程安排。

33 保持合理的工作时间：每天在公司吃晚餐毫无道理，对任何人都是如此。项目经理在面临很多问题的时候，会很容易产生让团队一起加班的想法。可是，如果人们加班。

34 如果要耗费很长时间才能完成一个任务，项目就会丧失节奏。团队成员看不到任务结束的时候，他们就会变得懈怠。所以，要持续集成，让团队成员在每个短期迭代时都可以看到自己的工作成果，以此作为鼓励。

35  如果人们直到最后一刻，有时甚至超过了这个时刻，才开始某个任务的工作，这就发生了“学生综合症”。如果人们用周来估算任务，就很容易引发“学生综合症”，用天或者

　　35.1 小石子就不会。保证每个人每天都有所交付，可以有效避免。

36 作为项目经理应该保护迭代工作。顺序式生命周期中，整个项目就是一个迭代。如果使用时间盒，迭代就是时间盒持续的时间。在迭代式生命周期中，迭代持续时间可以发生变化，不过与要完成的工作有关。在增量式生命周期中，本质上时没有迭代的。开发某个功能的时间也许可以成为迭代。

37 如何影响别人：放弃命令和控制式管理所带来的幻想，学习影响别人

　　37.1 在项目中，发布时间、功能集合、缺陷水平，每个人都对这些由责任，项目经理有责任让团队解决问题，而不是强令他们如何解决。

　　37.2 发现其他人或团队的驱动力。有人喜欢做有意思的事情，有人希望得到公众的认可。很多人希望把工作做的出色，而且知道自己能为整个项目成功做出哪些贡献。

　　37.3 建议项目经理和负责的人（或团队）共同面对问题。这可以让项目经理能够友善、开发地接受他人的建议和想法。

　　37.4 倾听团队：团队会告诉项目经理他们要怎么样才能达到最高的工作效率。

38 如果项目经理不在项目初期就开始管理缺陷，那缺陷就会反过来控制你。项目的技术债务会不断增长，项目经理不到最后根本无从知晓。到最后，就会有太多缺陷需要修复，也就没有办法全部搞定了。

39 项目经理有下列选择：

　　39.1 如果条件允许，使用敏捷生命周期，开发人员和测试人员同时进行开发和测试。团队报告的总体缺陷数目就会减少，项目经理也能更快的了解到缺陷，并且马上着手处理。

　　39.2 否则，就使用增量式生命周期把，还哟啊确保开发人员随工作进展进行持续集成。让测试人员用不同的方式来测试开发人员已经完成的功能。

40 铭记在心：

　　40.1 作为项目经理，你要带头考虑使用或调整哪些管理实践。

　　40.2 评估项目的问题，然后根据这些问题来判断使用或调整哪些实践。

　　40.3 要寻找可以建立和维持项目节奏的实践。

41 要想掌握一个项目，关键在于经常进行测量，包括定性和定量两种方式，并且要将结果公之于众。项目经理将测量结果作为项目进度的一部分展示出来，团队成员就可以调整自己的工作，并取得更多成果。

42 测量驱动因素、约束和浮动因素，排列组合成6个维度，可以从至少4个维度进行测量。

43 测量的三大风险：

　　43.1 团队花费时间过多的时间进行测量，从而影响正常工作。 所有的测量都有项目经理完成，不要影响团队成员的工作时间。

　　43.2 人们不认真对待测量。 如果只测量了项目中的一种因素，导致成员会因此投机取巧。

　　43.3 测量人，而不是项目。如果测量的任何东西可以直接跟踪到某个人身上，这就是等于在对人而不是对项目或产品进行测量。这样会导致，团队成员不认真对待测量。

44 技术带头人的作用：带领其他团队成员修补缺陷、攻克技术障碍等非管理性工作。

45 打算仅用小团队启动项目，到了后期在加入新成员，这样做没有问题，只要你做好计划。

　　45.1 有的项目在也开始就有做原型的人，而且团队中有技术带头人

　　45.2 有的项目需要我去要求开发人员修补缺陷，因为没有技术带头人

　　45.3 有的项目使用短迭代，而我只有开发人员，没有测试人员。

　　45.4  以上项目中，我们都有计划，可以在项目需要其他人加入时，把让他们顺利整合到团队中

　　45.5 但是，如果启动给一个人力不足的项目，这就等于自寻烦恼。

　　45.6      

　　45.7 上图：如果把人员总数加起来，实际人员要多出三分之一，并且，团队只交付了之前期望的三分之二的功能，而且系统也不是特别稳定。

　　45.8 如果项目经理面临人员不足的状况，要小心不要陷入上面图中项目经理的状况中，必须要重新设计项目计划。可以这么做：

　　　　45.8.1 让前期仅有的开发人员按功能逐个实现，并使用为期一周的迭代。如果项目人员的到位状况无法达到当初规划时的要求，那就重新设计项目计划吧。这几乎等同于转向敏捷开发，以获得在安排人员时的最大灵活性。

46  团队进入代码开发阶段后，项目经理就可以马上开始测量故障反馈率（FFR：Fault FeedBack Ratio）。它是指被拒绝修复的缺陷数与修复缺陷总数之比。如果FFR高于10%，就说明开发人员遇到了问题，难以取得实际进展。

　　46.1 成功的敏捷项目中，开发每段代码都会用到测试驱动开发、结对编程和单元测试等实践，FFR会很低。而没有使用持续集成和持续代码复查的项目，其缺陷会不断累积，并欠下重大的技术债务。这时测量FFR就非常有用：

　　46.3 在第6周前后FFR升高了，而且在第13周之前一直高于10%。一旦团队连续两周保持高FFR，项目经理就应该针对所有修复开始PeerReview。发现问题：

　　　　46.3.1 先问问开发人员，看看他们是否在修复是遇到了问题。看看开发人员能否以此解决问题的一个方面。

　　　　46.3.2 问问测试人员，能否确定发现该问题的所有条件，以此了解测试人员是否足够了解系统从而进行全面的测试。

47 在不同阶段，修改单个缺陷的成本：

　　47.1      

　　47.2  要记住，重要的不是每个缺陷的成本，二是每个缺陷的成本乘以缺陷总数。要是不查看总成本，项目经理就不会知道该如何利用时间。

　　47.3  最好是采取积极的手段：一开始就查看关键项目文档、实施测试驱动开发或结对编程。

　　47.4      

　　47.5      

　　47.6 在上图中，只有三个作者最看重的三个指标：每周发现的缺陷数、每周关闭的缺陷数、每周仍未关闭的缺陷数。不要表明缺陷等级，避免团队或者高层玩“缺陷提升或者降级的游戏”。

　　47.7 在上图中统计尚未关闭的缺陷数目，是为了知道缺陷关闭率何时可以查过缺陷发现率，此时尚未关闭的缺陷数据就开始减少了，对应到尚未关闭缺陷数目曲线的拐点。

48  项目开始后，项目经理就可以马上开始绘制测试进度相关的图标了。五路你采用何种生命周期模型，我都推荐将测试与开发结合在一起：

　　48.1      

　　48.2 上图来自一个真实的项目，团队使用按阶段集成的方式，而没有使用持续集成。

　　48.3 通过的测试与运行的测试之间的面积便是修复缺陷的工作量。如果采用持续集成，这个工作量会少很多。

49 如果项目经理选择使用敏捷生命周期，迭代时间长度不超过4周，同时在一个迭代中，所有分配给项目的人员不会被重新分配工作。如果你可以完成迭代中应该完成的工作，包括找到并修复当前迭代引入的缺陷，那么你也许只需要速度图、测试进度图、迭代内容图。至于是否需要跟踪迭代实践的运作状况，可以咨询团队的一键。

50 为出资人创建项目仪表板

　　50.1 项目经理在编写项目计划时就已经开始制定风险列表了。风险列表会随项目进度发生变化。

　　50.2      

　　50.3 要是项目经理的风险列表条目与日俱增，而且你也不确定有两个功能点能否准时完成。虽然项目仍然按计划进行，但是你确定将来一定会出问题。又好比现在是项目早期，但是你的测试团队无法按计划运行测试，更不用提成功通过率了。对于这两种情况，　　　　项目经理可以将项目标识为有少量云量。这个状态维持几周，开发人员和测试人员仍然不能取得进展，你就可以将项目标识为阴了。

　　50.4 如果项目风险列表还在不断增加，开发人员虽然花了不少力气却是白费，项目经理找到的缺陷也越来越多。这个项目就变成有雨状态了。

　　50.5 建立可信的气息报告：每周不要剧烈变动，仅在确实发生了某些严重影响项目的事情，包括：相对客观的人员转而从事其他工作、厂商缺过截止时间或者没有认识到架构师无法为规划好的功能集合提供支持等等。还有就是，图标一定要职业。

　　50.6 气象报告建立在大量项目数据的基础上：日程相关数据、速度图、缺陷趋势、测试覆盖率、人员分配、风险列表等等。+

 

最后说一下，少了最关键的速度图，有时间了补上来。

 

 

转载于:https://www.cnblogs.com/magic-house/archive/2013/02/21/2921451.html