项目管理修炼之道
第六章 识别和避免日程安排游戏
出资人不会认同你提出来的每一个截止日期－你的日期总是离他们的期望值很遥远。可以准备一些问题：
－你喜欢短的日程，还是长的日程？是要更多的人，还是更少的人？要是少实现几个功能会如何？先知道什么是最重要的，这会帮项目经理产生更加合理的解决方案，多少也能为你的谈判做些准备。
－找出是什么原因促成了他们期望的截止日期。探寻出项目的战略原因，并搞清楚“成功”的真正含义
－要让出资人明白你做出的选择以及背后的原因。也许出资人会有更容易操作、更快实现的好主意
－为你提供的日期说明信心范围。
－在提供日期时要说明发布条件，了解他们对于发布版本的质量和功能要求
考虑一些常见实践：制订排好优先级的产品待办事项列表、逐个实现功能、使用短时间盒（持续时间少于四周）让出资人看清项目进程，每隔几周就显示出项目有价值的进展
仅靠希望，不足以交付一个成功的项目。常见策略：识别风险并记录下来，来自技术或者日程安排；不到万不得已不选择瀑布式生命周期，前期计划时间太长；让团队通过试验“哈德逊湾式启动”了解要做的东西，揭示一些目前尚未发现的风险；确保大家具备相关的技术能力，解决问题必备的领域知识，有必要可以进行培训；考虑所有工作都采取迭代的方式进行，特别是项目规划和日程安排；缺少经验和专业知识可以寻求的帮助和信息－跟团队成员一起商量如何能让别人了解他们的工作进展；制定里程碑条件，管理层复审，按里程碑周期性审查项目进度
计划、计划再计划，使用时间盒限制迭代，使用速度图展示项目进度
拒绝女王：找出你的经理拒绝原因【尝试无关问题理解原因】、写下项目的风险及其潜在影响【高中低】、展示你所能做的事情，比你测量团队在项目中的实际开发速度、保证参与项目工作的每个人都有相关领域知识
让管理层看到现实，项目经理要确保自己有部分部分可工作的产品、可以展示的数据，让管理层可跟你讨论接下来能做些什么，“哪些不能做”。
时间盒迭代和制订优先级产品待办事项，按照业务价值从高到低实现。
建设性讨论（冲突）可以让组织更坚强，避免冲突和必要的讨论只会让组织变得更孱弱
当管理层害怕或无法一次将精力集中在一件事情之上时，就会发生屁股着火：技术人员过去就曾延迟交付、公司没有战略规划、战略规划未拆解到足够详细
采取行动：按小时间盒进行规划，每个迭代边界开始新工作，达到该目的迭代必须足够短；无法管理迭代则按功能逐个实现阶段式交付；采取策略成本告诉管理层，让他们选择解决时间上的危机，还是要付出经过计算的额外成本；策略确定后，帮助公司检查相应的具体措施；调整估算方法，让团队更容易达到最初的估算日期；项目启动时就要知道是否存在导致项目推迟的原因。
分散注意力：多项目多任务。采取行动：非要如此，一周一迭代，关注当前周，短期内开发小批量任务；无法迭代则按阶段交付方式；让管理层在时间上的危机和付出额外的成本之间进行权衡；确保需求优先级排定，而且可以赶紧完成一些工作。
集中注意力是将所有精力都放在一件事情上
日程安排只是估计而已，不过是大概猜测罢了。讨论项目截止日期之前，考虑背后的驱动因素、约束和浮动因素，哪些功能需要交付，质量标准。信心水平，不同信心水平下会做的事情。
交付日期渐进法，迭代优先级确保最重要的需求已实现，带有日期估算的自信心水平。
到了之后，我们会知道身处何方：确定已经有书面的项目愿景、项目目标和发布条件，达成共识，项目经理知道未来方向、剩余工作和何时就算成功；项目经理帮助管理层定义愿景，完成后公布坚守这个目标；迭代，持续评估项目进度。
项目要有清晰明确的目标，整个项目团队要把精力都放在这些目标上。
日程安排工具总是对的，决策层都是看到过去的报表。日程安排只是猜测，制定波浪式规划、低技术含量日程安排技术、提供带有信心水平的估算、测量开发进度
我们必须拥有这个功能，否则就完蛋了：日程不变。可能做法：要求改变集合、要求更多时间、要求更多资金。发布列车，项目经理的职责是让团队成员认识现实。
我们不能说“不”：询问团队成员，看他们能否针对添加额外的功能制订计划；想加班建议用时间盒限制加班时间并衡量加班结果；可以加入额外的人力来做更多工作。都不起作用，就要帮助团队说“不”，用数据来抵消团队的内疚或反驳完成公司要求的渴望。
日程小鸡：每个人都说自己在按日程安排进行，而实际情况却是没有一个人做到，除非已经太晚了。讲究失效的项目经理会做如下选择：避免逐个进行的状态报告会议；将任务分解成更小部分，每天交付一块，最多两块任务；按功能逐个实现，定期集成。
帮助团队看到真正的进度：与团队成员讨论进展速度－收集数据；测量估算质量因子；测量团队所做的每件事情【确保全力投入，交付必要任务】；涉及硬件组件要衡量其挣值；三个迭代开发速度才能相对稳定。
令人恍惚的日程【面对不可改变的日程、一系列充满野心或不可能实现的功能集合】：项目仪表盘【迭代式开发，迭代越短越好，每周调整优先级，“完成”定义】；每个迭代集中精力，团队目标放在必须完成的工作；如果没准备好就按功能逐个实现。
“游击式敏捷”：不超过四周的时间盒，按功能逐个实现，按进度集成，并测量进展速度
铭记在心
日程安排游戏总是会发生的。项目经理的工作就是要识别它们，然后管理项目，让项目仍然可以取得成功。
绝大多数情况下，人们玩这些游戏都不出于善意。
即使没有恶意，日程安排游戏还是会拖项目后腿，使其停滞不前。
第七章 创建出色的项目团队
首先要招聘或引进所需要的人才，其次要发挥他们的能力一起工作，成为高效的团队。团队角色：架构师、开发人员、测试人员、技术文案、业务分析师、发布工程师、项目经理。每个项目都要有能够胜任工作的人，不管他们是一个人担任多个角色还是怎样。墨菲定律：越担心某件事情发生，某件事情越会发生。
帮助团队融为一体最佳方式就是让他们一起工作，而不是去参加拓展活动。目标一致，彼此承诺互相依赖的任务，商量好工作方式－团队会议特地留出时间让大家共同解决问题。
好工具让团队有更好的发挥，工具本身并不能解决问题，但配置管理（共享代码，代码分支，打标签，自动合并多个作者，个人沙箱）和缺陷跟踪系统（缺陷，优先级，严重程度，状态，持续时间，分类）可以带来很多好处。
团队发展阶段：组建期、激荡期（共同工作彼此试探）、规范期（行为一致）、表现期（协作）、结束期。若在一个项目章程中规定好的、令人信服的共识，可以让团队进入规范期。将所在团队项目经理看做自己人，可以协同工作。项目经理可以促进团队经过这些阶段，但必须花时间留意项目的风险和问题，并与团队成员不断沟通。
让组织配合你的工作，每个团队成员对职能团队负责，同时对项目团队负责。让职能经理参与项目，让成员知道分配的是项目任务－项目经理必须具备谈判和说服技巧，管理矩阵式项目团队，谁负责给团队成员反馈和指导。项目经理要承担责任，职能经理关注职业发展。
以项目经理的方式管理职能团队：说服同事用管理工程的方式来管理项目，跨职能团队组成，总体项目经理，提供有价值的反馈。你的下属项目经理和技术带头人必须知道如何给出有效的反馈和指导。
对必需的团队规模了如指掌：项目经理一个人最多可以管理9个人的团队。超过9人需要技术负责人协助。要是项目真的对组织很重要，你就有权做任何需要做的事情（你要有勇气、有信心），看看项目组合，找一个重要的项目吧，政治很重要，提前积累并发挥影响力。
作为项目经理，你有责任树立权威，而不是等着别人给你权威。
项目启动后再加入更多人，项目会花费更多时间。改变人员构成，团队会退回到震荡阶段，指定伙伴指导新人。项目启动时加人且尽量人员一次性配备齐全。只有在项目延迟已不可避免，而且当前人手也无法完成项目情况下增加需要的人吧，然后重新规划。
成为出色的项目经理
提升人际交往技能与团队一起工作，提升或维护足够的技术能力了解和管理项目风险。掌控项目的能力，观察项目目前是状况，和方向与规划有何不同，并引导项目进入新的状态。
提升人际交往技能：倾听技能、谈判技能、写作技能、以目标为导向、了解和尊重项目相关的工作人员【必须能够看出别人什么时候陷入困境，什么时候出现了问题，什么时候一切正常运转】、能够应对信息不足的状况，并做出决策、能够管理细节、解决问题的技巧【当前必须解决，哪些可以推迟，以及如何解决问题－三种备选方案原则：陷阱+两难困境】、辨别寻找进度的障碍，比你消除它们
提升功能性技能：项目中的问题及如何解决这些问题，项目经理不需要知道二者都具体技术细节。但需要了解一些才能做出更好的决策；要敢于承认自己的不足，雇佣聪明的人，咨询他们。坦诚，愿意学习，团队会帮助你成功的；理解不同生命周期模型，知道哪种最适合；能够安排项目的日程规划；能够估算任务，或指导其他人完成任务估算；知道如何评估管理风险；清楚如何度量项目状态，以及如何报告状态；如何处理已完成工作和未完成工作，衡量挣值或进度图表。
提升领域专业知识技能：需求/设计/技术和日程风险/配置管理/测试/审计/产品和工具知识。了解开发用到的技术如何帮助客户解决问题，用到的流程以了解项目风险。问题空间域的专业知识是指要理解项目要解决的难题，理解系统如何利用解决方案来解决项目的问题。
提升工具和技术的专业知识：让工具符合自己的要求。
知道何时该全身而退：知道什么样的组织、团队和产品不适合自己。接受目前的情况并心中有数？转换到组织中的其他项目？改变所处的组织？
什么样的组织不适合你
不能选择团队成员、所有的项目在启动时都面临资源不足、你总是听见人们说“你没法融入团队”
什么样的团队不适合你
对管理项目需要的信息了解不足。不知道团队如何工作，以及项目试图解决的问题。
你的管理层非要给团队施加帮助，可你无法拒绝。敢于做团队的挡箭牌，让管理层“帮助”落在你身上，而不是团队。
对管理项目需要的信息了解过多。如果你不能放下架构和设计等技术工作，移出障碍、管理风险。
什么样的产品不适合你
团队中没有具备足够的技术深度，没人了解技术上的风险。敏捷生命周期+短迭代，原型化工作还是按功能逐个实现，知道团队是否交付了真正有用的东西。
铭记在心
项目风险越大，团队的多样化程度就应该越高
提升多方面的技能：人际关系、功能性、领域还有非技术功能
知道何时应该离开
第八章 掌控项目
项目仪表盘，定性或定量都需要反映项目的真实状态。寻找和管理风险－任何扰乱节奏的都是已出现风险，任何可能扰乱节奏的事情就是潜在风险。积极管理风险，保证项目不会偏离正确的轨道。
掌控项目节奏：建立和维持合理的节奏。打断项目正常节奏的问题包括－不知道先要完成哪些需求、允许项目的需求收集阶段持续过长时间、允许GUI随时发生变化、没有架构整体描述、无法及时向项目中加入必要的人员。
举行中途回顾：了解项目中发生了什么，同时为未来项目做规划。可以过程中或结束时举办回顾。
为需求排序：所有需求收集到一个地方，知道先实现哪个，后实现哪个。给需求排序，从1开始分配唯一的数字。两个需求对比，温柔而坚决地方式说明只能有一个第1位的需求；明确需求价值，按评判标准排定优先级－通过“头脑风暴”产生一系列可能条件、将相似的条件分为一组、为每组分配一个分类名称。作者用过的一些条件【功能对架构的影响、估算的实现时间、该功能对特别重要客户的重要性、特定人员实现或测试该功能的可行性】，每个条件分配一定权重；制定并维护不断变化的需求日志－产品待办事项列表【季度日志】
用时间盒限定需求相关的工作：如果项目中有明确的需求阶段，就用时间盒限制它。可以选择合理很短的时间段（不超过项目总体持续时间的10%，收集到最重要的需求－风险在最重要的需求不一定能够确定最终的架构）、用时间盒限制所有需求定义活动【用一分为二的方式减少迭代持续时间：快速发现问题，着手移出障碍】
将迭代限制在4周或更少的时间：迭代时间越长，项目的节奏越难保持。更频繁反馈，让问题暴露得更明显，着手解决问题。
使用波浪式规划和日程安排：每次规划少量的工作，这让我更具有灵活性。顺序式生命周期有严格关卡，迭代式规划，先定义出里程碑，每个里程碑的含义，设置验收条件。不要试图规划所有的工作，只规划未来3-4周的工作，每个人知道接下来要做什么，后续几周要完成哪些任务。
项目经理需要监控项目进度，牢记里程碑验收条件。若后续阶段所花费时间超出预期，就存在技术债务的警讯。将重新规划活动放到项目日程安排中，为迭代式、增量式和敏捷生命周期进行重新规划。
迭代式日程安排主要适合【你知道要做什么，却不知道应该怎么做的时候；面临时间压力，而且希望利用项目现有进展时】
创建跨职能团队：为自己团队配备几种不通角色的人员，跨职能团队，实现全部功能；具有多样性，可测试性&需求澄清&参与验收
根据项目风险选择生命周期模型：早日决定采取何种模型，要三思而后行，若不能确定不妨采用敏捷生命周期，具有最大限度的灵活性。
保持合理工作时间：人们每天最多只能完成6个小时的技术工作，较短时间1-2周可以每天多干1-2小时。长时间加班会扰乱一个人每天的节奏。
使用“小石头”：每个任务拆成“小石子”（甚至探索式开发），时间盒方式，每天每人要有所交付。如果人们直到最后一刻－有时甚至已经超过这个时刻－才开始某个任务的工作，这就发生了“学生综合症”。
管理干扰：罗列出来一周发生的干扰并评估影响，以事实为依据。干扰会导致人们多达40%的时间。有两种类型的干扰【其他项目干扰－迭代结束后？和其他人－结对编程？作战室？】
如何影响别人
管理缺陷，从项目初就开始：技术债务日常化，缺陷分类，严重性【技术层面】和优先级【业务层面】要分清楚。包括的字段【缺陷编号、简要描述、优先级、严重程度、暴露程度、何时修复】
如果运营与开发同时进行，我该如何应对干扰？
－调出几个开发人员，用1-2周的时间专门负责运营工作，运营期间调换人员
－假定每个人每周只能用2—3天进行开发，其余时间都用来处理突发任务，每个人一天之内不能从事多个任务
－加入更多人手，这些人“喜欢”灭火，解决突发问题，接下来是项目任务
－成绩负责运营的小组
－使用迭代，相对大小和持续时间估算，加入产品待办事项列表
铭记在心
作为项目经理，你要带头考虑使用或调整哪些管理实践
评估项目问题，根据问题来判断使用或调整哪些实践
要寻找可以建立和维持项目节奏的实践
第九章 保持项目节奏
项目经理不但要管理实践掌控项目，还可以鼓励团队改变自己的技术实践，从而获得更大收益。
在项目中使用持续集成
让开发人员马上得到反馈，每天有所收获，任务拆解，小步快跑，尽早识别项目的集成风险。
阶段式签入，周或月签入，会打断人们的思路，不得不记住很多小细节。
频繁构建是为开发人员和项目经理准备的。最新（主代码库拉分支）和最全代码版本库进行开发，而且他们一直都在持续集成。
为构建创建自动化测试
冒烟测试仅仅是为了验证要构建的版本没有问题。让构建版本正常工作，能够第一时间发现构建版本出现问题，也能帮助项目经理将项目带回正常的节奏。
按功能实现，而不是按架构
完成功能才算有价值。首先实现需求价值最高的需求，把风险最高的功能往后放一放。功能的价值和完成度越高，就能为自己和团队带来更多灵活性－推迟高风险低价值的功能，可以保持项目的节奏，并降低当前版本的风险。
按功能调试（跨组织架构团队），按功能测试。硬件团队完成设计时，要准备对原型进行迭代（记住，这不是最终代码）。尽量减少软硬件交互接口部分，需要调试部分就减少了，出现缺陷可以很快找到源头。
多几只眼睛盯着产品：邀请团队互相检查工作，结对编程（允许大家这么做，先学习相关资源，反馈最及时）、伙伴复查、同行复查（只能复查风格，反馈时间长达一周）、走查（集中会议说明）、正式代码（长久维持很难，准备时间长）检查都行，从不正式到正式。
准备重构：对代码的简化，不会改变它的契约，只是更简单。可以让重构和开发同时进行，也可以最后进行重构。
通过用例、用户故事、角色和场景来定义需求：减少不必要代码的一个好方法－想想谁会使用系统，又该如何开发用户需要的系统
需求收集应该为团队提供上下文，说明一个人如何使用系统，以及一个功能在何种场景下必须运行。如果需求以功能性和非功能性需求方式罗列，可以问一些更好的问题，从而深入了解需求。
分离需求与GUI设计：页面是设计，不是需求
尽可能使用低保真度的原型：低保真度人们会更全面评估要解决的问题，高保真会限制反馈。
铭记在心
项目经理可以邀请团队成员考虑这些实践，不过你不能强迫他们采纳这些实践
如果项目经理即使尽全力也只能选择一个实践，推荐选择持续集成
项目经理采纳和调整的实践要有助于保持项目节奏，允许项目提高启动和结束的速度
网友评论