在SCRUM敏捷开发中如何使用看板？

Posted 2021-04-25 未知时代

我们知道，SCRUM敏捷开发相对于传统的瀑布模型的开发模式是一次管理的变革，无论是对开发团队中的角色的定义，还是研发的流程，其改变的实质是思维的改变。因为瀑布模型强调在确定的需求范围内以文档为驱动将交付的过程划分为分析、设计、开发、测试和上线的几个阶段，其理念在于以需求的预测性为原则，而管理上以过程控制为核心，敏捷开发则有所不同，在软件开发已经共识为实际是知识演进的过程以后，敏捷号称以拥抱需求变化为优势，对于需求的涌现具备很强的适应能力，采取快速迭代持续集成的方法完成交付，而在管理上，对应前者的过程控制和文档驱动，敏捷更强调自组织的团队管理和测试驱动。所以这是二者的核心差异所在。

 

由于敏捷强调的是增量迭代、持续集成、快速交付为目标，也就是相对于瀑布模型大而全、流程繁琐的特点，敏捷则回归到开发编程的初衷，即不断地提供增量的交付，并不断构建直到完成需求的实现。想想如果是单兵作战实现开发，我们是不是正是这样玩的呢？那我们的团队既要协同作战，又要达到单兵作战的效率，所以就有了敏捷所倡导的思想和价值观。

 

首先，增量迭代对应我们的一个开发周期，在SCRUM我们称之为Sprint，即冲刺，一个冲刺的目标可以定义为一次完整的交付，但根据项目的背景和客户的要求，可以是开发的冲刺，也可以是包括开发和测试的冲刺，冲刺的周期一般为1-4周，根据我们的迭代速率来进行调整。我们建议可以先按2周一迭代作为目标，再逐步提高至1周一迭代。

 

其次，对于持续集成，恰恰是响应敏捷而生的，而且在分布式架构的背景下对于自动化部署提出了更高的要求，持续集成完美解决快速交付和快速部署的难题。

持续集成要求团队开发成员经常集成他们的代码，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

我们要求持续集成，一般建议采用jenkins来进行自动化构建，Jenkins可以配置指向我们的代码管理分支，按照Sprint迭代的要求，我们会将每次迭代开发的需求在新的代码分支中去完成开发，并在交付构建前合并到release分支，作为专门用于发布和构建的代码分支。

 

有了对前面关于SCRUM的完整了解以后，我们再来看看接下来我们看看如何在项目中使用看板。

 

看板的原理是将需求纳入到流水线，看板可以看成是制造行业生产车间的一条生产流水线，软件开发是从需求开始，需求的分析在Scrum中采用用户故事US来拆解，然而形成backlog，用户故事作为可以度量需求并作为开发测试共用的单元来理解，用户故事从纳入分析到分析完成、设计完成、开发完成、测试完成，最终完成投产交付，恰恰将我们开发的全过程定义出来了。当然，看板关注每一个迭代的流动效率，当前迭代的如果遇到阻碍时，代表看板发生了阻塞，就需要得到关注和跟进解决，所以看板的可视化的价值就体现出来了，能够非常清晰地看到项目的进度，并且让阻塞无处可藏。

 

在制作看板之前，我们先定义用户故事，以某银行IT系统项目为例：

序号	功能点	工时	SPRINT
1	查询与报表服务>核销余额对账查询	20	Sprint3
2	查询与报表服务>核销交易查询	20	Sprint3
3	查询与报表服务>核销账户查询	20	Sprint3
4	查询与报表服务>交易日结单查询	24	Sprint2
5	查询与报表服务>科目日结单查询	24	Sprint2
6	查询与报表服务>会计分录查询	24	Sprint2
7	查询与报表服务>会计流水查询	24	Sprint2
8	查询与报表服务>科目余额查询	24	Sprint2
9	查询与报表服务>借贷平衡检查查询	20	Sprint2
10	查询与报表服务>会计平台日终平账核对	40	Sprint4

根据用户故事的backlog，我们编制迭代总体计划，如下：

Sprint	Goal	Start Date	End Date
Sprint 1	完成需求分析及系统设计； 完成技术选型、分布式架构设计	10/30/16	11/10/16
Sprint 2	完成权限接入及菜单的配置； 完成系统参数管理及查询开发；	11/13/16	11/24/16
Sprint 3	完成交易流水批处理开发； 完成日终对账的开发	11/27/16	12/8/16

  

如上图所见，我们将交付过程拆解为3个迭代，而且为每个sprint定义了目标、开始时间、结束时间，按照两周一迭代作为周期。

 

我们还需要制定Sprint的计划，一般我们会有一个计划发布会议来确认sprint的计划，一旦发布以后，所有开发人员就以此进行冲刺，如下：

WBS	工作任务：需求功能或接口	状态	工作量
1	代码工程及开发环境搭建	未开始	5
2	需求培训及评审	未开始	1
3	分布式架构方案与技术选型讨论	未开始	9
4	分布式平台架构设计	未开始	6
5	分布式平台ER关系图	未开始	6
6	分布式平台类图设计	未开始	6
7	需求User Story拆分	未开始	3

 

到此为止，我们有个总体的迭代计划和Sprint的计划，是否已经就绪了呢？没有，看板还没登场，我们紧接着要根据拆分的用户故事，按照冲刺的计划绘制scrum看板，效果如下：

 

如上图，我们来解释看板的要素：

1.  看板状态区划分为Backlog、In Dev、DevDone和持续集成，意味着对应需求清单、开发进行中、开发完成和提交测试的状态；

2.  看板的任务贴纸颜色代表不同的迭代，以区分不同迭代用户故事任务的归属区域；

3.  任务贴以粗体白板笔书写，目的是醒目，让参与会议的人可以远处就能看清楚；

4.  任务贴以简单的文字描述用户故事，起到标识作用，具体的细节以文档为准；

5.  任务贴需求标示出负责人及工期，负责人采用拼音首字母大写，工期以阿拉伯数字书写；

6.  若任务执行消耗了工时，则使用写“正”字来表达，若正字笔数超出工期，则表明任务延迟；

7.  看板在标题下方描述本次冲刺的目标，以及当前所处的迭代周期。

 

值得一提的是，究竟如何界定任务可以移到对应的区域呢？

Backlog: 需求的用户故事分拆以后，即可以放入此区域；

In Dev:表明US进入开发阶段；

Dev Done：表明US已经完成开发及单元测试，单元测试的完成以覆盖率为标准；

持续集成：此区域代表提测的目标，即迭代的用户故事完成开发及单元测试以后，需要准备相关文档、进行自动构建和部署，一旦持续集成启动，就代表提交测试的流程已经开始。

 

            所以持续集成也是有标准和门槛，结合某银行的项目，持续集成需要完成以下任务，供参考：

 

ID	Task  Name	Tools
1	单元测试覆盖率检查	Cobertura
2	代码安全扫描	Fortify
3	代码Bug扫描	Findbugs
4	GIT  分支合并	GIT  Merge
5	版本自动构建	Jenkins
6	提测清单	Excel
7	单元测试报告	Word
8	变更上线文档	Word
9	版本部署发布	jenkins+shell

 

 

当然，更多的状态比如“设计中”、“设计完成”、“投产上线”等这些都可以纳入到看板作为状态区，Scrum Master可以根据具体的项目要求和客户的选择来灵活定义。

 

而且，Scrum的每日站会的形式都是针对看板来进行，开发人员在ScrumMaster的主持下围绕看板任务的进展汇报任务进度、当天计划及遇到的阻碍问题，主持人则关注进度是否正常、任务是否可以移动、是否阻塞看板正常流动。