Manage It!: Your Guide to Modern, Pragmatic Project Management 项目管理修炼之道 2018 程序啪啪啪
项目管理修炼之道
图书目录
- 启动项目
- 定义项目和项目经理 1
- 管理项目的关键驱动因素、约束和浮动因素 2
- 与客户或出资人讨论项目约束 5
- 决定项目的关键驱动因素 6
- 应对喜欢过多干预项目的出资人 7
- 预测未来 8
- 使用与上下文无关的问题识别项目真正的驱动因素 8
- 编写项目章程,共享现有决策 9
- 远景 10
- 需求 10
- 目标 10
- 成功标准 11
- ROI 11
- 理解质量对于项目的意义 12
- 规划项目 14
- 踏上征程 14
- 使项目足以启动的规划 14
- 开发项目规划模板 16
- 产品意图 16
- 历史记录 17
- 发布条件 17
- 目标 18
- 项目组织 18
- 日程总览 19
- 人员配备 20
- 建议日程 20
- 制订项目风险列表 21
- 制订发布条件 21
- 确定当前项目最重要的因素 22
- 草拟发布条件 23
- 让发布条件符合SMART原则 24
- 在发布条件上达成多方共识 25
- 使用发布条件 25
- 使用生命周期组织项目 27
- 理解项目生命周期 27
- 生命周期概览 28
- 在项目中寻求反馈 31
- 大规模项目需要组合使用多种生命周期 33
- 管理架构风险 35
- 从瀑布中摆脱出来 36
- 我最钟爱的生命周期 36
- 安排项目日程 38
- 注重实效的项目日程安排 38
- 可供选择的项目日程安排技术 39
- 自顶向下式日程安排 40
- 自底向上式日程安排 40
- 由内及外式日程安排 40
- 哈德逊湾式启动 41
- 短期迭代 41
- 用低技术含量的工具安排项目日程 42
- 使用即时贴安排项目日程的基本技术 43
- 使用即时贴和箭头安排项目日程 45
- 为每一个职能组使用即时贴安排项目日程 45
- 按功能使用即时贴安排项目日程 46
- 使用即时贴安排项目日程的好处 46
- 基于可交付物的规划 47
- 估算工作 48
- 实用的项目估算方式 48
- 通过对比历史数据进行估算 48
- 通过Delphi和宽带Delphi方式进行估算 48
- 何时不应相信团队的估算 49
- 小心顺序式生命周期的估算陷阱 50
- 使用自信心范围进行估算 51
- 使用日期范围进行估算 53
- 使用三个日期:最佳状况、最有可能、“墨菲”日期 53
- 在估算时分开考虑任务的大小与持续时间 54
- 规划扑克 55
- 在估算前用试探性开发收集数据 56
- 让估算更容易的提示 56
- 用里程碑切分项目 57
- 你们能够不做哪些事情 59
- 身背多个项目时的估算 59
- 主动安排人们进行多任务 60
- 使用波浪式规划 60
- 决定迭代的持续时间 62
- 尽可能使用“小石子”进行估算 63
- 当任务不清楚时创建并使用“小石子” 63
- 如何得到“小石子” 63
- 为什么使用“小石子” 64
- 识别和避免日程安排游戏 65
- 给我一块石头 65
- “希望”是我们最重要的策略 67
- 拒绝女王 69
- 把灰扫到地毯下面 71
- 幸福日期 72
- 屁股着火 74
- 分散注意力 76
- 日程等于承诺 77
- 到了之后,我们会知道身处何方 78
- 日程安排工具总是对的,又称为梦幻时间日程 80
- 我们必须拥有这个功能,否则就完蛋了 82
- 我们不能说“不” 83
- 日程小鸡 85
- 90%完成状态 86
- 我们马上会变得更快 87
- 令人恍惚的日程 88
- 创建出色的项目团队 90
- 招募需要的人 90
- 形成团队凝聚力 91
- 好工具让团队有好的发挥 92
- 软件配置管理系统应满足的最低要求 93
- 缺陷跟踪系统应满足的最低要求 93
- 团队发展的5个阶段 93
- 让组织配合你的工作 94
- 以项目经理的方式管理职能团队 95
- 管理矩阵式项目团队 95
- 管理跨职能项目团队 96
- 对必需的团队规模了如指掌 96
- 知道何时应该加人 97
- 成为出色的项目经理 98
- 提升人际交往技能 98
- 提升功能性技能 99
- 提升领域专业知识技能 99
- 提升工具和技术的专业技能 100
- 知道何时该全身而退 101
- 什么样的组织不适合你 101
- 什么样的团队不适合你 104
- 什么样的产品不适合你 105
- 掌控项目 106
- 掌控项目的节奏 106
- 举行中途回顾 107
- 为需求排序 108
- 用时间盒限定需求相关的工作 111
- 将迭代限制在4周或是更少的时间内 112
- 使用波浪式的规划和日程安排 113
- 创建跨职能团队 116
- 根据项目的风险选择生命周期模型 116
- 保持合理的工作时间 117
- 使用“小石子” 118
- 管理干扰 119
- 应对其他项目干扰 119
- 应对其他人的干扰 120
- 管理缺陷,从项目初就开始 120
- 保持项目节奏 124
- 在项目中使用持续集成 124
- 为构建创建自动化冒烟测试 125
- 按功能实现,而不是按架构 126
- 首先实现具有最高价值的功能 128
- 按功能调试 129
- 按功能测试 129
- 多几只眼睛盯着产品 130
- 准备重构 131
- 通过用例、用户故事、角色和场景来定义需求 132
- 分离需求与GUI设计 133
- 尽可能使用低保真度的原型 134
- 管理会议 136
- 取消这些会议 136
- 避免不需要你解决问题的会议 137
- 绝对不要举行多人参加的顺序式进度报告会议 137
- 避免这些会议 138
- 举行下列会议 139
- 项目启动会议 139
- 发布版本规划会议 139
- 进度报告会议 140
- 每日站立会议 140
- 一对一会议 141
- 通过可见的方式了解进度 142
- 通过电子邮件,从团队成员那里获取每周进度报告 143
- 每周向团队报告进度 144
- 向管理层报告进度 144
- 项目团队会议 144
- 迭代审查会议 145
- 会议疑难问题解答 146
- 管理与远程团队的电话会议.. 147
- 通用引导指南 148
- 准备工作 148
- 进行事先规划 149
- 引导会议 149
- 电话会议后的工作 150
- 创建并使用项目仪表板 151
- 测量有风险 151
- 根据项目完成度来衡量进度 153
- 使用速度图表跟踪日程安排进度 153
- 使用迭代内容图跟踪总体进度 155
- 计算软件项目的挣值并无实际意义 155
- 用EQF跟踪最初的估算 157
- 更多的度量能提供更多信息 159
- 如果只能度量项目日程,那就这么做 160
- 与项目团队人员分配情况相关的图表 161
- 判断项目的变化率 163
- 查看开发人员是在取得进展还是在白费时间 164
- 测量查找和修复问题的成本 165
- 了解开发人员和测试人员是否在解决缺陷方面取得进展 166
- 展示测试过程 167
- 展示定性数据 168
- 用图表展示团队同意采用的实践 169
- 度量敏捷项目 171
- 为出资人创建项目仪表板 171
- 展示风险列表 171
- 展示在满足发布条件方面取得的进展 171
- 使用项目气象报告 173
- 要小心定义气象报告的图示 174
- 建立可信的气象报告 176
- 每周发布气象报告 176
- 管理多地点项目 177
- 一个问题的成本是多少 177
- 识别项目的文化差异 178
- 在团队间培养信任 179
- 确保每个地点都有完整的项目可交付物 179
- 确保各个团队可以互相协作 181
- 让人们建立个人接触 181
- 在团队间使用互补实践 182
- 使用互补生命周期 182
- 详细说明每个团队的里程碑和交接物 183
- 寻找潜在的多地点项目和不同文化导致的问题 187
- 在外包时要避免下列错误 188
- 在项目中集成测试 191
- 从一开始,就让人们将“减少技术债务”牢记心间 191
- 使用小规模测试降低风险 192
- TDD是在项目中集成测试最简便的方式 193
- 使用多种测试技巧 195
- 确定每个团队成员在测试工作中的角色 197
- 正确的开发人员与测试人员之比应该是多少 201
- 产品风险对比率的影响 201
- 项目和流程风险对比率的影响 202
- 人员及其能力对比率的影响 203
- 让测试与开发同步进行 205
- 为项目制定测试策略 205
- 系统测试策略模板 205
- QA与测试有差别 207
- 管理工程 209
- 如果项目是工程 209
- 将多个相关项目组织到一个发布版本中 210
- 随时间推移组织多个相关项目 212
- 将产品的多个版本组织到发布列车中 212
- 让发布列车为你服务 213
- 在不使用发布列车的情况下,将多个版本组织到一个产品中 214
- 管理项目经理 214
- 创建工程仪表板 215
- 度量互相依赖的项目 216
- 度量一系列项目 216
- 结束项目 218
- 管理发布早期版本的请求 218
- 管理beta版本 219
- 项目经理何时知道无法按时发布项目 220
- “避免小的偏差” 220
- 承诺一个新日期 220
- 估算系统测试时间 222
- 在时间不够的情况下管理系统测试 224
- 指导项目走向完成 225
- 管理“结束游戏” 225
- 避免“缺陷提升和降级的游戏” 226
- 规划回顾 227
- 规划庆祝 228
- 取消项目 229
- 管理项目组合 231
- 构建所有项目的组合 231
- 评估项目 232
- 定性评估项目 232
- 定量评估项目 233
- 决定现在为哪个项目提供资金 233
- 对组合中的项目进行排序 233
- 尽快启动项目 234
- 使用产品待办事项列表管理新功能需求 235
- 构建产品待办事项列表 235
- 管理待办事项列表 237
- 组合管理答疑 237
- 管理从事多个项目多个任务的情况 238
- 说服管理层“切换上下文”是个坏主意 238
- 如何对多任务说“不” 240
铭记在心45点
- 项目规划是在不断进行的,这只是开始。
- 为项目团队、出资人、项目经理自己制订发布条件,以明确定义“完成”的含义。
- 项目规划不必完美无瑕,但是它必须存在。
- 在组织项目时,使用任何生命周期或是多种生命周期的组合,都可以让项目踏上成功之路。
- 不要怯于创建反映你自己项目实际情况的生命周期。“完美的”生命周期只是模型而已,你是生活在现实世界的。
- 阶段-关卡流程或瀑布式生命周期,只有在确定使用它可以获得成功时才使用,而不是不经思考,拿来就用。
- 用低技术含量的工具开始安排项目日程。如果真地需要相关软件工具,过后再转换数据。
- 按可交付物安排日程,而不是按功能。---我个人在这点上犯了极大错误。
- 要有以迭代的方式安排日程的准备。一次完成的项目时间表,其作用根本无法对得起花在上面的时间。
- 绝对不要提供确定的项目结束日期。
- 任务越小,估算起来就越容易。
- 寻求估算的准确性,而不是精确性。
- 日程安排游戏总是会发生的。项目经理的工作就是要识别它们,然后管理项目,让项目仍然可以取得成功。
- 绝大多数情况下,人们玩这些游戏都不是出于恶意。
- 即使没有恶意,日程安排游戏还是会拖项目后腿,使其停滞不前。
- 项目风险越大,团队的多样华程度就应该越高。
- 提升多方面的技能:人际交往技能、功能性技能、领域技能,还有非技术技能。 --我想这个我们都很欠缺
- 知道何时应该离开。
- 作为项目经理,你要带头考虑使用或调整哪些管理实践。
- 评估项目的问题,然后根据这些问题来判断使用或调整哪些实践。
- 要寻找可发建立或维持项目节奏的实践。
- 项目经理可以邀请团队成员考虑这些实践,不过你不能强迫他们采纳这些实践。
- 如果项目经理即使尽全力也只能选择一个实践,推荐选择持续集成。
- 项目经理采纳和调整的实践要有助于保持项目的节奏,允许项目提高启动和结束的速度。
- 你可以判断一次会议对你是否有价值,是否值得花费你或都任何团队成员的时间。
- 要像逃避瘟疫一样,逃避顺序式进度报告会议。
- 观察会议进程,看看是不是能够满足每名参会者的需要。
- 使用速度图的迭代内容图作为首选。
- 数据是工具,不是目的。要记住,图表应该为你服务。
- 如果无法获取需要的数据,项目经理就遇到了比数据更严重的问题。先解决这个问题。
- 如果团队没有分布在同一楼层的十米之内,这就是一个多地点团队。
- 相对于管理坐在一起的团队,管理多地点团队要花费更多时间,还需要更多的项目推进技能。
- 如果项目无法构建起与远程团队的信任关系,这个项目就不可能成功。
- 如果项目经理有在项目中集成测试的规划,你就可以做到。
- 使用TDD,可以提升产品的设计和代码的质量。
- 可以考虑在项目中使用测试连续体系。
- 工程管理需要从战略的角度看待产品,不能仅从战术角度去看。
- 工程管理要确保自己能够看么所有项目的进度。
- 要想清楚哪些度量方法适用于你工程。
- 将精力放在中期里程碑上,很容易引发“穿越沙漠综合症”,一定要避免这种情况。
- 在项目结事时,一定要做回顾,即使已经在项目中进行过中期回顾也要如此。--这点很重要
- 如果项目经理必须取消一个月,那就取消吧。要取消得彻底,不能半途而废。
- 使用产品待办事项列表,不管你采用什么样的生命周期模型。
- 制定项目组合,以从视觉上了解所有项目的情况,不管这些项目是在进行中,还是刚做计划。
- 学着如何说“不”
创建@
2011-02-12
最后修改@
2014-01-01