项目管理修炼之道
第一章 启动项目（是项目就会有风险）
多做一些组织和规划的工作，项目就多一分成功的希望。项目经理必须知道项目关键驱动因素是什么、项目要怎么样才算“完成”，而且还得把这些结论写到章程中，让整个项目团队都能了如指掌。
项目：一个独特的任务或系统化的流程，其目的是创建新的产品或服务，产品和服务交付完成标志着项目的结束。项目都有风险（不同团队具体风险不尽相同），并且受制于有限的资源。
项目经理负责管理风险和资源。每个项目都是独一无二的，项目经理要根据每个项目不同的实际情况，进行管理和规划。启动前，要着手收集信息，了解项目要实现哪些目标
产品：项目产生的一系列可交付物。
成功项目经理应该花些时间来发现当前项目的独特之处。这样你就有可能成功地启动、管理和结束项目。
项目经理：负责向团队清晰说明“完成”的含义，并带领团队完成项目的人。完成（暗含风险，风险总是伴随着我们），是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。在采取任何进一步行动之前，项目经理必须理解项目的关键驱动因素是什么。
需要首先了解项目背景，项目的背景是由所在组织的关键因素决定，当前项目驱动因素与上一个不同。项目的驱动因素是什么？是否存在约束？有没有可能在驱动因素和约束之间进行折衷？项目经理能否为自己争取更多的自由运作空间？
首先，要写下客户的期望－客户角度，项目的驱动因素是什么。这个列表应该包括：客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）。
接下来，写下项目的约束。环境是怎样？能否灵活安排团队的位置？必须遵守的流程？手下的人是哪些？他们能做什么？预算有多少？这些约束是可以改变的，约束决定了项目的规模（还有持续时间和质量）。
对比客户的期望列表和项目约束列表－选择项目成功的必要因素。按重要性排列出关注点，选择其中两三项作为项目约束，重要但有调整余地的条目称为浮动因素，一个项目至少要有三个浮动因素。最后看还未选择的条目，是不是还有哪个比已经选择的更加重要。浮动因素越多，项目越容易管理。
理想情况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个－过多的关键因素或约束，会让项目过于受限。若存在过多的关键因素和约束，项目经理除了启动项目之外别无选择，选定一个关键驱动因素，并尽可能频繁地向出资人提交项目产出，帮助他们决定想要的东西。
提示：要是约束太多了，就自己做决定吧。有必要的话，让管理层决定项目的关键驱动因素、约束和浮动因素，否则就自己做决定
决定项目的关键驱动因素（制定优先级列表）：发布日期、发布成本、功能集合、减少缺陷、人员配备、工作环境等排序。可以草拟优先级，让出资人调整签名通过此列表
项目经理要帮助出资人搞清楚：哪些约束是真正的约束，哪些是出资人自己一厢情愿的想法。
在对话中使用与上下文无关的问题，有助于识别项目的驱动因素、约束及活动余地－项目怎么样才算成功？为什么想得到这样的结果？这种解决方案对你价值何在？这个系统要解决什么样的问题？这个系统会造成什么样的问题？向出资人提问，要营造平等的气氛。
编写项目章程，共享现有决策 －【明确记录项目目标、需求和约束，可助项目经理思考如何进行项目规划，有助于发现潜在问题】－理解风险和成功标准。
项目章程模版：远景【发起缘由？项目价值，实用愿景对团队不可或缺】、需求【特定日期前发布某些功能】、目标【通过项目达成的目的，尽量多成员参与，启动会过章程】、成功标准【客户基于完成做什么给出定义，不涉及缺陷只注重能力－确保成功标准不会包含非项目人员才能完成的任务】、ROI估算【试做计算】
“质量，就是对于某人的价值”：质量对出资人和客户定义可能不同。添加某个功能，该功能吸引（或排斥）了多少个（以及什么样的）某人。若项目经理和团队知道“某人”对质量的定义，大家就可以朝着这个目标来努力；即使改变了主意，团队仍然可以成功。
摩尔的鸿沟
每个项目启动时都要有章程
对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动
要知道“质量”的意义以及项目的驱动因素。这样项目经理和团队才可以做出正确的决策
第二章 规划项目
要是团队成员不能跟你一起编程，项目启动会议上跟团队成员一起把它过一遍。下一步就是有目的的规划和日程安排工作。
规划（敏捷即发布计划）是指制订带有发布条件的项目计划，而日程安排则对工作项目的有序描述。
使项目足以启动的规划：规划不必完美无缺【能让项目启动起来，同时让大家看到成功希望就可以了】，时间有压力就用时间盒来辅助规划活动。
时间盒是指特定的时间长度，个人或团队用它来完成某项特定的任务。个人或团队在这段时间完成的工作量，就是项目接下来工作的基础。如有必要，可调整范围。
时间盒限制启动规划活动
提示：要根据经验而不是预言来规划项目。经验式规划是指不妨先做少量规划，再根据实际过程中收集到的信息反馈来影响未来的规划，这样做具有很高的可行性。预言式规划则是试图预测未来，是很难奏效的。应该尽量在项目中使用经验式规划和日程安排。
“规划毫无用处，但是制定规划必不可少”－反复规划，滚动式规划，不要创建完美的规划
提示：以始为终【开始规划时要想清楚有多少内容需要写下来。发布条件可以使出资人和项目团队集中注意力。如果想减少制订规划的时间，至少要保证规划出发布条件和风险列表，必要时要反复修订规划】
开发项目规划模板（重用）
产品意图【简单描述产品，为什么要开发这个产品，能带来哪些收益－每个子团队有自己的意图，与章程大方向保持一致但又不完全相同】
历史记录【发现技术债务，复查发布频率－产品生命周期、发布后发现的缺陷数和类型－技术债务、客户报告的问题－文档还是代码，及会影响项目经理对质量的定义，对项目管理方式的任何内容】
提示：知道的越少……感到惊讶的几率也就越大。适用于技术债务、新的架构、开发或测试风险或制订规划等多个方面。反复规划，减少意外。
发布条件【详细列出项目产品的关键交付物－不那么做还能发布产品吗？将功能、性能和质量要求都涵盖在内】
目标【产品目标：已设置好优先级不承诺在当前版本完成 + 项目目标：诸如性能之类的指标，高于一般需求 + 团队目标：改进功能可靠性 + 组织目标：减少项目耗费时间，提升组织敏捷性 】
项目组织【明确说明职责分配，采用哪些关键实践，是否有决策人可以影响当前项目－团队结构】
要是有一个产品负责人专门负责做出与产品相关的所有决策，可以考虑是否给他一个任命。如果有多个人同时决定功能特性及彼此间的权衡，就把这些决策人和对应的领域都列出来。时间盒限制迭代说明迭代长度，版本火车同样如此。
日程总览【主要里程碑，迭代增量说明预期产出，生命周期不放这里】
复杂项目开始之前就已经感受到日程安排的风险，不妨考虑多几个方案，让出资人进行选择。
项目经理要确保自己可以理解项目的价值，发布条件要明确。
人员配备（人员曲线）【要在此说明何时需要多少、何种类型的人员】
建议日程【列出主要里程碑，滚动式规划，即时贴安排日程。小心过早细化日程】
风险列表【至少把排名前十风险记录在案，经常监控这些风险，不到十个则进行头脑风暴】
尽早开始识别和管理风险。随时更新风险列表
风险列表
制订发布条件
为产品是否可以发布提供一些客观的评判标准，出资人和客户可以为发布条件做出合理的决策，对产品的质量和风险做出判断。
制定发布条件时，要先判断当前项目的关键因素是什么。为什么做这个？为什么客户愿意买？试运营条件？业务使用条件？监控中心？培训？利用发布条件，项目经理可以将整个产品的职责分工贯穿到产品的发布之中
步骤：确定当前发布最重要的因素【相关活动贯穿项目始终】－草拟发布条件－发布条件符合SMART原则－得到项目团队与高层管理人员认可
1. 当前项目最重要的因素，由组织需要和客户需要共同组成。制定发布条件应该考虑缺陷水平，但要确保发布条件中不仅仅包括缺陷相关内容。大局观－发布日期、功能特性和低缺陷率都很重要。取舍
2. 提供讨论草案，而非承诺
发布条件草稿
发布条件修改稿
3. 让发布条件符合SMART原则
检查合理和客观性，在项目的整个生命周期中评估这些条件。每个条件是确定可测量的可达到的，具有相关性和可跟踪性。
4. 再发布条件上达成多方共识
发布前，我们是不是必须满足这个条件？不在发布日期前满足这个条件会发生什么？若不满足，我们产品或公司会不会因此而承担风险？人们的安全感会不会因此被破坏？
与团队和职能经理一起讨论并产生发布条件形成归属感。达成一致后用这些条件来监控项目了。
使用发布条件
产品发布时只能有“满足”或“未满足”两种状态（还未满足某个条件），整个团队看仪表盘状态，距离发布日期还有多久。
早期预警信号，不要到最后时刻才发现有惊喜。项目经理了解到项目真实情况，就此与管理层沟通，看看哪些方面可以折衷，可以产生最现实的结果。
必要时变更发布条件【比如完成日期无法达到】：不满足会有什么后果？
首先跟团队确认为什么无法满足条件，向管理层解释。促使管理层向项目团队解释目前的状况－下个版本不会发生，当前版本说明复盘不能满足的原因和改进措施。
第三章 使用生命周期组织项目
生命周期是项目经理和团队组织产品开发的方式。定义需求、设计、开发、测试以及与这些工作同时进行的过程，都算是生命周期的一部分。
从整体上组织项目时，不要把现实状况理想化。要讲求时效－将内外部风险记在心间，选择的生命周期要有助于识别项目风险，帮助项目经理交付成功的产品。
项目经理必须找出对客户最重要的风险：能否及时发布、缺陷、特性、成本等。
四种不同类型的生命周期：顺序、迭代、增量、迭代/增量（敏捷）
不同生命周期风险管理风险
提示：编码并修复－永远糟糕透顶的生命周期，绝不选择其作为生命周期。开始时一定要做规划，哪怕一点点也成。一开始是不必获得所有需求的，时间盒迭代+客户参与。
生命周期是组织项目的理想化方式。可以整合其他生命周期的管理方式。
在项目中寻求反馈
测试反馈开发，得不到反馈很难评估剩余的项目风险、项目集状态以及团队的开发工作效率。顺序式生命周期预测未来但缺少足够的数据，越早得到产品反馈，预测未来越容易。
反馈循环
大规模项目需要组合使用多种生命周期
多种生命周期的结合
原型化设计是需要的， 随时留意架构能否满足需求，风险越早发现越好。要想完全掌控架构风险，只有基于它实现某些功能并进行测试。
从瀑布中摆脱出来
用迭代来规划所有工作，包括规划、需求收集和原型化等工作；将产品原型化，尽早向客户或代理人展示（越多反馈越好）；从项目一开始就加入测试的工作；功能要逐个实现，完成后随即进行集成和测试；要确保文档不是唯一的可交付物，与客户一起探讨原型，并交付可工作的产品，为团队提供很有价值的反馈。
项目经理如何管理项目，要向出资人坦诚相告，告诉他们你要应对很多风险。
尽早向代码库提交功能代码，使用Scrum产生演进的架构和交付功能。加入XP实践，敏捷－阶段式交付－瀑布式
铭记在心
在组织项目时，使用任何生命周期或多种生命周期的组合，都可以让项目踏上成功之路
不要怯于创建反映你自己项目实际情况的生命周期。“完美的”生命周期只是模型而已，你是生活在现实世界中的。
阶段－关卡流程或瀑布式生命周期，只有在确定使用它可以获得成功时才使用，而不是不经思考，上来就用。
第四章 安排项目日程
估算要准确，而不是精确：这个时间表基于目前状况所做出的最好猜测，会发生变化的
对于照顾来说，规划和日程安排二者不可或缺。让项目先启动起来，会做恰到好处的规划。
日常排定要安排工作任务的顺序，展示它们之间的依赖关系。工作估算则要猜测某个任务要花费的工时数。日程与估算工时数和需要的特定人员有关，对未知事物判断本来就是一种艺术。
提示：总时间盒限制初始规划－前期规划活动耗费的时间要尽量少，特别在团队已到位的情况下，只要产生的规划足以让项目启动起来。用一个小时制订项目章程，再用一个小时完成项目规划，日程安排草案也一小时完成。考虑接下来一到两周大家要做什么，每个人注意力放在项目启动的关键活动上，最后补充内容。
可供选择的项目日程安排技术
自顶向下：设置里程碑开始－制定任务支撑这些里程碑。即时贴，最底层的任务越小，估算任务完成所需要的时间也就越容易。
自底向上：从特定任务开始，从任务产生里程碑，任务如何组织在一起。
由内而外：思维导图开始，把所有与项目有关的东西放进去。可行性审查点，整理出来作为讨论基石，团队一起制定任务和里程碑
哈德逊湾式启动：先尝试在项目的实际环境中开展某些工作。项目经理应尽量缩短这个过程。关键要让团队了解到，在当前项目产品所在的领域中实际工作会是怎样的状况。先短期迭代，分析4个小时内完成的工作并分析它。
短期迭代：开发环境了解，开发任务没有把握，可以使用短时间迭代。时间盒迭代（不超过两周，再看看团队能完成多少工作－迭代结束回顾），大家更清楚如何安排项目日程。
用低技术含量的工具安排项目日程：要是项目团队有时间表的所有权，他们就会对其负责到底。黄色即时贴可以让整个团队参与项目日程安排的讨论。
使用即时贴安排项目日程的基本技术：写下主要的里程碑，每个人把所有任务写到即时贴，放在墙上，墙上放了些停车位用于摆放大家收集到的问题和假设，项目经理应该把这些疑惑作为日程安排的一部分。
即时贴日程安排
项目团队一起讨论事件的顺序、任何前置条件、假定以及问题。项目启动时跨职能团队互相提问－团队成员写完所有故事并解决完问题后，项目经理上场。
项目安排中的问题
使用即时贴和箭头安排项目日程、为每一个职能组使用即时贴安排项目日程，每周计划标识，项目团队结束时间表示出来。
每个可交付物一张即时贴，写明截至日期，短期迭代不必根据即时贴生成甘特图。
软件项目的关键路径是通过任务、人，有时是设备来体现的。即使使用甘特图每天也在变化，每个人更有意识地去思考关键路径有力于大家对其的责任意识。
跨多地点项目，项目经理应该把各个团队的带头人或项目负责人召集在一起，确保他们理解：谁负责何时把什么交付给谁。
基于可交付物的规划，尽早获取关于项目的反馈。若是需求冻结或代码冻结，这个项目就是基于阶段进行规划的。
提示：延迟的项目无法弥补时间进度，一定会延迟……项目开始时就意识到团队没有按进度进行，就应该想点别的办法了。
铭记在心
用低技术含量的工具开始安排项目日程。如果真需要相关软件工具，过后再转换数据。－要注意不使用“大型可见图表”或“信息辐射器”所带来的成本。
按可交付物安排日程，而不是按功能。
要有以迭代的方式安排日程的准备。一次完成的项目时间表，其作用根本无法对得起花在上面的时间。
第五章 估算工作
实用的项目估算方式：历史数据【考虑项目的非线性】、德尔菲【团队成员估算，提各种问题，每个人写下自己的任务列表和时间估算，同时注明自己对项目的预设条件－团队收集任务列表进行复查，看哪些任务可以同时进行，项目经理求和】、宽带德尔菲【专家暂时替代项目团队，产生任务列表和估算－完成估算后提交任务列表、预设条件和风险】
何时不应相信团队的估算：了解你的团队【没必要在项目第一周就解决所有估算问题】、去掉每个任务的任何缓冲时间【询问大家是否考虑，确保最精确估算－考虑约束理论，不要为任务的估算添加过多松散的时间，提供一个估算信心百分比、一个日期范围，考虑三点情况】估算质量因子监控数据
小心一开始就估算整个项目，这是个陷阱。顺序式生命周期可以先动手，测量出完成这些工作需要多长时间，利用估算信心百分比和日期范围，透明不确定性。
如何加入松散时间
项目日程并非一成不变。可能性范围就是自信心水平，利用自信心范围进行估算。使用自信心水平解释交付－早期里程碑【需求冻结、设计冻结和代码冻结】，不确定性锥形图。估算需要准确性【预测离实际情况有多远】，而不是精确性。
使用三个日期：最佳状况【最早可能的完成日期，由于某些原因不太可能】、最有可能【根据经验系数和缓冲时间】、墨菲日期【某事可能出错，它一定会在最不应该出错的时候出错，最有可能基础上再加入一些经验系数】
在估算时分开考虑任务的大小与持续时间－斐波那列数列估算，试探性开发决定任务大小（短期时间盒：拆分任务和确定时间）。建议用人时估算，理想日大家理解不同－规划扑克牌团队参与。
让估算更容易的提示：记住，估算只是一个大概值－一个猜测，让听众知道你是猜测；开发人员都是可观的；完成一项任务总是要花费比预计更多的时间；估算小块工作更容易；推荐用人时估算；项目经理和团队需要练习估算并收集反馈；做好反复估算的准备【已延迟的项目一定会继续延迟】；必须遵循某个日期，按优先级开发；项目被限制得很死，就要用时间盒把各个阶段和任务包围起来；任务过大（包含很多技术风险）不容易估算，可以先用试探性开发。
如果截止时间定死了，就别浪费时间进行估算了。制定出功能开发顺序，大体估计，快速估计。
用里程碑切分项目
用可交付物作为里程碑，不要用与功能相关的活动。比如开发系统需要架构原型，可交付的里程碑：为架构制定三种可选方案、审查这些可选方案、选择一种方案原型实现、完成架构原型。
要使用低技术含量的方式做项目日程安排，特别是管理时间紧张的项目时。时间约束越紧，团队制订日程时间安排要求越紧迫，保证每个人都接受这个时间表，并且努力去达成它。花些时间和团队成员在会议室中安排项目日程，可以用黄色即时贴让大家看到潜在约束条件。
提示：将里程碑（或迭代）结束安排一周之中的某天。选择周二或周三作为开始/结束的日期。
你们能够不做哪些事情
“能做哪些事情”思维方式基于假设：人不是稀缺资源、日程安排其实无关紧要、开发成本不是驱动因素
“能够不做哪些事情”思维方式基于假设：对需求的理解是稀缺资源【特定需求知道其对客户的价值所在】、日程安排至关重要、项目成本非常重要。
身背多个项目时的估算：不要估算，也不能估算，想都别想。项目必然会延迟、无法按要求交付、无法按质量交付。跟出资人讨论提供这些人。
有些人不需要专职投入，可以主动安排人们进行多个任务，一时需要的人员以周为单位切换项目，结束？周迭代？背负多项任务的人要完成工作会花更长的时间。
使用波浪式规划产生初始日程，在项目进行新调整日程，并在必要时重新规划各种活动－持续不断只覆盖几周内容，力所能及做好工作安排。无论团队的估算有多好，总是会有突发事件阻止他们按计划完成项目。
按照里程碑规划，下面写下任务和任务之间的关联，让团队参与任务拆解，更多时间看团队的进展并帮助他们移出障碍。
如何在短迭代开发大任务？拆分团队，确保团队保持持续集成。迭代不超过四周。
尽可能使用小石子将大任务拆分为小任务，每个小任务完成不超过两天，通常一天，估算任务和监控进度都算。小石子只有完成和未完成两种状态。
当任务不清楚时创建并使用小石子：不使用时间盒，通过问问题来知道一项任务何时完成。提出问题，寻找答案，再到怎么做。
铭记在心
绝对不要提供确定的项目结束日期
任务越小，估算起来就越容易
寻求估算的准确性，而不是精确性
网友评论