项目管理修炼之道
2021-04-10 21:03:05 1 举报AI智能生成
登录查看完整内容
项目管理修炼之道
作者其他创作
大纲/内容
项目管理修炼之道
启动项目
定义项目和项目经理
必须确定关键驱动因素
管理项目的关键驱动因素、约束和浮动因素
关键驱动因素应该只有一个
约束应该只有一个
而浮动因素可以有四个
与客户或出资人讨论项目约束
决定项目的关键驱动因素
发布成本
发布日期
功能集合
减少缺陷
人员配备
工作环境
应对喜欢过多干预项目的出资人
使用与上下文无关的问题识别项目真正的驱动因素
项目要怎样才算成功
为什么想得这样的结果
这种解决方案对你来说价值何在
这个系统要解决什么样的问题
这个系统可能会造成什么样的问题
编写项目章程，共享现有对策
项目章程模板
远景
要用描述远景的句子来说明项目的价值
需求
目标
成功标准
例子
功能
要提升产品性能
第一季度发布
ROI(投资回报率 )估算
理解质量对于项目的意义
铭记在心
每个项目启动都要有章程
对项目章程的反复修改要有心理准备
要知道“质量”的意义以及项目的驱动因素
规划项目
使项目足以启动的规划
规划不必完美无缺
使用时间盒
要根据经验而不是语言来规划项目
以终为始
开发项目规划模板
产品意图
历史记录
发布条件
产品目标
项目目标
团队目标
组织目标
项目组织
日程总揽
建议日程
风险列表
制定发布条件
确定当前项目最重要的因素
草拟发布条件
让发布条件符合SMART原则
确定的（specific）
可测量的（Measurable）
可达成的（Attainable）
相关的（Relevant）
可跟踪的（Trackable）
在发布条件上达成多方共识
使用发布条件
在必要时变更发布条件
项目规划是在不断进行的，这只是开始
为项目团队、出资人和项目经理自己制定发布条件，以明确定义“完成”的含义
项目规划不必完美无暇，但是它必须存在
使用生命周期组织项目
理解项目生命周期
定义需求
设计
测试
生命周期概览
顺序式
管理成本风险
需求已知并已就期达成共识
系统架构已被深入理解
项目团队不会发生变化
项目需求不会发生变化
瀑布
阶段-管卡
低缺陷率
发布时间
迭代式
管理技术风险
不断演化的需求
螺旋
不断演化的原型
增量式
管理日程风险
可以应对小的需求变更，无法处理架构变更
项目日程由设计决定，并按阶段交付
迭代/增量式（敏捷）
管理日程和技术风险
团队不在一起，难以实施
敏捷
Scrum
XP
其他
编码并修复
在项目中寻求反馈
大规模项目需求组合使用多种生命周期
项目架构风向
尽早迭代
尽早实现几个可以考验架构承受能力的功能
用时间盒来限制整个架构相关的工作
从瀑布中摆脱出来
用迭代来规划所有的工作
将产品原型化，并尽早向客户或其代理人展示
从项目一开始就加入测试的工作
功能要逐个完成，完成后随即进行集成测试
确保文档不是唯一可交付物
项目经理不必告诉外人如何处理项目内部各种事物
我钟爱的生命周期
铭记在线
使用任何生命周期或多种生命周期的组合
不要怯于创建反映你自己项目实际情况的生命周期
慎用顺序式生命周期
安排项目日程
注重实效的项目日程安排
只要能启动项目即可
估算要准确而不是精确
前期规划活动消费的时间要尽量少
可供选择的项目日程安排技术
自顶向下式日程安排
自底向上式日程安排
由内及外式日程安排
哈德逊湾式启动
让项目团队先尝试在项目的实际环境中开展某些工作
短期迭代
用低技术含量的工具安排项目日程
使用即时贴安排项目日程
使用即时贴和箭头安排项目日程
为每个职能组使用即时贴安排项目日程
按功能使用即时贴安排项目日程
使用即时贴安排项目日程的好处
基于可交付物的规划
按可交付物安排日程而不是按功能
要有以迭代的方式安排日程的准备
估算工作
实用的项目估算方式
通过对比利时数据进行估算
通过Delphi和宽带Delphi方式进行估算
何时不应该相信团队的估算
帕金森定律
只要还有时间，工作就会不断扩展，直到用完所有的时间
学生综合症
工作总是拖延但它所能够允许最迟完成的那一天
不要为任务的估算添加过多的松散时间
小心顺序式生命周期的估算陷阱
使用自信心范围进行估算
使用日期范围进行估算
使用三个日期：最佳状态、最有可能、墨菲日期
估算要准确性不是精确性
在估算时分开考虑任务的大小与持续时间
规划扑克
在估算前用试探性开发收集数据
让估算更容易的提示
估算只是个大概值
多数开发人员都是很乐观
完成一项任务总是要花费比预计更多的时间
估算小块工作更容易
推荐使用人时估算
要练习估算并收集反馈
做好反复估算的准备
不要有某个截至日期
如果任务大，不易估算，可以先用试探性开发
用里程碑切分项目
你们能够不做哪些事情
对需求的理解是稀缺资源
日程安排至关重要
项目成本非常重要
身背多个项目时的估算
主动安排人们进行多任务
使用波浪式规划
为固定的时间安排详细日程规划过程
进行中的规划会维护时间盒
决定迭代的持续时间
尽可能使用“小石子”进行估算
小石子：就是大任务被拆分成小任务
当任务不清楚时创建并使用“小石子”
如何得到“小石子”
指导，但不规定
为什么使用小石子
减少日程安排的风险
绝对不要提供确定的项目结束日期
任务越小，估算起来越容易
寻求估算的准确性，而不是精确性
识别和避免日程安排游戏
给我一块石头
提出问题
你喜欢短日程，还是长日程
是要更多的人，还是更少的人
要是少实现几个功能会如何
找出什么原因促成了他们期望的截至时间
要让出资人明白做出选择以及背后的原因
为你提供的日期说明信心范围
在提供日期时要说明发布条件
制定排好优先级的产品待办事项列表
逐个实现功能
使用短小的时间盒
“希望”是我们最终的策略
识别风险并记录下来
不到万不得已，不要选择瀑布式生命周期
可以用“哈德逊湾式启动”看看是不是能做出什么东西
确保大家具备相关的技术能力
考虑所有工作都采取迭代的方式进行
寻求相关的帮助和信息
制定里程碑条件
使用时间盒限制迭代
使用速度图表展示项目进度
拒绝女王
找出你的经理表示拒绝的原因
写下项目的风险及其潜在影响
展示你所能做到的事情
保证参与项目工作的每个人都有相关领域的专业知识
制定排定优先级的产品代办事项
把灰扫到地毯下面
把某个版本需要的功能先按优先级进行排序，再实现
逐个实现各功能
使用产品待办事项列表，功能按业务价值排序
幸福日期
说明日程安排范围
使用迭代生命周期，并说明将会信心范围实现哪些功能
使用敏捷生命周期和经过排序的待办事项列表
使用短小时间盒
不要仅仅以里程碑日期作为项目的衡量标准
屁股着火
按时间盒迭代进行规划
如果无法管理迭代，就按功能逐个实现，使用按阶段式的交付
将采取这种策略的成本告诉管理层，让他们选择
策略确定后，帮助公司检查相应的具体措施
项目经理可以调整估算方法
分散注意力
保证不让成员被随意切换到其他项目，对工作完成定优先级
短迭代
如果无法管理迭代，那就按功能逐个实现
将成本告诉管理层
确保已经对需求进行过优先级排定
日程等于承诺
日程安排只是估计而已
到了之后，我们会知道身处何方
确定已经有书面的项目愿景、项目目标和发布条件
如果管理层不愿意定义愿景，那项目经理就要担起这个责任
如果项目会持续很长时间，就用迭代组织项目
梦幻时间日程
制定波浪式规划
使用低技术含量的日程安排技术
提供带有信心的水平的估算
使用有时间盒限制的迭代
必须拥有某项功能
要求改变功能集合
要求更多的时间
要求更多地资金
我们不能说“不”
询问团队成员
可以加入额外的人力资源
日程小鸡
避免进度报告会议
将任务分解成更小的部分
按功能逐个实现
使用迭代
90%完成状态
帮助大家定义自己的“小石子”
要让大家把自己的工作进度展示给你
教给大家如何跟踪自己的估算
我们马上会变得更快
与项目团队成员讨论进度速度
测量估算质量因子
测量团队所做的每一件事情
令人恍惚的日程
迭代开发
在一个迭代中要集中精神
如果没有准备好，就按功能逐个实现吧
日程安排游戏总是发生
绝大多数情况下，人们玩这些游戏都不是出于恶意
尽量避免日程安排游戏
创建出色的项目团队
招募你需要的人
架构师
开发人员
测试人员
技术文案
业务分析师
发布工程师
项目经理
形成团队凝聚力
一起工作
好工具让团队有好的发挥
软件配置管理系统
缺陷跟踪系统
团队发展的5个阶段
组建期
激荡期
规范期
表现期
中止期
让你组织配合你的工作
以项目经理的方式管理职能团队
管理矩阵式项目团队
与职能经理建立良好的沟通
对必须得团队规模了如指掌
团队不要多于9个人
知道何时应该加入
项目初期一次性配齐
项目中期谨慎加入
项目快结束时避免加入
成为出色的项目经理
提升人际交往技能
倾听技能
谈判技能
写作技能
以目标为导向
了解和尊重项目相关的工作人员
能够应对信息不足的状况
能够管理细节
判别、寻找进度的障碍，并消除他们
提升功能性技能
不懂技术不要试图遮掩
需要了解问题的大概
理解不同的生命周期模型，知道哪一种适合你的项目
能够安排项目的日程规划
能够估算任务，或者指导其他人完成任务估算
指导如何评估风险、管理风险
清楚如何度量项目状态，以及如何报告项目状态
指导如何处理以完成和未完成的工作
提升领域专业知识技能
提升工具和技术的专业技能
知道何时该全身而退
什么样组织不适合你
你不能选择团队成员
出席会议变成行政任务
出资人坚持认为人们应该同时处理多个任务，而不愿意做出改变
别人想让你承担一些开发相关工作
管理层强制切分项目工作
所有的项目在启动时都面临资源不足
你总是听见人们说“你没法融入团队”
什么样的团队不适合你
对于管理项目的信息了解不足
你知道团队是如何工作的吗
你明白这个项目试图解决什么的问题吗
你的管理层非要给团队施加帮助，可你无法拒绝
对于管理项目需要的信息了解过多
什么样的产品不适合你
你的团队中没有人了解专业知识
项目风险越大，团队的多样化程度就应该越高
提升多方面的技能
人际交往技能
功能性技能
领域技能
非技术技能
知道何时应该离开
掌控项目
掌控项目的节奏
节奏，每个项目生而有之
举行中途回顾
为需求排序
两项对比
按评判标准排定优先级
产品代办列表
用时间盒限定需求相关工作
用时间盒限制初始的需求相关活动，并持续收集更多的需求
用时间盒限制所有的需求定义活动
用一分为二的方式减少迭代持续时间
将迭代限制在4周或是更少的时间内
迭代时间越长，项目的节奏越难保持
短时间盒会让问题暴露的更加明显
使用波浪式的规划和日程安排
每次规划少量的工作
创建跨职能团队
跨职能团队工作效率更高
跨职能团队具有多样性
根据项目的风险选择生命周期模型
不知道用什么，不妨先用敏捷生命周期
标准流程其实无用
保持合理的工作时间
使用小石子
大任务切分成小任务
管理干扰
应对其他项目干扰
应对其他人的干扰
管理缺陷，从项目初就开始
带头考虑使用或调整哪些管理实践
评估项目的问题，然后根据这些问题来判断使用或调整哪些实践
要寻找可以建立和维持项目节奏的实践
保持项目节奏
在项目中使用持续集成
为构建创建自动化冒烟测试
别让烟炮出去
按功能实现，而不是按架构
不要分什么平台组，中间件组，GUI组
按功能可以快速反馈
首先实现具有最高价值的功能
按功能调试
按功能测试
多几只眼睛盯着产品
结对编程
最有效，不是特别容易实施
伙伴复查
同行复查
走查
正式检查
很难坚持
准备重构
重构会让代码减少
及时重构
通过用例，用户故事，角色和场景来定义需求
分离需求与GUI设计
往往我们喜欢用美工进行需求设计，不要这样做
尽可能使用低保真的原型
高保真的原型会限制反馈
不要强迫团队成员采用以上实践
最优推荐持续集成
要正直理解以上实践后再应用，调整实践使其能真正的保持项目的节奏
管理会议
取消这些会议
不需要你解决问题的会议
绝对不要举行多人参加的顺序式报告会议
没有存在理由的会议
没有会后行动的会议
上层主管的顺序顺序式进度报告会议
任何不允许携带笔记本电脑的会议
需要举行的会议
项目启动会议
发布版本规划会议
进度报告会议
每日站立会议
一对一会议
讨论进度和状态
讨论他们的障碍
复查所有的行动计划
通过可见的方式了解进度
小石子
了解何时去定进展，何时陷入僵局
教导下属请求帮助并不丢人
通过电子邮件，从团队成员那里获取每周进度报告
工作成果
未来的里程碑
障碍
每周向团队报告进度
向高层报告进度的会议
项目团队会议
提纲
标题行
期望与会人员
主要里程碑检查
本周遇到的问题
现有障碍
其他话题
回顾以往行动计划
未决事项
迭代回顾会议
项目回顾会议
判断会议是否有价值，决定参会人员
逃避顺序式进度报告会议
观察会议进程，看看是不是能够满足每名参会者的需求
创建并使用项目仪表板
项目仪表板
项目中大多数问题：我们的进度怎么样了？
真正掌握项目关键在于经常进行测量
定性
定量
测量构成了项目仪表板
测量有风险
测量是否花费过多实践，从而影响工作
人们不认真对待测量
测量人，而不是项目
根据项目完成衡量进度
使用速度图表跟着日程安排进度
速度表是最佳图表
使用迭代内容图跟踪总体进度
计算软件项目的挣值并无实际意义
挣值可以用来衡量到目前为止已完成工作的价值
用EQF跟踪最初的估算
更多的度量提供更多的信息
如果职能度量项目日程，那就这么做
与项目团队人员分配情况相关的图表
计划加入和实际加入人员图表
判断项目的变化率
查看开发人员是在取得进展还是在白费时间
测量查找和修复问题的成本
了解开发人员和测试人员是否在解决缺陷方面取得进展
展示测试过程
展示定性数据
用图表展示团队同意采用的实践
度量敏捷项目
为出资人创建项目仪表板
展示风险列表
展示在满足发布条件方面取得的进展
使用项目气象报告
小心定义气象报告的图示
建立可信的气象报告
每周发布气象报告
使用速度图和迭代内容图做为首选
数据是工具，不是目的，要记住，图表应该为你服务
如果无法获取需要的数据，项目经理就遇到比数据更严重的问题
管理多地点项目
识别项目的文化差异
在团队间培养信任
确保每个地点都有完整的项目可交付物
互相依存的团队之间不能存在竞争关系
确保各个团队可以互相协作
让人们建立个人接触
在团队间使用互补实践
使用互补生命周期
详细说明每个团队的里程碑和交接物
详细说明每个词汇的含义
详细说明里程碑的含义
详细说明团队了解自己工作进度的方法
详细说明团队如何评审工作产品
寻找潜在的多地点项目和不同文化导致的问题
外包时还要注意
训练外包相关负责人员
挑选厂商
选取最好的项目经理
与接包方的管理层或项目经理建立信任关系
规划、调整内部及外部职员的工作时间
用文档记录需求
制度适当的变更流程
选择需求相对稳定的项目进行外包
外每个项目规划更长的时间、更多的资金预算
在整个项目开发过程中，坚持接包方不变更团队
为了支持接包团队，要确保有合适的工具、信息系统和流程
要验证确实是他们在做项目的工作
如果团队没有分布在同一楼层的10米之内，这就是一个多地点团队
管理多地点团队要花费更多地时间，还需要更多的项目推进技能
项目经理必须构建与远程团队的信任关系
在项目中集成测试
减少技术债务
使用小规模测试降低风险
单元测试
测试驱动开发
TDD是在项目中集成测试最简便的方式
单元测试不是万能药
使用多种测试技巧
组件测试
功能测试
集成测试
黑盒测试
确定每个团队成员在测试中的角色
正确的开发人员与测试人员之比应该是多少
需求，产品规模，产品的复杂度
组织开发产品的方式
开发人员和测试人员的能力和职责
让测试与开发同步进行
为项目制定测试策略
系统测试策略模板
产品版本和概览
产品历史
待测试功能
不需要测试功能
包含和排斥的环境配置说明
环境需求
系统测试方式
系统测试入口条件
系统测试出口条件
测试交付物
其他参考文档
规划集成测试
使用测试驱动开发
考虑在项目中使用测试连续体系
管理工程
工程管理
协调多个子项目或一系列项目，以达成特定的业务目标
工程经理是战略上的
工程规划模板
综述
工程需求
工程目标
市场评估和推广计划
销售计划
投资回报率和产品生命周期
日程综述
人员安排曲线
培训计划
服务/支持计划
其他计划
组织多个相关项目
将产品的多个版本组织到发布列车中
让发布列车为你服务
工程经理必须与定制项目组合的人一起工作
项目经理管理各个项目，工程经理管理列车
工程经理需要很好的软件配置管理过程
每个人都要有很好的估算能力
提供足够的自动化测试
管理项目经理
确保可交付物为准绳
鼓励使用敏捷和增量式生命周期
从项目经理处了解情况
创建工程仪表板
工程经理需要从战略的角度看待产品
工程经理要确保自己能够明确看到所有项目的进度
要想清楚哪些度量方法适用于你的恶工程
结束项目
管理发布早期版本的请求
管理beta版本
测试目的
测试客户选择
测试入口条件
测试出口条件
总体测试日程
项目经理何时知道无法按时发布项目
避免小的偏差
承诺一个新日期
估算系统测试时间
在时间不够的情况下管理系统测试
复查最初的测试计划
在一周内明确说明测试计划的具体活动
在接下来的三周时间内，要开发测试用例，并持续修改测试计划
在每周测试工作结束时，要评估当前进度，并报告测试数据
后期要验证修复的正确性
指导项目走向完成
管理“结束游戏”
避免“缺陷提升和降级的游戏”
规划回顾
准备阶段
收集数据
深入讨论
行动决策
结束回顾
规划庆祝
取消项目
避免将精力放在中期里程碑上
项目结束时一定要做回顾
如果必须取消一个项目，那就彻底取消
管理项目组合
构建所有项目的组合
评估项目
定性评估项目
定量评估项目
决定现在为哪个项目提供资金
对组合中的项目进行排序
尽快启动项目
使用产品待办事项列表管理新功能需求
构建产品待办事项列表
管理待办事项列表
组合管理答疑
说服管理层“切换上下文”是个坏主意
如何对多任务说“不”
现在不行，再给个日期
这些是我现在的工作，我应该停下来哪一项
与上司一起制定产品，待办事项列表
使用项目组合排定工作优先级
多任务请求是有风险和后果的
你什么时候需要这些功能
使用产品待办列表
制定项目组合
学着如何说不
0 条评论
回复 删除
下一页
