改进从何谈起？必须找到起点，那起点从哪来？

看板不需要像Scrum那样改变以往工作角色，简单通过任务上墙，配合敏捷的设计就能通过显示化日常工作来让问题自己蹦出来。在任何一个新采用看板的研发团队，执行一两周后一定会暴露出很多在开发过程中的问题，这些问题就是团队成长的空间，可以把这些问题作为团队持续改进的出发点。

上午公司开完2016战略发布会，下午来到公司想写写文字记录一下材价看板这两周中发生的事，准备下周再带着团队一起做一个回顾会议（如果还不知道回顾是什么，看看我以前写的  《回顾会议》）。

这是刚开始做的 第一个kanban

1月份这一周各种会议，我基本不在公司，不过大家经过一周的践行，已经会自己去运作看板了，这是两周后看板的样子

总体来看，看板卡片往右移，多了一些黄色小纸条。怎么多了黄色小纸条？Scrum不是说过程中不允许添加任务吗？

我们不是在用Scrum，而是看板，所以忘记那些书本上学到的或者听来的知识吧。今天我会展开来说一下这些变化，以及其中一些看板卡片。

挪来挪去的卡片

这个故事卡片是【查找周边城市材料】，这个卡片有很多可以回顾的点，有些在  第一个kanban 中已经说过了。这里我们再说说它在这两周是怎么动的。

第一周的时候，这个卡片经过设计的doing之后挪到开发的doing，但是开发对这个任务还不能肯定能完成，所以一直还未开发完，存在技术障碍，这说明我们对搜索引擎的深入一些的技术就无法胜任。深入搜索引擎学习是上半年团队研发人员的主要工作，否则不可能改变核心问题，下周看看团队是如何回顾这个卡片的：）

为了不影响其他任务的进行，我破例做了一次操作，把卡片挪回来设计的done，以便可以挪入另一个任务进来。（如果你没有听过我的看板课，不知道WIP的可以自己上网找找详细说明，简单的说就是在制品work in progress，用来明确限制流程中每个状态上最多同时进行的任务数）。

还过去的债

往往我们被工作压着往前赶，去忘记一些基础的东西不做好要付出的代价，这是一个重构的卡片，过去的建索引代码不易维护、比较混乱，建索引中还有错误，但是开发人员没去查到底是数据原本就有问题，还是代码有问题，这就么一直留着。这次项目组人员变动，交接后就立即开始了还债工作，重构了信息价和市场价的建索部分代码。

这个卡片属于技术性的任务，之前我定了一个规则：任何一个看板上的故事卡片都必须填写部分，于是测试人员后来在这卡片上补上了这部分内容。

必须建立起灰度发布的机制

这期有一个任务是去掉首页的城市选择，我觉得这已经改变了用户的习惯，所以提出必须灰度发布，还讲到一个成熟的灰度发布还必须有一个灰度发布引擎，可以根据一定的规则由发布引擎判断之后转发到不同的版本去，但至于如何去做团队自己考虑。

开发后来想到是否仍旧使用一个页面，通过访问IP来控制显示选择城市按钮，于是问我是否可行。这个时候我把自己定位于敏捷教练，所以我要控制自己的方案提出，除非他们真的想不出来，于是我说可以，并且说到，只要能实现我们所要的结果，越简单的方案越好，我们的目的是通过快速发版获得学习。

一个问题的解决方案总有多个，没多久团队又提出一个方案，是否可以发布两个包，让IDC通过IP直接转发到不同的服务器。听完之后我觉得这个方案比第一个好，适用性比较强，以后可以去做更多基于地理位置的灰度发布。

这里要说一下，我一开始想到的方案其实第一种，如果我当时分任务的时候，我要是说出我的方案，估计大家就不会想出第二种方案了，所以作为敏捷教练，时刻要记住什么时候该做什么事。

第二天站会，测试提出一个问题，说灰度发布好像没什么意义，能不做灰度发布测试嘛？当时我就和她重新说了一下灰度发布的意义，以及为什么这次任务需要发布。但是她还是说能不能不做。继续问下去，她说到：这样灰度发布测试起来好麻烦，我要用外地的机器登录才能测，所以现在是和分支的人沟通，然后远程连接他们机器操作进行测试，这个沟通和远程操作耽误的时间很长。听后我也没有立即回答方案，因为我当时也没想到什么好的解决办法，于是我对着负责这个任务的研发人员说：“你看看能否从技术上去解决这个问题？这样测试的确太麻烦了。” 接着转向测试说：“不管测试多么麻烦，这是我们现在的能力问题，但是灰度发布这个事情是必须要做的，不管多难测试，这是你需要考虑去解决如何更方便测试的问题。”

晚上我回家就想这个问题，毕竟我还是团队Leader，在没有方案的时候我必须是要有至少一个方案的。第二天早上，我准备去和开发说用VPN应该可以。我说到：“那个灰度发布测试的问题你看看能否通过VPN来解决。” 开发人员说：“这个问题已经解决了，测试已经开始测了，用网络代理，浏览器设置一下就可以了。”

又一个比我好的方案，让我再次印证了教练的最佳方法是激发团队自己找到解决问题的答案，这也保证了我们后续更方便的进行灰度发布了：）

怎么又是登录问题？

去年初接手掌中广材时，在维护老版时总接到登录不了的反馈。当时我就觉得很纳闷并有点不可思议，一个产品竟然有总反馈登录不了，那用户还怎么使用产品功能呢！考虑再三，后来我决定重新开发掌中广材，也就再没有因为登录问题困扰我们了。

今年接手广材网，感觉好像历史重演，有反馈登录不了，同样的一个遗留问题。

因为有了看板和之前我约定的一些规则，大家解决这个问题的响应时间还是比较快了，几个开发都一起来找问题，最后发现可能是公司云账户那边处理的问题：在IE11下cookie传入不到公司云账户系统导致登录不了。我说到出现问题在哪就和谁一起解决，研发都蛮主动，找了云账户研发人员，但是他们那边始终没有复现这个bug，在我们这边也就一个人的机器能复现这个问题，于是大家也不知道该如何解决了。

我看到这个黄纸贴在快速通道的开发doing呆了两天，解决不了不要紧，问问用户情况，于是和产品人员说到，和用户联系一下，具体问问他们现在怎么样了。得到的回复是：“打了，不过没人接，打不通。”我问能不能拿自己手机打？

这几天都是会，我也没有太关心此事了，今天下午回到公司，广讯通看到测试发的留言信息，是用户和她聊天的截图。

于是我和产品人员留言：联系不上用户，别人却主动找上门来了。有没有和用户说这里也可以登录？

对于用户反馈，大家缺少一些常见问题的应对，也缺少对服务的认识。如果登录不了，是否可以让他直接访问公司云账号登录页面来登录一下，这样可以初步定位一下问题是在云账号还是广材网呢？如果云账号可以登录，那是否可以先告诉用户点击广材网最上面的【登录】按钮进行登录使用呢？对用户反馈bug的服务，首要是解决用户当下之急。一般这时候反馈的用户都不是粉丝，他反馈登录不了就是要马上登录进去查材料价格，如果我们先告诉他通过上面的登录按钮点击进去登录后再解决这个技术问题，用户的感受是否会好一些呢？

我发现网站首页对登录功能竟然有三个地方，最上面，右边，以及下边栏。不知道当时为什么这么设计的，从没看过因为要让用户登录就到处放登录按钮的。这里暂且不说产品设计，回到这个技术问题，自己解决其实并不难，不过从架构设计角度来说，这个应该放在会员中心，各产品只是调用会员中心的接口，所以从产品最优来看，我会把这个问题提到公共组，如果公共组不解决，那我就会自行先去解决。

【搜索排序】加塞了

看这个图片【无法登录】黄纸贴下的【搜索排序】这张卡片，为什么要说这个呢？因为这在最开始团队所做的看板上是不存在的，是因为在元旦期间进行站长培训中获得了一些反馈，我们于是在看板上增加了一些卡片。

这里要说一下的就是，实施看板和实施Scrum有些地方是不一样的，之所以我在团队没有推行Scrum，是因为当前团队和工作任务更适合用kanban，所以大家不要误会实施敏捷就只有一种。实施敏捷一定是根据团队成员现状以及产品而定，不过对于互联网产品我更倾向于使用看板和Scrum结合的方式，以后有机会还会写本系列的后续文字与大家分享。

这个卡片任务单我们团队是完成不了的，还需后台一起来完成，属于一个协调性工作，目前来看，大家配合的都还很不错。还是上篇说到，如果大家都来玩看板，弄成一个大看板就更好玩了。

开始优化工作

接手广材网之后，我申请了SVN权限，下载源代码之后，妈啊，这么多项目。在我印象中，如果广材网是我来架构的，一定是一个项目下有很多模块，而基于历史原因，模块都成了一个单独的项目，而且很多项目都找不到主人了。公共组想法和我也一致，就一起把这事给提前做了，放上一张卡片就代表开始了。

快速通道的设计

在看板的最上面一行，我们设计为快速通道。放到这一行的卡片就意味着大家先放下手上的事情，一起去解决完之后再做手头上的事，保证尽早解决问题和反馈。至于如何判定是否放入这里，每个团队可以制定自己的规则，我把用户反馈的bug，特别是数据类问题都归为此类，见一个就要立即着手给用户解决。于是大家可以看到上面的一些黄色纸条。

去年11月份的bug竟然还没改

看板运转一周后，大家对bug的处理方式建立了。站会上我提到：“我发现广材网bug很多，材料搜索的价格过滤有问题，而且这个问题从去年底就一直存在。”测试说：“不会吧，我这些都测过啊。” 我也没说什么，就让她站会结束后复测一下。

没多久，收到广讯通一个截图，测试来到我的位置，对我说：“这是以前测试的bug，还没改，这里还有一些。现在怎么办呢？”

我一看顿时又被惊呆了，都2016年了，这里的bug还有2015年11月份的。我反问到：“你觉得现在应该怎么办？”

后来我说到：“作为一个产品把关人，如果开发不管，测试应该义不容辞的去催着改。”然后我和大家说，“所有bug今天解决掉。” 接着下午开发和我说，“bug解决完了。”

这里要说一下的是，看板故事卡片的bug不需要再上墙了，因为本来就是一个任务。这次属于特殊，所有遗留bug改完复测完就行了，不需要上墙。

【样式调整】过三关上线后却被我一眼提了好几个问题

这一期有一个任务，是把信息价栏目的样式改为和市场价一样。

这几天经常在外开会，晚上回到公司的时候大家都已经下班了，我看了一下看板。测试人员还在，看我回来了对我说今天发版了，于是我马上打开看看，发现几个明显的问题，于是给大家留言。

这么明显被我一眼就能看出的问题竟然可以逃过三个人的眼睛，第二天站会我对开发、产品人员和测试人员一一说到这个卡片的测试问题，希望以后不要再发生发布之后被我一眼就能看出的问题，并增加了一条规则：以后任何一个故事都要经过三关严格验收才能发布（开发自测、产品负责人测试、测试人员测试）。

关于发布

bug解决了，测试问我什么时候发布？我说，如果你们能保证改完后的版本一切正常，那就当天发版。

这次改的一些是小问题，不会有代码关联的影响，所以我说今天发版，只要改掉一个问题就发版，我是不能容忍一个明知道存在的bug还留在正式线上环境的。这时他们说，以前是一周发一次的，我说不能等，必须发。这时候开发提出，他改了代码，SVN的代码不能编译发布。这明显属于开发管理上的问题，于是我又增加了一条规则：开发人员必须保证SVN的源码都可以随时编译运行。等这个任务完成之后，以后就要做到每日发版，更改一个bug或反馈必须当天就发。

关于看板方法

目前来看，大家对看板只能是简单使用，一些估时、卡片填写、验收等环节都做得还不足，不过经过两周的看板，大家的工作也基本开始有序起来，接下来的就是需要以目前已发现的问题作为起点，逐步改进优化。

昨天公司战略发布会上说到混序，自组织理论很早就有了。如果说我们的团队以前是一个无序状态，现在实施看板后就开始慢慢变得有序，敏捷团队的形成就是一个自组织的过程。最后放上一张12年我的一张讲义，大家可以先自己理解一下“涌现”、“规则”等这些字眼的含义，具体内容我们以后再在《材价看板》系列慢慢说。

互联网企业看板已经玩了好几年了，以前都是我给别人培训教别人玩，现在我也开始在自己的团队玩看板了。毫不夸张的说，工信部的每个团队都可以来玩看板，越早越好，即使你没经验也不要紧，因为有我在啊。