一、敏捷革命 1.当我们将试验成本减少到足够低时，整个产品开发的经济学就会发生改变——从以预测为基础的流程（定义、设计，然后建造）转变为一个以适应为基础的流程（构想、探索，然后适应） 2.当生产不同产品的成本突然降低，而把这些不同产品集成到一个产品的成本又很低时，那么这个很大的产品可以说不是生产出来的，而是进化出来的 3.罗伯特·库珀：“各地的公司，无论蔬菜销售商还是坚果销售商，无论是开罐器制造商还是汽车制造商，都参与了新产品研发战争 ，而前沿部队就是产品开发团队。在这个新产品战场上，闪电般的攻击能力——计划充分且出击迅速——越来越成为成功的关键因素。而机动性或者速度则可以保证闪电攻击能够抓住机会或者捕捉到敌人” 4.最终客户价值是在销售时交付，不是在计划时交付 5.任何以敏捷方法为幌子进行特殊开发的人，都是彻头彻尾的骗子 A.敏捷商业目标 1.一个良好的探索流程（如敏捷项目管理）需要实现5个关键的商业目标：
* 1）持续创新，满足当前客户的需求 * 致力于向客户提供价值，以及创造满足当今客户需求的产品，是这个持续创新流程的推动力 * 创新思想并不会在模式化的、独裁的环境中产生，而会在基于自我组织和自我约束为原则的不断适应氛围中产生 * 2）产品适应性，满足未来客户的需要 * 要想让产品持久地占有市场，唯有努力提高产品的适应能力 * 在敏捷项目中，卓越技术通过两方面判定：一是现在提供客户价值的能力；二是创造强适应性产品的能力 * 敏捷技术的做法将重点放在减少技术债务（提高适应能力），将其作为开发流程的组成部分 * 在敏捷项目中，开发人员致力于卓越技术，而项目经理则提供支持 * 3）缩短交付进度，满足市场，提高投资回报率（return on investment，ROI） * 缩短交付周期、满足市场需求仍然是项目经理和主管要优先考虑的企业目标 * 敏捷项目管理的迭代开发、基于功能的本质可以通过3种方式缩短交付周期：突出重点、简化流程和培养技能 * 4）人员和流程适应性，对产品和企业变化做出迅速反应 * 如果我们想要适应能力强的产品，就必须建立一支适应能力强的队伍——其成员都乐于变革 * 敏捷项目管理的指导原则和架构鼓励把学习和适应当做向客户提供价值的组成部分 * 5）可靠的结果，支持业务增长和赢利能力 * 探索项目不能产生已知的、完全预告规定的结果，但可以产生有价值的结果——一个满足客户目标和商业需求的可以交付的产品 * 良好的探索流程可以不断地提供创新
2.重复的流程是指按照同样的方式做同样的事情 ，并产生同样的结果；而可选是指无论在生产过程中遇到什么障碍，都能达到目标，它意味着为达到一个目标而不断改变 3.如果目标是提供符合已知的、不变的说明要求的产品，就用重复的流程。相反，如果目标是提供有特定限制的价值的产品，而变化和截止日期都是非常重要的因素，那么可靠流程更为适用 B.敏捷的定义 1.敏捷是制造并响应变化从而在动荡的商业环境中创造利润的能力 2.敏捷是平衡灵活性和稳定性的能力 3.制造变化可以扰乱竞争对手（及其整个市场系统），而对变化作出反应能防止竞争冲击。制造变化需要创新：开发新产品、建立新的销售渠道、缩短产品开发周期、为日益变小的细分市场定制个性化产品。此外，公司还必须能够迅速响应竞争对手和客户制造的可预见和不可预见的变化 4.复杂性理论告诉我们，创新（即创造一些我们不能完全预见的新东西、突发的结果）最容易出现在混乱和秩序、灵活性和稳定性之间的平衡点时 5.组织结构太严密会抑制创造性，太松散会导致效率低下 C.敏捷价值观 1.敏捷强调的是态度而不是流程，它是氛围而不是方法 2.那些卓越的公司创立的基础（核心价值和目的）往往是永恒不变，但其策略（商业）和做法（业务实践）是变化的 3.在业绩优良的团队中，领导管理原则，而原则管理团队 4.团队为何存在、要创造什么产品、为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。如果想要创造优秀的产品，就需要有优秀的人才；如果想吸引并留住优秀的人才，就需要有优秀的原则 5.没有行动的宏伟原则纯属幻想，相反，缺乏指导原则的具体的实践通常都是不合理的应用 6.敏捷宣言
* 个体和交互胜过流程和工具 * 可以工作的软件胜过面面俱到的文档 * 客户合作胜过合同谈判 * 响应变化胜过遵循计划 * 虽然右项也具有价值，但我们认为左项更具有价值
7.相互依赖声明
* 通过持续为客户创造价值来提高投资回报 * 通过不断地与客户交互、共享所有权来交付可靠的结果 * 预测不确定性，并设法通过迭代、预防、适应来应对不确定性 * 个体价值是团队价值的源泉、创建能让个体卓越的环境，实现创造和创新 * 通过激发成员的使命感和责任感来提高团队绩效 * 通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性
8.平等主义精英的核心价值观强烈影响着敏捷运动。当然，这个核心价值观并不是唯一能制造产品的价值观，但其定义了大多数敏捷主义者对自己的认识 9.敏捷管理者应该具有的信心价值观：
* 交付价值胜过满足约束（价值胜过约束） * 领导团队胜过管理任务（团队胜过任务） * 适应变化胜过遵循计划（适应胜过遵循）
10.传统的项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目管理者则关注如何 成功地去适应那些不可避免的变化 11.技术质量：价值持续产生的决定性因素 D.敏捷绩效评估 1.敏捷项目评估的3个目标：
* 价值目标——提供可交付的产品 * 质量目标——提供可靠的、适应性强的可交付产品 * 约束目标——在可接受的约束内，实现价值和质量目标
2.敏捷三角形的演变
E.敏捷项目管理架构 1.以生产为导向的项目管理流程和做法强调完整的早期计划和要求说明，并且要求以后将尽量不会改动；而基于探索的流程虽然也强调早期计划（仅是名义上的），但它更强调足够好的要求和可实验可改进的设计方案，而且随后会通过不断学习，做出重大改动 2.敏捷项目管理交付方法包括5个阶段：构想、推测、探索、适应和结束 3.构想阶段产生一个清晰明白的业务或者产品构想，为后面的阶段划出边界；在推测阶段，团队推测产品的规格，制定一个发布计划，随着项目的不断进行，技术要求和客户要求会随着新知识的获得不断演变；然后是探索阶段，它和迭代平等作业，其中要完成最初的功能和需求设计；在适应阶段，这些试验的结果需要经过技术、客户和企业的个案审查，以便在下一次迭代过程中继续做出调整 F.敏捷项目成功率 1.至少，敏捷方法有潜力极大地提高竞争优势。它能很大程度上提高生产力和质量缩短时间，而这些最终会改变整个商业模式 2.敏捷项目管理不限于一小套做法和技巧，它定义了如下的策略能力：提供可交付的产品、创造和适应变化 、在灵活性和结构之间保持平衡、挖掘开发团队的创造力和创新能力以及引导组织度过动荡和不确定的时期 二、价值胜过约束 1.尽管诸如成本和进度这样的约束很重要，但为客户创造价值也很重要。通常人们总是关注容易测量的因素，而忽视了真正至关重要却难以量化的特征 2.如果团队关注结果——哪怕仅给予最小的关注，他们也更有可能交付真正商业价值 3.结果包括产品构想、商业目标和性能（高级产品功能），而没有具体需求 4.质量目标定义了交付可靠的、可适应的（可工作的并易于改进）产品，这些都是很关键的价值特质 5.项目领导可以通过以下几种方式来关注产品价值：价值确定（与客户一起）、价值优先级排序（订单管理）、价值创造（迭代开发）
* 价值确定通常是业务经理和产品经理的职责，但项目领导也经常参与成本/效益分析和价值判断（特别是在产品公司） * 价值优先级排序也大多是产品经理的工作，但项目领导者也要参与，特别是面对客户或不知道技术需求的情况下 * 价值创造是在项目组内指的是与客户合作、把客户需求分组、减少技术债务（保证质量和价值交付）等活动
A.持续创造客户价值 1.通过持续创造客户价值来提高投资回报——相互依赖宣言 2.价值是指企业或组织的产出结果，往往与财务收益有关 3.持续是指价值能经得起时间的考验——无论是现在还是将来 4.软件设计行业，适时交付软件第一个版本固然重要，但交付高质量并能适应未来需求的产品更重要 5.客户和产品经理推动着敏捷开发 6.客户阐明产品应该具备的性能、带来的价值和实现量化该价值的商业目标 7.符合当前客户需求，但不容易适应未来需要的产品，注定其生命周期是很短暂的 8.成功的秘笈很简单——今天交付，明天适应 9.客户是用创造的产品来产生商业价值的个人或群体 10.“利益相关方”表示与项目相关的、协助定义产品商业价值和其他约束的个人 11.如果希望交付的产品具有重大的客户价值，就必须在客户和开发人员之间建立伙伴关系，一种双方都承担责任和义务的关系 12.敏捷团队不断地寻求客户参与，并总向客户提问“我们所做的对您实现企业目标有帮助吗？” 13.提供客户价值涉及3个特别重要的话题：一是将重点放在创新和适应性而不是效率和优化，二是专注于执行，三是精益思维 14.“我们生活在一个由创造力、创新和想象力推动世界发展的时代”——汤姆·吴杰克和桑德拉·马斯喀特 15.创造新产品和新服务不同于对现有产品作微小改进
* 前者必须将重点放在创新和适应性，而后者通常注重效率和优化 * 效率提供我们能想见到的产品和服务，而创新提供的是我们想象不到的产品 * 效率和优化是生产型项目的有利助推器，而创新和创造力却是探索型项目的助推器 * 生产型思想倾向会限制对可行性方案的想象，而探索型思想倾向帮助探索看似不可能的事情 * 优化意味着已经知道如何做某事，只是现在需要改进它；创新意味着不知道如何做，所以探求知识就显得极为重要
16.如果项目经理将精力集中于交付活动，他们为项目增加了价值；而如果集中于计划和控制，就可能增加管理费用 17.传统项目管理方法由3个信息交流流程组成：计划、控制和执行 18.传统计划存在一些问题：
* 计划的动机通常来自项目之外，即制定计划的目的是为了满足法律法规或者管理要求 * 制定计划的动机往往与控制欲有关，而不是与实际工作的实施需要有关 * 计划和控制成为焦点，而执行被看作是最不重要的
19.在敏捷项目管理中，项目经理的首要任务是促进产品构想的构思，并指导团队去实现该构想，而不是制定计划和进度表、控制进度，保证“计划”得以实行 20.敏捷项目管理不是反计划的模型。计划（和控制）是敏捷项目管理的一个组成部分，只不过它不是重点 21.敏捷运动的许多想法都源于精益生产。精益生产的一个基本原则是系统地消除浪费，即减少不向客户提供价值的活动 22.一个简化项目（做较少的事、做正确的事、消除瓶颈）的方法是区分交付活动和合规活动，以及对每种活动分别采用相应的策略 23.过多的结构不仅会扼杀主动性和创新，而且消耗了大量的时间。根本问题不在于这些方案有无价值，而在于他们从根本上将流程凌驾于个人知识和能力之上 24.交付的相关活动与合规活动对项目经理有特殊的重大意义：
* 项目经理需要分析项目活动，以保证用在交付活动上的时间最多 * 项目经理必须分析他们自己的活动，以确定他们是在从事交付活动还是合规活动
B.迭代、基于功能的交付 1.如果想创新，就必须迭代 2.敏捷项目可以快速并递增地在整个项目期内交付价值。采用迭代、基于功能的交付方式，能在早期捕获价值，而且通常可以极大地提高项目的投资回报率 3.完成一个需求文件只是证实这个团队成功地收集到了一套需求；而完成或演示一套可以工作的产品功能证实开发团队实际已经向客户交付了有形的东西 4.敏捷的迭代组成部分可以用4个关键词表示：迭代、基于功能、时间框和增量
* 迭代开发是指要建造产品的部分版本，然后通过连续的短期开发以及评审和修改，扩展该版本 * 基于功能的交付是指设计团队建造最终产品的功能，或者至少是与最终产品最接近的代表物（如模拟、模型），尤其是对于工业产品 * 迭代要求在一定的时间期限内——时间框（对于软件是1-4个星期）——产生一个结果，该时间框强制迭代的结束，强迫人们在准备充分之前，就制造出部分实体 * 增量开发是指建造的产品，在经过一次或多次迭代后都可以及时的被调用
5.功能交付方法：客户决定进度和功能的优先次序，而产品工程师确定提供这些功能需要的任务，以及完成这该任务要花费的时间和成本 6.对于需求可能会随时间推移而演变的项目和产品，让客户在开发过程期间评审结果，使其尽可能接近实际产品，就显得尤为关键 7.迭代开发同时也是自我纠正的过程。自我纠正最重要的方面是客户在产品演变过程中提供的反馈信息 8.随着演变融入后面的迭代开发，客户对产品的信心会增加，或者相反，开始清楚地认识到该产品无法工作，应该趁早抛弃 9.促进探索很关键，但知道何时停止也很关键 10.“在我实行迭代开发的前几年，认为时间框实际上是关于时间的，但后来我逐渐意识 到，时间框的作用实际上是强制做出困难的决定” C.卓越技术 1.敏捷开发人员致力于卓越技术，不是因为美学，而是因为致力于卓越技术可以交付客户价值。项目领导必须是卓越技术的拥护者；他们在密切注视其他项目目标的同时，必须支持并提倡卓越技术 2.高品质能确保公司在未来交付价值。许多软件都是苦于技术债务和低质量的做法带来的问题的积累 3.敏捷开发人员认为迭代、新兴设计和频繁反馈可以产生更出众的设计 4.任何公司都不可能制造出完美的产品，但制造提供客户价值并保持技术完整的产品是商业成功的关键，也是令技术团队满意的关键 5.项目经理需要与团队一起，讨论和决定开发的技术方法，而且在决定技术问题时，让团队不要忘记企业目标。项目经理可以不做决定，但他们应该具备足够的知识，去引导团队成员相互交流，以确保团队充分地消化吸收项目资料，并及时做出正确的技术决定 6.项目经理必须支持卓越技术，因为它是适应能力和低成本迭代的关键，而这两者是产品长期成功的推动力。项目经理不必是技术权威人士，但必须具备足够的知识，才能与这样的技术权威交流 D.简化 1.“如果想让船走得更快，那么割断锚绳比加大马力要来得容易”——卢克·霍 2.如果想快速而又敏捷，就要保持事情简单。速度不是简化的结果，但简化能提高速度 3.“简化非常关键，它是最大程度地减少不必要工作的艺术”——敏捷宣言 4.采用去掉详细的基于任务的结构和合规工作来简化流程，就强迫人们思考和交流 5.简单原则是复杂性理论“群体智能”的一个方面，其思想是一套简单正确的规划，应用到一个高度相互作用的群体中，然后产生诸如创新和创造力之类的复杂行为 6.再生做法：一个系统在一起正常运转的小最单位，它并不规定一个转化需要做的每件事，而是确定那些具有非常高的价值、适用于几乎每个项目的做法。采用这些做法，项目团队将“生成”其他必要的辅助做法，作为他们裁减和改变该套做法、适应具体需要的一部分 7.在决定流程、方法、做法、文档以及产品开发的其他方面时，简化理念告诫我们应该把方向引向刚刚足够、精简和实施的“比刚刚够少一点”
* 简化需要平衡速度需求和灵活性，同时保持足够的稳定性，避免疏忽错误 * 刚刚足够并不意味着不足，也不意味着“无文档”或者“无流程”
8.在产品开发中，缺乏速度会导致竞争劣势，而仓促会导致错误。平衡，是敏捷的关键之一 9.如果领导者能够巧妙地将复杂问题简单化、能够制定刚刚足够的流程、能够找到快速和仓促之间的分界线，那么他无疑有更高的成功机率 10.如果不能区分交付和合规，就会导致合规工作——为管理机构、律师或者高层管理编制文件——不断增加，而将产品降到次要位置 11.“系统主义”：盲目地相信系统，认为可以通过系统达到任何必要的目标 12.约翰·格尔反对系统主义：
* “根本问题不在于某个特定系统，而在于类似的系统” * “系统往往不断扩张，填补已知世界” * “系统往往反对他们自身的正确功能”
13.一些合规活动是必要的。每个组织、每个项目团队都有一定的合规活动。例如医疗行业医药许可
三、团队胜过任务 1.敏捷领导者领导团队，非敏捷领导者管理任务 2.敏捷项目管理强调团队管理，提倡建立自我组织团队和发展服务型领导方式。这比管理任务更加困难，但最终的结果会更令人满意。在敏捷项目中，团队成员关注任务，项目领导关注团队 A.领导团队 1.“在战斗中，你管不了人，你只能管事情……并领导别人” 2.项目管理和领导的区别：管理处理复杂性，领导就会变化 3.想建立适应能力强的、自我组织的项目团队，领导者应该引导而不是控制，在某些情况下，他们影响、轻推、促进、教授、建议、协助、催促、劝告以及指导 4.项目领导应该即是管理者，又是领导者，随着项目的探索系数增高，后者的重要性将迅速上升 5.领导者之所以成为领导者，不是因为他们所做的事情 ，而是因为他们扮演的角色 6.领导者在很大程度上依靠的是影响力而非权力，影响力来自于人们的尊敬而不是敬畏。取决于领导者的性格。领导者虽然得到组织的授权，但他们真正的权力不是自上而下委派的，而是自下而上赢得的 7.领导者鼓励变化：提出未来可能性的想象（通常细节很少）；通过大量人员交流，发现能够帮助将产品构想变为现实的新信息；以及激发目的感，激励人们致力于一些超出常规的事情 8.管理幻想（霍奇森和怀特）：
* 为什么认为你处于受控状态？ * 为什么认为你能够预测未来及其结果和效果？ * 为什么认为你曾成功过的方法就能够再次行得通？ * 为什么认为任何重要的事情都是可以评估的？ * 为什么认为诸如领导、管理和变化这些词对任何人来说，意思都一样？ * 为什么认为降低不确定性必然会增加确定性？
9.敏捷项目经理帮助他们的团队在混沌的边缘保持平衡——一些而不是过多的组织结构、适度而不过多的文件、一些事先准备但不过多的体系结构工作，找到这些平衡点是敏捷领导才能的艺术 10.领导-协作的管理风格创建了这样的社会体系结构：一个可以让组织和团队面对环境多变性的结构。这种社会体系融合了这些概念：平等主义、才干、激情、自律和自我组织 11.“指挥官知道目标，领导者把握方向；指挥官发号施令，领导者施加影响；控制者提出要求，协作者加以促进；控制者事事管理，协作者不断鼓励。支持领导-协作模式的经理非常清楚他们的主要角色是设定方向、提供指导以及促进人们与团队之间的联系” 12.“在混沌时代，成功较少取决于生搬硬套而更多的是依赖于理智；较少取决于少数人的权力而更多的是依赖于多数人的判断；较少取决于强制而更多的是依赖于激励；较少取决于外部控制而更多的是依赖于内部纪律” 13.“敏捷”是社会技术运动，它有两个推动力：一个是愿望——创造一种特定的工作环境；另一个是信念——适应性强的环境是向客户提供创新产品目标的关键 B.建立自我组织（自律）团队 1.自我组织团队是敏捷项目管理的核心，他们结合了自由和责任、灵活性和结构。面对矛盾和模糊性，团队的目标是始终如一地在项目范围内和产品构想基础上进行交付（包括适应性） 2.在自我组织的团队中，个人负责管理自己的工作量，根据需要和最适合原则轮班工作，并对团队效率负责 3.对于如何“交付结果”，团队成员有自己保有较大的灵活性，但他们对结果负责，并在制定的灵活框架内工作 4.“自我组织的团队的特征不是缺乏领导，而是一种领导风格” 5.创建自我组织的团队需要：
* 1）找到适当的人员 * 项目领导者有权否决其他经理单方面想指派到该项目的任何团队成员 * 任何流程都不能克服优秀工程师、产品经理、客户和主管缺乏的问题 * 高效率的项目经理将重点依次放在人员、产品和流程。没有适当的人员，将不能建造任何任何产品；不将精力放在产品上，其他无关系的活动就会渗入；没有一个最低限度的流程框架，就会出现效率低下乃至混乱 * 2）清楚表达产品构想、界限和团队角色 * 3）鼓励协作 * 4）坚持负责 * 通过激发成员的使命感和责任感来提高团队绩效——相互依赖声明 * 团队成员相互承诺 ，团队对客户承诺，项目经理承诺为团队提供特殊资源，他们就都同意了承担责任 * 每个团队成员都有责任提高团队协作，每个团队成员和项目领导相互履行承诺 是义不容辞的责任 * 5）培养自律 * 自律是自由和授权的前提。如果个人和团队想要更多的自主权，他们就必须有更多的自律 * 自律的人可以：对结果负责；用严谨的思维对抗现实；参与激烈的交流和争辩；愿意在自我组织框架内工作；尊重同事 * 自律也是建立在能力、坚持和愿意承担结果的责任之上，才干不仅是技能和能力，它是态度和经验 * “关键是首先要找到自律的人，他们进行严谨思维并会在一致的系统框架内采取守纪律的行动” * 6）引导而不是控制
6.敏捷不会因为有良好的意图就自动发展。敏捷团队的成长和成熟需要时间，也需要致力于建立关系和鼓励协作 C.鼓励协作 1.自我组织团队的能力在于协作，即两个或更多的人相互交流和合作以共同产生一个结果 2.协作的结果可以分为：有形的可交付物、决定和共享知识 3.如果没有有着正确技能和行为规范的合适人选，任何的流程和工具都不会产生任何结果 4.协作结果的质量优劣取决于信任与尊重的程度、信息流动的自由度、辩论以及积极的参与，同时也受到参与式决策流程的约束 5.健康团队关系的核心是信任和尊重，自信和自负仅有一线之隔 6.如果协作太少、信息交流太少，团队就会分歧严重，整合就会变成一个恶梦（因此需要经常整合）；而如果协作太多、信息交流太多，团队就会陷入会议和信息超载 7.参与式决策：
* 决策是协作的心脏和灵魂，领导也是良好决策的关键 * 高效率的领导“吸收”模糊性、负责做决定并让团队继续其工作。知道何时和如何应对模糊是高效率领导者的一个标志 * 重新构思意味着将多种想法合并起来，创造一种比任何一个单独想法更好的东西。它不是放弃而是增加 * 创新是通过相互交流、逐步扩展想法，然后融合这些想法后突然出现的 * “妥协造成两极分化、重新构思导致联合” * 自我组织的团队偶尔需要经理做出单方面的决定，但他们的主要风格是包容，鼓励团队成员广泛地参与决策以便做出最好的决策
8.共享空间：
* 创新并不会因为一些确定性的流程而得到保证，创新是安全性流程的结果，在这个流程中，具有创造性想法的个人相互交流，引发了某些新颖的、与众不同的东西的产生。演示、原型、模拟和模型是相互交流的催化剂，他们组成了“共享空间”，其中开发人员、市场人员、客户和经理可以做有重大意义的交流 * 共享空间有两个要求：直观化和公共性 * 直观化：当工程师与客户讨论原型、致力于功能而不是文档时，相互交流的质量就会得到很大提高 * 公共性：意味着原型需要得到开发工作的所有利益相关方的理解
9.客户合作：
* 客户或者产品团队应该是任何敏捷开发工作不可或缺的一部分 * “敏捷”经常指出客户和产品团队的不足，并且需要和产品团队定位自已的角色
D.不再需要自我组织团队 1.如果让自我组织继续发挥价值，那么有几个问题要处理：
* 需要摆脱掉一个观点——敏捷项目无领导或者谁是领导取决于不同的情境 * 授权型自我组织团队的支持者已经过时了——适宜的领导保留适当的决策权与授权给团队相结合的方式
四、适应胜过遵循 1.“传统的项目管理者注重按计划行事，尽量做到和计划没有出入；而敏捷项目领导者关注如何成功地去适应不可避免出现的变化” 2.以客户价值和质量为目标，计划就是实现这些目标的方式，而不是目标本身 3.传统经理不断修正实际结果来符合基线，PMBOK称为纠偏行为，用来引导团队回归基线；适用行为用来描述应该采取 什么行动方针（其中一个行为可能被修正以符合计划要求） 4.《敏捷宣言》和《相互依赖声明》中包含了5个与适应性有关的原则：
* 《声明》：预测不确定性，并设法通过迭代、预防 、适应来应对不确定性 * 《声明》：通过使用根据具体情况而定的策略、流程和实践来提高效率和可靠性 * 《宣言》：响应变化胜过遵循计划 * 《宣言》：即使在产品开发后期，也乐于接受变化的需求，敏捷流程充分利用变化以增加客户竞争优势 * 《宣言》：团队定期反省如何做到更有效，然后相应调整团队行为
5.上述原则可以概括为：
* 预测变化（不确定的），然后做相应调整，而不是遵循过期计划 * 根据需要调整流程和做法
6.团队必须适应，但是不能脱离最终的项目目标，无论是适应性流程还是预测性流程 7.可以用4个问题来评估流程：
* 在发布产品的同时，是否交付了价值？ * 是否实现了创造可靠的、具有适应性的产品质量目标？ * 项目进程是否满足可接受的要素范围？ * 团队是否在有效地适应管理、客户和技术等方面的变化？
8.适应可以看做是对变化做出的沉思熟虑的回应 9.“变化”：变得不同，使事物的性质、形态变得与原来不同 10.“适应”：不断作相应的改变以满足一定用途或形势 A.适应学 1.如果认为世界是静止的，则生产型管理做法将占主导地位；但如果认为世界是动态的，则探索型的管理做法将涌现出来。通常会出现静态和动态的混合。 2.复杂适应系统，无论是生物学还是经济学，都是以下独立行动者的集合：
* 通过相互影响创造生态系统的行动者 * 其相互交流定义为信息交流的行动者 * 其个体行为基于一些内部规划系统的行动者 * 按照非线性方式自我组织、产生安全性结果的行动者 * 显示出秩序和混乱两个特征的行动者 * 随时间演变的行动者
3.个体行动者的行动由一套内部规则推动：敏捷项目管理的核心思想和原则 4.一套简单的规则会产生复杂的行为和结果，而另一方面，复杂的规则通常会变成官僚作风，这些规则的表达方式对复杂系统的动作有非常大的影响 5.安全性是复杂适应系统的一个特性，复杂适应系统通过各部分（自我组织的行动者的行为）的相互作用，会创造出整个（系统行为）系统的更大特征。这个安全性系统行为是不能完全用行动者的标准行为来解释的，安全性结果不能以正常的因果关系来预测，但可以通过以前产生类似结果的模式来预见他们的发生 6.适应性开发流程与优化流程具有不同的特征。优化反映的是说明性的“计划-设计-建造”周期，而适应反映的是有机的、进化的“构想-探索-适应”周期。适应流程不是以一个解决方案开始，而是以多个可能的解决方案（试验）开始，然后，应用一系列的适合性测试（实际产品功能或者模拟，取决于验收试验），根据反馈信息进行改变，从而探索并选择最好的解决方案 7.如果不确定性低，则适应方法的风险是高成本，而如果不确定性高，则优化方法的风险在于太早的确定某个解决方案会抑制创新 B.探索 1.拥有响应变化的能力固然很好，但是如果能给竞争对手创造变化则更佳 2.创造变化，就是向对手展开竞争攻势，响应竞争对手的变化，就是在防守 3.“适应的速率要超过市场变化的速率” 4.敏捷领导者需要鼓励和激发团队成员通过这些高度变化的环境所造成的困难。鼓励包括保持自我镇静、鼓励试验 、借鉴成功和错误经验，以及帮助团队成员理解这种鼓励的所有部分 5.伟大的探索者清楚表述出可以激发人们灵感的目标——让人们激动、自我激励的目标，这些目标或者构想作为一致的工作重点，刺激人们并在团队中建立团队精神，激发灵感的目标必须是充满活力的、令人信服的、清楚的、可行的但又刚好的，它融入团队的激情中 6.鼓励型领导者知道好目标和坏目标之间的区别。鼓励型领导知道设定一个产品的构想需要团队的努力，需要基于分析、理解和现实的风险评估，同时还要有一点冒险精神 7.创新产品开发团队是被引导的而不是被管理的。他们容许他们的领导是有灵感的，将领导者的鼓励变成自我意识 的一部分。优秀的新产品、现有产品的显著改进和创新的新业务方案都是由激情和灵感推动的 8.领导者清楚团队目标。团队成员了解这些目标并以此激励自己。内在的激励可以激发探索。如果没有探索和失败，如果不探索多个方向并最终找到那个似乎有前途的方向，我们就不可能获得新的、更好的和与众不同的东西 C.响应变化 1.“预测变化 （不确定性），然后做相应调整，而不是遵循过期计划” 2.上述宣言可进一步归纳为：
* 构想—探索与计划—执行 * 适应与预见
3.每个项目都有已知的未知的条件、有确定因素和不确定因素，因此，每个项目都必须在计划和变化之间找到平衡 4.影响项目管理类型的另一个因素是迭代的成本，即试验成本 D.产品、流程和人员 1.适应性有3个组成部分：产品、流程和人员 2.许多软件组织实施敏捷的障碍是他们没有处理遗留代码中的技术债务 E.障碍还是机会 1.伊斯雷尔·干特“新玩具”综合症：“把重点放在新的开发上而忽视遗留代码” 2.经常集成好处非常大，它可以减少许多以前遗留的问题，迟早发现那些直到发布期快结束的时候才发现的问题 3.大多数情况下，人们感觉适应变化有障碍（成本太贵）是因为做事效率低下——没能抓住机会简化流程并提高组织的适应能力 4.敏捷开发需要短期迭代：做短期迭代需要找到快速、低成本的做重复事情的办法；快速、低成本的做事情使得团队采用以前从没有想到的方式去适应变化 F.可靠，但不重复 1.重复意味着按照同样的方式做同样的事情 ，并取得同样的结果；而可靠意味着无论在前进道路中遇到什么障碍，都能达到目标，也意味着为达到一个目标而不断改变 2.可重复流程通过评估和不断的流程纠正，减少可变性 3.可靠流程将重点放在输出，而非输入 4.可靠性是以结果为推动力，重复性是以输入为推动力 5.“重复流程最多只能交付事先规定的东西，而可靠、突发流程可以交付比开始时每个人的设想都更好的结果，只要你足够机敏且具备预见能力，突发流程就可以产生最初希望的东西” 6.敏捷项目中需要考虑的正确范围不是限定的要求，而是清晰、明白的产品构想——一个可发布的产品 7.评估项目成功的方法可以简化成一个问题：“我们有可发布的产品吗？”，而不是制造出了在项目开始时就规定好的特定功能的产品 8.尽管敏捷项目管理是可靠的，但它不是一贯正确的，它也不能消除不确定性的反复无常和在探索中遇到的出乎意料的事情 G.反思和回顾 1.适应变化需要具备这种理念和技巧 2.如果希望有较强的适应性，就必须愿意认真严格地评估个人和团队的绩效。有效的团队在回顾时会涉及4个领域：产品、流程、团队、项目 3.在每次迭代结束时和项目末期，对这些领域进行回顾和反馈，然后适应，从而提高绩效 H.从原则到做法 1.“根据需要调整流程和做法” 2.原则和做法是向导，他们帮着确定和加强人们的行为 3.在敏捷项目中，既要有预见性也要有适应性的流程和做法。根据已知信息发布计划来预见未来，反思根据随后 在项目中发现的信息来适应代码 五、敏捷项目管理模式 A.敏捷企业架构 1.投资组合治理层提供一些常见的检查点：项目管理层对各种项目的管理提供指导。项目管理层和迭代管理层不同，其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。区分迭代管理层和技术做法层，有助于把核心技术做活融合到几个项目或者迭代管理方法中去
2.投资组合治理：主管们都想知道项目的价值（及投资回报率）和获取该价值的确定性和不确定性 3.项目管理层：管理发布，与核心小组的外围利益相关者打交道 4.迭代管理层：关注每个短期迭代的计划、执行和团队领导 5.技术实践层：包括从持续集成到结对编程，从测试开始到重构等做法 B.敏捷交付架构 1.流程也许不如人那么重要，但它绝非不重要 2.如果企业目标是重复性的制造，那么常规性流程是完全合理的；而如果目标是可靠的创新，则流程架构必须是有组织的、灵活的和容易适应的 3.敏捷交付架构需要：
* 支持企业目标 * 支持构想、探索、适应文化 * 支持自我组织、自律的团队 * 根据项目的不确定性程度，尽量提高可靠性和连贯性 * 保持灵活和易于适应 * 支持流程的透明化 * 合并知识 * 囊括支持各个阶段的做法 * 提供管理检查点
4.敏捷项目管理模式的结构：构想—推测—探索—适应—结束，重点在交付（执行）和适应
5.敏捷项目管理架构与传统项目阶段的区别：
* “构想”代替较传统的“开始”，指出构想的重要性 * 推测阶段代替计划阶段：“计划”已经与预测和相对确定性相关联，而“推测”表示未来是不确定的 * 敏捷项目管理模式用探索替代通常的设计、构建和测试阶段，探索是非线性的、并存的、非瀑布式的模式；敏捷项目管理模式强调执行以及探索性而非确定性。实施敏捷项目管理的团队密切关注构想、监控信息，从而适应当前情况，这就是适应阶段 * 敏捷项目管理模式以结束阶段收尾，这个阶段的主要目标是传递知识，当然它也是一个庆典
6.敏捷项目管理的5个阶段是：
* 1）构想：确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作 * 该构想包括什么、谁提供和如何提供 * 构想是项目早期 “成功的关键因素” * 产品及项目范围构想 * 需要构想参与者都有谁：客户、产品经理、项目团队成员和利益相关方组成的社团 * 项目团队成员必须构想他们打算如何共同工作 * 2）推测：制定基于性能和/或功能的发布计划，确保交付构想的产品 * “根据不完全的事实或者信息猜测某事” * 对于探索性的项目来说，计划是基于不完全的信息推测或猜测 * 包括：收集初始的、广泛的产品要求；将工作量定义为一个产品功能清单；制订一个迭代的、基于功能的交付计划；把风险降低策略纳入计划；估计项目成本，并生成其他必要的行政管理和财务信息 * 3）探索：在短期内计划和提供经测试的功能，不断致力于减少项目风险和不确定性 * 通过管理工作量和合作适当的技术方法和风险降低策略，按计划交付产品功能 * 建立协作的、自我组织的项目社团，这是每个人的责任但需要由项目经理和迭代领导者推动 * 管理团队与客户、产品经理和其他利益相关方的相互交流 * 4）适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整 * 控制和纠正是这个周期阶段常用的术语 * 计划制定了，结果监控了，纠正也完成了，这个流程意味着计划是正确的，而如果实际结果与计划不同，则表明计划是错误的 * 适应意味着修改或改变，而不是成功或失败 * 非常特别的流程并不能从错误中吸取教训，而吸取教训是敏捷项目管理的关键部分 * 在适应阶段，需要从客户、技术、人员和流程绩效，以及项目状况等方面对结果进行检查 * 思考实际的与修订后的项目前景，修改后的结果将反馈并应用到重新计划工作中，以开始新的迭代 * 自构想阶段以后，其循环通常是推测—探索—适应，每次迭代都不断地优化产品。但是对团队收集新信息来说，定期修正构想阶段也万分重要 * 5）结束：终止项目、交流主要的学习成果并庆祝 * 结束阶段（以及每次迭代末尾的小型结束）的主要目标是：学习并将学到的东西融入下一次迭代工作中，或者传递给下一个项目团队
7.敏捷项目管理的构想和探索周期
8.没有做法的原则只是个空壳，而没有原则的做法经常会被毫无判断地生搬硬套；没有简单原则 ，人们往往会过多地看重做法的形式和仪式。原则指导做法，做法用实际例子证明原则 ，两者是相辅相成的 9.“没有最好的做法，只有更适合具体情况的做法” 10.过分强调线性会导致停滞不前，而过分强调演变会导致无休止的、最终证明是盲目的变化 11.“一切工作都应该是循序渐进的，即使是架构开发。序列开发中前期架构出错通常意味着长期适应性较差，因为没有人能够经得起在项目晚期再改变架构” 12.一个500人的团队可能不如一个10人团队敏捷，但它可以比竞争对手的500从团队更敏捷。只要将重点集中在价值、交付、自我组织和自律，即使团队再大，面临的协调问题再复杂，它也能随时应对商业、技术和组织的变化 C.扩展的敏捷交付架构
六、构想阶段 1.“在人类行为领域，很难发现非常一致的事情 。因此，一旦一个团队被认为是功能有效的，人们便归功于它们对目标有明确的了解”——拉森和拉法斯 2.虽然要求和设计的细节可能是易变的和模糊的，但企业目标和产品构想必须是非常明确的
A.可发布的产品 1.产品的一个发布标准是功能或者故事的完成，既从开发人员的角度（编码、单元测试）完成，也从产品团队的角度（验收测试）完成 2.可发布的产品和可用到的产品构想框和项目数据表中的信息可以定义为：
* 1）可交付的产品；产品构想框；项目数据表——项目目标声明、企业目标、性能、性能价值 * 2）可靠的、适应性强的产品：项目数据表——质量目标 * 3）在可接受的约束内：项目数据表——均衡矩阵（范围、进度、成本）
B.构想做法 1.目的是明确地鉴定需要做什么以及如何做，需要回答以下几个问题：
* 1）客户的产品构想是什么？ * 2）该产品的主要性能是什么？ * 3）项目的商业目标是什么？ * 4）项目的质量目标是什么？ * 5）项目的约束是什么（范围、进度和成本）？ * 6）谁是项目社团的合适参与者？ * 7）团队将如何交付产品（方法）？
2.如果没有共同的构想，项目就会步履蹒跚。没有构想，启动就成为官僚作风和缺乏新意的形式 3.构想阶段应该举行一系列的协调会议，让开发和产品团队成员参与进来 4.在敏捷项目管理的构想和推测阶段，尤其重要的是要记住：
* 1）团队成员应该经常自问：“我们需要的刚好足够的流程和文档是什么?” * 2）与团队交付“方式”有关的所有做法都需要随着项目的进行，不断做出裁剪和调整，以提高业绩 * 3）项目社团将会不断演变其团队做法
5.4类做法：
* 1）产品构想 * 产品构想框和电梯测试说明书 * 产品体系结构和指导原则 * 2）项目目标和约束 * 项目数据表 * 3）项目社团 * 找到合适的人选 * 确定参与者 * 客户团队-开发团队界面 * 4）方法 * 流程和做法的截取
C.产品构想 1.产品构想（产品构想框和电梯测试声明）激励团队成员将各自对产品的不同观点集中成简练的、直观的简短文本格式 2.创新（创造我们无法预测的突发结果）需要一个能够容纳探索和错误的演变流程 3.每个产品需要有一个营销主题、一个简明直观的图像和功能描述，其目的是吸引潜在客户对该产品作进一步的了解 4.提出15个或20个产品功能很容易 ，但要想确认哪3个或4个功能能够吸引其他人来购买该产品却很困难，这通常会引发关于真正客户身份的激烈讨论 5.在每个小组递交产品构想框后，要讨论如何将不同的重点功能缩减成每个人都同意的几个功能 6.“电梯测试说明书”，编写产品定位的简短陈述 ，用几个句子表明目标客户、主要好处和竞争优势 7.“电梯测试说明书”的格式：
* 对于（目标客户）； * 谁（需要或有机会声明）； * 这个（产品名称）是（产品类别 ）； * 它（主要的优点、引人注目的购买原因）； * 不同于（主要的竞争产品）； * 我们的产品（主要差别）
8.产品构想框和电梯测试说明书强调项目的目的是制造产品，可以让团队的客户产品思想有据可循 9.最后需要花费几个小时讨论记录活动挂图纸上的产品构想，团队可以对一个1-2页的完整产品构想文档有更好的概括认识。这份文档可能包括任务说明、构想框图、目标客户及其各自的需要、电梯测试说明书、客户满意评估标准、主要技术和业务要求、关键产品限制（性能、操作的简便性、体积）、竞争分析，以及主要财务指标 10.交付进度越关键、项目越多变，团队对于最终需要的结果是否有较好的构想就显得越重要。如果没有这个构想，迭代开发项目就很可能变得摇摆不定，是因为每个人看到的都是细节而不是宏伟的蓝图 11.产品体系结构的目标是描述项目的内部沟通渠道，是一种促进探索和指导正在进行的产品开发的设计 12.一个早期的“骨架”产品体系结构不仅能指导技术工作，也能指导执行技术工作人员的组织工作。它旨在把较大的项目背景传达给开发团队，而不是局限于一个设计 13.敏捷开发中，体系结构是引导，而不是紧箍咒 14.在敏捷发展中，体系结构和设计不是一次性的活动，而是随着自身演变在每次迭代中都会出现的活动 15.如果在一次又一次的迭代中，主要的体系结构不断发生变化 ，很明显，可能是什么地方出问题了 16.虽然通常来说，敏捷做法鼓励变化和适应，但是某些变化有更大的影响，而需要认真地协作；如果技术体系结构不好，就会使得这个变化的协调工作非常困难。一旦部件之间的协调或者整合花费了过多的时间，机敏的项目团队就会认识到体系结构决策不恰当，而需要修正 17.功能分解结构（Feature Breakdown Structure,FBS）可以用来描述软件或硬件项目产品体系结构 18.在项目早期阶段人力组织和技术体系结构同时演变，这个模式有利于大型项目中各个项目功能团队与主要的产品部件保持一致 19.指导原则（Guiding Principles,GP），用来协助开发团队塑造产品，满足客户需求。通常不是可衡量的要求或者限制，而只是概念上的指导 20.早期的指导原则可以在以后的演变中成具体要求 21.每个原则应该用一两个句子描述，而且在任何情况下，一个项目的全部原则描述不得超过10个句子 D.项目目标和约束 1.产品构想勾勒的目标没有限制，但是作为一个项目来讲就需要有目标和限制 2.项目需要有明确的商业目标（不同于客户的产品构想）、质量目标和一套明确定义的性能，从而开始界定出可交付产品的范围 3.项目数据表（Project Data Sheet，PDS）是项目目标和约束的最少文档编制 4.项目数据表是用一页纸概括主要商业和质量目标、产品功能和项目管理信息。这是一个简单却有重要影响力的文档。它简洁的格式，对整个项目社区呼吁并且不断提醒他们哪些是项目的战略方面 5.根据不同的组织和项目类型，项目数据表包括：
* 顾客/客户：主要顾客或者客户一览表 * 项目经理：项目经理的姓名 * 产品经理：产品经理的名称（产品拥有者） * 高级主管：负责决策项目计划和约束的人 * 项目目标声明（Project Objective Statement，POS）：明确而简短的声明（不超过25个字），其中包括重要范围、进度和成本信息 * 商业目标：做这个项目的总的金融和商业原因 * 权衡矩阵：确立项目范围、进度和成本的相对优先次序的表格 * 探索系数：衡量项目风险和不确定性的度量标准（1~10） * 延误成本：项目延误所造成的每日、每周或者每月成本（进度被列为最优先次序时尤其有用） * 功能：主要功能一览表 * 质量目标：一个可发布的产品的定量、定性质量目标 * 性能/质量属性：产品主要性能和质量属性清单 * 体系结构指导方针：修正设计决定的主要体系结构指导方针 * 问题/风险：对项目有负面影响的因素
6.权衡矩阵帮助开发团队、产品团队和各利益相关方管理项目期间的变化，它告知所有参与方变化的重要性，是团队决策的依据。这个矩阵显示出敏捷三角形（价值、质量、约束）所确定的3个约束（范围、进度、成本）的相对重要性。如果组织必须适应变化，那么他们需要知道哪方面最具有灵活性
7.当项目启动的时候，项目计划估计在价值、质量和约束三者之间的健康平衡非常重要。当这个平衡被打破的时候，权衡矩阵就开始发挥作用。——肯·科利尔 8.探索系数用来表示项目的不确定性和风险的指标。探索系数为10表示问题领域是以探索为主（高风险），而系数为1表示比较稳定的环境 9.阐明项目的探索系数有助于管理客户和主管的期望值 10.探索系数是从产品需求（目的）的易变性及其技术平台（手段）的新颖性（也就是不确定性）派生出来的 11.探索系数矩阵
12.如果没有认识到不同的问题领域，整齐划一的项目流程和做法也许还有理由；而一旦有了这样的认识，按具体的问题量身定制适合的流程和做法将会使项目团队取得成功 E.项目社团 1.产品开发同其他大多数工作一样，找到合适的人员是成功的关键因素。这里的“合适的”包含了两层意思：具备适当的技术能力（或者专业技术）；表现出适当的自律行为 2.找到合适的人员并不意味着要找到最具天赋的、经验最丰富的人，而是说要做这个工作最适合的人选 3.如果计划承担困难的、极其苛责的项目，就需要最优秀的人才；而如果承担的是要求不很高的项目，并且有高于平常人的人才，仍然可以做得很好 4.几乎每个人在某些方面上都有超出平均水平的潜力。帮助他们发现自己的潜力是经理的工作 5.两个因素决定了团队是否有“合适”的人员：能力和自律。合理的流程可以帮助适当的人员有效地在一起工作，但这并不能弥补人员配置不恰当的问题 6.合适的人员将重点放在交付上，而不合适的人员带来更多的合规工作 7.确定参与者
* 1）3类参与者：客户（可能包括最终用户、他们的经理、产品专员、产品经理和高级主管）、开发团队成员和利益相关方 * 2）如果产品团队成员忘记他们仅仅是代表真正的客户，而不是真的客户的话，就会发生大问题 * 3）利益相关方3个级别： * 关键的：无论在实施之前或之后，这些参与者都可以阻止项目成功，换句话说，他们是特别有影响力的人 * 必需的：在实施之前或之后，这些参与者可以拖延项目成功，换句话说，要围绕他们工作 * 非必需的：这些参与者是感兴趣者，对项目没有直接影响，但是如果不将他们包括在社团内，他们可能变成关键或者重要的参与者 * 4）项目参与者可能包括：高级主管、项目领导者、产品经理、产品专员、迭代经理、总工程师（开发人员、架构师）、高层管理、产品团队、项目团队、开发团队、供应商、政府等 * 5）参与者的群体越复杂，项目领导者在管理期望值、做关键的项目决策和防止团队不受到太多方向的牵制等方面花费的时间就越多
8.产品团队——开发团队交互
* 1）产品团队负责“建造什么”，开发团队负责“如何建造它” * 2）如果没有强有力的产品经理，就会出现最坏的情况——无法确定优先次序
* 3）组织内部IT项目失败或者表现不佳的其中一个关键原因是：错误地理解了项目经理和产品经理这两个角色的本质，产品经理必须来自IT部门外部 * 4）尽管角色界定很重要，实际上角色具有灵活性，应该根据担任该角色的人做出适当调整。强迫人们按照固定的角色描述不仅是不可能的，也是违背敏捷原则的 * 5）人员不仅比流程重要，也比角色重要 * 6）“建造什么”的决策要由客户团队做出，而开发团队做“如何建造”的决策。优秀的开发团队是有丰富的产品知识，应该积极参与“建造什么”的决策，而产品经理和客户团队成员通常可以对产品“如何”设计做出重大贡献 * 7）每个团队的责任和两个团队之间的交流是成功的关键
9.交付方法
* 1）团队自律的部分内容是团队就某种方法达成一致，然后实际地应用它。无论是否达成一致，还是没有执行该方法，都是缺乏自律的表现 * 2）流程和做法和裁剪工作定义了项目团队交付某个产品将使用的方法 * 3）自我组织策略将重点集中在人们如何一起工作、如何协作以及协作的机制上 * 4）流程和做法是不断演变的
10.自我组织策略
* 1）自我组织策略让团队将精力首先集中在相互交流上，即与项目有关的每个人如何在一起工作。该策略确定了团队的沟通、协调、协作、决策，以及其他个人与个人和团队与团体的相互交流方法 * 2）自我组织策略问题 * 我们如何与客户协作？ * 来自不同功能团队的项目成员如何相互协作？ * 亚特兰大的团队如何与西雅图或者孟买的团队协作？ * 授权对我们团队来说意味着什么？ * 谁需要在何时与谁交流？ * 相互交谈的这些人如何决策？ * 谁负责什么？ * 他们打算用哪些做法来推动上面提出的问题？ * 3）仅有沟通是不够的，还涉及相互交流以产生一些共同结果。协作是把大家的想法综合为一个整体
11.流程架构裁剪
* 流程架构应该努力找出刚刚好（可以接受的最小程度）的项目组织标准 * 即流程组成元素的数量、必要的过渡产物数量、决策的数量、文档形式越多，项目的敏捷度就越低
12.做法的选择和裁剪
* 1）敏捷开发和项目管理是建立在一个基本前提下的，即个人能力是成功的基石，而且个人是独一无二的贡献者 * 2）不应该塑造人，使其适应一套共同的流程和做法；而应该按照团队自身特点，塑造流程和做法 * 3）4个基本问题： * 哪些做法是必需的？ * 还需要哪些辅助性做法？ * 需要对选择的做法做那些修改？ * 做法的编档、批准和更改需要什么手续和形式？ * 4）“如果文档是正确的，即使很少，它也大有帮助” * 5）“不是文档的问题，而是理解的问题”
七、推测阶段 1.计划既是对未来的猜想——在已有的信息基础上猜测将发生的事情 ，也是对未来的指南——确定想要的事情并促使其发生 2.计划是重要的活动，但随着不确定性的增加，用推测这个术语更加恰当 3.推测确立目标和方向，同时也表明期望在项目期间存在许多变化，不是狂热的冒险，而是“根据不完整的事实或者信息猜想某些事情” A.推测产品和项目 1.推测阶段的产品是发布计划，基于要交付的功能而并非活动（指传统的项目计划中的活动） 2.迭代计划和开发方法有两个至关重要的组成部分——短期迭代时间框和功能 3.基于功能的计划和开发的首要目标是制定有形的、客户团队可以理解的流程 4.功能是开发工程师和产品团队之间的界面——共同理解的一个媒介。这个共同的媒介采用故事卡片的形式。每个故事都写在一个另外的索引卡上，把功能拆分成可以执行的小块任务。索引卡的前面包含需求信息，用于制定计划，背面包含技术任务信息，可以让团队估计并管理其工作 5.敏捷项目推测有助于项目团队：
* 确定产品及其功能在当前版本中如何演变 * 随着项目的开展，平衡预期和适应 * 在项目早期将重点放在价值最高的功能上 * 考虑项目、企业目标和客户期望值 * 为管理层提供必要的预算和进度信息 * 为权衡决策建立优先级 * 协调团队之间的相关活动和功能 * 考虑其他选择和应变措施 * 为分析项目期间出现的事件提供基准
6.敏捷项目领导者需要通过行动、绩效评估和构想，不断地鼓励团队随着项目的进行，不断地学习并适应。演化的项目是困难的，它充满了模糊性、变化和不稳定性，但是适应以交付价值的回报是丰厚的 B.产品功能清单 1.产品功能清单是对构想阶段制定的清单的扩充和提炼，列出那些经过可行性分析或市场研究、初步需求收集工作和产品构想等工作收集起来的产品功能 2.产品经理维护这个清单，使得这个清单及伴随的功能卡成为发布、里程碑和迭代计划的主要资料来源 3.功能细节随着开发阶段的演变而演变。在构想阶段，团队创建初步的功能或者产品细目结构。在推测阶段，团队扩充这个清单，并为每种功能都建立一张或多张“故事”卡，其中包含基本的描述和估计的信息。在探索期间的每次迭代，按照计划实施功能、详细地确定需求、建造和测试功能 4.软件是最有可塑性的产品，公司需要利用这个特点来增加竞争优势，坚持传统的瀑布式开发方法则减少这个优势 5.需求说明流程的结果，无论涉及什么设计内容，都应该按照产品功能等级如（产品、平台、功能组和功能）制成文档 6.功能、故事的概念
* 1）功能或者故事被定义为产品的一部分，向客户提供一些有用的、有价值的功能 * 2）功能和故事的基本区别是：故事是一个小的可交付的有用功能，但构不成一个完整的功能 * 3）性能、功能和故事构成一个分层结构，该分层结果用来管理越来越大的产品规模
7.故事的重点
* 1）对于有开发技术任务经验的个体来说，定义故事会非常困难。对于详细的迭代计划，故事被拆分成技术任务，供开发团队使用 * 2）缺少明确的客户能够理解的故事会导致项目快速地脱离轨道，在一次迭代期间，把几个故事中的任务结合起来做，大多数所谓的效率低下情况就会消除 * 3）一些故事不是一次迭代就能完成，往往需要较长的时间或似乎较长的时间。通常情况下，当团队被迫把大故事分解成小故事时，他们也就找到了方法，不能按这种方式拆分任务通常是因为缺乏经验而不是故事不可拆分 * 4）在客户功能之前构建技术功能的危险是“黑洞”。技术团队“涉黑”时间越长（构建技术人员的东西），项目在得到客户团队的反馈之前 偏离轨道就越远
8.故事卡片
* 1）目的是提供简单的媒介，用于收集有关故事的基本信息、记录高层次的需求、开发工作估计和定义验收测试 * 2）故事卡片用于列出功能，而不是详细定义功能 * 3）故事卡片的用途是客户和项目团队成员在一次迭代期间详细需求的讨论（以及抽成最低限度的文档）后达成的协议。讨论是理解的关键，而理解是估计的关键
* 4）故事卡片信息： * 故事ID和名称 * 故事描述：用一两个句子，从客户的角度描述功能 * 故事类型（C=客户领域、T=技术领域） * 估计工作量：交付该故事所需的工作量的估计，包括需求收集、设计、编码、测试和文档编制 * 估计价值点 * 需求不确定性（无规律的、波动的、常规的、稳定的）：每个特定故事采用一个探索系数 * 故事依赖关系：可能影响实施顺序的依赖关系 * 验收测试：客户团队用于接收或拒绝该故事的标准 * 5）开发团队也会用任务分解来估算实施该故事所需要的工作量 * 6）需求不确定性的程度和技术风险因素不仅会影响故事进度，而且会影响团队实施该故事的方法 * 7）高风险的故事（无规律或者波动的）将安排在早期的迭代中
9.创建功能清单
* 1）功能清单是产品团队确定的产品性能、功能和故事的一列表，通常包括ID、名称、简要描述、优先级别、探索系数和估算等项目 * 2）发布计划和迭代计划都会使用功能清单上的数据 * 3）主要分为两个工作：谁做这项工作、确定和定义功能清单项目的做法 * 4）有3个因素与理解程度密切相关：涉及的人、确定这些人要履行哪些职责、把功能拆分成若干可执行的块
C.发布计划 1.发布计划是团队在项目数据表中所描述的在项目目标和约束内实现产品构想的路线图 2.故事驱动表现在它将计划和执行的主要重点从任务转变为产品功能 3.敏捷目标是在任何一次迭代结束时都能具备可以部署的产品，即功能、测试、文档和其他可交付的产品可以打包并部署 4.客户价值和风险是推动发布计划的两个主要因素 5.发布计划的主要任务是以价值风险为基础把故事分配到迭代中 6.在将故事分配到迭代时，最优先考虑的是交付产品团队规定的产品价值，然后是制定故事的进度计划，以便迟早降低项目风险。但有时，技术风险需要放在首要位置 7.其他因素，如资源的可用性、依赖关系以及其他，都排在价值和风险因素之后 8.范围演变
* 1）范围蔓延不是问题，如果范围改变是随意和恶意想出来的，那么它们对于项目有害无利。但一般而言，从满足不断演变的客户需求出发、在认同它对项目的影响的基础上做出的范围变更会提高项目成功的可能性 * 2）让功能随着项目周期不断演变（当然有一定的限度），这比在开始时幻想需求、又在没有客户经常参与的情况下构建功能会更快速、更节省。构建最少功能策略以及简单、适度地适应变化会使团队受益匪浅 * 3）敏捷开发进关于焦点和平衡的：集中于项目的主要构想和目标，强迫做出困难的权衡决策，以保持产品各方面的平衡 * 4）产品范围的推动因素应该包括：客户价值、技术可行性、成本和关键的业务进度需要 * 5）“简化非常关键，它是最大程度地减少不必要的工作的艺术”——《敏捷宣言》 * 6）敏捷项目中的短期迭代结合迭代结束时的客户评审，使整个团队（包括开发人员、客户和经理）都认清了现实 * 7）“当进度出现问题的时候，瀑布式方法缩减任务，通常是减少测试，而敏捷方法减少功能，前者降低质量，后者缩小范围” * 8）短期迭代也让开发人员精力高度集中。由于每隔几周就有一个截止日期临近，因此，“增强”功能的倾向就会减少
9.第0次迭代
* 1）“0”意味着在时间期限内没有任何有用的东西（即功能）可以向客户交付 * 2）第0次迭代有助于团队在预期和适应之间保持平衡 * 3）有可能做为构想阶段的一部分 * 4）使用不熟悉技术之前可能需要的培训时间
10.第1~N次迭代
* 1）制定发布计划涉及的活动 * 确定已知的风险对迭代计划的影响 * 确定进度目标（不考虑可实现性，只从产品管理的角度确定进度目标） * 为每次迭代编制主题 * 将故事卡片分派给每次迭代，必要时，平衡价值、风险、资源和依赖关系 * 结合故事卡片布局（通常在墙上）、完事的发布计划或者项目停车场图总结该计划 * 运用权衡矩阵，必要时，调整完成的计划
* 2）客户价值和风险是制定功能进度计划的主要因素 * 为了降低风险，会首先选择实施高风险的功能，而推迟开发正常情况下应该首先实施的高价值的功能 * 应该认真检查风险清单，确定风险降低对发布计划的影响，特别是改变功能顺序和纳入高风险项目对发布计划的影响 * 3）目标交付日期，由营销部门、高层管理或者客户共同选择并确定。该目标确定项目团队之外的人想要得到什么东西 * 4）对于每次迭代，团队应该制定一个指导主题，这有助于团队确定重点并确保在功能的深度和广度两者之间保持平衡 * 5）主题的制定通常是从分配功能到迭代的流程中演变成而来，但有时也可以预先设定一个主题 * 6）其他技巧帮助制定可靠的进度计划： * 在每次迭代中为迭代评审期间找出的已知变化分配额外的时间，在每次迭代中放入一个标为“返工和意外事故”的故事卡 * 对于探索系数高的项目，在项目结尾留出一个或者多个“空的”迭代 * 7）在制定发布计划时，为每次迭代多安排10%的时间以应对返工和意外事件，可以使计划更加精确
11.第一个可行的部署
* 1）第一个可行的部署（FFD），即确定第一个可以部署产品的迭代 * 2）开发团队可以获得收入，也有助于验证产品概念并得到用户反馈 * 3）可部署和已部署问题一直困扰着敏捷主义者。迭代开发建造产品的可部署部分。这些可部署的部分在随后的开发中会根据不同情况逐步实施或者不被实施（部署）。实际部署更受欢迎，但并非必需
12.估计 * 1）“如何估计”这个问题暗含几个问题： * 估计未知因素 * 按功能而非活动进行估计 * 循序渐进地估计 * 估计会非常浪费时间 * 估计与设定界限 * 使用故事点和员工工作时间估计 * 2）面对未知因素时，您是在猜测而不是估计，这也是我们唯一能做的，这也是进度和成本被看作是限制而非估计的原因 * 3）项目经理必须学会将他们估计任务的经验运用到估计功能上，他们逐个地估计功能，而不是估计整个项目的需求 * 4）精益思想的原则即减少浪费，对于研究活动来说，就是消除或减少不直接产生客户价值的活动 * 5）一个减轻估计负担的方法是把估计和设定界限区分开来。设定界限是基于拥有足够的有关项目规模的信息，从而感觉发布计划是可行的
