敏捷开发、DevOps和云计算（四）

1.4敏捷实践

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发的实现方式有很多种，最常用的是SCRUM和极限编程（ExtremeProgramming，简称XP）。Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

1.3.1 SCRUM

SCRUM是一种开发流程框架，也可以说是一种套路，是迭代式增量软件开发过程。
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
关于迭代和Sprint(冲刺)：
初涉敏捷开发的人，经常会混淆迭代和Sprint的概念，导致在各种场合混用这两个词语。
迭代：开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程。它类似于小型的瀑布式项目。迭代开发本身是一种有计划的修改策略：通过多次开发来改善正在构建的特性，逐步得出一个完善的解决方案。例如，对一个知之甚少的产品，开始时可以先创建原型以获得重要知识，接着可以创建一个更好一点的修订版，再接下来是一个相当好的版本。
Sprint：Sprint（冲刺）是 Scrum 的核心，其长度（持续时间）为一个月或更短时间的限时，在这段时间内构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间， Sprint 的长度通常保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。冲刺的另外一个特性则是在每个冲刺中一定要有计划/评审/回顾/每日站会等仪式来确保冲刺能够达到应用的效果。

1.3.1.1 Scrum开发流程中的三大角色

1.3.1.1.1 产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

1.3.1.1.2 流程管理员（Scrum Master）

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

该角色也被称为“敏捷教练”：敏捷教练，从职责和影响范围大体可分为四类：
● 技术教练（CI/CD，OO，微服务，Cloud 等）
● 团队教练（团队流程，团队建设，团队回顾等）
● 组织教练（组织级变革）
● 管理教练（战略，人才等）

开发出身一般比较容易从技术教练做起。
产品，BA，QA，PM 一般可从团队教练做起。
中高层管理者可以直接做组织级教练。
CXO 可以做管理教练

教练存在的形式有内部教练和外部教练两种，一般从内部教练做起容易。

1.3.1.1.3 开发团队（Scrum Team）

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

1.3.1.2 Scrum开发流程中的四种会议

四种会议指的是Sprint计划会议、每日站会（Daily Scrum）、Sprint评审会议和Sprint回顾会议。

1.3.1.2.1 Sprint计划会议（Sprint Planning）

在Scrum中，Sprint计划会议有两部分：

决定需要完成哪些工作？
决定这些工作如何完成？
第一部分：需要完成哪些工作？
参会人员：团队、项目负责人（Scrum Master）、产品负责人（Product Owner）
第一部分的会议，产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解这些工作。
Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定，产品负责人或任何其它人都不能给开发团队强加更多的工作量。
第二部分：如何完成工作？
参会人员：团队、项目负责人（Scrum Master）
第二部分的会议，开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划，从而有信心可以在Sprint中完成所有工作。
决定如何完成工作是开发团队的职责，决定做什么则是产品负责人的职责。
Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识，最终产生的待办事项列表就是“Sprint待办事项列表（Sprint Backlog）”。
Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项，并包括了一个团队完成这些工作的计划。

1.3.1.2.2 每日站会（Daily Scrum）

开发团队是自组织的，通过每日站会来确认他们仍然可以实现Sprint的目标。
每一个开发团队成员需要提供以下三点信息：
● 从昨天的站立会到现在，我完成了什么；
● 从现在到明天的站立会，我计划完成什么；
● 有什么阻碍了我的进展。

每日Scrum通常不超过15分钟。
每日Scrum中可能有简要的问题澄清和回答，但是不应该有任何话题的讨论。
每日Scrum既不是向管理层汇报，也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解。

1.3.1.2.3 Sprint评审会议（Sprint Review）

Sprint结束时，Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的，Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时（比如，一个Sprint包含2个星期，则Sprint评审会议时长为2个小时）。
每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定，并适当地调整产品待办事项列表（Product Backlog）。
Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

1.3.1.2.4 Sprint回顼会议（Sprint Retrospective）

在每个Sprint结束后，Scrum团队会聚在一起开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。所有的Scrum会议都是限定时长的，Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时。

1.3.1.3 Scrum开发流程中的三个物件

三个物件指的是产品待办事项列表（Product Backlog）、迭代待办事项（Sprint Backlog）和燃尽图（Burndown Chart）。

1.3.1.3.1产品待办事项（Product Backlog）

在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。
Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些可以在下个Sprint中完成的Product Backlog功能点，大约10人天的工作量的粒度就不错了。对于那些以后将要实现的特性可以不够详细。

1.3.1.3.2迭代待办事项（Sprint Backlog）

Sprint Backlog 是Sprint规划会上产出的内容。当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog：一个完成Product Backlog功能点的必需的任务列表。这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner 协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。

1.3.1.3.3燃尽图（Burndown Chart）

Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。
在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，Scrum master 会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。

1.3.1.4 Scrum流程图

1.3.1.5 如何进行Scrum开发

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

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

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

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

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

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

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

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

上一篇：敏捷开发、DevOps和云计算（三）
下一篇：敏捷开发、DevOps和云计算（五）