Agile（敏捷开发）

敏捷开发是什么？

敏捷开发（scrum）是一种软件开发的流程，强调快速反应、快速迭代、价值驱动。

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；运用该流程，你就能看到你团队高效的工作。

敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

是谁这么厉害，提出了敏捷开发思想？是一位名叫 Martin Fowler 的美国大叔。

大叔不但是敏捷开发的创始人之一，还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

Scrum开发3个角色

• Product Owner(PO) -- 产品负责人，产品所有者

• Scrum Master(SM) -- 敏捷顾问

• Development Team -- 开发团队

细分之11个角色（领域和技术）

加号为必须有的成员，其它视情况而定

领域

+Product Owner(PO)--产品方向及目标，并根据使用者的需求来设计有价值的产品
+Scrum Master(SM)--顾问，确保团队是用敏捷的方式进行工作，追踪维持团队的效率
Translator(技术转译)--协助PO理解技术内容，商业价值和技术沟通的桥梁
Domain Expert --某个领域的专家，协助PO来判断产品价值
Change Agent -- 公司内位阶较高者，协助SM来排除由于组织等造成的阻碍，加上组织变革的脚步

技术

+Tech Lead --设计技术架构并协调领导开发团队和技术方向，依照设计撰写程式，解决开发过程中的错误
+UI/UX Designer -- 设计使用者界面
+Developer -- 真正打造应用程式的程式设计师
Data Architect 负责提供资料数据来源及设计整个数据架构
Data Scientist--透过探索分析数据已及建立模型来寻找潜在的价值
Data Engineer -- 负责处理整个数据与资料流中运算、储存分析与实作的各种相关事情

主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任。

流程管理员（Scrum Master）

问题清道夫！主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

开发主力！主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；不论过程只问结果！只要能达到目标，不论任何工作时间、方式。

产品负责人、产品所有者（Product Owner）

在Scrum的产品所有者(product owner)通常是项目的主要利益相关者。产品所有者的部分职责是——了解用户希望构建的内容，并将这一愿景传达给Scrum团队。这个角色是成功启动所有的敏捷软件开发项目的关键。敏捷产品所有者(PO)部分通过产品待办事项来执行此操作，产品待办事项（ product backlog）是产品的优先级功能列表。

产品所有者(PO)通常是正在开发的软件或系统的的主要用户，他可能来自市场、产品经理，也可能是任何对用户、市场、竞争以及正在开发的系统领域或类型的未来趋势有深刻理解的人。

当然，这取决于团队是开发商业软件，内部使用的软件，硬件还是其他类型的产品。关键是产品所有者(PO)角色需要对即将构建的产品有一个愿景。

虽然敏捷产品所有者（PO）在sprint计划会议期间优先考虑产品待办事项，但团队成员会选择他们认为在每个sprint期间可以执行的工作量，以及估算大概需要多少sprint。

产品所有者（PO）不会说，“我们剩下四个sprint冲刺，因此你必须做四分之一的产品待办事项来完成这个冲刺。” Scrum产品所有者的工作是以明确的目标来激励团队。团队成员最了解自己的能力，因此他们从产品待办列表中选择那些可以承诺交付的用户故事。

作为Scrum团队，致力于从产品待办事项的顶部完成所选用户故事的回报，产品所有者也要做出相应的承诺，不在sprint期间向团队提出新要求、允许更改要求（并鼓励更改），但仅限于sprint之外。一旦团队开始冲刺，它仍然专注于冲刺的目标。

产品所有者（PO）角色要求具有这些技能和特征——包括可用性商业头脑和沟通技巧。首先，Scrum产品所有者需要向他的团队提供帮助。最好的产品所有者通过尽一切可能建立最好的产品来表现出承诺 ——他会积极参与他们的团队。

商业头脑对敏捷产品所有者很重要，因为他（她）决定了产品具有哪些功能。这意味着，敏捷产品所有者应该了解市场、客户和业务，以便做出正确的决策。

最后，沟通是产品所有者责任的重要组成部分。产品所有者角色需要与整个组织内外的关键利益相关者密切合作，因此他或她必须能够在任何给定时间，向不同的人传达关于项目的不同消息。

https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner
Scrum Master
Scrum 团队

3个工件

产品Backlog（Product Backlog） ----产品积压的工作，未完成的
SprintBacklog
燃尽图（Burn-down Chart)

5个活动

Sprint计划会议（Sprint Planning Meeting）
每日站会（Daily Scrum Meeting）
Sprint评审会议（Sprint Review Meeting）
Sprint回顾会议（Sprint Retrospective Meeting）
产品Backlog梳理会议（ Product Backlog Refinement）

1）待办事项整理会议（Backlog Grooming Meeting）

迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。

由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。

会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。

2）迭代计划会议（Sprint Planning Meeting）

产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。

Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。

产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内。

3）每日站会（Standup Meeting）

团队内部利用每日立会来沟通进度，15分钟结束，开发团队利用燃尽图来展示整体进度；如无特殊原因，迭代期内无变更，在每日站会上团队成员需要回答以下3个问题：

昨天你做了什么?
今天你将要做什么?
你有需要帮助的地方吗?
这些都是团队成员的彼此承诺。

4）评审会（Retrospective Meeting）

小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加，ScrumMaster、产品所有者、团队，可能还有客户，时间控制在1-2小时内。

5）反思会（Retrospective Meeting）

在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好。做得好的保留，不好的摒弃。会议得出这样的结论：开始做什么、继续做什么、停止做什么，一般控制在15-30分钟。

Scrum是一套开发流程，是敏捷的一种，实施主要还是看人，强调是自组织、自驱动的，只有不断的在实际应用中仔细体会，才能理解Scrum的真谛，把Scrum用好。

Use Case、Epic、User Story、Task

如何從 Use Case 展開到 Task
Use Case
Use Case(使用用例) -- 想要做什么事情来解决问题或痛点--
Epic（史诗）-- 类似功能的分类或功能的较大集合
User Story（用户故事） -- 描述使用者所需要的功能，以及透过这个功能他能用来做什么以获得好处
Task（任务）由 User Story 拆分成的具体开发任务，开发团队撰写
Backlog
Product Backlog（产品代办清单）-- 描述产品想要的功能
Sprint Backlog（冲刺待办清单）-- 描述这次的Sprint想要完成的功能有哪些
Backlog通常会以Epic或User Story的方式来撰写，
到了sprint随着对开发团队的理解更详细，开始以User Story的方式来撰写
sprint
sprint -- 2-4周 task -- 2天内
Meeting
Planning Meeting -- (user case => user stroy拆成task)
Daily Scrum Meeting
Review Meeting
Retrospective Meeting
Use Case(使用用例)
Epic（史诗）
User Story（用户故事）
Task（）由 User Story 拆分成的具体开发任务
学习 Scrum 之前，我们先要了解几个基本术语：

Sprint：冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
User Story：用户的外在业务需求。拿银行系统来举例的话，一个 Story 可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。
Task：由 User Story 拆分成的具体开发任务。
Backlog：需求列表，可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为 Scrum。
Sprint Review meeting: 冲刺评审会议，让团队成员们演示成果。
Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况。
Release：开发周期完成，项目发布新的可用版本。

一个或多个MMF与最小可用产品（MVP）

接下面我们来具体看一下执行scrum的套路。

Scrum的三大角色
产品负责人（Product Owner）

主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任。

流程管理员（Scrum Master）

问题清道夫！主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

开发主力！主要负责软件产品在Scrum规定流程下进行开发工作。人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；不论过程只问结果！只要能达到目标，不论任何工作时间、方式。

Scrum的组成
Sprint：指的是一次迭代，而一次迭代的周期最好是1-4个星期，也就是我们要把产品需求分布到各个周期完成，这个过程我们称它为Sprint。

Story：用户故事，也可以看做是用户需求点。

Task：story的进一步细分。为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。

Backlog：Backlog是Scrum中的一个专用名词，意思是待办工作事项的集合。在开发中需要明确2个Backlog。

Product Backlog ——产品待办事项列表，产品负责人量化用户需求，逐条列出实际需要开发的需求（Story）。

Sprint Backlog——任务列表，是一次迭代中需要完成的任务，主要是开发团队细化工作的列表。

燃尽图（Burn Down Chart）

是一个展示开发时间的图，但是展示的是每天累加所有任务的剩余时间。

燃尽图是用来跟踪sprint中未完成工作的情况。每做完一个sprint的用户故事就烧掉，最后烧完sprint也就完成了。用蓝色线表示计划走向，红色线则是实际走向，两条线共同组成了燃尽图。如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。所有点组成sprint。

4个会议
Sprint计划会

Sprint 计划会就是大家坐下来，PO 向大家介绍排好序的产品待办事项（Product Backlog），然后大家共同思考决定如何推进计划，梳理出 Sprint Backlog 来完成后续的工作。

每日站会

每位开发成员都要交代3点

昨天完成了什么

今天计划完成什么

是否有困难需要帮助

每日站会

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的看板和燃尽图。

Sprint 评审会

当一个Sprint完成，这时就要进行最重要的演示会议，也称为评审会议，产品负责人和客户都要参加，每一个开发团队的成员都要演示自己完成的软件产品，然后被判定产品合格、成功、需要修改还是重新做。

Sprint 总结会

总结会议以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

以上的会议都不需要准备PPT或者大量的文档，但要注意会议的时长。

使用鱼骨Scrum项目的开发步骤
1.产品负责人使用产品Tab收集产品需求（story）。

Product Backlog

2.开发团队根据Product Backlog列表，在Sprint计划会议中做工作量的预估和安排，确定需求提交研发，进入Story看板。

Story看板

3.确定Sprint周期（1-4周）和本次开发迭代冲刺的开发需求（Stories）。进入Sprint的story出现在Task看板。 在Task看板，研发团队可以拆分Story到任务进行协作。

Task看板

5.每日立会，团队更新Task看板，和Story看板，保持信息的同步。

功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。
https://zhuanlan.zhihu.com/p/145431012