敏捷项目管理的焦点
一个企业主管期望从产品看法可项目管理流程中得到什么呢？他想得到3个关键的东西：首先，他希望这个流程是可靠的，每个项目都可以产生创新的结果；第二，他希望这个流程是可预见的，这样他可以有效地计划和管理诸如财务管理、人员配备和产品投放等企业活动；第三，他想得到可信的、符合实际的信息，因为构想可能是错的、商业模式可能是错的、人们可能遇到不能跨越的障碍、项目进展并不总是一帆风顺。如果项目需要终止，他想及早结束而不是等到后期才结束。可信的进度报告可以让经理尽早采取适当的措施。
可靠和重复之间的关键区别：重复意味着按同样的方式做同样的事情、取得同样的结果；而可靠意味着无论在前进道路中遇到什么障碍，都能达到目标，它意味着为达到目标而不断改变。
l 可靠但不重复
在评估项目绩效时，不能区分高度不确定性和高度确定性的项目环境会造成很多混乱，这种混乱源于两个地方：范围的定义、估计和限制之间的区别。
可靠流程将重点放在输出，而不是输入。可靠性是以结果为推动力，重复性是以输入为推动力。敏捷项目中需要考虑的正确范围不是限定的要求，而是清晰明白的产品构想。“整个产品是否符合客户或者产品营销的构想？”
混乱的另一个源泉是将成本和进度看作是估计，而不是限制。
l 进度报告
敏捷项目管理并不放弃控制，它确定了责任，修订了对控制内容的定义。
敏捷项目管理指导原则
人是受价值观驱使的，敏捷项目管理因而也是以价值观为推动力的。一个团队可以采用敏捷做法，但如果它不接受敏捷价值观和原则，它将不能得到敏捷开发的潜在好处。
卡尔·拉森和弗兰克·拉法斯托(1989)的研究成果被许多的团队协作书籍用作佐证材料。他们认为，原则性强的领导是高效团队最为关键的8个特征之一。在业绩优良的团队中，“领导管理原则，而原则管理团队。”
敏捷宣言的核心价值观派生出6条原则，而正是这6条原则指导着敏捷项目管理(参看图2-1)。如果没有这些指导原则，那么，即使敏捷做法，如迭代交付，通常也会被错误使用，甚至更糟糕的是，团队自以为自己使用的是敏捷做法而其实却不然。这些指导原则可以帮助团队确定哪些做法是适当的、如何在必要时提出新的做法、对出现的新做法进行评估、以及按照敏捷方式实施这些做法。这6条原则分成两大类，一类与产品和客户相关，而另一类与管理相关：
客户价值和创新产品
l 提供客户价值；
l 采用迭代的、基于功能的交付方式；
l 支持卓越技术。
领导—协作管理
l 鼓励探索；
l 建立适应能力(自我组织、自律)强的团队；
l 简单化。
这6条原则有效地组合在一起，组成了一个原则体系。虽然，各条原则分开来也可能有帮助，但6条原则合在一起则可以创造一个促进突发结果的环境。
提供客户价值
这是一条看起来很简单的原则，一条简单得无法清楚表述的原则，但我们必须反复强调它，以免项目团队成员忘记。
在定义客户价值时，一个令人关注的问题是“谁是客户？他们是产品的用户、是经理、或是其他利益相关方？”最直接的回答是，客户是用创造的产品产生商业价值的个人或群体。这个定义将客户与其他利益相关方区别开来。在本书中，“利益相关方”一词将表示与项目相关的其他个人。
在新产品开发环境中提供客户价值涉及到两个特别重要的话题：一是将重点放在创新和适应性而不是效率和优化，二是专心于交付活动而不是合规活动。
l 创新和适应性
敏捷项目管理的客户价值目标包含两个同等重要的部分：创造的创新产品必须在当时以及未来提供突出的客户价值。这个“以及未来”表达了对适应性的需要，这反过来证明了卓越技术的重要性。符合当今客户需求、但不容易适应未来需要的产品注定了其生命周期很短暂。
敏捷项目管理创造创新产品和服务这个核心目的意味着要应付技术和竞争的不断变化、产生新颖的想法以及不断缩短产品开发时间。虽然这个核心目的也可能会减少成本或提高效率，但它主要不是减少成本，也不是获得效率。当然，即使最具创新能力的团队有时也需要为项目带来一定的效率，这是让项目管理既保持有趣又增加难度的平衡行动的一部分。
l 专心于交付活动
如果项目经理将精力集中于交付活动，他们会增加项目的价值；而如果他们集中于计划和控制的话，管理费用往往会增加。
敏捷项目管理是侧重于实施的模式，而不是侧重于计划和控制的模式。在敏捷项目管理中，项目经理的首要任务是促进产品构想的构思，并指导团队去实现该构想，而不是制定计划和进度表、控制进度，保证“计划”得以实行。然而，我们需要阐释一下前面的观念—— 敏捷项目管理不是反对计划的模式。计划(和控制)是敏捷项目管理的组成部分，只不过它不是重点。如同敏捷开发的许多方面一样，次重要的事情与重要的事情之间是存在很大差别的。
一旦项目团队将重点放在实施，下一个关键步骤是将精力集中到增值活动上，即那些帮助团队交付结果的活动，而非那些只是确保合规活动。
敏捷项目管理首要关心的是交付—— 交付结果和提供价值给客户。许许多多的项目经理、项目办公室成员、组织盲目地将合规作为他们首要的重点。合规活动充其量只能减少错误、欺骗、劣绩和财政透支的风险。
精简流程、以刚好足够为目标以及认识到合规活动与交付活动(虽然一些活动具有两方面特征，很难将它们分开)之间的区别，这些对于向客户更快速、更节省地提供价值等方面具有巨大的好处。
精益生产的一个基本原则是系统地消除浪费，即那些不向客户提供价值的活动。简化项目(做较少的事、做正确的事、消除瓶颈)的一个方法是区分交付活动和合规活动，以及对每种活动分别采用不同的策略。
交付活动与合规活动的问题对于项目经理有特殊的重大意义。第一，项目经理需要分析项目活动，以保证花费到交付活动的时间最大化；第二，项目经理必须分析他们自己的活动，确定它们是交付活动或是合规活动。
精益思维提供了一个区分交付活动和合规活动的方法。精益思维的4个原则是：
1. 指定价值；
价值只能由最终客户确定，用产品术语表达—— 客户需要、价格、时间和质量。此分析中的客户通常是指终端客户，而非市场客户。对客户的界定不正确(比如内部管理人员)会导致市场价值的错误估计
2. 确定价值流向；
价值流包括了产品提供给客户过程中的必要活动：产品开发、订单处理到交付、产品生产。我们要对每个特定的活动加以分析，确定它增值的部分以及不增值的部分。
3. 流动思维；
流动思维鼓励每个人，包括经理和员工，抛弃传统的、批处理—— 排队思维模式，而采用小批量流动的思维模式，换句话说，无论在哪个步骤，活动都不必等待审批或者等待下一个部门，要毫无耽误地从一个步骤流动到下一个步骤。例如，使用快速试验技巧的药品开发团队如果必须经常等待试验测试结果，就说明它缺乏流动性。
4. 拉动思维。
最后，拉动思维意味着要等待客户找上产品而不是保持大库存量，然后将产品“推给”客户。戴尔电脑公司就是实行拉动*，等待客户的订单来“拉动”产品。
项目经理通过处理合规问题，同样可以为项目增加价值。
合规活动是经营的成本，但合规工作可能会扼杀创新、大幅度提高成本以及延长产品开发周期。
实际上有两种合规活动—— 内部和外部的。外部合规活动是不能避免的，也不应该避免。
对于必要的合规活动，应该采取的策略是尽量减少它们并使它们远离关键途径和关键的人。
另一突出的问题是许多人(尤其是经理和流程设计人员)认为合规活动—— 审查、检验点、正式文件和精致而又详细的计划—— 增加价值。
合规活动除了成本可能很高外，更严重的问题是它们对开发时间的影响。
如果我们没能区分交付活动和合规活动，我们会错误地认为整理和使文件正式化可以帮助开发者建造更好的产品。通过剥离出合规活动，我们就强迫自己直面了解它们的真正成本，防止它们破坏开发进度。
采用迭代、基于功能的交付方式
如果你想创新，就必须迭代！
迭代、基于功能的开发可以定义为4个关键词：迭代、基于功能、时间框和渐进。
迭代开发意味着我们要建造产品的部分版本，然后通过连续的短期开发以及评审和修改，扩展该版本。基于功能的交付意味着设计团队建造最终产品的功能，或者至少是最终产品最接近的代表物(如模拟、模型)，尤其是对于工业产品。
迭代被限定在一定的时间期限—— 时间框—— 内产生一个结果。该时间框强制迭代的结束，强迫我们在准备充分之前，就制造出一些具体的东西。渐进开发意味着我们先建造部分产品，在经过一次或多次迭代后配置它们。部分产品可以以硬件形式交付，以便尽早地测试其关键的性能属性。对于软件公司而言，迭代开发和渐进交付已经成为了竞争优势。
功能交付方法帮助定义客户和产品开发者之间的可行界面。客户对进度有影响力并能决定功能的优先次序，而产品工程师确定提供这些功能需要哪些任务，将花费多少时间和成本。高级管理人员只限于功能管理，而不是任务管理，他们可以削减功能但不能削减任务。功能比过渡文件更接近现实，它们显示出真实的而非人为的进展情况。面对实际的进展，项目团队、客户和利益相关方就*围绕成本、进度和范围问题，面临困难的权衡决策。客户、产品经理和其他利益相关方在开发流程中不再是无关紧要的旁观者。
迭代开发同时也是自我纠正的，在迭代结束时，对产品、技术、流程和团队的评审后，它会根据合理的评审结果，自我改正。
支持卓越技术
敏捷开发人员致力于卓越技术，不是因为美学(尽管对一些项目，它可能是其根本原因)，而是因为致力于卓越技术可以提供客户价值。项目经理必须是卓越技术的拥护者；他们必须支持并提倡卓越技术，同时密切注视其他项目目标。
支持卓越技术在以下两方面都显得非常关键：在规定的时间和成本限制制造客户当前想要的产品；减少变化成本，使得产品适应未来的需要。丰田体系的4大支柱之一是“专业的工程队伍”，它鼓励卓越技术以及个人责任感。
项目经理需要专门的技术专家，才能正确地管理项目。支持卓越技术要求项目经理和团队成员明白卓越技术的含义—— 它在于产品、技术、以及从事工作的人的技能；他们必须明白在特定产品的环境下，卓越和完美之间的区别。任何公司都不可能制造完美的产品，但制造提供客户价值并保持技术完整性的产品是商业成功的关键，是令技术团队满意的关键。
“不懂所管理的技术为何物的项目经理会使团队失去信心，尤其是那些以其技术能力引以自豪的团队。”作家埃里克·维祖(1999)说。
项目经理必须支持卓越技术，因为它是适应能力和低成本迭代的关键，而这两者是产品长期成功的推动力。也就是说，如果项目经理不是技术权威，那他最好有一个技术权威，担任总工程师或开发总管这样的职位。
小结：顾客和产品
提*品价值，即在目标时间范围内生产的产品功能，是敏捷项目管理的基础，并且客户是其流程的推动力。为了在提供该价值方面有效而又及时地创新，敏捷团队采用了迭代、基于功能的交付。最后，为了确保该价值在如今以及未来的提供、产品可以在开发期间和第一次使用后都能够适应客户不断变化的需要，项目经理和团队需要创造环境，将卓越技术看作是一个关键的优先考虑事项。
鼓励探索
探索是困难的，它会引发焦虑、颤抖，甚至有时是恐惧。敏捷项目管理需要鼓励和激发团队成员渡过这些高度变化环境造成的困难。这种鼓励包括保持自我镇静、鼓励试验、借鉴成功和错误，以及帮助团队成员理解产品构想。
伟大的探索来自于有灵感的领导者。
伟大的探险者清楚表述出可以激发人们灵感的目标——让人们激动、自我激励的目标。
鼓励型领导者知道好目标和坏目标之间的区别。
领导者帮助弄清目标，团队透彻了解这些目标并以此鼓励自己。
演示、原型、模拟和模型是相互交流的催化剂，它们组成了“共享空间”，其中开发者、市场人员、客户和经理可以做有意义的相互交流。
共享空间有两个要求——直观化和公共性。公共性意味着原型需要得到开发工作的所有相关方的理解。
建立适应能力强（自我组织、自律）的团队
适应能力强的团队是敏捷项目管理的核心，它们结合了*和责任、灵活性和结构。
自我组织的团队的特征不是缺乏领导，而是一种领导风格。
建立自我组织的框架必须要：
l 找到适当的人；
流程可以为人们的高效工作提供共同框架，但它不能代替能力和技能；产品是由能干、技术熟练的个人制造的，而不是由流程制造的。
l 清楚表述产品构想、界限和团队角色；
l 鼓励团队之间的相互交流和信息流动；
健康团队关系的核心是信任和尊重。
项目经理需要将精力放在相互交流、协作上，需要先协调，然后再准备适当的文档，因为文档会妨碍交流。
l 促进参与式决策；
决策是协作的心脏和灵魂。团队如何作出决策确定了团队是否真正协作。
选择双赢思维模式，用重新构思代替妥协。重新构思意味着将多种想法合并起来，创造一种比任何一个单独想法更好的东西。
l 坚持负责；
责任和负责创造了高效的自我组织团队。
信任是协作的基石，而履行承诺是建立信任的核心。
l 引导而不是控制。
那些想建立适应能力强的、自我组织的项目团队的经理应该引导而不是控制，他们影响、轻推、促进、劝告，以及在某些情况下指导，他们将自己看作是教师（教练）。
自律是*和授权的前提。
自律的个人可以：
l 对结果负责；
l 用严谨的思维对抗现实；
l 参与激烈的交流和争论；
l 愿意在自我组织框架内工作；
l 尊重同事。
简单化
如果你想快速而又敏捷，那么就要使事情保持简单。速度不是简化的结果，但简化能提高速度。当你去掉详细的任务和合规工作、简化流程时，你就强迫人们思考和交流，因为无论是他们或他们的经理都不能用结构作为一个拐杖。
l 再生规则
简单规则是复杂性理论“群集智能”的一面。其想法是正确的一套简单规则，一旦应用到一群充分交流的个人之中，会产生诸如创新和创造力之类的复杂性为。
一套正确的规则应该是为创新和生产设立界限最少的一组规则，它们制定简单的、但产生复杂行为的规则组，营造创新环境。
l 刚刚足够的方法论
在决定流程、方法、做法、文档以及产品开发的其他方面时，简化的警告将我们引向刚刚足够、引向精简、引向实施“比刚刚够少一点”。
“迅速，但不仓促。”
必须快速适应，但永远不要失去控制。
小结：领导——协作管理
项目管理和项目领导的区别是什么呢？它们之间有微妙的关联，但其根本区别是管理处理复杂性，而领导应付变化。
敏捷项目经理帮助他们的团队在混沌的边缘保持平衡——一些而又不太多的组织结构、适度而又不太多的文件、一些事先准备而又不太多的体系结构工作，找到这些平衡点是管理的“艺术”。探索系数高的项目充满了渴望、变化、模糊性和不确定性，这些都是团队必须处理的，而且需要用不同的项目管理风格、不同的项目团队运作模式和不同类型的项目经理。这种类型的管理称为“领导——协作”。
领导——协作的管理风格建立这样的社会体系结构：一个可以让组织和团队面对环境多变性的结构。这种社会体系结构融合了绩效和激情、结果和平等主义。
人们做什么，如何做最终决定了是否能够创造优秀的产品。原则和做法只是指南，用来帮助并加强某些行为。在敏捷开发中，我们想鼓励的行为是思考、行动和相互交流。我们希望知识渊博的人从产品开发流程中收集新信息，深思熟虑地运用这些新信息，并且与他们的同事交流，从事产生突发性的、创新想法并将那些想法用于建造真实的、可得到论证的产品部件