敏捷开发：从理论到团队落地

敏捷开发很早就已经流行过了，之前也零碎地了解了一些相关知识，并在团队中进行了部分实践，但效果都不怎么好。最近又重新梳理了一遍，并结合现状，准备在团队中重新实践敏捷。

什么是敏捷？

首先，敏捷是一种观点和价值观，不是具体的指导性方法，其核心思想是：

• 响应变化、拥抱变化；
• 注重沟通；
• 能够持续交付，注意这里的持续非常重要，这也是我们团队之前存在的问题；
• 交付的成果是以客户的角度，对客户来说是有价值的。

2001 年，17 位软件开发者齐聚在美国的犹他州的雪鸟( snowbird )，讨论轻量级的软件开发方法，并写下了敏捷软件开发宣言，其中包括四条核心价值观和十二条原则，这里就不具体贴出了。想表达的还是上面总结的核心思想。

既然敏捷是一种思想，终究还是要落地的，针对敏捷的落地有很多的实践方法，比如：精益软件开发、特性驱动开发、极限编程（XP）、Scrum，其中 Scrum 是比较流行也是资料最多的，我们团队也将采用 Scrum 进行实践。

什么是 Scrum？

Scrum 是一种实践敏捷的框架和方法论。其中包含：

• 三种角色；
• 五大会议；
• 两个关键产物。

三种角色

Product Owner：产品负责人，主要把控产品的方向，构建正确的产品，解决做什么的问题；

Scrum Master：

• 确保团队能够使用正确的流程；
• 确保团队能够正常召开各种会议；
• 帮助团队成员理解 Scrum 理论、实践、规则和价值；
• 不设置固定的人员，可以是团队中的任何人以轮流的方式担任。

Development Team：

• 包含架构、开发、设计、测试、运维等；
• 在产品方向确定的前提下，确保能以正确的方式来构建产品，解决怎么做的问题。

五大会议

待办事项梳理会（梳理 Product Backlog）

• 建议每周都和相关人员进行沟通，确保 Product Backlog 中不会断货，不然就持续不起来；
• 在该会议中，进行待办事项的补充、优先级的调整和一些具体实现思路的讨论。

迭代计划会 （确定 Sprint Backlog）

• 在每个迭代开始时进行；
• 从 Product Backlog 中挑选一个迭代能完成的事项放入到当前的迭代列表中；
• 一个迭代周期一到四周不等，我们现在团队在实践初期，准备 3 周一个迭代，等到流程运转顺畅了，可以再调整为 2 周；
• 在会上还需要将用户故事拆解成任务，指定责任人和工时。

每日站会

• 由 Scrum Master 主持，团队成员每人轮流发言，控制好时间，一般不超过 15 分钟；
• 发言内容为：做过什么？将要做什么？遇到什么问题？

迭代评审会

• 迭代结束前进行；
• 迭代负责人给相关人员（产品负责人、其他的利益方）做功能的验收演示；
• 在会上提出的意见或建议记录到 Product Backlog ，可能会规划到下一个迭代中进行处理。

迭代回顾会

• 迭代结束后进行；
• 因为一个迭代的周期不会很长，所以在迭代结束后进行回顾，能够比较真实，不会有遗忘的情况；
• 在会上可以讨论当前迭代中做的好的和做的不好的地方，团队的每个成员都要积极发言，这也是考验 Scrum Master 的时候。

两个关键产物

Product Backlog

• 产品的待办事项列表，作为每个迭代的来源；
• 需要相关人员持续地进行碰撞，确保待办列表中的事项的优先级是正确的。

Sprint Backlog

• 迭代列表，每个迭代周期的范围；
• 迭代结束后的交付内容。

通过上面的描述，应该大致清楚了敏捷和 Scrum 是怎么回事了。接下来介绍在我们团队怎么去使用。

敏捷对组织是有一定要求的，希望是跨职能组织，在一个组织中包含架构、开发、测试、运维、UI 设计等角色。如果不是，组织结构需要进行调整。要求跨职能组织的一个重要原因就是希望不同角色的人在工作时能随时面对面交流。目前我们产品团队是符合跨职能组织的要求，这也为实践敏捷提供了先决条件。

整个过程就是按照 Scrum 的五大会议进行，其中有一些小的调整，如下图：

1、最开始的待办事项梳理会，建议是每周都能进行，因为待办事项的优先级会受到很多因素的干扰，每周进行能够及时调整；

2、站会的时间调整到上午的 11 点半，目的就是为了控制时间，毕竟谁也不想到了 12 点还吃不上午饭；

3、在迭代周期中添加了「用户故事评审会」，在会上用户故事的责任人对该用户故事的成果进行演示，这样可以让用户故事的责任人更有责任感，想要在一个相对比较正式的场合进行演示，那么事前肯定要做些演练，除此之外也能锻炼到每个人的演讲和沟通能力；还有一个好处就是演示过程中，集思广益，容易找出之前考虑不足的一些地方。

组织调整为了跨职能组织，每个成员也都对敏捷的思想达成了共识，并且制定了相关的工作流程，剩下的就是选择一个合适的工具来辅助了，这类的工具有很多，比如 PingCode、Tower 等。选择一个自己用着顺手的就行。

网上很多的文章都说敏捷执行到最后会变形，最终只留下了一个站会，或者变成小瀑布的模式，我认为在还没执行前就各种担心是大可不必的，出来混最重要的是出来，我们先得执行起来，过程中发现问题即使改进、调整，其实不光开发模式可以采用敏捷的方式、团队和个人也可以是敏捷的。