《精益开发与看板方法》—2-4 为何要使用看板方法

2-4  为何要使用看板方法

看板方法想要达成以下两个目的。

1.     实践工程师能够在敏捷开发中以一种持续的步调工作，而免受无穷无尽的需求所困扰，搞得精疲力尽（希望工程师能够在正常工作下，活得快乐一些！）。

2.     在最小的阻力之下，将敏捷方法成功推广到整个企业（希望能够顺畅且成功推广敏捷开发）。

这是看板方法之父安德森第一次采用看板方法的时候心里想达成的两件事。2004 年，安德森受上级指派前往微软一家子公司负责推行敏捷开发方法，那时候的他担任产品经理人的职务，由于已经有相当丰富的项目经理经验，也知道子公司的工程师大概会有什么样的反应，因此他选择阻力最小的方式，也就是让工程师们自己主动进行改善的方式。但是万万没有想到看板方法居然具有如此强大的效能及改善能力，从此以后，一提到采用看板方法，大家想到的就是流程效能的极致化，也就是持续追求效能改进的方法。当然，看板方法绝不止于效能的追求，但目前我们还是先把它界定于此，因为这样有助于我们快速学会如何运用它（在下一章里，我们会用六个实践来体验看板制作的步骤）。

看板方法能够协助我们做到一个首要目标七个次要目标：

l   首要目标：优化现有的流程

l   高质量交付

l   提升前置时间的可预测性

l   提升员工满意度

l   为改善留出盈余时间

l   简化优先级排序

l   使系统设计及运作透明化

l   设计能够打造高成熟度组织的流程

首要目标：优化现有的流程

l   贡献看得见：通过看得见的流程、看得见的瓶颈、看得见的问题、看得见的浪费……，针对这类只要看到之后就容易进行调整的症状，运用可视化流程做到持续改善、继续调整流程的贡献。虽然看得见（Visualize）不是灵丹妙药，但却是一种不折不扣的最佳做法。例如测试的工作，与其大量做猜测式的测试，还不如在开发之初就针对需求把测试用例写好，让看板方法协助在文件阶段就开始查错，让测试计划与开发计划一起透明化展现在看板上面，此时产品的质量自然也会渗入其中。这是它正面的部分，但还是有负面的地方值得注意，就是那些看不见的地方，要知道不是做完所有的测试用例之后产品就没有缺陷，还有许多在测试用例之外的缺陷是看不见的，同样需要操心。

l   设限半成品（WIP）数量：通过限制半成品数量来取得“盈余时间”，是平衡多任务浪费的最佳解决方案，也就是让工程师做对产能有帮助的事，比做一大堆半成品更有价值。这一点最有意义的地方是，工程师可以利用盈余时间来写文件或交叉测试，另外，拿盈余时间帮助学习成长也是很好的投资。

l   调整就是持续改进：看板上显现出来的问题，团队一起分析和讨论找出解决方式，然后尝试调整改进，这正是敏捷开发所追求的渐进式的开发方式。丰田式管理认为只有在生产一线的工作者才是最熟悉流程的人，如果可以让他们自行视状况做决策，应该是最合适、最正确的决策。同样的道理，只有写程序的工程师才知道程序目前的状态，何时必须做怎样的调整，所以程序的作者才是最适合做调整的人，让他们自主调整才是最具有效能的改善。

高质量交付

想要产品有好的质量怎么办呢？“重视它”是提升质量最有效的方法！是的，就只是重视它，质量就会开始变好，这正是所谓的霍桑效应[1]，即只要你一开始重视，质量就会开始变好。看板方法是直接把它（测试、验收）当成一个开发流程的字段，然后进行流程控制，每完成一个工作项就立刻做测试，摒除传统测试必须冻结程序开发，而后排定时间进行 α 测试及 β 测试[2]的方式。让测试与程序开发并行，自然会强化交付的质量（要提升质量，我通常建议客户由重视质量开始做起，运用的方法是牺牲所有会议的前 5 分钟来讨论缺陷 bug，不管开什么会，会议开始时一律硬性规定这么做：先来讨论 5 分钟如何改善缺陷，不用多久质量就自然而然有所改善了）。

图2-3  直接将测试排入每个工作项目的开发流程中

敏捷测试的精髓在才能将质量持续注入产品的开发过程中，它的做法是让每个开发的工作项目都用测试来做验证，只有通过验证后才算真正“完成”（done）。由图2-3可以发现，开发与测试都是工序，这也说明了测试与程序的开发工作是同样重要的事情。

许多国外的软件公司确实都已经这么做了，在软件项目的人力规划中，一个程序设计师就会搭配一个专职的测试人员（微软的软件开发部门已经这么做许多年），实际上的测试人员与程序设计人员的比例是一比一。但这一点对人力资源没有那么充足的软件开发公司就很难实施，必须有多一倍的人力才可能做到，真正实施起来确实有些困难，怎么办呢？看板方法正好可以运用排队理论与多任务的思维来解决这个问题（详细的解决方法请参考下一章对如何进行多任务工作的介绍）。

提升前置时间的可预测性

这里的“可预测性”是指经由稳定的半成品（WIP）数值，使得记录在累积流程图（Cumulative Flow Diagram，CFD）上的曲线显得平滑，因此我们就可以比较容易去预估它。对主管而言，这种好的可预测性相当珍贵。图2-4的左图中有四条曲线，分别描述单位时间里停办事项（Backlog）的减少量、单位时间里的开发工作量（Dev）、单位时间里的测试工作量（Test）及单位时间的产出量（Production），当曲线越平滑则相对的可预测性就越高。右图则是描述理想中的看板流程图，读者可以很清楚地看出固定斜率的斜线就是我们预估的理想状态（WIP值始终不变）。两张图示相比较之下，可以体会到现实与理想的差距，还真是不容易预测。

图2-4  累积流程图（CFD）

前置时间越长，越容易引起缺陷率呈非线性增长（这是观察到的普遍现象，目前尚待理论的佐证），但避免前置时间太长是必要的措施之一。

提升员工满意度

看板方法从一开始便认为被压迫的员工不见得能有高效能的表现；反之，员工在满意的环境下容易受到激励而有高效能的表现。

我们已经提到过几次看板方法如何来增加团队的效能，它们大都是数据化，可以度量，这一点是看板方法能被制造业所接受的地方。但其实在实施精益原则的时候，精益的精神同样具有相当大的影响，一个能够让员工满意的企业，经营成功的机会自然会上升；同样的原则可以延伸到开发团队身上，一个满意度高的团队，自然会有较好的输出效能，因此提升员工满意度也是增进团队的方法之一。

为改善留出盈余时间

平衡员工的生活与在不影响产能之下的适当盈余时间，能让员工有更多的时间与机会学习和成长，公司也会因为员工的成长而间接提升战斗力。下一回我们再来谈盈余时间（Slack），即安德森所称的产生盈余时间（Create Slack）。

信息快速起飞的时代大家都更忙碌了，更没有时间学习与成长，所以企业会随着潮流的变化快起快落，过去所谓的“十年河东，十年河西”的变化，现在可能要缩短成一两年之间就会有大起大落的改变。敏捷方法所带来的竞争力提升，是一种改善开发方式的良方，而看板方法则通过改善流程所产出的盈余时间直接帮助团队成员。我过去做顾问的经验中，在引入新改革方法的时候，首先要做的便是为团队找时间，要知道一个没有时间的团队根本很难再去学习新的东西。秉持着“要找时间”这种想法，我的第一步动作通常是先进行流程改善的工作，想办法在实质上通过流程的改善为团队找时间，当找出可以运用的时间，团队才可能学好一种新的东西，相对地我的顾问成功率才会提升，这一点还需要组织领导者的配合才可能成功。

简化优先级排序

并非所有东西都能用精确的数据来表达它的重要性，当我们刻意或过度追求这些数据时，反而容易适得其反。一个现实的例子是索尼的员工考绩评估，由于过度追求精确度（这是典型的政策执行复杂化，造成战斗力的大量消耗所带来的后果），因而造成公司战斗力大幅度下滑，以至于在市场上无法与对手竞争，并造成上百亿的亏损。因此，适度的抽象化各个功能之间的优先级是一个既简洁又可以节省时间的动作，例如：对各个工作事项采用“高、中、低”三种层级的分类，或是参考 Scrum 在计划会议时常常采用的MSCW（必须要有 Must have、应该要有 Should have、能有很好 Could have、不必要有 Won’t have），也相当可行。当然，实施的方式影响也相当大，不能只有抽象化考绩的评等，实施细节的简单化更是不可或缺的要素。

使系统设计及运作透明化

“透明化”几乎是所有敏捷开发方法都强调的重点，原因是敏捷开发强调团队自我管理，而团队要能够做到自我管理，必须有一个先决条件，那便是项目开发流程的透明化。团队成员必须知道自己在做什么？这些工作对团队有什么影响？弄清楚才能够发挥自己在团队中的影响，从而做出贡献。所以，项目的透明化是团队运作的基础。

看板方法实施的第一步骤是“可视化”。可视化无疑已经奠定了极度透明化的基础，而更进一步，它把“静态”的透明化演进为“动态”运作的透明化，让不只是主管而是全体成员都能知道整个流程的运作，这一点使团队成员容易发挥自我管理的效能，对管理而言弥足珍贵。

静态的透明化 VS. 动态的透明化

透明化应该只有多寡、深浅之分，哪来静态与动态的区分呢？请听我说，我们往往假设团队的成员都有一定的技术水平，对敏捷开发方法也有着相当的认知，但这种假设通常都与事实不符，因为很少有团队能够做到阵容整齐、一致。团队的阵容总是有强有弱，有资深的和资浅的，有刚进来的也有一直想出去的，有科班出身的也有转行过来的，有熟悉数据库的也有只会处理用户接口的前端工程师，各式各样的工程师你都可能遇到，而大家所看到的项目透明化也一定不相同，至少不会与屏幕上图片的透明度一样。

当大家一起站在看板的前面时，所有的信息都写在看板上面（包括 Scrum 著名的站会的三大问，[1]），但每一个人的解读就可能不太一样！所以看板上所提供的信息对大家或许是相同的，这种陈列在看板上的信息我称之为“静态的透明化”；而有人认知较深、有人则意会得较肤浅，这种超越视觉的、在认知上的差异我称之为“动态的透明化”。

我们可以让团队通过站会一起在看板前面讨论工作流程，但很难想象工程师的脑子里到底在想些什么？也不可能做到团队成员对看板上的信息都有相同的认知。通过看板，我们可以很容易做到静态的透明化，但是必须想法子让工程师通过讨论或互动教学等方式，让成员做到动态的透明化。要知道，透明化不是主管单方面的责任，若要达到团队自我管理则，一定要想法子[2]迈向动态的透明化，之后才可能发挥看板方法持续改善的效果。

设计能够打造高成熟度组织的流程

看板方法的拉动系统（Pull System），能够适度在组织管理上显现出团队自我运作的独立性，提升组织运作的成熟度，而逐渐影响到企业的精神文化。“能够渐进地影响企业的文化”这一点早已是精益软件开发（Lean software Development）的基本特色了。

丰田精神被软件界的先驱玛丽&汤姆·波彭迪克解读成精益软件开发的七大原则，这七个原则最大的目的就是在通过精益的精神，让组织底层的工程人员能够学习到一种自主式的拉动精神，晓得在工作流程里扮演好自己的角色，主动做好自己的工作，借此由下而上改善企业的成熟度。虽然我们都知道，改革的动作通常都是由上而下运作才容易获得成功，但精益的精神则告诉我们要通过持续改善，不止是由上往下，更要由下往上才能形成自我管理的团队，并获得全面性的成功。