敏捷开发模型讲解

CSDN：在你的工作生涯中，前期是在创业公司，后来是大公司，有着一套自己的敏捷开发模式，能够谈谈在你现在使用的敏捷开发工具或方法？

黄勇：敏捷这个话题大家一直都在谈论，也有很多关于敏捷的工具或方法，我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想，Scrum 是对让这个思想落地的一个参考。也就是说，我们大可不必完全拘泥于 Scrum 定义的规范，只需要参考它并结合自身的条件做适当调整即可。比如说，每日站会这个环节就非常重要，不管是放在每天上午，还是放在每天下午，总之最好要有固定的周期。此外，每次 Sprint（迭代）结束后除了有评审会以外，Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结，哪些是本次迭代中做的好的地方，哪些是做的不好的，再对比上次迭代的的结论，哪些是有改进的，哪些是新的问题。

Scrum 提供了三类角色，分别是：Product Owner（一般由产品经理担任）、Scrum Master（一般由开发经理担任）、Scrum Team（包括开发与测试人员），其中，Scrum Master 的角色至关重要，对项目的成败起决定性作用。

阿里巴巴也在广泛使用 Scrum 敏捷开发模式，而且整个项目几十人都可以用 Scrum，只是首先需要将整个团队拆分成若干小团队，保证每个小团队按照 Scrum 进行操作，此外，再将每个小团队的 Scrum Master 召集在一起，再做一轮 Scrum，这就是所谓的 Scrum of Scrum。过程稍微复杂一点，但可以将敏捷用于更大的团队规模，并能保证敏捷的效果。

CSDN：你认为Scrum Master 的角色至关重要，对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题？

黄勇：我个人不太建议由产品经理来担当Scrum Master，原因如下：

Scrum Master 关注的是项目开发视角，而产品经理关注的是产品功能视角，两者关注的视角是不一样的。
Scrum Master 需要有一定的技术开发功底，需要对开发工作量进行评估，也需要对技术实现进行评审，可能还会有一定的编码工作，而具有技术功底的产品经理毕竟太少了，即便有的话，可能对技术方面也不会太深入。
需要有一个人，他来对整个产品负责，这个人就是Product Owner，该角色最好由产品经理来担任。

CSDN：敏捷开发过程中测试团队的职责和产出是什么？

黄勇：在敏捷开发过程中，我认为测试团队的职责有以下几点：

根据产品需求，定义测试用例。
针对测试用例进行功能测试，并将测试的结果反馈给开发人员。
负责搭建系统运行所需的环境，包括软件安装、数据初始化等。

CSDN：除了Scrum，还有XP、CM、FDD、ASD、DSDM等敏捷开发方法，如何去选择一个合适的敏捷开发工具或者方法呢？

黄勇：敏捷开发方法有很多，不仅仅只有Scrum 一种，其实不妨相互借鉴，再结合自身的特点，定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等，这些都是很好的方法，值得借鉴。包括看板也是一个很不错的工具，可以结合Scrum 来工作。

CSDN：从博客上，你也研究过「使用看板进行敏捷开发」，能不能分享你的研究成果？

黄勇：敏捷开发工具“看板”,该词汇来自于岛国，当我看到看板的英文时，我真的惊呆了，看板竟然就是 Kanban？！

我们可以结合 Scrum 与 Kanban，让项目管理更加有效，让资源分配更加合理，让绩效考核更加公平！

对于项目经理而言，最担心的就是项目进度不可控，不知道每位开发人员具体的工作进度，有了 Kanban 一切都是那么地清晰。
对于开发经理而言，最担心的就是资源分配不合理，忙的人忙死，闲的人闲死，有了 Kanban 一切都是那么地自然。
对于开发人员而言，最担心的就是绩效考核不公平，“凭什么我做的比他多，拿的工资却比他少？不公平啊！”有了 Kanban 一切都是那么地公平。

可见，项目经理、开发经理、开发人员拥有了 Kanban，也就拥有了和谐与快乐！

那么 Kanban 到底是什么呢？我们先来看看这张表格吧：

下面我们来理解一下这个表格吧！

这个表格有 5 列：Backlog（原始需求）、Selected（被选中的需求）、Develop（开发阶段）、Deploy（部署阶段）、Live（上线阶段）
其中 Develop 阶段包括 2 个子阶段：Ongoing（进行中）、Done（已完成）
包括 3 中角色：产品经理（红色小人）、开发人员（蓝色小人）、部署人员（绿色小人），其实还有项目经理，只是他/她贯穿于始终，所有就没有画出来了。

在 Backlog 中放置了许多小卡片，它们在 Kanban 中被称为 WIP（Work In Process，在制品）。对于产品经理而言，WIP 是需求，而对于开发人员与部署人员而言，WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述，包括：标题、描述、优先级等信息。

需要注意的是，Selected、Develop、Deploy 下方有一个数字，该数字表示此阶段中最多可以放置的 WIP 数量。例如，在 Selected 中最多只能放 2 个 WIP；在 Develop 中（包括它的子阶段）最多只能放置 2 个 WIP。这里的数字只是一个示例，具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”，减 1 表示大家需要协作，例如：4 人的团队，WIP 上限是 7。

也许有人会提出，为什么没有 Test 阶段？—— 这个可以有，这里只是一个示例而已，你不妨自行加上去。

对于多个项目而言，可以在这张表格中添加更多的泳道（行），每一行相当于一个项目，所有的项目进度清晰明了。

好！继续我们的 Kanban，有意思的事情即将发生！

产品经理挑选了 2 个 WIP 到 Selected 中，此时，由开发经理决定该任务的技术难度，并由项目经理将任务分配到指定的开发人员，也可将同一个任务分配给两个人，让他们去结对编程。

开发人员（架构师与程序员）可对 Selected 中的需求进行工作量评估，可采用投票的方式进行，最终给出一个合理的评估值，整个估算过程，项目经理无需参与，主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”，这个分值可直接影响到后续的绩效考核，所以对大家来说，这个分值是公开可见的，谁做的多，谁做得少，一目了然。当然，开发人员也可以主动承担具有更具挑战的任务（为了锻炼自己，也为了多拿点钱），但任务分配的决定权始终在项目经理手中。

现在假设 A、B 两个任务已经分别被不同的开发人员处理了，那么这些任务就应该移动到 Ongoing 中，同时，产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。

有人已经把 A 做完了，那么 A 就可以移动到 Done 中了。随后，部署人员就可以开始干活了。

部署人员就可以将 A 从 Done 中移动到 Deploy 中，表示部署人员正在做这件事情。同时，做完了 A 任务的开发人员可以再做其它新任务，只需从 Selected 中移动到 Ongoing 中，移动这件事情不是开发人员随意操作的，而是有项目经理负责的。产品经理发现 Selected 中只有一个 D，就可以考虑放入一些新的需求了。