AI 考拉技术分享--Scrum 入门

[kaolalicai]

前言

互联网时代，产品迭代速度快，传统的瀑布流开发模型已经无法满足产品快速开发的需求，敏捷开发的思想应运而生。
考拉技术团队在 CEO 的大力推行下，一直沿用 scrum 开发模型，保证产品每周一次的迭代。今天我们先来入个门，了解下 scrum 模型的基本内容。

一、传统开发模型

在开始介绍 scrum 模型之前，我们先来回顾下之前软件开发模式。
起初，软件开发最基础的模型叫做瀑布模型（Waterfall Model）。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。瀑布模型下的产品开发各部分都是独立分开，各不干扰，一般适应于大型软件。 但瀑布模型也存在不能在开发过程更改需求、无法赶上变化迅速的市场，容易造成资源浪费等缺点。
在这个基础上，引入敏捷开发模型对于小开发团队来说是比较合适的。

二、scrum 的简介

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

Scrum 作为敏捷的方法之一，用不断迭代的框架方法来管理复杂产品的开发。

原词来自于橄榄球中“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应发。

三、scrum 的优势

灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出，容易学习。
Why choose Scrum ？ 原因如下 （敏捷宣言）：

1. 个体交互重于过程和工具；

2. 可用的软件重于完备的文档；

3. 客户协作重于合同谈判；

4. 响应变化重于遵循计划。

概况地说，它适用于快速变化的市场，可以根据客户不断更换的需求，调整产品的方向，按时交付客户想要的产品。这在今天竞争激烈的市场来说，优先于竞争对手交付一个不完美但能不断改进优化的产品是非常重要的。

四、scrum 中 3 个关键角色

scrum 团队的成员由开发人员、测试人员以及其他帮助研发的人组成：
核心团队：

• Scrum Master ——项目负责人，帮助团队完成工作，组织日常会议和保障其他工作展开；
• Team ——开发人员，经常扮演多种角色，开发人员兼职测试，测试人员搬砖文案；
• Product Owner ——产品负责人，确定产品特性，提出产品亮点。
  scrum 团队的规模不宜过大，一般在 3-9 人为佳。

五、scrum 流程

1. 建立 Product Backlog
   记录已知需求并调整。
   在整个开发过程中，Product Owner 要不断的把已知的所有需求记录到这里面来，任何时间或步骤中产生的新需求都需要进行更新。scrum 团队总是先开发对需求方具有较高价值的需求。
   需求方为了能更加清晰表达需求，可用user story描述需求。user story 是从用户 /需求方的角度对产品的某个功能进行的简短描述，具体格式如下：
   
   一个 story 的大小以及复杂度应以能在一个 sprint 中完成为宜。如果 user story 横跨了几个 sprint，那个就需要进行分解成若干个 task （任务），每个 task 的时间最好不要超过 8 小时.
2. Sprint Planning
   在 scrum 中，sprint 定义为产品的迭代周期。一般是 1~6 周。在一个 sprint 开始前，定义本次 sprint 要讨论的 backlo 为 sprint backlog. 它是团队在 sprint 要完成的任务。
   为了确定团队内部任务以及具体分工，需要进行 sprint planing，由 Scrum Master 决定需求，然后将任务拆分，估时，并完成分配。当任务分配之后，要记录到 sprint backlog 中。在 sprint 中，scrum 团队从 backlog 中挑选最高优先级的需求进行开发。 在每次例会之后，由 Scrum Master 更新 backlog。
3. Daily Scrum
   也称为每日站会，一般不超过 15min。参会的成员由核心团队的成员组成，每个人只说 3 个问题：
   今天完成了哪些任务？ 明天的任务是什么？ 今天遇到了哪些问题？
   每日站会的主要作用是 update 整个团队的进度，会上成员提出的问题不进行详细讨论，会议后 master 对这些问题进行解决。
4. Sprint Review
   总结 sprint 的会议，在会议上会将本次 sprint 的新功能展示出来，并收取反馈，为下一次新的需求做准备。
5. Retrospective Meeting
   反思 sprint 的会议，目的是回顾 sprint 过程组内成员的表现。为了让成员能够更加真实反思自己的工作情况，安全的讨论环境是必须的。在回顾会议上，主要做这三件事情：
   good--如果我们可以重做同一个 sprint，哪些做法是可以保留的？
   could have done better--如果我们可以重做同一个 sprint，哪些做法需要改变？
   improvement--如何改进的具体想法？

六、scrum 工具

1. 任务板
   任务板用可视化方式展示，将一个 sprint 分为四个阶段：
   Product Backlog：按照需求的优先级，将团队在 sprint 中要进行的 backlog 放在该列；
   To Do：将当前 sprint 需要完成的任务放入该列；
   In Progress：当团队开发进行某个任务之后，便将任务对应的卡片放到该列中。如果该任务在该列中所处时间超过 1 天，则应该将任务拆分为更小的部分，并将新任务放到该列中，移出原有的任务。若一个新任务因某个障碍无法完成，master 就会将其标记为障碍，用特定红点标记。
   Done：完成一个任务之后，便将任务放到该列。继续开始下一个任务。
   看板（ kanban ）开发方法作为一种敏捷方式，在改善协助，优化管理、提高交付速度、质量以及灵活性方面有显著作用。下篇文章会着重讲述 kanban 开发模型在技术团队中的应用。
   

2. 燃尽图
   sprint 的开发时间需要团队跟进，燃尽图可以帮助团队评估 sprint 开发任务的时间以及效率。
   燃尽图是以图表展示随着时间的减少工作量的完成情况。燃尽图的横轴表示整个 Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。 为了更好表示任务开发情况，团队每天要更新燃尽图，并且要根据燃尽图中任务的完成情况对任务进行调整：如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的 Y 值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果 Sprint 燃尽图下降得很快，例如 Sprint 刚过半时 Y 值已经接近 0 了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。
   为了方便管理燃尽图，在设计燃尽图的时候，从简出发。
   

3. Jira
   作为敏捷团队用来管理开发项目流程以及进展的工具，Jira 提供了丰富的功能，方便开发团队对开发中的问题进行记录跟踪，并通过可视化图表展现出来。当团队进行一次 sprint 时，Jira 会帮你记录任务的完成状态，团队的分工情况以及完成情况。，支持将任务简化，把开发时间分配到每个具体任务中，在规定的时间内完成任务。这与敏捷开发的思想不谋而合。

七、结束语

尽管 scrum 很美好很轻量，但是这种模型不一定适用于所有的企业。为了保持产品的快速优化，团队在进行敏捷开发模式的同时，还应该注重敏捷开发过程的不断优化。敏捷的出发点是为了提高工作效率，以人为本。没有谁的敏捷之路是一帆风顺，不断优化，小步快跑的方式才是敏捷可行的路。