敏捷开发
一个短迭代周期称为一个Sprint、每一个迭代的每个Sprint周期1-4周；
Scrum 采用迭代、增量的方法保持和增强可预见性，并控制风险；
3个特点:
1 透明性：
各个环节，保持高度可见性。影响交付成果的方面对参与交付的所有人、管理生产结果的人保持透明。管理生产结果的人不但需要看到过程的各个方面，而且必须理解他们看到的内容。
2 检验
检验必须足够频繁，确保能够及时发现开发过程中的偏差。还检验工作人员的技能水平和工作积极性
3 适应
检验结果的时候，发现不符合验收标准，而且最终产品是不合格的，需要对过程和材料进行调整。调整工作必须尽快展开，以进一步减少偏差。
实践：
- 每日例会，检验sprint目标的达成情况，作出调整，从而提升次日工作价值。
- 在sprint计划会议中检验发布目标的达成情况，作出调整，从而提升下一个sprint的工作价值。
- sprint回顾会议回顾已完成的sprint，并确定相应的改善措施，让后续的sprint更加高效，更令人满意。
Scrum的框架属性
3种角色
- 角色
产品负责人:负责最大化产品和开发团队的工作的价值
开发团队
Scrum Master - 特点
开发团队是自组织的，没有人告诉开发团队成员如何把产品待办事项列表变成潜在可发布的功能。
开发团队都是跨只能得，团队作为一个整体拥有创造产品增量所需的全部技能。
不认可开发团队成员的头衔，无论承担哪种工作，均是开发者。
成员可以由自己的特长和专注领域，责任归属整个开发团队。
开发团队不包含如测试和业务分析等特定领域的子团队
3种工作
- 产品待办事项列表
一个持续完善的清单，随着产品和开发环境的变化而演进，是产品需求变动的唯一来源。 - sprint待办事项列表
包含一组被当前sprint选出的产品待办事项列表条目，以及交付产品增量和实现sprint目标的计划。
通俗理解：对需求有了更好的理解而衍生的一些新的任务和开发过程中的bug。
Sprint燃尽图 展示了Sprint中剩余的工作量，它是一个反应工作量完成情况的趋势图。 - 产品增量
表示一个sprint完成的所有产品代表事项列表条目的总和，以及之前所有的sprint产生的增量的价值总和。
事件
-
sprint
其持续时间为一个月或者更短的时间，前一个结束，下一个sprint会立即开始 -
sprint计划会议
Sprint中要做的工作需要再Sprint计划会议中计划。由整个Scrum团队共同完成。 -
每日scrum站会
每日站会是一个以15分钟为限的时间，同步团队开发活动，并未接下来的24小时制定计划，需要检视自上次每日scrum站会以来完成的工作和预测下次每次scrum站会之前能够完成的工作。
内容：- 昨天，为了达成sprint目标，做了什么
- 今天，为了达成sprint目标，准备做什么
- 是否存在阻碍个人或开发团队达成sprint目标的障碍。
作用：促进开发团队成员的交流和沟通，减少其他会议数量，及时发现开发过程中需要移除的障碍，加快决策进度，以及提高团队成员的认知水平。
-
sprint评审会议
在sprint快结束时举行，用以检视交付的产品增量并按需调整产品待办事项列表。
通俗理解：拉上各方关系人，了解项目目前状况，收集反馈，探讨下一步工作，，结果是形成一个修订后的产品待办事项列表。 -
sprint回顾会议
团队检视自身并制定下一个sprint的改进计划。检视一下执勤啊优劣制定改进团队的工作方式的计划。
用户故事
用户故事从用户的角度描述用户渴望得到的功能，它是DevOps价值输出的源头
三要素
- 角色方面，存在场景和功能的区分。根据场景和功能匹配某个用户或某类用户。
- 活动，表示的是功能，体现在用户操作和对应的产品功能。
- 价值最终体现为客户得到的价值，最终价值是让产品得到市场的认可
3C原则：
Card：故事写在卡片上，包括简述、工作量估算、规则和完成标准。
Conversation：编写故事的人和客户或产品负责人的交流与沟通，确保理解没有偏差；
Confirmation：最终的验收测试课确认用户故事正确完成。
INVEST原则：
- Idependent独立原则，尽可能保持故事独立。
- Negotiate协商原则，内容需要协商，不包括太多细节
- Valuable 原则，每个故事必须对用户有价值。
- Estimatable 原则，团队需要评估优先级，工作量、工作计划、技术储备、技术实现和开发的工作量，最终估算故事需要的资源和用户故事本身的复杂度。
- Small原则，工作量上尽可能的小，不超过10个理想人天，确保能够在一个sprint中完成。
- Testable 原则，用户故事是可以测试的，不能测试就不能估算出完成时间和过程风险。
用户故事的内容
- 故事标题
- 故事描述：用户角色+活动内容+实现价值
- 规则描述：实现规则和名词定义。
- 验收标准：通过测试用例或业务验证用例
- 设计方案：包括实现的原型界面和交互规则
- 检查清单：将上线步骤进行分解。
领域驱动敏捷开发
领域驱动是一种思维方式，特点是在于解决软件核心的复杂性问题。
敏捷其实是增量交付的过程，将大需求拆成小需求，将小需求进行快速的迭代交付。需要架构设计，业务设计和需求设计相互配合。
敏捷开发：通过敏捷团队内部协作进行能力输出，
领域驱动：通过架构设计降低系统的复杂度
二者松耦合状态
架构设计层面，领域驱动能更好的为敏捷开发赋能。
敏捷开发强调增量交付，领域驱动着眼全局，结合的过程中，需要进行边界的区分。较好的实践是通过同意的领域模型，在增量交付的过程中根据新的需求不断地进行底层框架的优化，并将优化内容更新至领域模型，通过协作，将信息传递至所有组织成员。
FDD 特征驱动开发（Feature Driven Development）是敏捷软件开发的一种，特点是强调特性驱动，快速迭代，保证敏捷开发过程快速，又能保证文档的全面和高质量，时间一般在2周内。
5个活动组成：
开发一个全局模型、建立以个特征列表、依据特征进行规划、一句特征进行设计和依据特征进行重构
3种角色：
领域专家、首席架构师、主程序员。
它的本质是针对增量交付过程提前进行定义和规划。
TDD（Test Driven Development TDD）测试驱动敏捷开发
- 需要对敏捷开发团队成员进行约束，需要做到单元测试的前置，没有经过单元测试的类型，不允许交付持续地指定单元测试，不断地对单元测试哟哦哦那个李进行优化和补充。
是敏捷开发中的一种实践方式和技术，也是一种设计方法论。
测试驱动开发需要在开发功能代码之前，先编写单元测试用例代码，利用单元测试用例确定需要编写什么产品代码。
4个优点： - 减轻敏捷开发团队成员的负担
- 覆盖大范围的单元测试，提供更高质量的产品代码，敏捷开发团队可以轻松的面对需求的变化和进行内部逻辑的优化。
- 将单元测试前置，有助于理解需求，在开发阶段，对需求的细节进行开发活动验证。
- 提升反馈速度，从而提升全局的开发效率。