看板原则：软件开发项目的灵活新解

北京心玥软件公司的一个项目经理在做一个生产型企业的项目时，差点被瀑布模型坑死——半年憋个大版本，客户中途说“这功能不要了”，全组人加班白干。后来听同行说试试看板，一开始还觉得“这不就是块白板贴便利贴吗”，真用起来才发现，这玩意儿是把制造业的老法子揉进软件开发里，比Scrum还懂“灵活”俩字咋写。  

看板的起源与发展

说起看板，它压根不是为软件生的。我有个在丰田混过的老同学，说他爷爷那辈车间就用看板了——上世纪50年代丰田搞精益生产，看板就是块小卡片，写着“该生产啥、生产多少”，机器没空就不动工，绝不瞎囤零件。这套“准时制”思路，说白了就是“按需干活，别浪费”，后来不知谁把它搬进软件圈，嘿，还真成了香饽饽。  

其实啊，这套思路跟后来敏捷软件开发的根儿是一脉相承的。2001年《敏捷宣言》刚出来那阵儿，我们公司还在死磕瀑布，半年憋版本，改需求就得吵架。后来转敏捷，Scrum、精益都试过，才发现小步快跑多爽——但Scrum太“规矩”，定了冲刺目标想插活儿比登天难；精益又偏理论，决策链绕得人头晕。直到用上看板，才算找着平衡。  

看板与Scrum、精益的对比

说到这儿得提提Scrum和精益，这仨常被放一块比，但其实各有脾气。Scrum像个严格的跑步训练营，每天站会、冲刺计划、评审回顾一套仪式下来，协作是顺了，可一旦定下冲刺目标，想临时插活儿比登天难——去年我们组用Scrum，客户突然要加个紧急功能，卡在冲刺里动弹不得，急得我直薅头发。精益呢，Tom和Mary Poppendieck 2003年写了本《精益软件开发》，把“映射价值流”“消浪费”这些词儿整得挺玄乎，实际用起来决策老费劲。  

看板就聪明多了，它不跟你抢地盘，反而把Scrum的协作和精益的“拉式”思路揉一块。微软2004年就试过Scrumban（Scrum+看板），苹果更绝，新手机先造一批卖，看客户反馈再扩产，全是“拉式”那套——客户要啥我做啥，不瞎忙活。  

看板的四项原则

看板这东西不是让你推翻重来，它的四项原则听着就实在：  

第一，从已知入手。别上来就喊“革命”，先看看团队现在干啥有用。我带过一新团队，之前用Excel管任务，虽然乱但没出岔子，我们就从Excel入手，慢慢加看板列，没硬推新工具，反而大家接受得快。  

第二，同意慢慢变。变革不是一锤子买卖，得像煮粥似的文火炖。我们组每周五留半小时聊“这周看板哪卡壳了”，小改小动，半年下来流程顺多了。  

第三，别动人家饭碗。看板不是来换你Title的，该开发开发，该测试测试，只改影响效率的地儿。我见过有的团队强推看板，非让测试兼做产品，结果全乱套。  

第四，人人都能当领导。看板墙前谁都能指指点点，新人发现流程堵了也能直接说，去年我们组实习生提了个“按客户分泳道”的点子，真把跨团队沟通成本砍了一半。  

看板的六招核心实践

光有原则不够，还得有六招核心实践，说白了就是“拉式干活”的具体法子：  

1. 把活儿摆出来让人看见。我们组看板就三列：“待做-进行中-完成”，再加个“阻塞”列，谁卡壳了贴红标签，一眼就知道哪着火了。设计看板别学别人，按自己团队痛点来——我们给VIP客户单开个泳道，优先级立马显出来。  

2. 别贪多，限着WIP（进行中工作）干。这招最狠！以前我们组同时开七八个任务，人都累成狗还没产出。后来定死WIP上限5个，做完一个再拉新的，速度反而快了——就跟吃饭似的，一口一口嚼才香。  

3. 盯着流程走。看板列就是流程地图，哪列堆一堆卡片，准是那儿卡住了。上周我们“测试中”列堆了8张票，一查是自动化脚本挂了，赶紧修，当天就疏通了。  

4. 规则摊开了说。什么算“完成”、谁来挪卡片，全贴在看板旁边。别搞暗箱操作，不然新人以为你在针对他。  

5. 反馈要快。我们组代码提交后自动跑测试，15分钟出结果，有问题立刻@人改。慢反馈跟吃馊饭似的，越拖越难咽。  

6. 边干边调。看板不是死的，这个月好用下个月可能就废。上个月我们试了“按技术债分泳道”，发现效果一般，这周又改回按模块分，灵活才是王道。  

用看板这种方式，最大的感受是“不折腾”。它不像Scrum非得搞仪式，也不像精益讲一堆大道理，就是把“按需干活、少浪费、看得见”这三件事做到位。我们组现在用看板+Scrum混搭，紧急需求直接插“快速通道”列，不耽误正事，客户满意度倒涨了。  

说到底，软件开发不是造火箭，别把自己框死。看板这老法子，说不定就是你缺的那把“灵活钥匙”。