精益看板实践

从北京搬家到深圳都落定了。

2015-12-7日 ，我开始了到券商M公司上班日子。面试之时就了解了在深圳的这家M公司是它香港母W公司这这边的新研发中心。整个研发中心的头儿老王是在软件金融业泡了不少年头的技术大牛。公司租了了不大不小的临时办公室，十几个开发，两个测试，一个运维，一个画图UI和一个产品理在我来之前已经吭哧吭哧没日没夜地干了几个月。据老王在面试时说，9-10-6是正常的上班节奏。。。在互联网行业工作的小伙伴们你懂的。

既来之，则安之。先了解业务吧。因为还没混熟，所以小心地，礼貌地，斯文地跟周边的同事打招呼试图着打听哪里能看到一些产品或是项目的文档- 虽然早有准备因为是新的研发中心，但是还是吃了一惊，真的是什么都没有。这是一群人类聚集在一个不太明亮的地球角落，从事着非常原始的产品开发，做完了什么，还有什么需要做都无从知道。

那就口头挨个问吧。作为项目经理的我要知道每个人在做什么。

形成第一版本的Kankan墙

针对当下项目情况，最可能的是使用物理墙的Kanban了。物理墙Kanban的引入能在现阶段提供以下帮助：

可视化团队每个成员的工作
建立初始的工作流，用于以后演变及固化
了解团队对于交付能力，从经验的模型到量化模型做准备
量化剩余工作量以及制定一个可行的工作计划
团队里绝大多数成员之前没实践或是听说Kanban。很多新的实践引入都会引起反感以及抵触。为了最大限度地避免这种情况，第一是要得到老王的支持；第二是要让团队成员明白什么是Kanban,看板能帮助我们做什么，特别是我们如何用。为此，第一周的时间在观察了团队的工作方式，配合习惯以后我开始准备一个介绍Kanban的PPT。目的在于介绍让团队了解Kanban的同时，也收集团队的意见和想法对于形成适合团队的第一版本的Kanban墙.

1）第一步要了解和可视化团队的工作流。

从模糊的概念到可工作的软件每一阶段，这就是Kanban墙的工作流。部门里存在产品管理，开发，测试，运营等部门，每个部门的工作都有侧重性，那么工作流的列就自然形成从产品列表，开发缓存区，开发进行中，开发结束；测试缓冲区，测试进行中，测试完成；部署缓存区，预生产部署，生产部署以及发布。

2）建立过程规则

为减少返工，减少工作流中从某一阶段进入到下一阶段要达到的条件并且把它们规则化，显性化，制定明确的阶段完成定义以及规则是让工作项在工作流流动中显得尤其重要。建立过程规则并把它显性化不但从概念上是团队了解自己往下游交付工作时需要完成什么，而且使得信息透明化，这个是我理解各个阶段的definition of Done. DoD不但对于用户故事，在各个阶段都应该有，这也是内建质量的重要前提。

3）限制在制品数量 – 对工作中的每一个阶段所允许的数量设置明确的界限

每个团队在固定人数下，能同时处理的任务是有限的，况且人类是一种不能同时进行多项任务的物种。设置限定每个阶段在制品数量有利于整个工作量自上有到下游的流畅流通。但是，在没有任何参考数据的情况下，如何设置在制品品数量呢？

考虑到团队都是一个办公室里，其实每天开会，回邮件等沟通成本比大公司特别是外企要低的很多。我提议我们用2N-1(N表示所在工作流阶段处理此类工作的人数）来设定。每个人2个任务，-1表示有一部分工作会在每天站立会，团队讨论等沟通的花销。在没有其他异议的情况下，同意开始尝试用2N-1来设定在制品数量。以后在跟根据在运行中观察，跟踪实际的任务项来调整。

这3步设置完毕，下图是经过介绍和团队讨论，第一版本的看板墙格式达成了。开发部门，测试部门，运营和产品管理部门的同事都同意一个原则：从简单的做起， 增量提高，持续改进。





到此，最早版本Kanban样式形成，算是迈出了第一步。按照这个样式，在办公室里的玻璃墙上搭起了物理的Kanban墙。

 

关于工作拆分

为了了解我们还有多少工作量，我们需要对手头的工作进行拆分并且细化。

首先我们要发布的第一版本进行模块划分。在看板墙功能列表区域，划出5个区域用于表示模块。最后经过讨论，形成5个功能模块：安卓，iOS，HTML5,行情服务器，用户服务器，和交易服务器。开辟出来的功能列表列被6个细分的模块规划成看板图

接下来，拉着老王，产品经理，技术开发负责人JAMES我们几个人关到一个小黑屋里，对于第一版本要做的功能进行拆分。每一个模块想要做的以可测试，可交付为原则进行讨论。每一个要做的功能记录成一个贴纸，分别标上ID,描述，要达成的目的。这就形成了最原始的第一版本发布功能列表- 准确地说是第一版剩余开发功能列表，因为在我来之前已经有少量的功能开发完成。整个功能点的拆分进行了一个下午，共产生了70多上功能卡，这是一个富有成效的下午。





关于评估

Estimation never accurate-评估从来就不准确。我一直信奉这个话，特别是在软件行业显得特别真实。软件研发跟其他行业不一样，它的未知性，不可预测性太多。而且涉及到程序员之前个体能力，经验，对业务熟悉程度的差异，评估就更显那么不靠谱。在敏捷中有用故事点，人天等来做评估，但是我觉得用T-Shirt size来做评估就合理，特别是在现阶段，花少量的时间在评估上更多的时间在做开发以及解决真正问题上更符合我们特点。而且T-Shirt size 一样可以测量以及度量。

很快地，跟老王商定评估就用T-Shirt技术。并约定S号为小于1天能完成的评估量；M号表示大于1天而小于3天完成的评估量；L号表示大于3天而小于5天能完成的评估量。任务大于5天的功能点应该再进行拆分。

而且希望50%以上的功能点都是属于S型号的，30～40%功能点属于M号的，L号的功能最好能控制在15%范围内。

选定评估技术，接下来就请每个模块的开发者来到物理看板前，针对每个功能点贴纸进行讨论评估，把评估结果S,M,L写在贴纸的右上角标识每个功能点需要开发的估算。整个评估过陈大概用了2个多小时，对于一些有疑问的功能点，产品经理和老王在旁边解释。

我喜欢这样的评估过程，耗时不长，但是基本能让开发人知道要做什么而且回答了他们大多少的问题，并且得到了评估结果。

每日站立会更新

相信但凡实施敏捷或是精益看板的团队都会举行站立会。标准的站立会沟通方式模式每个参加人员回答

今天完成了什么
明天计划完成什么
别人对我，或是我对其他人有什么依赖
但是居于我们功能点划分采用T-Shirt评估技术，一些M型号以及L型号的在某一天内不能完成，所有
4000
我们在站立会时会针对地采取如下方式

对于S型号的功能点我们会回答完成了哪个功能点
对于一天内不能完成M或者L号的功能点，我们回答完成了%。于是在贴纸有了这样记录 2015-12-16 :30%;  2015-12-17:70%; 2015-12-18:100%
这样用百分比的进度也给我们一个清晰一个概念,对于比较大号的功能点开发的进度

 

度量 – 周计开发吞吐量

看板经常用的累积流图,特别是Cycle time,lead time来度量团队对开发能力。

我考量的是每周能完成多少个功能的开发。当前情况下没有能够度量的数据，那能做的是利用当下，跟踪记录每周团队能够交付多少S,M,L功能点。

设计的跟踪表格是这样的

 

周计算开发交付功能吞吐量统计表
周	S	M	L	总计
W49	15	8	0	23
W50
W51

 

 

 

 

发布计划

一种是Time-boxing 发布，即是固定时间发布。

另外一种是功能驱动发布，即是一定要满足某些固定功能才可以发布的。

我们的产品成功，基于一些特性功能所以我采用第二中即功能驱动发布计划。

计划的关键点之一在于，对于团队当前开发吞吐量能力的一个掌握以及剩余工作量的预估。

通过2周的记录跟踪，我有了过去2周时间内每周能够完成S,M,L共23个功能点的，这就是当前团队开发的周吞吐量。

 

我再把剩余的工作量输入到工作表中，用excel 表中的透视表功能汇总出S,M,L的功能点个数。按照当前的周吞吐量为完成23个S,L,M个功能点，剩余的功能点需要3周的时间才能开发完成。

3周后我们会把所有功能交付，预留出一周时间来做UAT以及功能到生产服务器上线 – 这就是我们第一版本发布计划。

计数项:Sizing	模块
Sizing	H5	iOS	安卓	行情服务器	交易服务器	用户服务器	总计
L	0	0	0	3	0	0	3
M	3	6	6	1		3	19
S	5	12	11	7	3	1	39
总计	8	18	17	11	3	4	61