前篇文章中介绍了敏捷开发的Scrum方法，本文将要介绍的是另一种流行的方法——看板Kanban，以及两种方法的对比。
看板源自丰田公司开发的用以改善汽车制造流程的体系，其生产体系注重及时生产「Just-in-Time，JIT」，以避免浪费，这可以认为是精益软件开发运动的前身。
看板的核心概念是可视化。每张卡片代表一个用户故事或随之而来的开发子任务。卡片都被排在看板上，从左至右，每一列按照工作流程顺序，如下图所示。
有些列代表工作正在进行「如开发中、测试中」；有些则表示有待进入下一个工作阶段「如预备、开发完成」，同时这些列表中积攒的一系列工作，当一名团队成员完成了手头的工作后，便可以从中选取最优先一项。
当工作项目逐一经过各个阶段时，代表这项工作的卡片也会从上一列移动至下一列。整个团队的工作状态都可以通过看板一目了然，与此同时也很容易从那些积攒了很多卡片的列中看出瓶颈所在。
「开发」和「测试」有两种状态的好处在于有助于让团队对工作状态有一个更清晰的认识，易于发现瓶颈。
看板中激活的工作数量受到“进行中的工作”的制约，开发团队会决定每一列所允许的最多卡片上限，称为在制品数量上限「working in progress，WIP」。这条规则能确保工作流程的平稳、顺畅。
还可以用用到来进一步划分看板，采用水平线横向管理个列表中的卡片。采用优先泳道的方式为每个史诗故事分配单独的泳道；可以为每个人分配单独的泳道来更清楚地显示其工作流程；可以在一块看板上记录下多个相关项目，将每个项目放在一个单独的泳道。
看板的重点在于工作流程，它没有Scrum的迭代时限。当工作向前推进时，相应的工作项目也持续从看板的左侧向右侧移动，所以Scrum中的开发速度改变并不是适用于看板。但可以按团队在一段时间内完成的工作项目来测量团队的生产能力。
看板中有两个经常用到的指标：循环时间「即某工作项目从开始处理到交付给客户所消耗时间的平均值」和交付时间「即每项工作从创建之初到交付给客户所消耗时间的平均值」。工作循环时间和交付时间并不一定与工作量相关。比如某项工作可能只需要一个小时「循环时间」即可完成，但由于需要等待开发团队来处理而很较长的交付时间。
可以用累积流图形象地观察看板系统中的工作流状况，如下图示，简单起见，只用了三种工作状态：待办、开始和完成。
看板理念体系专注于持续改善，团队应定期回顾和讨论如何更快、更好的工作。随着团队技能水平和流程持续的改善，产品的交付时间和循环时间也会逐渐缩短。
Scrum冲刺期，待办任务列表在每一次迭代期内经常是锁定的；在看板体系中，团队成员可以在任何时间点改变看板中的待办任务。看板没有Scrum对各层次的过程规定和工作仪式，不过许多应用看板方式管理的团队也会开每日例会和定期回顾会议。
对于看板工具，小型团队一般会用一块白板+便利贴来表示，另外一些专业的管理看板工具，如Trello、国内的Teambition、Worktile、Leangoo等。
Scrum vs Kanban
看板往往适合小型开发团队，更低的流程开销和无需预先定义迭代时间的长短，使得产品交付更加快捷。但随着开发组织发展至多个团队，由于缺乏预定的工作节奏，要保持所有人达成共识所需的沟通成本越来越高，看板就越来越难以应付。如果团队有强大的协作功能，可以藉此放大看板的使用范围。
如果组织能有多个开发团队需要协调工作，工作节奏更加可控的Scrum比较合适。
如果很难抛开时间节点的限制，或者心里没底，那Scrum可能比看板更适合。因为在Scrum中，至少知道每轮迭代后还有什么工作可做，并且能大致预估出每项功能需要多少轮冲刺迭代才能完成。而绝大多数看板并不会在评估工作量或预测完成日期上花时间。
不论采取何种方法，敏捷开发方法成功创建产品有一下几个秘诀，
跨职能合作：强有力的跨职能团队的相互协作；
精密排序：维护一份最新的、根据优先级排序的待办任务事项列表；
为开发者充分定义产品：提供一份清晰明了的用户故事，配以框架图或模型；
不能让开发者无米下锅：待办事项列表的内容至少要保证开发人员在一个冲刺迭代期内满负荷工作；
分解用户故事：用户故事不应超过某个合理的规模范围，应分解成尽可能小的模块。
网友评论