第十章 管理会议
不要在会议之间穿梭，要判断哪些会议值得你花时间，哪些会议浪费时间（找到并取消之）。你必须知道要召开哪些会议、参加哪些会议、派代表替你参加哪些会议，以及－最重要的－忽略哪些会议。
保护团队不受外界干扰和影响，可以帮助团队不参加不必要的会议。允许团队成员不参与无法贡献和收获价值的会议。要跟团队强调，你不让他们参会是因为他们太重要了。
项目经理要避免让团队成员参加毫无效率的会议，同时也要记得自己不去参加这些会议－参会过程中根本没有听别人在讲什么，自己也没有做出贡献，那你就对不起付给你的那份工钱。
下次开会的时候，你可以看看周围的人，计算下这个会议的成本。包括会前准备和会后再投入各自工作。
避免不需要你解决问题的会议：不需要你参与决策或解决问题，这样的会议就不必参加－可以鼓足勇气，表明自己要与项目为伴，你希望看到会议记录，但不必亲自到场。
绝对不要举行多人参加的顺序式进度报告会议：注重形式？如果团队会议不能解决任何问题，这个会议就在拖项目后腿。赶紧停止吧，重新规划相关会议。
避免这些会议：没有存在理由的会议【会议最早负责人早已离开原来职位】、没有会后行动的会议、上层主管的顺序式进度报告会议【用电子邮件告知别人你的工作进度】、任何不允许携带笔记本电脑的会议【跟会议负责人单独碰面，说明你需要用笔记本解决问题】
举行下列会议：项目启动会议【跟大家一起确定项目章程】、发布版本规划会议【每个迭代待办事项列表，完成的定义，可能的发布日期】、向高层报告进度的会议、项目团队会议、迭代回顾会议、项目回顾会议
团队进度报告不一定需要，可以采用每日站立会议【15分钟足以，团队任务足够小，拆成1-2天任务－建议直接向项目经理报告的人数不超过6个，带头人每天一碰】，每周一对一会议【顺序迭代或增量式生命周期每周一对一，验证项目状态，矩阵一对一关注项目进度，职业发展职能经理】，每周电子邮件进度报告。
一对一形式－问候（关闭手机离开电脑）、讨论进度和状态（复查小石子任务完成状况－如何制定“小石子”任务，尽量可见的方式表示项目进度）、讨论他们的障碍（帮助认识到他们面临的障碍）、复查所有行动计划（自己的和对方的－做笔记记录后续行动计划和眼前问题）。
以可见的方式了解进度。项目经理必须知道人们在不断取得工作进展。说明为什么需要信息，以及需要什么级别的信息，那么大多数团队成员都会愿意跟你合作。让人们注意自己何时陷入困境，然后告诉项目经理他们是否需要某些帮助。请求帮忙并不丢人，独自挣扎是不合适的。
项目仪表盘，电子邮件进度报告模板：工作成果【几段简短的话】、未来里程碑【任务描述、规划完成日期、预计完成日期、实际完成日期－变更的外部事件导致工作内容变化】、障碍【解决办法】
每周向团队报告进度：邮件告知，周报告汇总但不要提咱们所说的障碍。说明项目仪表盘的位置以及其中数字的含义，让大家专心于最终目标对中途里程碑有所注意。敏捷可以不用，但也可以发出。
向管理层报告进度：项目仪表盘，工作成果列表，中间阶段里程碑。仪表盘里的所有提供详细数据。最佳做法就是整理数据，并准备跟主管一起讨论。
项目团队会议：解决问题的会议，有会议提纲，确保这些提纲为解决某个问题，或阻止某个问题发生。
会议提纲【标题行、期望与会人员、主要里程碑检查（预计讨论时间）、本周遇到的问题、现有障碍？其他话题？回顾以往行动计划、下次会议、未决事项/停车位（不想忘记不急于解决的事情）】，可提前结束，会后给每个人发送行动计划。
迭代审查会议：展示工作成果，随工作推进不断审视并调整工作方式。团队开发速度图表，中期回顾总结经验教训
会议疑难问题解答：每日站立会议超过15分钟、确保人们报告已经完成的工作；没人能够及时参会【大家商量开会时间，组织层面一个人做所有决策，24小时会前发送提纲，会后24小时发送含行动计划的会议记录】、没人能在下次会议前完成各自负责的行动计划【每项行动负责人和截止日期，提前发会议提纲】、与项目无关的人希望参加团队会议【寻找参会原因，可以帮助优先级，保护团队不受外界干扰是项目经理职责所在，观察员角色】
管理与远程团队的电话会议
一些尝试：一次只允许一个人说话，吃东西不允许发出声音
事先规划+引导会议
按话题组织提纲。一个话题讨论完毕，要跟大家确认
要知道，想通过电话会议完全听懂非本国口音的发言是很困难的
确保人们发言在电话会议中不会被打断
要在会议进行到一半和结束时进行总结
电话会议结束时，列出行动计划
明确宣布会议的结束
会议结束后，一定要给所有参与者发送会议中的决策、会后的行动计划，并以此作为跟进；确保自己知道电话会议何时真正结束，检查扬声电话尚未关闭。
铭记在心
你可以判断一次会议对你是否有价值，是否值得花费你或者任何团队成员的时间
要向逃避瘟疫一样，逃避顺序式进度报告会议
观察会议进程，看是不是能够满足每名参会者的需要
第十一章 创建并使用项目仪表盘
要想真正掌握一个项目，关键在于经常测量，包括定性和定量两种方式。仪表盘的目标是为使用数据评估项目状态，而不是花时间创建仪表盘。
测量项目回面临三个大问题：项目团队花费过多时间进行测量，从而影响正常工作；人们不认真对待测量；测量人，而不是项目。
要确保存在多种测量方式以评估项目的真正进度，多纬度测量。选择测量方法时，要确保以项目和产品为测量对象，而不是对准人。
使用项目驱动因素、约束和浮动因素排列组合6个纬度，至少使用4个纬度进行测量，这4个纬度涵盖了项目经理最有可能修改的项目因素。
使用项目完成度来衡量进度
团队预先估算准确性和团队已完成的进度，决定项目完成度。仅从时间表衡量还不够完善，准确衡量判断项目实际进度，应该衡量团队已完成多少功能、已完成功能的质量以及还剩多少功能尚未完成。
跟踪功能或任务小石子，不仅要询问团队成员是否达成他们的里程碑，还要记得检查已完成工作的质量。
如果项目经理只能绘制一个图表，应该选择速度图（需求，已完成工作，时间）。
除跟踪已完成工作外，还需要详细了解每个迭代的工作进展。
挣值可以用来衡量已完成工作，不断变化的软件让真正的挣值计算几乎不可能。精益社区中部分完成的工作被称为“浪费”，速度图展示已完成的工作。完成百分比通常只包含开发工作，未将测试涵盖在内。用速度图取代挣值（速度图能够揭示团队的真实进度，而不是计划进度。能够展示项目发生的变化以及正在发生的变化数目）。
Estimation Quality Factor，EQF使项目经理了解最初的估算质量。每隔一段时间，项目团队就要回答这个问题“你们认为项目什么时候可以完成？”团队就项目预期时间达成一致
日程估算只是猜测而已，如果可以显示出实际进度与初始规划的差距，并解释其背后的原因，对希望知道目前实际进度的人来说很有帮助。
技术负责人一定希望尽早得到项目日程可能不准确的警告信号－更多的度量能提供更多信息：除EQF外的日程估算与实际值－使用速度图会部分体现该数据；（有适当能力的）人加入团队的时间以及实际需要他们的时间；项目过程中需求变化的情况；故障反馈率；缺陷修复成本；缺陷发现/关闭/未关闭的比率。
失去的时间永远无法恢复
度量项目日程：计划里程碑，实际里程碑，基于实际启动时间的里程碑
资源不足的情况下启动项目比较常见。先是小团队启动，后期加入新成员可以，但需要整体计划。
如果启动一个人手不足的项目，这就等于自寻烦恼。计划人员vs.实际人员
判断项目变化率：单个模块微小变更多个模块重大变更
用数据说话，尤其是项目后期看到重大需求变更时，解释可能会延期，或缺陷数目可能增加。
故障反馈率：FFR没有真正解决问题的缺陷数目与修复缺陷总数比较，超过10%说明开发遇到问题。
测量FFR可以每周一次，并可与开发人员和测试人员讨论该数据。若某周FFR很高，先检查这一周修复缺陷总数。某一团队连续两周保持高FFR，考虑同行检查。“修复时是否其他地方出现问题？”“能否确定发生该问题的所有条件”。
测量查找和修复问题的成本
一般来说，越在项目前期，查找修复成本越低。重要的不是每个缺陷的成本，而是每个缺陷成本乘以缺陷总数。
很多缺陷都是在测试中发现并不是好事，积极主动方式寻找缺陷方式更好。寻找模式，实施测试驱动开发或结对编程，同行代码检查－修复一个缺陷的总成本越高，项目经理就越有必要管理缺陷相关的风险。
开发人员修复一个问题时间越久，他们就越可能不敢触碰系统的某些部分，因为对系统某些部分不了解；测试人员找到问题所用时间越久，他们就对产品了解得越少，或者他们测试产品的手段越匮乏。
了解开发人员和测试人员是否在解决缺陷方面取得进展
测量缺陷趋势，作者最看重三个指标：每周发现的新缺陷数、每周关闭的缺陷数、每周仍未关闭的缺陷数。作者图上未标明缺陷优先级（避免缺陷提升和降级的游戏），必须把所有缺陷从头看到尾。
缺陷关闭率vs.缺陷发现率，尚未关闭的缺陷数目曲线斜率可以看到这一点
展示测试过程
测试进度图，将测试和开发结合在一起。规划的测试数目，需要运行的测试数目，运行通过的测试数目。
针对较长的迭代或顺序式生命周期，试图解释算法研究、性能场景和测试等工作进度。
用图表展示团队同意采用的实践
移出团队实践过程中的某些障碍，项目经理帮助团队移出障碍。团队说明问题，一起解决问题。
团队实践图可以让开发团队开放讨论他们选择的实践，收到哪些成效、哪些运转不畅。项目经理要知道如何看图、如何帮助团队发现问题根源，如何跟团队一起解决问题。
度量敏捷项目，同一个迭代所有分配给项目的人员不会被重新分配工作；可以完成迭代工作并修复迭代中缺陷，也许使用速度图、测试进度图和迭代内容图就可以了。
为出资人创建项目仪表盘
展示项目风险列表：列出所有可能阻止项目团队达成项目驱动因素、约束和项目因素的事物。
展示在满足发布条件方面取得的进展：比如可靠性条件，所有在线帮助等。
使用项目气象报告
有些情况下，出资人或管理层希望每天了解项目的进展－微管理，人们只有在没有数据或不理解数据的时候才会选择微管理。高级管理层会从较高层面思考问题，而不会深入过多细节。微管理，可以使用“项目仪表盘+平衡计分卡”相结合。
项目气象报告会评估对比项目的当前状态和它的应有状态。交通灯模型可能不一定能完全展现差别。
气象报告模型评估项目数据，以预测项目进度。需要建立可信的气象报告，包括日程相关数据、速度图、缺陷趋势、测试覆盖率、人员分配、风险列表等，气象报告就是整体状况评估的最佳方式。
气象报告的目标是帮助人们了解项目评估状态，不让他们感到意外。多于两个月剩余时间项目应该每周发布气象报告。项目状态快速改变的时间点气象报告可以发布多次。
铭记在心
使用速度图和迭代内容图作为首选
数据是工具，不是目的。要记住，图表应该为你服务
如果无法获取需要的数据，项目经理就遇到了比数据更严重的问题。先解决这个问题吧
第十二章 管理多地点项目
一个问题成本是多少？如果你是项目经理，要尽你所能让整个团队坐在一起
识别项目的文化差异？可以讨论哪些话题，给予哪些奖励，人们对待彼此的方式。项目经理需要准备各种文化冲突。整个项目不一定要使用同样的生命周期模型、开发手段和具体实践，但整个项目团队必须使用互补的生命周期，手段和实践。
在团队间培养信任：帮助每个团队制定承诺目标，定义可交付物。确保每个地点都有完整的项目可交付物、确保团队可以彼此互相合作，帮助人们互相接触。
要保证每个地点都有一个完整跨职能团队，他们交付相对完整的功能，而且必须通过测试、可以顺利运行的功能。如果实在不行，就得想办法保证每个人跟团队其他人能够紧密接触－逻辑意义上的紧密联系，哪怕微信
要确保多地点团队有同样的目标－以项目或工程为重，绝不要让他们彼此竞争。
让人们建立个人接触，一起工作一段时间或社交场合。无法所有人，则让项目经理和技术带头人聚到一块儿，人越多越好。定期互访，项目经理应该定期访问各个地点，呆上一段时间。每个地点主持会议并让人们见到我。
在团队间使用互补实践：若实在无法要求人们以特定方式工作，那就要求结果吧。多地点不要使用顺序生命周期，需要同时掌控发布时间、功能集合和缺陷水平。不能联合使用迭代和增量式开发，至少需要迭代。多站点开发测试需要尽快得到反馈。
详细说明每个团队一起里程碑和可交付物：说明每个词汇的含义（修复、验证、冻结、完成等）；详细说明里程碑的含义（相同理解，可以有临时的过渡性里程碑）；详细说明团队了解自己工作进度的方法（以结果为重，而不是方式方法或具体实践－使用回顾帮助人们反思实践，但不强制）；详细说明团队如何评审工作产品（可额外沟通框架和上下文，评审规划日程表等，鼓励评审工作产品－正式评审需求和架构，了解目标，至少技术代表参加，重点评审接口而不是实现－电话会议&视频会议）
寻找潜在多地点项目和不同文化导致的问题
不同地点团队里程碑和交付物定义不同，对承诺理解不同，可以通过一些开发实践解决
进度沟通和报告不一致，项目初期，因为看不到其他人做什么，容易丧失信任
语言差异，二义性，流利，听力，书面和口头，文化
节假日，假期和加班。每个人理解当天结束不一样，通用工具使用水平不同
需要中途回顾，无法召集所有人，每个地点回顾活动
使用外包需要避免如下错误
训练外包相关负责人员、挑选厂商、选取最好的项目经理、与接包方管理层或项目经理保持信任关系、规划调整内部职员工作时间、用文档记录需求、制定适当的变更流程、选择需求相对稳定的项目外包、为每个项目规划更长时间和更多资金预算，尤其是初期、坚持接受方不变更团队、确保合适的工具信息系统和流程、验证他们的工作
铭记在心
如果团队没有分布在同一层楼10米之内，就是一个多地点团队
相对于管理坐在一起的团队，管理多地点团队要花费更多时间，还需要更多的项目推进技能
如果项目经理无法构建起与远程团队的信任关系，项目不可能成功