jmsjjyl@com 1. 敏捷革命
1. 降低实验成本足以改变产品开发的整个经济学，从基于预测的过程（定义、设计、构建）转变为基于适应的过程（想法、探索，然后适应）。
2、如果生产不同产品的成本突然下降，把这些不同产品整合成一个产品的成本变得很低，那么这个大产品不是生产出来的，而是进化出来的，我可以这么说。
3. 罗伯特·库珀：“每个公司，无论是蔬菜销售商还是坚果销售商，开罐器制造商还是汽车制造商，都在进行新产品开发战争，没有必要站在第一线。 -计划性雷击能力——和快速攻击——一直是这款新产品成功的关键因素。机动性和速度让雷击能够趁机抓住或捕获敌人。”
4. 最终客户价值是在销售时交付的，而不是在规划时交付的。
5.打着敏捷方法幌子进行专业化开发的人都是彻头彻尾的骗子。
A. 敏捷业务目标
1. 一个好的探索过程（例如敏捷项目管理）必须实现五个关键业务目标：
*1) 持续创新以满足当前客户需求
* 这种持续创新的过程是由我们致力于创造为客户提供价值并满足当今客户需求的产品所驱动的。
* 创新思想诞生于基于自组织和自律原则的不断适应的氛围中，而不是千篇一律的独裁环境中。
*2) 产品适应性以满足未来客户需求
*如果我们想要我们的产品长期占领市场，我们就必须努力提高我们的适应性。
* 在敏捷项目中，技术卓越性通过两个方面来判断：第一，立即交付客户价值的能力；第二，创建高度适应性产品的能力。
* 敏捷技术实践侧重于减少技术债务（增加适应性），作为开发过程的一个组成部分。
* 在敏捷项目中，开发人员追求卓越，项目经理提供支持
*3) 缩短交付时间、提高市场满意度并提高投资回报率(ROI)
* 缩短交付周期和满足市场需求仍然是项目经理和主管应优先考虑的企业目标。
* 敏捷项目管理的迭代、基于功能的本质可以通过三种方式缩短交付周期：专注、简化流程和培养技能。
* 4）人员和流程的适应性，快速响应产品和公司的变化
* 如果你想要一个适应性强的产品，你需要建立一个适应性强的团队，其成员拥抱变化
* 敏捷项目管理的核心原则和结构鼓励学习和适应，作为向客户提供价值的一个组成部分。
*5) 坚实的业绩记录支持业务增长和盈利能力
* 发现项目无法产生已知的、完全指定的结果，但它们可以产生有价值的结果。 —— 满足客户目标和业务需求的可交付成果
* 良好的探索过程可以提供持续的创新
2、重复过程是指用同样的方法做同样的事情，得到同样的结果，而任意过程是指在制造过程中无论遇到什么障碍都能达到目标，即永远实现-改变目标。
3. 当目标是交付符合已知且不变的规格的产品时，请使用迭代过程。相反，如果目标是交付具有一定价值限制的产品，并且变化和截止日期是重要因素，则可靠的流程更合适。
B. 定义敏捷
1. 敏捷性是指在动荡的商业环境中创造和应对变化以创造利润的能力。
2.敏捷性是平衡灵活性和稳定性的能力。
3. 创造变革可以扰乱竞争对手（及其整个市场体系），但应对变革可以防止竞争冲击。制造业的变革需要创新。这意味着开发新产品，建立新的销售渠道，缩短产品开发周期，并为日益缩小的细分市场定制个性化产品。此外，公司必须能够快速响应竞争对手和客户的可预见和不可预见的变化。
4.根据复杂性理论，创新（即创造出无法完全预测的新的、意想不到的结果）最有可能在混乱与秩序、灵活性与稳定之间的平衡点上出现。
5、组织结构太严格会抑制创造力，组织结构太松则会降低效率。
C. 敏捷价值观
1.敏捷是态度，不是过程，是氛围，不是方法。
2.伟大公司的基础（核心价值观和宗旨）往往保持不变，但他们的战略（业务）和实践（商业实践）却是一样的。
3. 在高绩效团队中，领导者管理原则，原则管理团队
4. 团队为何存在、他们创建什么产品、为谁创建以及他们如何协同工作，这些构成了敏捷项目管理的核心原则。如果你想创造伟大的产品，你需要伟大的人才，如果你想吸引和留住优秀的人才，你需要伟大的原则。
5、没有行动的宏大原则只是空想；反之，没有指导的具体实践往往会导致不合理的运用。
6. 敏捷宣言
* 个人和互动优先于流程和工具
* 工作软件胜过全面的文档
*客户合作优先于合同谈判
* 响应变化而不是遵循计划
*右边的物品有价值，但我认为左边的物品更有价值。
7. 相互依存声明
* 持续为客户创造价值，提高投资回报
* 通过与客户的持续对话和共享所有权来提供值得信赖的结果
* 预测不确定性并寻求通过重复、预防和适应来解决它。
*个人价值成为团队价值的源泉，创造个人成长的环境，实现创造和创新。
* 激发成员的使命感和责任感，提高团队绩效
* 使用相关政策、流程和实践来提高效率和可靠性
8. 平等主义精英的核心价值观强烈影响敏捷运动。当然，这些核心价值观并不是制造产品的唯一因素，但它们定义了大多数敏捷主义者如何看待自己。
9. 敏捷管理者应具备的信心价值：
* 提供价值优于满足约束（价值优于约束）
* 领导团队执行行政任务（任务团队）
* 适应变化比遵循计划更好（适应比遵循更好）
10. 传统项目经理专注于遵循并遵守计划，而敏捷项目经理则专注于如何成功适应不可避免的变化。
11.技术品质是持续创造价值的决定性因素
D. 敏捷绩效评估
1. 敏捷项目评估的三个目标：
* 价值目标—— 提供可交付成果
* 质量目标—— 提供可靠且适应性强的交付成果
* 约束目标—— 在可接受的约束范围内实现价值和质量目标
2. 敏捷三角的演变
E. 敏捷项目管理结构
1. 以生产为导向的项目管理流程和实践强调彻底的早期规划和需求规范，以便需求在未来尽可能保持稳定。另一方面，基于探索的流程（名义上）也强调早期规划，但更强调足够好的需求和设计可以试验和改进的解决方案，允许通过持续学习做出重大改变。
2. 敏捷项目管理实践包括五个阶段：构思、猜测、探索、适应、收尾。
3. 构思阶段产生清晰的业务或产品创意，为后续阶段划定界限。在思考阶段，团队推测产品规格并制定发布计划。随着项目的继续，技术和客户要求变得更加清晰。它随着新知识的获得而不断发展，然后是探索阶段，这是一个类似的迭代练习，完成功能和需求的初始设计，以及适应阶段，必须获得这些实验的结果。应根据具体情况审查技术、客户和业务，以便在下一次迭代中继续进行调整。
F. 敏捷项目成功率
1. 至少，敏捷方法有可能显着提高您的竞争优势。您可以显着提高生产力、质量、时间，并最终改变您的整个业务模式。
2. 敏捷项目管理不限于少数实践或方法论，而是专注于交付可交付成果、创造和适应变化、保持灵活性与结构、创造力与发展之间的平衡。定义战略能力，例如利用创造力。能够创新并领导团队和组织度过动荡和不确定的时期。
2.价值观胜过约束。
1. 成本和进度等限制很重要，但为客户创造价值也很重要。人们常常关注容易衡量的因素，而忽略真正重要但难以量化的特征。
2. 团队注重结果，更有可能创造真正的商业价值，即使注意力很少——
3. 结果包括产品创意、业务目标和性能（高级产品功能），无需特定要求。
4. 质量目标定义了可靠且适应性强（实用且易于改进）产品的交付，这是关键价值属性。
5. 项目负责人可以通过以下方式关注产品价值：确定价值（客户互动）、确定价值优先级（订单管理）和创造价值（迭代开发）。
* 确定价值通常是业务经理和产品经理的职责，但项目负责人也经常参与成本/效益分析和价值确定，特别是在产品公司中。
* 价值优先主要是产品经理的工作，但项目负责人也应该参与其中，特别是在面向客户或技术要求未知时。
*项目团队内的价值创造是指与客户协作、对客户需求进行分组以及减少技术债务（确保质量和价值交付）等活动。
A、持续创造客户价值
1. 通过持续创造客户价值提高投资回报—— 相互依存宣言
2.价值是指公司或组织的生产成果，通常与财务回报相关。
3.可持续性意味着价值观经得起时间的考验，无论是现在还是未来。
4. 在软件设计行业，及时交付软件的第一个版本很重要，但更重要的是交付能够适应未来需求的优质产品。
5. 客户和产品经理驱动敏捷开发
6. 客户确定产品应具有的性能、提供的价值以及量化该价值的业务目标。
7. 满足当前客户需求但无法轻松适应未来需求的产品注定生命周期较短。
8. 成功的秘诀很简单—— 今天交付，明天适应。
9. 客户是使用所创造的产品创造商业价值的个人或团体。
10. “利益相关者”是指与项目相关、协助定义产品的商业价值和其他限制的个人。
11. 如果你想为客户提供具有巨大价值的产品，你需要在客户和开发者之间建立一种合作伙伴关系，双方都有责任和义务。
12. 敏捷团队始终寻求客户参与，总是询问客户：“我们正在做的事情是否有助于我们实现业务目标？”
13. 交付客户价值涉及三个特别重要的主题：关注创新和适应性而不是效率和优化、关注执行以及精益思维。
14.“我们生活在一个创造力、创新和想象力主宰世界的时代。” —— Tom Jack Wu 和Sandra Muscat
15. 创造新产品或服务不同于对现有产品进行小幅改进。
* 前者必须注重创新和适应性，而后者通常注重效率和优化。
*效率提供可以想象的产品和服务，创新提供难以想象的产品。
* 效率和优化对于生产型项目是有益的推动，而创新和创造力对于探索性项目是有益的推动。
*生产性思维倾向限制了我们对可能解决方案的想象力，而探索性思维倾向帮助我们探索看似不可能的事情
*优化是我们知道怎么做但需要改进的事情，创新是我们不知道怎么做的事情，所以求知非常重要。
16. 当项目经理专注于交付活动时，它会增加项目的价值，但当它专注于计划和控制时，它会增加管理费用。
17. 传统的项目管理技术由三个信息交换过程组成：计划、控制和执行。
18. 传统计划存在几个问题。
* 规划的动机通常来自项目外部。换句话说，规划的目的是满足法律、法规或行政要求。
* 计划的动机通常与控制欲有关，而不是与实际执行任务的需要有关。
* 计划和控制是重点，执行是最不重要的。
19. 在敏捷项目管理中，项目经理的首要任务不是制定计划和进度、控制进度、确保“计划”得到执行，而是促进产品创意的构思，而是指导你的团队把他们的想法生活。
20. 敏捷项目管理不是反计划模型。规划（和控制）是敏捷项目管理的重要组成部分，但不是重点
21. 敏捷运动中的许多想法都来自精益制造。精益制造的基本原则是系统地消除浪费，即减少不为客户提供价值的活动。
22. 简化项目（做更少的工作、做正确的工作、消除瓶颈）的一种方法是区分交付活动和合规活动，并对每项活动采取单独的策略。
23.太多的结构不仅扼杀主动性和创新性，而且占用大量时间。根本问题不在于这些解决方案有什么优点，而在于它们从根本上强调过程而不是个人知识和能力。
24. 与交付相关的活动和合规活动对于项目经理来说特别重要。
* 项目经理应该分析项目活动，以确保他们将最多的时间花在交付活动上。
*项目经理需要分析自己的活动并决定是从事交付活动还是合规活动。
B. 基于特征的迭代交付
1.想要创新，就需要迭代。
2. 敏捷项目可以在项目的整个生命周期中快速、增量地交付价值。采用基于功能的迭代交付方法可以提供早期价值捕获，并且通常可以显着提高项目投资回报率。
3. 完成一份需求文档仅证明团队已经成功收集了一组需求；完成或演示了一组工作产品功能并不能证明开发团队实际上证明你已经向客户提供了一些东西。
4. 敏捷的迭代部分可以用四个关键词来描述：迭代、基于功能、时间盒和增量。
* 迭代开发涉及构建产品的部分版本，然后通过持续的短期开发、审查和修订来扩展该版本。
*基于功能的交付，特别是对于工业产品，是指设计团队构建最终产品的功能，或者至少是最终产品的最接近的表示（模拟、模型等）。
* 迭代必须在特定的时间范围内产生结果——（软件为1-4 周） —— 。这将强制迭代结束，您必须在完全准备好之前创建部分实体。
* 增量开发是指构建一个经过一次或多次迭代后可以及时调用的产品。
5. 如何交付功能：客户确定功能的时间表和优先级，产品工程师确定交付这些功能所需的任务以及完成这些任务的时间和成本。
6. 对于需求可能随时间变化的项目或产品，让客户在开发过程中审查结果尤为重要，以便它们尽可能接近实际产品。
7、迭代开发也是一个自我修正的过程。自我修正最重要的方面是随着产品的发展客户提供的反馈。
8. 当进化被纳入后续的开发迭代中时，客户对产品的信心就会增加。或者，相反，很明显该产品不起作用，需要尽早丢弃。
9. 鼓励探索很重要，但知道何时停止也很重要
10.“在迭代开发的最初几年，我认为时间盒只是时间问题，但后来我意识到时间盒实际上是一个很难做出的决定。”
C、技术过硬
1. 敏捷开发人员致力于卓越技术并不是为了美观，而是因为他们对卓越技术的承诺可以带来客户价值。项目领导者必须是卓越技术的拥护者，并支持和促进它，同时还要关注其他项目目标。
2. 高质量确保公司在未来创造价值。许多软件都存在技术债务和质量问题造成的问题累积。
3. 敏捷开发人员相信迭代、新设计和频繁的反馈会带来更好的设计。
4. 没有一家公司能够创造出完美的产品，但创造一种能够提供客户价值并保持技术完整性的产品是业务成功的关键，也是让你的技术团队保持快乐的关键。
5. 项目经理必须与团队一起讨论并决定开发的技术方法。在决定技术问题时，团队需要牢记公司的目标。虽然项目经理不必做出决策，但他们做的工作足以保证团队成员相互沟通，使团队能够充分消化和吸收项目信息并及时做出适当的技术决策，你必须具备以下知识。
6.项目经理必须支持好的技术。这是适应性和低成本迭代的关键，两者都推动产品的长期成功。项目经理不一定是技术权威，但必须有足够的知识与这样的技术权威沟通
D、简化
1.“如果你想让你的船走得更快，割断锚绳比增加马力更容易。”—— Luke Howe
2. 如果你想快速敏捷，就让事情变得简单。速度不是简化的结果，但简化可以提高速度
3.“简化很重要。这是最大限度减少不必要工作的艺术。”—— 敏捷宣言
4. 通过消除基于任务的详细结构来简化流程，合规工作迫使人们思考和沟通。
* 为什么你认为曾经有效的方法会再次有效？
* 为什么我们认为重要的事情是可以评估的？
* 为什么你认为领导力、管理和变革等词对每个人来说都有同样的含义？
* 您为什么认为减少不确定性会增加确定性？
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. 共享空间：
* 创新不是由某些确定性过程来保证的，而是一个安全过程的结果，在这个过程中，具有创造性想法的个人相互互动，并导致创造出新的和不同的东西。演示、原型、模拟和模型促进了相互沟通，并创建了一个“共享空间”，让开发人员、营销人员、客户和高管可以进行有意义的互动。
*共享空间有两个要求：可见性和公共关系。
* 直观：当工程师与客户讨论原型并处理功能而不是文档时，相互沟通的质量会显着提高。
* 公开：意味着原型需要开发工作中的各方都理解
九、客户合作：
* 客户或产品团队必须成为敏捷开发工作不可或缺的一部分
* “敏捷”常常指出客户和产品团队的缺点，并指出需要定义自己相对于产品团队的角色。
D. 不再需要自组织团队。
1. 如果自组织要继续发挥价值，需要解决几个问题。
* 需要删除视角—— 敏捷项目没有领导者，或者领导者是谁取决于具体情况。
* 拥护授权自组织团队的观点已经过时了—— 良好的领导力将授权团队与持有适当的决策权结合起来
4. 适应胜于跟随
1.“传统项目经理专注于遵循计划并努力遵守计划，而敏捷项目领导者则专注于如何成功适应不可避免的变化。”
2、客户价值和质量是目标，规划是实现这些目标的方法，而不是目标本身。
3. 传统管理者不断调整实际结果以匹配基线。 PMBOK 称为纠正措施，用于使团队回到基线。适用的行动用于描述应采取的行动方案（可以更改其中一项行动以符合计划要求）
4.《敏捷宣言》和《相互依赖声明》包含与适应性相关的五个原则。
* 《声明》：预测不确定性并寻求通过重复、预防和适应来解决它。
* 《声明》：使用特定于环境的政策、流程和实践来提高效率和可靠性
* 《宣言》：响应变化而不是遵循计划
* 《宣言》：即使在产品开发的后期阶段，我们也会主动拥抱不断变化的需求，并使用敏捷流程来充分利用变化，为客户提供竞争优势。
* 《宣言》：团队定期考虑如何变得更有效，并相应地调整团队的行动。
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）一个减轻估计负担的方法是把估计和设定界限区分开来。设定界限是基于拥有足够的有关项目规模的信息，从而感觉发布计划是可行的
微信扫一扫打赏
支付宝扫一扫打赏