如何结合Scrum和Kanban实施敏捷开发

作者：郭振宇，新炬网络高级技术专家。

敏捷方法主要是针对快速变化的需求，强调以人为本，早交付、频交付，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善，工作推进过程不断改善、调整流程，一直到项目完成为止。

大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。我们主要用到以下几个关键的软件：

1. Maven：是软件生命周期、依赖管理，集中管理jar包，把jar包仓库和工程连接起来。

2. Jenkins：持续集成和自动编译发布

3. Git：集中代码管理

4. Redmine：记录需求、任务、状态、缺陷

5. Tomcat/jetty/netty/glassfish：开源Web应用服务器。

6. Oracle/Mysql：数据库。

7. Sonar：用于代码质量管理的平台，用于管理Java源代码的质量

8. STAX+STAF+SAFS：开源测试框架

9. RFT：自动化测试工具

敏捷价值观：

l  个体和交互高于流程与工具

l  工作的软件高于详尽的文档

l  客户合作高于合同谈判

l  响应变化高于遵循计划

在敏捷方法中，Scrum方法在国内已被逐渐普及，为众多知名IT公司和软件开发团队采用。我们可以结合Scrum与Kanban，让项目管理更加有效，让资源分配更加合理，让绩效考核更加公平！

l  对于项目经理而言，最担心的就是项目进度不可控，不知道每位开发人员具体的工作进度，有了Kanban一切都是那么地清晰。

l  对于开发经理而言，最担心的就是资源分配不合理，忙的人忙死，闲的人闲死，有了Kanban一切都是那么地自然。

l  对于开发人员而言，最担心的就是绩效考核不公平，“凭什么我做的比他多，拿的工资却比他少？不公平啊！”有了Kanban一切都是那么地公平。

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

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

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

?这个表格有5列：Backlog（原始需求）、Selected（被选中的需求）、Develop（开发阶段）、Deploy（部署阶段）、Live（上线阶段）

?其中Develop阶段包括2个子阶段：Ongoing（进行中）、Done（已完成）

?包括3中角色：产品经理（红色小人）、开发人员（蓝色小人）、部署人员（绿色小人），其实还有项目经理，只是他/她贯穿于始终，所有就没有画出来了。

在Backlog中放置了许多小卡片，它们在Kanban中被称为WIP（WorkInProcess，在制品）。对于产品经理而言，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，就可以考虑放入一些新的需求了。

此时，部署人员遇到了问题，发现A部署的时候总是报错，跑不起来了。同时，其他开发人员也完成了B任务。

完成了B任务的开发人员本来是可以做新需求的，但项目经理发现Develop中只能放2个任务，所以肯定是后面的阶段出现了问题，导致整个流程受阻了。项目经理可以灵活调度人力资源，集中火力解决现在所遇到的问题。

所以项目经理不得不放弃新的任务，去让开发人员去帮助部署人员来解决问题。此时，其他的开发人员还在进行C任务。

部署的问题还没来得及解决，此时C任务也完成了，同时，产品经理也放入了新的K需求，确保Selected这个水池是装满水的。

整个部署问题看起来比较搞人，所有的开发人员全都上阵了，集中更多人的智慧，解决这个棘手的问题。此时，产品经理不能放入更多的需求，由于此时Selected已经满额了。其实，开发人员面对太多的需求时，往往都会倍感压力，身心憔悴。

看来这个部署问题，确实够折腾的，连产品经理都过来了凑热闹了。但他或许不懂技术，但多个人多个头脑吧，正所谓“当局者迷，旁观者清”，最终经过大家的努力，肯定会攻克这座碉堡！

几天之后，Kanban流程依旧是稳定的，大家分工协作，人力资源合理利用。大家是一个团队，目标就是把项目做好，不会因为自己的事情做完了就闲置了。