项目管理修炼之道
2017-01-18 16:46:19 0 举报AI智能生成
读书笔记 项目管理
作者其他创作
大纲/内容
第9章 保持项目节奏
在项目中使用持续集成
开发人员用一两个小时编写一段代码，对其进行编译，测试，复查，构建，运行冒烟测试，并验证做出的改变不会破坏现有系统代码，再将其签入到代码库中。持续集成就这么发生了。
为构建创建自动化冒烟测试
按功能实现，而不是按架构
首先实现具有最高价值的功能
按功能调试
按功能测试
邀请团队成员相互复查工作。
复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。
准备重构
通过用例、用户故事、角色和场景来定义需求
分离需求与GUI设计
尽可能使用低保真度的原型
小结
□项目经理可以邀请团队成员考虑这些实践，不过你不能强迫他们采纳这些实践。
□如果项目经理即使尽全力也只能选择一个实践，推荐选择持续集成。
□项目经理采纳和调整的实践要有助于保持项目的节奏，允许项目提高启动和结束的速度。
第10章 管理会议
发现并摧毁浪费时间的会议
避免不需要你解决问题的会议
绝对不要举行多人参加的顺序式进度报告会议
举行下列会议
项目启动会议
如果章程已经编写完毕，那就跟大家一起把章程过一遍吧。这可以帮助大家看到如何开始复查工作成果
发布版本规划会议
如果项目经理管理敏捷项目，会主持一个发布版本规划会议，而不是项目启动会议。发布版本规划可以让每个人（包括团队成员、出资人、客户）看到你对于项目进展的规划。项目经理会规划出希望一个迭代交付哪些功能。项目经理会在迭代之间对产品待办事项列表重新排序（参见16.6.2节），细节会有变化。
进度报告会议
每日站立会议
团队成员在一起，耗时不超过15分钟。每个人都站着
□我昨天完成了什么？
□我今天计划要做什么？
□我面临哪些障碍？
适用敏捷开发
一对一会议
目的，了解项目进度
如果项目经理管理的项目使用顺序式或迭代式生命周期，或者处于增量式生命周期的早期，你应该与团队每名成员进行每周一次的一对一会议。
通过可见的方式了解进度
通过电子邮件，从团队成员那里获取每周进度报告
电子邮件进度报告模板
工作成果。几段简短的话（每段两三句话），报告过去一周完成的工作。
未来的里程碑。任务描述 规划完成日期 预计完成日期 实际完成日期
有些项目由于发生外部事件，团队成员的工作会有变化。对于这样的项目，可以在右边加上另外一列：估算变更次数。
障碍。团队成员写下导致不能完成工作的障碍。而且希望能从这个列表产生行动计划。
每周向团队报告进
向管理层报告进度
项目团队会议
目的
解决问题而不是项目进度
会议提纲
主要里程碑检查
本周遇到的问题
现有障碍？
其他话题
回顾以往行动
未决事项
迭代回顾会议
迭代尾声，团队会向产品负责人展示工作成果
项目回顾会议
小结
□你可以判断一次会议对你是否有价值，是否值得花费你或者任何团队成员的时间。
□要像逃避瘟疫一样，逃避顺序式进度报告会议。
□观察会议进程，看看是不是能够满足每名参会者的需要。
第11章 创建并使用项目仪表板
测量风险
项目团队花费过多时间进行测量，从而影响正常工作；人们不认真对待测量；测量人，而不是项目。
使用多维度的测量来评估项目进度
使用速度图表跟踪日程安排进度
如果项目采取按功能逐个实现的方式，中所示的速度图表可以很好地指示出团队的项目进度，而且它还能告诉项目经理剩余多少未完成工作。
可以按照下面的步骤来绘制速度图。将所有的功能汇总，得到项目的全部功能数。开发完一个功能，就将已完成功能数加1，并减少剩余功能数。如果必须在项目进行过程中添加新功能，就得把这些额外的功能加入到全部功能数中。即使这些功能的规模并不齐整，速度图也能有所帮助。
图表
X轴
日期
Y轴
功能数
3条曲线
剩余功能数
已完成功能数
全部功能数
使用迭代内容图跟踪总体进度
小结
□使用速度图和迭代内容图作为首选。
□数据是工具，不是目的。要记住，图表应该为你服务。
□如果无法获取需要的数据，项目经理就遇到了比数据更严重的问题。先解决这个问题吧。
第12章 管理多地点项目
小结
□如果团队没有分布在同一楼层的10米之内，这就是一个多地点团队。
□相对于管理坐在一起的团队，管理多地点团队要花费更多时间，还需要更多的项目推进技能。
□如果项目经理无法构建起与远程团队的信任关系，项目就不可能成功。
第13章 在项目中集成测试
TDD遵循流程
1.开发人员（如果是结对编程的话，就是一对开发人员）针对某个尚未开发的新功能创建一个测试。这个测试应该失败，因为功能的实现代码还不存在。
2.然后开发人员加入能够使测试通过的最简单的实现代码。
3.开发人员重新运行测试。如果实现代码能够通过测试，开发人员就重构以简化代码。如果代码无法通过测试，开发人员会继续修改代码。在修改时，开发人员会重构代码，使其变得更简单、运行更迅速、维护更简单——这都是为了防止发生技术债务。
4.随着开发人员继续工作，他们会运行所有的测试，以保证不会引入问题，使得回归测试不能通过。开发人员会继续遵循这个循环过程，直到所有的功能全部实现。
使用一流的测试人员
QA与测试有差别
QA是指质量保证，这是流程改进和流程度量活动。
QA小组或经理具备如下特质
有权有钱，能够为开发人员提供必要的培训
有权解决客户的投诉，或是有权推动客户投诉的处理，特别是在产品下一版本的需求优先级排序过程中。
□有权、有能力修复缺陷。
□有权、有能力编写或重写用户手册。
□有能力了解客户需求，并据此设计产品。
□有能力根据多个项目度量产品开发过程，对比结果，并解释这些结果——而且不会因此被解雇。
□有能力了解当前产品开发过程，并有权对其进行修改。
QA经理或小组也许不会直接干这些工作，但是他们有能力安排相关的人力和工作。
小结
□如果项目经理有在项目中集成测试的规划，你就可以做到。
□使用TDD，可以提升产品的设计和代码的质量。
□可以考虑在项目中使用测试连续体系。
□可以考虑在项目中使用测试连续体系。
第14章 管理工程
工程管理
定义
工程管理：协调多个子项目或是一系列项目，以达成特定的业务目标。
项目管理是战术上的。项目经理的职责是完成自己手上的项目，而不会考虑其他进行中的项目。但是工程经理的职责更注重战略性，因为工程经理要协调多个子项目或是一系列项目。工程经理必须时刻将工程的战略业务目标牢记在心，而且要保证每个项目都遵循这个目标。如果目标发生变化，工程经理还得（与相关项目经理）决定各个项目要做哪些调整。项目经理会完成具体的调整措施。
制定工程规划
工程规划模板：
□综述
□功能
□工程需求
□工程目标
□市场评估和推广计划
□销售计划
□投资回报率和产品生命周期
□日程综述
□人员安排曲线
□培训计划
□服务/支持计划
□其他计划
管理风险列表
管理项目经理
以交付物为准绳
建立信任
管理异常情况
审查仪表盘
风险列表
创建工程仪表板
□工程管理需要从战略的角度看待产品，不能仅从战术角度去看。
□工程经理要确保自己能够明确看到所有项目的进度。
□要想清楚哪些度量方法适用于你的工程。
第15章 结束项目
指导项目走向完成
继续收集缺陷相关数据，避免缺陷升级和降级的游戏
排定已知问题，并告知客户修复日期
规划回顾
目的是要回顾项目的进展过程、人们有哪些经验教训、他们在这个项目中工作时的感觉如何。经过用心设计和推进的回顾，可以为下个项目节省好几周的时间。
步骤
准备阶段
收集数据
深入讨论
行动决策
结束回顾
规划庆祝
取消项目
也是一种结束项目的方式
小结
□将精力放在中期里程碑上，很容易引发“穿越沙漠综合症”，一定要避免这种情况。
□在项目结束时，一定要做回顾，即使已经在项目中进行过中期回顾也要如此。
□如果项目经理必须取消一个项目，那就取消吧。要取消得彻底，不能半途而废。
第16章 管理项目组合
管理项目组合
构建项目列表
评估每个项目
定性评估
回答以下问题
□这个项目与其他项目之间是什么关系？
□实施这个项目的战略原因是什么？
□完成这个项目有哪些战术上的收益？
□为了使项目成功，我们是否提供了足够的资金？
□为了使项目成功，我们是否提供了足够的人力？
□我们是否知道这个项目成功的标准？
定量评估
回答以下问题
□何时可以看到该项目的财务回报？
□该项目的收益曲线是什么样子？
□该项目的客户获取曲线是什么样子？
□何时能见到该项目的当前客户保持率？
□期望的客户增长曲线是什么样子？
□何时能见到该项目降低运营成本？
□期望的运营成本曲线是什么样子？
指定关于项目人员和资金的决策
对项目排序
按排序安排人员
小结
□使用产品待办事项列表，不管你采用什么样的生命周期模型。
□制定项目组合，以从视觉上了解所有项目的情况，不管这些项目是在进行中，还是刚做计划。
□学着如何说“不”
第1章 启 动 项 目
定义项目经理
职责
负责向团队清晰说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。
定义项目目标
每个项目都是独一无二的
发现当前项目的独特之处
管理项目的关键驱动因素、约束和浮动因素
理论
关键驱动因素
需权衡的不仅仅是“铁三角”
项目的“铁三角”
时间
成本
范围（或质量）
理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。
如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理。
约束
选出重要性高的2-3项
浮动因素
一个项目至少要有三个浮动因素
怎么找
0、理解项目背景
1、写出客户的期望
客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）
功能集合
功能齐全
发布时间
质量
产品缺陷率
项目成本
人员配备
工作环境？
2、写下项目约束
环境是什么样子的？能否灵活安排团队的位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般只有项目出问题的时候才能改变）。约束决定了项目的规模（还有持续时间和质量）。
与客户或出资人讨论项目约束
3、识别出项目成功的必要因素
怎么找
经验
受到过多限制的项目难以逃避失败的厄运
项目经理自己做决定
决定项目的关键驱动因素
可以使用项目优先级决定出来
应对喜欢过多干预项目的出资人
预测未来
使用与上下文无关的问题
□项目要怎么样才算成功？
□为什么想得到这样的结果？
□这种解决方案对你来说价值何在？
□这个系统要解决什么样的问题？
□这个系统可能会造成什么样的问题？
理解质量对于项目的意义
了解摩尔的鸿沟
编写项目章程，共享现有决策
项目章程模板
远景
需求
常见需求：要在某个特定日期到达之时发布某些功能
目标
目标与需求不同，项目并不一定必须交付它的目标
几类目标举例
产品目标也许包括这样一些需求，它们已经被设定好优先级，但是不承诺在当前发布版本中完成。
性能标准之类的目标，对它们的要求会高于一般需求
“在产品交付时，要将未解决缺陷的数目从50个减少到40个”
目团队要解决某些特定的技术债务
“增加产品的自动化冒烟测试所占的百分比”
“减少项目的耗费时间，以提升组织的敏捷性”
成功标准
围绕客户能基于完成的产品做什么给出的定义。成功的标准并不涉及缺陷，而只关注能力
□要包括功能1、2、3，这样我们的产品就可以打入目标市场了。
□要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，并编写新的市场营销材料了。
□客户不需要访问我们的网站，就可以打开安装包、加载软件。
□在第一季度发布。
ROI（投资回报率）估算
小结
□每个项目启动时都要有章程。
□对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。
□要知道“质量”的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。
第2章 规 划 项 目
使项目足以启动的规划
经验式规划
先做少量规划，再根据实际过程中收集到的信息反馈来影响未来的规划，这样做具有很高的可行性。
项目有太多的风险和不确定性，想在一开始就把一切都想好势比登天。从规划开始，每隔几周再重新规划，无论采取何种生命周期管理项目，都得做好反复规划的准备。不要创建完美的规划，只要这个规划在被（很快）替换之前具备可行性就可以了。
开发项目规划模板
产品意图
简单描述产品，为什么公司要开发这个产品，它能为公司带来哪些效益，等等。
借用项目章程的远景
历史记录
说明之前任何已知的技术债务
发布条件
要详细列举出项目产品的关键可交付物。
“要是不那么做，我们还能发布产品吗？”
目标
同项目章程
项目组织
要明确说明团队在项目中的职责分配
日程总览
主要里程碑
如有beta测试或是早期的客户发布版本，要把这些作为里程碑对外说明。
7月1日 项目启动。
7月15日 向露辛达展示Web界面的原型。（待续）
7月30日 向露辛达和厨房职员们展示厨房界面的原型。
8月15日 内部交付Web和厨房界面。
8月30日 向露辛达挑选的5个客户交付早期版本（beta测试）。
9月1日 开始beta测试。
9月30日 结束beta测试。
10月30日 系统上线，包括所有的客户订单和厨房的界面。
以矩阵的方式给出项目团队的不同运作方案
人员配备（人员曲线）
需要多少、何种类型的人员
建议日程
风险列表
至少要将排名前十的风险记录在案
制订发布条件
为产品是否可以发布提供一些客观的评判标准
步骤
(1) 确定当前发布最重要的因素，这样可以将监控发布条件的活动贯穿项目始终。
组织的需要？
客户的需要？
通常
日常安排
功能特性
低缺陷率
(2) 草拟发布条件
发布日期、足够好的软件、一个已经完成测试并由两个客户验证通过的特定功能。
在草拟发布条件时，要在纸面上注明“草案”字样。
举例
□所有代码必须针对所有运行平台编译并构建。
□没有高优先级的bug。
□所有未解决的bug和临时解决方案都要记录在版本发布说明中。
□所有计划好的测试都要运行，要保证通过率至少为90%。
□在最后三周内，未解决缺陷的数目要不断下降。
□在发布之前，功能X要由开发人员完成单元测试，由测试组完成系统测试，由客户A和客户B完成验证。
□准备6月1日发布。
(3) 让发布条件符合SMART原则：确定的、可测量的、可达成的、相关的和可跟踪的
(4) 获得项目团队与高层管理人员认可。
□在发布日期之前，我们是不是必须满足这个条件？
□要是我们不能在发布日期之前满足这个条件，会发生什么？
□如果不能满足这个条件，我们的产品或公司是不是会因此而承担风险？人们的安全感是不是会因此被破坏？
在必要时变更发布条件
要跟团队确认为什么无法满足条件。
向管理层解释无法满足条件的原因。
小结
□项目规划是在不断进行的，这只是开始。
□为项目团队、出资人和项目经理自己制订发布条件，以明确定义“完成”的含义。
□项目规划不必完美无瑕，但是它必须存在。
小结
□项目规划是在不断进行的，这只是开始。
□为项目团队、出资人和项目经理自己制订发布条件，以明确定义“完成”的含义。
□项目规划不必完美无瑕，但是它必须存在。
第3章 使用生命周期组织项目
理解项目生命周期
生命周期是项目经理和团队组织产品开发的方式。定义需求、设计、开发、测试以及与这些工作同时进行的过程
要讲求实效——将风险记在心间，选择的生命周期要有助于识别项目风险，帮助项目经理交付成功的产品。
生命周期类型
顺序式
迭代式
增量式
敏捷
在项目中寻求反馈
了解敏捷生命周期
大规模项目需要组合使用多种生命周期
管理架构风险
尽早实现几个可以考验架构承受能力的功能。我喜欢用不超过三周的时间来实现这些功能。
小结
□在组织项目时，使用任何生命周期或是多种生命周期的组合，都可以让项目踏上成功之路。
□不要怯于创建反映你自己项目实际情况的生命周期。“完美的”生命周期只是模型而已，你是生活在现实世界中的。
□阶段-关卡流程或瀑布式生命周期，只有在确定使用它可以获得成功时才使用，而不是不经思考，上来就用。
第4章 安排项目日程
注重实效的项目日程安排
前期规划活动耗费的时间要尽量少
只要产生的规划足以让项目启动就可以了。用一个小时制订项目章程，再用一个小时完成项目规划，日程安排的草案也用一个小时完成。
项目日程安排技术
1.自顶向下式
2.自底向上
3.由内及外
4.哈德逊湾式启动
5.短期迭代
和团队一起，用黄色便利贴安排项目日程
基于可交付物的规划
按可交付物安排日程，而不是按功能
小结
□用低技术含量的工具开始安排项目日程。如果真地需要相关软件工具，过后再转换数据。要注意不使用“大型可见图表”或“信息辐射器”所带来的成本。
□按可交付物安排日程，而不是按功能。
□要有以迭代的方式安排日程的准备。一次完成的项目时间表，其作用根本无法对得起花在上面的时间。
第5章 估算工作
实用的项目估算方式
1.通过对比历史数据进行估算
2.通过Delphi和宽带Delphi方式进行估算
每个人（小组专家）都写下来自己的任务列表和时间估算，同时注明自己对项目的预设条件
复查，看看哪些任务可以同时进行
把估算时间加在一起，得到项目的整体估算
问题
有可能估算过低
3.何时不应相信团队的估算
4.小心顺序式生命周期的估算陷阱
陷阱：从一开始就估算整个项目
5.使用自信心范围进行估算
6.使用日期范围进行估算
7.使用三个日期：最佳状况、最有可能、“墨菲”日期
8.在估算时分开考虑任务的大小与持续时间
9.规划扑克
10.在估算前用试探性开发收集数据
用里程碑切分项目
用可交付物作为里程碑，不要用与功能相关的活动。
使用基于可交付物的规划来安排任务
将里程碑（或迭代）的结束安排在一周之中的某天
提示：将里程碑（或迭代）的结束安排在一周之中的某天
你们能够不做哪些事情
能够以“不做哪些事情”的方式思考是很重要的特质，以“能做哪些事情”的方式进行管理
有些人身背多个项目时无法估算
团队中有身背多个项目任务的成员，这个项目必然会延迟。而且项目经理都无法预测会晚多久，因为你不知道这些人能在你的项目上投入多少时间，甚至很难知道这些人在项目需要他们的时候，能否真正在场。
多任务会浪费20%到90%的时间
主动安排人们进行多任务
对于项目中只是一时需要的人员，可以让他们以周为单位来切换项目。或者，也许团队成员可以进行结对。项目经理让一对开发人员参与两个项目。
使用波浪式规划
波浪式的规划就是一个持续不断而且很详细的日程安排，只覆盖几周的时间。完成了一周详细工作安排之后，可以再继续安排一周详细的工作。使用四周的波浪式规划，四个星期的详细工作安排就在其中，不多也不少。项目经理也不会浪费时间去规划了解不充分的事情。
决定迭代的持续时间
尽可能使用“小石子”进行估算
用户故事就是“小石子”
小结
□绝对不要提供确定的项目结束日期。
□任务越小，估算起来就越容易。
□寻求估算的准确性，而不是精确性。
第6章 识别和避免日程安排游戏
给我一块石头
当“投资人”希望项目能更快交付，但是不告诉你何时需要或为什么的时候，就会玩“给我一块石头”游戏。
实践
制订排好优先级的产品代办事项列表
逐个实现功能。如果能够让出资人了解更多的项目进程，他们就不会那么纠缠截止日期了。
使用短小的时间盒（持续时间少于四周），这样出资人就可以看清项目进程。如果你每隔几周就能展示出项目的有价值的进展，截止日期就没那么重要了。你可以开始讨论何时实现哪个功能，他们对质量的要求又是什么。
“希望”是我们最重要的策略
拒绝女王
把灰扫到地毯下面
幸福日期
屁股着火
分散注意力
日程等于承诺
项目日程是对于团队何时到达哪个里程碑、何时完成项目的最佳推测。日程安排并不是预言，仅是猜测而已。但是有些项目经理的出资人会将这个猜测视为承诺
项目总是在变换目标
我们必须拥有这个功能，否则就完蛋了
我们不能说“不”
日程小鸡
90%完成状态
我们马上会变得更快
小结
□日程安排游戏总是会发生的。项目经理的工作就是要识别它们，然后管理项目，让项目仍然可以取得成功。
□绝大多数情况下，人们玩这些游戏都不是出于恶意。
□即使没有恶意，日程安排游戏还是会拖项目后腿，使其停滞不前。
第7章 创建出色的项目团队
1.招募需要的人
项目经理也许没有雇佣新人的权力 ，不过项目经理一定要能识别团队需要的人才和技能。
2. 形成团队凝聚力
帮助团队形成一体的最佳方式就是让他们一起工作，而不是去参加什么团队拓展活动。如果大家有同一目标，彼此承诺完成互相依赖的任务，而且采取商定好的工作方式，这就是一个团队。如果希望团队凝结在一起，那么就帮他们制订一些只有共同工作才能完成的短期目标。
好工具让团队有好的发挥
软件配置管理（SCM）
缺陷跟踪系统（DTS）
团队发展的5个阶段
组建期
团队刚刚成形的阶段就是组建期
激荡期
当团队开始共同工作并彼此试探的时候，就进入了激荡期
规范期
一个项目章程中规定好的、令人信服的共识，可以让团队进入规范期
表现期
当大家更加紧密地协作时，团队就能进入表现期
中止期
项目完成，这个团队也就完成了历史使命，进入中止期。
3.让组织配合你的工作
用管理工程的方式来管理项目，可以得到更好的结果
每个职能项目经理领取一些功能或是一系列需求，并使用跨职能团队来完成项目
对必需的团队规模了如指掌
多于6人的团队总是会自动拆成几个小组，但是项目经理一个人最多还是可以管理9个人的团队。
如果团队成员多于9人，根据可交付物，项目经理需要一些技术带头人或是其他项目经理的协助。
如果团队成员多于9人，根据可交付物，项目经理需要一些技术带头人或是其他项目经理的协助。
4.知道何时应该加人
改变人员构成，团队会至少因此退回到振荡期阶段，甚至有可能到组建期。如果雇佣新人，团队的整体工作效率会下降几个月的时间，除非项目经理专门指定一个“伙伴”来辅导新人。
如果项目刚启动，项目经理应该尽快加入需要的人手。每次人员变动都会对团队的工作效率产生影响，所以应该尽量一次性将人员配备整齐，避免成员变更降低工作效率。
如果项目进入到中期，加人就得小心。要记住布鲁克斯的法则：向进度落后的项目中增加人手，只会使进度更加落后。
5.成为出色的项目经理
要想成为出色的项目经理是有要求的：为了与团队一起工作，你要提升人际交往技能；为了了解和管理项目的风险，要提升或维护足够的技术能力。
技能
人际交往技能（非技术素质、偏好和技能）
倾听技能
谈判技能
写作技能
编写计划等
以目标为导向
了解和尊重项目相关的工作人员
能够应对信息不足的状况，并且做出决策
能够管理细节
解决问题的技巧
项目经理要识别出哪些问题当前必须解决，哪些问题可以推迟，以及如何解决问题。
“三种备选方案原则”是说：一种备选方案是陷阱，两种备选方案是两难的困境，提供三种备选方案就可以让相关人员开始考虑真地该怎么做了。
辨别、寻找进度的障碍，并消除它们
功能性（技术）技能
对于项目中的问题以及如何解决这些问题，项目经理不需要知道二者的具体技术细节，但是如果一点都不了解问题和解决方案的专业知识，项目经理就很难做出好的决策。
不懂技术的项目经理，不要试图遮掩自己技术上的不足。要敢于承认自己的不足，雇佣聪明的人，而且可以在了解项目的技术点时咨询这些聪明人。如果项目经理能够坦诚表明自己的弱点，并表示出学习的意愿，团队是愿意帮你成功的。
理解不同的生命周期模型，知道哪一种最适合你的项目。
能够安排项目的日程规划。
清楚如何度量项目状态，以及如何报告项目状态。
知道如何处理已完成和未完成的工作，可以使用速度图表或是挣值。如果没有上面这两种度量方式，要能理解软件配置管理系统中的数据和代码的状态。
领域专业知识
工具和技术上的专业知识
6.知道何时该全身而退
小结
□项目风险越大，团队的多样化程度就应该越高。
□提升多方面的技能：人际交往技能、功能性技能、领域技能，还有非技术技能。
□知道何时应该离开。
第8章 掌 控 项 目
掌控项目的节奏
打断项目正常节奏的常见问题
□不知道先要完成哪些需求。
□允许项目的需求收集阶段持续过长时间。
□允许GUI随时发生变化，而GUI相关人员在项目中不知该如何是好。
□没有架构的整体描述，不知道各个部分如何构成。
□无法及时向项目中加入必要的人员，使得他们很难取得成功。
举行中途回顾
为需求排序
问题
项目中有太多的高优先级需求，以至于中优先级的需求根本无暇顾及，更甭提优先级低的需求了。这一大堆的高优先级需求也根本无法区分先做哪个。
给需求排序吧。从1开始，为每个需求分配唯一的数字。这样人们就能了解团队会什么时候处理哪些需求了。即使不按照功能逐个实现，你也可以按照排序的顺序来实现功能。
方法
建立评估条件
□功能对架构的影响。
□估算的实现时间。
□该功能对于特别重要的客户的重要性。
□特定人员实现或测试该功能的可行性。
用时间盒限定需求相关的工作
如果项目中必须有明确的需求阶段，就用时间盒限制它。否则，需求分析和定义过程就有可能占用整个项目的时间。
将迭代限制在4周或是更少的时间内
如果迭代效果不好，提示：用一分为二的方式减少迭代持续时间
使用波浪式的规划和日程安排
创建跨职能团队
跨职能团队的工作效率更高
跨职能团队具有多样性
根据项目的风险选择生命周期模型
保持合理的工作时间
使用“小石子”
管理干扰
管理缺陷，从项目初就开始
“项目当时累积的缺陷使得我们无法达成最初2个月的截止期限”
在项目进行过程中，很多团队对缺陷都采取放任自流的态度。直到项目快结束了，他们才会认真考虑如何管理缺陷。
如何影响别人
记住问题不是你一个人的。项目经理有时会认为自己必须提供所有的建议和解决方案。并非如此。在项目中，发布日期、功能集合、缺陷水平，每个人都对这些有责任。不要认为一个问题就是你自己的。你有责任让团队解决问题，而不是强令他们如何解决。
思考你能为组织带来的价值。一旦明白了自己的价值，你就可以想想这些价值对于别人的意义了
发现其他人或团队的驱动力
建议项目经理和负责的人（或团队）共同面对问题。这可以让项目经理能够友善、开放地接受他人的建议和想法。
倾听团队。团队会告诉项目经理他们要怎么样才能达到最高的工作效率。
在讨论时，给他人思考的时间。在推行你自己的想法时，要允许别人认真思考和质疑这些想法。有些人可能需要多一点时间来提供有价值的反馈。
不要固执己见。如果你借助影响力，以协作方式工作，别人就能改善你提出的解决方案。
小结
□作为项目经理，你要带头考虑使用或调整哪些管理实践。
□评估项目的问题，然后根据这些问题来判断使用或调整哪些实践。
□要寻找可以建立和维持项目节奏的实践。
0 条评论
下一页
