Agile速查
敏捷宣言：4条
个人和互动 > 过程和工具
可以工作的软件 > 详尽的文档
客户合作 > 合同谈判
应对变化 > 遵循计划
敏捷原则：12条
- 我们的条最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
- 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优秀。
- 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
- 项目实施过程中，业务人员与开友入员必须始终通力协作。
- 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
- 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
- 可用的软件是衡量进度的首要衡量标准。
- 敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保 持步调稳定。
- 对技术的精益求精以及对设计的不断完善将提高敏捷性。
- 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
- 最佳的架构、需求和设计将出自于自组织团队。
- 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
Scrum的四个会议
Scrum的过程的流程，以Sprint为最小单元。本质上每个Sprint内，都有一个PDCA戴明环。
一个 Sprint 通常通过4个会议来规划执行，分别为：
- 迭代计划会
- 每日站会
- 迭代评审会
- 迭代回顾会。
首先， Scrum 团队通过开展迭代计划会来开启 Sprint 。迭代计划会中主要围绕两个基本问题进行：
- 在这个 Sprint 中可以完成哪些工作？
- 如何完成这些工作？
- 确定 Sprint 的工作需要
Scrum涉及的人员如下：
- Product Owner（产品负责人）
- Scrum（敏捷教练）
- 开发团队 。
角色职责
由 Product Owner 根据已经做好优先级排序的 **Product Backlog **（产品待办事项列表）选择本次 Sprint 要完成的目标工作。
然后，开发团队基于产品需求列表确定工作量，即 Sprint Backlog（迭代待办列表），并讨论如何在 Sprint 结束之前完成这些目标工作。
在 Sprint 结束前，团队集中精力完成迭代待办事项列表计划的工作项。
在 Sprint 期间，团队在每日站会同步工作的进展情况，会议的内容主要围绕以下三个问题展开：
- 昨天我做了什么事情帮助开发团队达成Sprint目标？
- 今天我要做什么帮助开发团队达成Sprint目标？
- 是否有任何障碍在阻碍我或开发团队达成Sprint目标？
在 Sprint 结束后，团队通过迭代评审会展示他们 Sprint 的工作成果。该会议主要是对 Product Owner、客户等利益相关者展示做好的软件产品，研发团队每一个成员都会参与展示。最后，团队通过回顾会议来复盘本次 Sprint，明确下次 Sprint 的改进点，帮助更好地完善 Sprint 。
用户故事的确认
分三类：
- 史诗基于产品的长期战略方向而被提出，需求级别最大，通常为可独立使用的一个产品模块，通常是一些特性的集合。
- 特性，作为比史诗更具体的子需求和若干个用户故事的集合，承上启下。
- 用户故事，是从用户的角度编写的简短需求或请求，能在一个迭代中开发完成。
用户故事一般由产品负责人（Product Owner）、产品经理或项目经理撰写和审核，撰写完成后将进入团队的研发流程当中。
在迭代前期或迭代计划会议期间，团队要确定本次迭代要完成哪些用户故事，并讨论每个用户故事场景下的需求和功能。团队在为每个用户故事构建解决方案过程中将激发成员的创意以及学习到其他技术。当研发团队对用户故事的实现方案达成一致，就会在用户故事中补充功能实现相关的需求描述。
在编写_用户故事_时需要考虑以下几点：
- “完成”的定义——当概述完一个用户故事后，一定要定义其完成的标准是什么。
- 概述子任务或任务——确定需要完成哪些特定步骤以及每个步骤的负责人。
- 用户角色——用户是谁？如果有多个用户，则需要考虑编写多个用户故事。
- 有序步骤——给大规模流程的每一个步骤写用户故事。
- 倾听用户声音——与您的用户交谈并从他们的角度来描述问题和需求。当能够从客户那里获取用户故事时，就不用猜测客户需求了。
- 时间——时间是一个敏感的话题。许多研发团队在评估时会忽略用户故事的实际完成时间，只依靠过往的估算经验来评估。用户故事应当在一个迭代中完成，因此应该把那些数周或数月才能完成的用户故事拆分成更小的用户故事，或者应该把它们上升为特性层级。
用户故事通常用一个简单的句子来表达，结构如下：
“作为一个[XX角色]，我[想要什么]，[以便达到什么目的]。”
结构分解如下：
- “作为[XX角色]”：我们是为谁实现这个需求？我们不仅要知道用户的职称，还要了解用户角色的特点。研发团队应该对用户角色有一个共同的理解。团队应该尽可能多地采访目标用户，了解他们的工作方式、想法和使用感受，对用户要有同理心。
- “想要什么”：这里我们描述的是用户的意图——而不是他们想使用的功能。用户本质上想达到什么目的？这个描述不用体现功能的实现——如果你描述的是软件功能而不是用户目标，就没有抓住重点了。
- “以便达到什么目的”：用户期望做的这件事符合他们的规划吗？他们想实现的整体效果是什么？需要解决的本质问题是什么？
参考：
- pingcode
- 《敏捷实践指南》