SAFe敏捷开发

一、敏捷开发介绍

1.什么是敏捷开发？

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

2.敏捷核心思想

• 价值驱动
  • 体现在传统的开发模式和敏捷开发模式的对比
• 适应变化
  • 创意、产品、市场的不确定性，迭代开发对于需求变更，进行修改、建立快速反馈
• 自组织团队
  • 训练个人能力、配合能力

3.传统的开发模式和敏捷开发模式的对比

瀑布模型：

优点：

1. 为项目提供了按阶段划分的检查点。

2. 当前一阶段完成后，您只需要去关注后续阶段.

3. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。

敏捷模型：

优点：

1. 敏捷开发的高适应性，以人为本的特性。
2. 更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

缺点：

1. 由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

二、敏捷开发Scrum软件

1.Scrum是什么？

​ Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

​ Scrum 是用于开发、交付和持续支持复杂产品的一个框架，规则是把角色、事件和工件组织在一起，管理它们之间的关系和交互。

2.Scrum框架

​ scrum框架包括3个角色、3个工件、5个事件、5个价值

• 3个角色

  ​ 产品负责人(Product Owner) Scrum Master 开发团队

• 3个工件

  ​ 产品Backlog(Product Backlog) SprintBacklog(冲刺待办事项) 产品增量(Increment)

• 5个事件

  1. Sprint(Sprint本身是一个事件，包括了如下4个事件)
  2. Sprint计划会议（Sprint Planning Meeting）
  3. 每日站会（Daily Scrum Meeting）
  4. Sprint评审会议（Sprint Review Meeting）
  5. Sprint回顾会议（Sprint Retrospective Meeting）

• 5个价值

  1. 承若 ——> 愿意对目标做出承诺
  2. 专注 ——> 把你的心思和能力都用到你承诺的工作上去
  3. 开放 ——> Scrum 把项目中的一切开放给每个人看
  4. 尊重 ——> 每个人都有他独特的背景和经验
  5. 勇气 ——> 有勇气做出承诺，履行承若，接受别人的尊重

角色介绍：https://www.scrumcn.com/agile/scrum_guide.html

3.Scrum理论核心

• 透明性（Transparency）

  透明度是指在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。

• 检验（Jnspection）

  ​ 开发过程中的各个方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。

• 适应（Adaptation）

  如果检验人员检验的时候发现过程的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。

​ Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

4.Scrum流程图

1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的；

2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。

6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

三、开发流程的形成

其实像交付流水线，包含了多个用户故事(User Story)、用户故事包含了多个故事点，是基于整个团队来基准和估算。

1.用户故事

从用户的角度来描述用户渴望得到的功能。

用户故事包括三个要素：

• 角色：谁要使用这个功能
• 活动：需要完成什么样的功能
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

作为一个“网站管理员”，我想要统计每天有多少人访问了我的网站，以便于我的赞助商了解我的网站会给他们带来什么收益。

故事主程：

​ 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

​ 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

​ 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事特性

​ 原子性：一个用户故事独立于其他用户故事

​ 细节讨论：一个用户故事内容是互相讨论协商

​ 用户价值：每个故事必须对客户具有价值

​ 具体可以估算：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划

2.故事点

​ 故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

3.敏捷估算

1. 相对估算，使用故事点作为单位，故事点是一个相对倍数。

2. 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。

3. 敏捷估算关注团队的速度，不关注单个人的速度。

4. 通过总规模和团队速度，推算周期。

总结：一个故事分为多个故事点基于一个小故事估算，可以快速得到用户的反馈，快速往前进、业务规则以及调整修改、对应的业务场景。