看板在开发与运维项目中的应用

PMP征文活动时写的, 博君一笑

看板在开发与运维项目中的应用

 

 

背景

 

自从2011年开始,公司开始上手新的项目, 我被任命为此项目的PM及PO, 开始了跨时两年多的敏捷之旅。以下与大家分享我在产品开发及运维管理中使用看板的经验。

为了使用业界的最佳实践，检验前一阶段的敏捷培训的成果，这个项目从开始就作为公司全面敏捷及应用SCRUM的几个试点大项目之一，关注点很多。我带的团队主要工作包括新特性的开发兼项目上线后的运维管理。

众所周知，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。减少了原先项目估算的不准确性,返工, 拖沓, 问题阻塞而导致的各种浪费,不均衡和风险。小粒度的用户故事可以在一两周的迭代内完成开发和测试（并行开发），从而可以缩短交付周期。而看板又可以有效管理大量小粒度user story。关于如何划分sprint, user story已经有大量的文章和资料可以参考，我们在本篇中只重点谈看板。因为一般看板的描述中，要不只照顾到新特性的开发，要不只注重于运维，如何两者兼顾，这就是我所研究的。我们的团队是国际化团队，一半在中国，一半在北美，如何使两个团队更好合作，也是一个挑战和乐趣。

我作为传统项目的PM向新的敏捷开发下的PO(ProductOwner)转变，PO会将项目发起人的一系列想法转换成具体的userstory, 计划好后交由敏捷团队来实现,可以说PO的主要工作作就是沟通和backlog的工作队列管理. 而看板和每日站会就是促进沟通和管理工作队列的强大工具。 下图[4]很好地描述了敏捷项目的基本框架stakeholder, PO, 开发团队, user story, 工作队列管理及团队容量管理。

 

 

经过管理层和团队骨干人员的讨论，决定采用以下几个阶段开展敏捷：第一阶段先在各本地团队中使用物理看板，然后再转换成电子看板，最后把两个团队的电子看板整合。整个过程中，实施每日站会，每天早上10点开始到10点15分结束,严格控制在15分钟内。

物理看板与每日站会

 

看板本来就从工厂中产生，使用的就是一块大的物理看板，每项任务都可视化，在每日站会中每个人都可以自由移动和改变相关任务块，例如从任务队列中拉一个任务出来分配给自己,从开发状态转入测试, 从测试到交付. 而关于客户的问题,则是从调查到验证方案, 到完成方案,或者说是由于受阻, 则会投递到等待状态.

模板如下：

 

看板很重要的是任务队列的管理, 这是PO的主要任务之一。但是不是所有任务就一定要由PO加到工作队列中去呢?一般来说对于新特性开发和新的release及sprint来说是的, 但对于运维任务, 则不一定.因为一般新来的运维任务都会有邮件系统通知团队,而不一定要由PO实时监视管理, PO也无法保及时把所有任务都加到backlog队列中,所以我们原来运维的team leader(screener)出马,负责观察和审核每日的新任务,以及时放到backlog队列中。但有时由于只有PO才能得到最重要的外部信息,例如客户突然要求某个特性或补丁由于商业的原因提前发布等等,而团队中其它的screener或Scrummaster都不知道,这时PO会立马出来添加高优先的工作任务到任务队列里去。

站会开始时, 很快可以见到的效果是沟通增加了,PM或者现在的PO的压力减少了, 不需要被动地接受任务, 每个人都可以主动去拿，而且大家也可以马上知道全局的工作状态。但站会的不足之处时有时轮为流水帐事的讲述，虽然所有人及所有工作状态都了解到,但重点把握不足, 有时为了避免超时,会将还没讲完的取消。于为改为从今天最重要的事开始说明，最重要的事中也按优先级顺序排列，这种可以保证要事为先的准则，而且即使时间不够，也可能保证最重要的事情先说完。

有时候看板在讨论中不知不觉地过时了，也PO, SM也尽量避免太多的控制，因此我们引入的看板主持人来引导讨论，控制时间，还有对全局所有任务的理解和相关跟进。我们采用每周一换的形式，发现效果还不错，每个人都有机会做主持人，显示自己的领导力，避免每个人只关心自己的任务，更多的是每个人都要（至少有机会）从全局上关注整个团队的任务。

         

统一的电子看板

 

在尝了物理看板和敏捷的鲜后，团队开始向下一个目标出发，如何与地理位置不同的国际团队统一流程 – 使用统一的看板。看板背后的流程与数据库，对于国际团队合作来说，如何统一看板，如何交接工作，是一个难题。物理看板只能适用于本地，因此有很大的局限性，电子看板似乎成为了我们的唯一选择。

 

我们调查了市面上的几个看板工具，例如hansoft,leankit等等,要不功能不适合,与我们现有数据库难整合,所以我们决定自己重新造轮子 - 我们自己开发了一个基于网页的电子看板，与我们现在的系统很好地整合了起来。幸好这个需求难度也不大，由于开发和运维两块我们都已经有了自己的工作界面和数据库，所要做的只是一个新的针对看板的界面而已。

 

例如我们原来的电子工作模式是，如果有一个新的特征过来，或者要做一个系统的新补丁，或者运维的任务，我们就会通过公司网页建立一个工作项，将需求(ticket或story point)，人物，交付日期等填上，然后每天更新状态及进展，有需要北美团队帮助的，就写上你的需求，然后晚上对方团队就会提出他们的建议及具体工作进展。同样如果北美团队需要我们的帮助，也是同样处理。这样的工作模式对于一般的工作任务是没问题的，但是如果对于难度更大，交付日期更短的工作，交接就不能这么简单，就需要电话实时沟通与交接了。电子看板的任务不过是将原来的电子工作流整合一下，每日站会也变成了需要订带有投影议的会议室的“坐会”，大家也只能“坐”在座位上指点看板。

 

 

成长之烦恼

 

后来由于项目人员的扩张,整个团队由8个扩张到14个人,差不多一倍的增长,工作量也大增,如果还像以前一样逐个任务一分钟讲解,那时间肯定超出15分钟.这时如何将时间继续控制好,而且也还能保持以前一样高效呢？我们采取的策略是：排序和精减！不是按先后顺序对它任务，而是按优先级顺序讲述。首先讲最今天最重要的任务,然后实行round table, 每个人快速的过一次,这样可以使要事为先,也能了解每个人的状态,同样由于每人都要发言,所以也避免了某人处于空闲状态,可以使人更主动地去”拉”工作队列里的工作。

其中保证优先级最高的任务先完成是最重要的一点，为此我们还修改了电子看板的工具，加多一条横向的泳道表示最高优先级的任务。

 

反思

 

实施了一看，有以下几个观察，好现象是：

1. 增加了团队的沟通，提高了士气.
2. 及时反映出工作中的问题以便及时解决.
3. 减少空闲状态，提高了团队的工作效率.

不足之处:

1. 重要任务只有站会不够
2. 自已电子看板的统计功能不够
3. 任务不能及时清理, 不像物理看板, 要清理任务, 把便笺条一撕就行了。

总结的最佳实践

1. PO使用优先级管理看板
2. 使用看板主持人引导讨论以及采用轮换
3. 对于一些重要的不能在看板讨论完的任务采用的是war room重点攻关
4. 对于跨地区团队来说，尽量使用统一的电子看板

相应的后续措施:

1. 关于统计和衡量功能,会继续参考其它公司的如Leankit来增强

 

总结

 

在国际化团化的协作中，电子看板能完成物理看板所不能实现的合作，是必不可少的。按优先级及roundtable来运行每日站会，即使团队扩大也能控制好时间。对于最重要的技术难题，使用warroom进行焦点攻坚。

 

 

Reference:

1. 拿看板拯救你——我的“红”项目
   http://www.infoq.com/cn/articles/kanban-distressed-projects?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_articles_clk
2. 看板和Scrum——相得益彰
   http://www.infoq.com/cn/minibooks/kanban-scrum-minibook-cn
3. 看板任务管理
   http://www.infoq.com/cn/articles/hl-kanban-task-management/
4. PO in a nutshell
   http://www.youtube.com/watch?feature=player_embedded&v=502ILHjX9EE
   http://pan.baidu.com/s/1qpqt9
   

 

 

更新

2014-01/07 - 添加看板最佳实践，更新看板主持人及轮换实践