项目管理的方式方法思维导图

必须确定关键驱动因素

关键驱动因素应该只有一个

约束应该只有一个

而浮动因素可以有四个

发布成本

发布日期

功能集合

减少缺陷

人员配备

工作环境

使用与上下文无关的问题识别项目真正的驱动因素

项目章程模板

每个项目启动都要有章程

对项目章程的反复修改要有心理准备

要知道“质量”的意义以及项目的驱动因素

规划不必完美无缺

使用时间盒

要根据经验而不是语言来规划项目

以终为始

产品意图

历史记录

发布条件

目标

项目组织

日程总揽

人员配备

建议日程

风险列表

确定当前项目最重要的因素

草拟发布条件

让发布条件符合SMART原则

在发布条件上达成多方共识

在必要时变更发布条件

项目规划是在不断进行的，这只是开始

为项目团队、出资人和项目经理自己制定发布条件，以明确定义“完成”的含义

项目规划不必完美无暇，但是它必须存在

定义需求

设计

测试

顺序式

迭代式

增量式

迭代/增量式（敏捷）

其他

尽早迭代

尽早实现几个可以考验架构承受能力的功能

用时间盒来限制整个架构相关的工作

用迭代来规划所有的工作

将产品原型化，并尽早向客户或其代理人展示

从项目一开始就加入测试的工作

功能要逐个完成，完成后随即进行集成测试

确保文档不是唯一可交付物

项目经理不必告诉外人如何处理项目内部各种事物

敏捷

使用任何生命周期或多种生命周期的组合

不要怯于创建反映你自己项目实际情况的生命周期

慎用顺序式生命周期

只要能启动项目即可

估算要准确而不是精确

前期规划活动消费的时间要尽量少

自顶向下式日程安排

自底向上式日程安排

由内及外式日程安排

哈德逊湾式启动

短期迭代

使用即时贴安排项目日程

使用即时贴和箭头安排项目日程

为每个职能组使用即时贴安排项目日程

按功能使用即时贴安排项目日程

使用即时贴安排项目日程的好处

基于可交付物的规划

用低技术含量的工具安排项目日程

按可交付物安排日程而不是按功能

要有以迭代的方式安排日程的准备

通过对比利时数据进行估算

通过Delphi和宽带Delphi方式进行估算

何时不应该相信团队的估算

小心顺序式生命周期的估算陷阱

使用自信心范围进行估算

使用日期范围进行估算

使用三个日期：最佳状态、最有可能、墨菲日期

在估算时分开考虑任务的大小与持续时间

规划扑克

在估算前用试探性开发收集数据

让估算更容易的提示

对需求的理解是稀缺资源

日程安排至关重要

项目成本非常重要

为固定的时间安排详细日程规划过程

进行中的规划会维护时间盒

小石子：就是大任务被拆分成小任务

当任务不清楚时创建并使用“小石子”

如何得到“小石子”

为什么使用小石子

绝对不要提供确定的项目结束日期

任务越小，估算起来越容易

寻求估算的准确性，而不是精确性

提出问题

找出什么原因促成了他们期望的截至时间

要让出资人明白做出选择以及背后的原因

为你提供的日期说明信心范围

在提供日期时要说明发布条件

制定排好优先级的产品待办事项列表

逐个实现功能

使用短小的时间盒

识别风险并记录下来

不到万不得已，不要选择瀑布式生命周期

可以用“哈德逊湾式启动”看看是不是能做出什么东西

确保大家具备相关的技术能力

考虑所有工作都采取迭代的方式进行

寻求相关的帮助和信息

制定里程碑条件

使用时间盒限制迭代

使用速度图表展示项目进度

找出你的经理表示拒绝的原因

写下项目的风险及其潜在影响

展示你所能做到的事情

保证参与项目工作的每个人都有相关领域的专业知识

使用时间盒限制迭代

制定排定优先级的产品代办事项

把某个版本需要的功能先按优先级进行排序，再实现

逐个实现各功能

制定发布条件

使用产品待办事项列表，功能按业务价值排序

说明日程安排范围

使用迭代生命周期，并说明将会信心范围实现哪些功能

使用敏捷生命周期和经过排序的待办事项列表

使用短小时间盒

不要仅仅以里程碑日期作为项目的衡量标准

按时间盒迭代进行规划

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

将采取这种策略的成本告诉管理层，让他们选择

策略确定后，帮助公司检查相应的具体措施

项目经理可以调整估算方法

保证不让成员被随意切换到其他项目，对工作完成定优先级

短迭代

如果无法管理迭代，那就按功能逐个实现

将成本告诉管理层

确保已经对需求进行过优先级排定

日程安排只是估计而已

确定已经有书面的项目愿景、项目目标和发布条件

如果管理层不愿意定义愿景，那项目经理就要担起这个责任

如果项目会持续很长时间，就用迭代组织项目

制定波浪式规划

使用低技术含量的日程安排技术

提供带有信心的水平的估算

使用有时间盒限制的迭代

要求改变功能集合

要求更多的时间

要求更多地资金

询问团队成员

可以加入额外的人力资源

避免进度报告会议

将任务分解成更小的部分

按功能逐个实现

使用迭代

帮助大家定义自己的“小石子”

要让大家把自己的工作进度展示给你

教给大家如何跟踪自己的估算

与项目团队成员讨论进度速度

测量估算质量因子

测量团队所做的每一件事情

迭代开发

在一个迭代中要集中精神

如果没有准备好，就按功能逐个实现吧

日程安排游戏总是发生

绝大多数情况下，人们玩这些游戏都不是出于恶意

尽量避免日程安排游戏

架构师

开发人员

测试人员

技术文案

业务分析师

发布工程师

项目经理

一起工作

好工具让团队有好的发挥

软件配置管理系统

缺陷跟踪系统

团队发展的5个阶段

以项目经理的方式管理职能团队

管理矩阵式项目团队

团队不要多于9个人

项目初期一次性配齐

项目中期谨慎加入

项目快结束时避免加入

提升人际交往技能

提升功能性技能

提升领域专业知识技能

提升工具和技术的专业技能

什么样组织不适合你

什么样的团队不适合你

什么样的产品不适合你

项目风险越大，团队的多样化程度就应该越高

提升多方面的技能

知道何时应该离开

节奏，每个项目生而有之

两项对比

按评判标准排定优先级

产品代办列表

用时间盒限制初始的需求相关活动，并持续收集更多的需求

用时间盒限制所有的需求定义活动

用一分为二的方式减少迭代持续时间

迭代时间越长，项目的节奏越难保持

短时间盒会让问题暴露的更加明显

每次规划少量的工作

跨职能团队工作效率更高

跨职能团队具有多样性

不知道用什么，不妨先用敏捷生命周期

标准流程其实无用

大任务切分成小任务

应对其他项目干扰

应对其他人的干扰

带头考虑使用或调整哪些管理实践

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

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

别让烟炮出去

不要分什么平台组，中间件组，GUI组

按功能可以快速反馈

首先实现具有最高价值的功能

按功能调试

按功能测试

结对编程

伙伴复查

同行复查

走查

正式检查

重构会让代码减少

及时重构

往往我们喜欢用美工进行需求设计，不要这样做

高保真的原型会限制反馈

不要强迫团队成员采用以上实践

最优推荐持续集成

要正直理解以上实践后再应用，调整实践使其能真正的保持项目的节奏

不需要你解决问题的会议

绝对不要举行多人参加的顺序式报告会议

没有存在理由的会议

没有会后行动的会议

上层主管的顺序顺序式进度报告会议

任何不允许携带笔记本电脑的会议

项目启动会议

发布版本规划会议

进度报告会议

向高层报告进度的会议

项目团队会议

迭代回顾会议

项目回顾会议

判断会议是否有价值，决定参会人员

逃避顺序式进度报告会议

观察会议进程，看看是不是能够满足每名参会者的需求

项目中大多数问题：我们的进度怎么样了？

真正掌握项目关键在于经常进行测量

测量构成了项目仪表板

测量是否花费过多实践，从而影响工作

人们不认真对待测量

测量人，而不是项目

使用速度图表跟着日程安排进度

使用迭代内容图跟踪总体进度

计算软件项目的挣值并无实际意义

用EQF跟踪最初的估算

更多的度量提供更多的信息

如果职能度量项目日程，那就这么做

与项目团队人员分配情况相关的图表

判断项目的变化率

查看开发人员是在取得进展还是在白费时间

测量查找和修复问题的成本

了解开发人员和测试人员是否在解决缺陷方面取得进展

展示测试过程

展示定性数据

用图表展示团队同意采用的实践

度量敏捷项目

展示风险列表

展示在满足发布条件方面取得的进展

小心定义气象报告的图示

建立可信的气象报告

每周发布气象报告

使用速度图和迭代内容图做为首选

数据是工具，不是目的，要记住，图表应该为你服务

如果无法获取需要的数据，项目经理就遇到比数据更严重的问题

确保每个地点都有完整的项目可交付物

互相依存的团队之间不能存在竞争关系

确保各个团队可以互相协作

让人们建立个人接触

使用互补生命周期

详细说明每个团队的里程碑和交接物

训练外包相关负责人员

挑选厂商

选取最好的项目经理

与接包方的管理层或项目经理建立信任关系

规划、调整内部及外部职员的工作时间

用文档记录需求

制度适当的变更流程

选择需求相对稳定的项目进行外包

外每个项目规划更长的时间、更多的资金预算

在整个项目开发过程中，坚持接包方不变更团队

为了支持接包团队，要确保有合适的工具、信息系统和流程

要验证确实是他们在做项目的工作

如果团队没有分布在同一楼层的10米之内，这就是一个多地点团队

管理多地点团队要花费更多地时间，还需要更多的项目推进技能

项目经理必须构建与远程团队的信任关系

单元测试

测试驱动开发

单元测试不是万能药

单元测试

组件测试

功能测试

集成测试

黑盒测试

需求，产品规模，产品的复杂度

组织开发产品的方式

开发人员和测试人员的能力和职责

产品版本和概览

产品历史

待测试功能

不需要测试功能

包含和排斥的环境配置说明

环境需求

系统测试方式

系统测试入口条件

系统测试出口条件

测试交付物

其他参考文档

规划集成测试

使用测试驱动开发

考虑在项目中使用测试连续体系

协调多个子项目或一系列项目，以达成特定的业务目标

工程经理是战略上的

综述

功能

工程需求

工程目标

市场评估和推广计划

销售计划

投资回报率和产品生命周期

日程综述

人员安排曲线

培训计划

服务/支持计划

其他计划

将产品的多个版本组织到发布列车中

让发布列车为你服务

确保可交付物为准绳

鼓励使用敏捷和增量式生命周期

从项目经理处了解情况

工程经理需要从战略的角度看待产品

工程经理要确保自己能够明确看到所有项目的进度

要想清楚哪些度量方法适用于你的恶工程

测试目的

测试客户选择

测试入口条件

测试出口条件

总体测试日程

避免小的偏差

承诺一个新日期

估算系统测试时间

在时间不够的情况下管理系统测试

管理“结束游戏”

避免“缺陷提升和降级的游戏”

规划回顾

规划庆祝

避免将精力放在中期里程碑上

项目结束时一定要做回顾

如果必须取消一个项目，那就彻底取消

定性评估项目

定量评估项目

构建产品待办事项列表

管理待办事项列表

说服管理层“切换上下文”是个坏主意

如何对多任务说“不”

使用产品待办列表

制定项目组合

学着如何说不