敏捷总结
- 教练和指导的定义是 C：指导个人或团队提高绩效
- 敏捷团队往往使用故事点来估算开发一个用户故事的相对大小或工作量。
- 项目章程是重要的管理文件，需要所有干系人的参与。虽然专家建议章程应不超过一页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。
- 项目章程中应包含3个关键信息：愿景，任务和成功标准。
- 敏捷开发中的主题是指一组相关的用户故事。
- 当估计敏捷项目时，宏观方法是常用的。首先是高级估计，接着是详细估计。
- 敏捷团队应约定使用一种估算方法，故事点或者理想时间，因为这两种方法使用不同的测量单位，会造成混乱。
- 敏捷开发的基石是“增量交付”。增量交付是指为及时反馈和接纳，频繁向客户交付连续改进的工作产品。为演示和反馈，往往在每一个冲刺或迭代的末期交付产品。这项反馈技能，可使客户评价产品并提出新的需求。在敏捷流程中，接受变动/更新/改善的需求，以确保客户得到有价值和质量的产品。一个冲刺或迭代往往持续2-4周，最后，渐进地交付一个新的持续改善的产品。
- 敏捷项目管理着重强调“持续完善”。从迭代后客户提供反馈，到迭代后团队保留时间回顾和反思执行情况，持续完善已经进入敏捷方法论中。 持续完善也是精益方法论的一个重点原则，注重从价值流中清除浪费。
- MoSCoW技术通常用在敏捷中，把用户故事以降序进行优先级排列： M-must have必须有； S-should have应该有； C-could have可能有； W-won’t have this time这次不会有。 必须有的事物是对开发很重要的产品特征。 应该有的事物是对开发不是很重要但有重要商业价值的产品特征。 能有的事物是能增加一些商业价值的产品特征。 会有的事物是有一点商业价值的产品特征。
- 增量交付是指为及时反馈和接受，频繁向客户交付连续改善的工作产品。
- 动态系统开发方法DSDM会特别关注产品的适用性和市场性
- 在迭代计划中，团队根据三部曲去设计迭代待办事项： 1.团队分解大的或复杂的用户故事为多元的，小的故事 2.团队把每个用户故事分解为开发任务 3.团队估算理想时间。
- 当启动一项新敏捷开发工作时，项目团队应该决定使用哪种敏捷方法。这也称为过程裁剪。敏捷团队自己决定项目采用哪种敏捷实践或者标准，比如团队是否进行每日站立会议以及其持续时长，团队使用何种信息发射源，团队如何估算和计划产品特性等等。
- 敏捷反馈技术包括 样板 模拟 演示 评价 结对编程 单元测试 持续整合 每日站立会议 冲刺计划
- 在敏捷中教练和指导不单是为新生的或未成熟的团队服务，同时由于指导有助于达到高水平的绩效，所以也服务于有经验的团队。对于敏捷团队而言，教练和指导的尺度是可变化的
- 部分常见的问题解决技能包括： 大声提问； 再次讨论问题； 5Y； 沉没成本谬误； 持不同意见的人； 保持善良，开放； 提问探究性问题； 积极聆听。
- 传统的铁三角包括的参数是范围，进度和成本；而价值，质量和约束是敏捷三角的参数。
- 在大的、复杂的项目里，敏捷项目领导能通过使用滚动计划制定迭代计划。
- 商业论证是对项目的目标，策略，里程碑，所需投资和预期回收进行说明的文件。商业论证向客户阐明该项目为什么和怎么样会带来价值。
- 敏捷提倡增量交付，频繁发布产品，所以要频繁进行验证和确认
- 漏筛缺陷是一个软件缺陷，没有被开发或测试团队发现，但是后来被终端用户发现。
- 敏捷项目管理着重强调“持续完善”。从迭代后客户提供反馈，到迭代后团队保留时间回顾和反思执行情况，持续完善已经进入敏捷方法论中
- 常见的敏捷架构/方法论包括： scrum， XP极限编程， 精益软件开发， 水晶， 特性驱动开发（FDD）， 动态系统开发方法（DSDM）， 敏捷统一过程（AUP）。
- 原型是向客户展示设计概念的低成本和低风险的方法，意在开发前获得用户反馈。
- 反馈是一个动态流程，过去的信息影响着未来的行为，敏捷反馈技术包括 样板 模拟 演示 评价 结对编程 单元测试 持续整合 每日站立会议 冲刺计划 因为敏捷的环境是透明和协作性的，所以反馈是普遍存在的。
- 因为每一项迭代通常产生的工作产品是完整的，迭代往往持续2-4周，期间不断地进行验证和确认以确保产品的质量。 验证是为了确保产品的执行符合客户的需求，确认是为了证明产品符合预期 有时候一个产品可能是依照规范执行的，即它可通过验证，但是它并不符合客户的目标，即它不能通过确认。
- 敏捷中一个常见的误解是敏捷团队并不需要一个领导者。事实上，所有的敏捷团队都需要领导者，但是领导团队的方式从根本上是不同于传统的项目管理人员的。虽然自组织的敏捷团队拥有产品的所有权并承担责任，同时可自行决策，但仍需要一个领导者来鼓励引导团队成员、帮助排除障碍，促进协作等
- 敏捷团队必须时常处理产品待办事项里的产品特性优先级问题。确保高质量和高价值的特性优先得以开发。
- 项目章程是重要的管理文件，需要所有干系人的参与。虽然专家建议章程应不超过一页，但是因为所有的干系人必须参与进来并且达成一致意见，所以创建项目章程是非常具有挑战性的。 项目章程中应包含3个关键信息：前景，任务和成功标准。
- 敏捷是拥抱变化的，但变动的范围使总成本的估算更艰难。
- 为了促进知识分享，敏捷采用标准实践如下： 跨职能团队， 自主管理和自我约束团队， 协作， 每日站立会议， 迭代/冲刺计划， 发布计划， 结对编程 项目回顾/反思 现场客户支持。
- 产品路线图是产品需求的高层次概述，常用作对特性进行优先级处理
- 速度是指在一次迭代中完成的故事点数
- 在定义迭代长度时，敏捷团队应思考如何交付大量有价值的产品设计目的，故事定义和开发，以及客户接受的故事。
- 敏捷项目管理的重点特征包括： 持续完善， 多功能团队， 短迭代， 增量开发， 商业优先权 客户的价值。
- 滚动计划（或计划前滚动rolling look ahead planning）包括部分波动性和阶段性的计划，尤其是在大型复杂的项目中作用明显。只有未来几个迭代会作细节计划，而时间较远的迭代则只作高层次计划。逐步完善则假定细节和需求会逐步得到改良，并且会适时融入到计划中。
- 一个成功的头脑风暴应尽量遵循以下几点： 在中立和舒适的环境中进行会议。 由一名有趣且有经验的引导者来主持头脑风暴会议。 提前向参与者分发包括目标，安排和基本原则的文件。 召集一个多领域/多样化的团队，来实现许多不同的期望。 排除任何会阻碍想法产生的言论。
- 验证是为了确保产品的执行符合客户的描述需求，确认是为了证明产品的执行符合预期（即符合客户需求）。所以频繁进行验证和确认可以保证产品的质量符合客户的需求
- 最小可售功能（MMF）是一个最小和可市场化的软件特征或者产品特佂。“最小”的意思是简单和小，并且不复杂。“可市场化的”的意思是拥有部分价值，无论是产生收益或者节约成本，都可进行市场化或者销售。
- 一个成功的头脑风暴环节应尽量遵循以下要点： 在中立和舒适的环境中进行会议。 由一名有趣且有经验的引导者来主持头脑风暴会议。 提前向参与者分发包括目标，安排和基本原则的文件。 由一个多领域/多样化的团队组成 排除任何会阻碍思想产生的评论。
- 增量交付往往是在每一个冲刺或迭代的末期对交付产品提供反馈，使客户评价产品并提出新的需求，以确保客户得到有价值和质量的产品。
- 商业论证是对项目的构想，目标，达到目标的策略，重大事件，所需投资和预期回收所做的简明概要文件。商业论证向客户阐明该项目为什么和怎么样会带来价值。
- 时间箱是对一项行为、任务或者事件执行的时长所做的预估。
- 敏捷项目计划为说明总体特性提供初始概述，并包含预测重大事件的粗略项目进度；然而，敏捷项目计划是不断变动的，随着客户需求改变而改变。
- 产品路线图是对产品需求的高层次概述。
- 定义验收标准通常是在发布计划过程中，与用户故事一起定义的，但是，一旦用户故事被放到迭代中，那么验收标准可以在迭代计划中定义。其中固定的规则是，验收标准必须在开发开始前定义。
- 商业论证是对项目的构想，目标，达到目标的策略，重大事件，所需投资和预期回收所做的简明概要文件。
- 敏捷宣言的第二价值指的是其右项价值，敏捷宣言的首要价值指的是其左项价值
- 敏捷项目中的两个待办事项是产品待办事项和冲刺待办事项。
- 敏捷工作均有项目和质量标准，在一项工作初期由团队协作地定义，并在整个工作期间协作地改进。
- 传统的铁三角包括的参数是范围，进度和成本；而价值，质量和约束是敏捷三角的参数。
- 敏捷项目管理的重点特征包括： 持续完善， 多功能团队， 短迭代， 增量方法， 商业优先权 客户的价值。
- 敏捷团队鼓励参与式决策模型
- 产品路线图常用作对特性进行优先处理，是特性归类和大致时间框架确定的工具。
- 常见的敏捷架构包括： scrum， XP 极限编程， 精益软件开发， 水晶， 特性驱动开发（FDD）， 动态系统开发方法（DSDM）， 敏捷统一过程（AUP）。
- 商业论证是对项目的构想，目标，达到目标的策略，重大事件，所需投资和预期回收所作的简明概要文件。
