上次Arthur老师给大家讲了敏捷开发模型之一的Scrum，这次给大家介绍的是敏捷开发的另一个模型——Kanban。
Kanban，各位读者您没看错，英文也是这个。翻译过来就是特直接的——看板。
Kanban是一种高效管理软件开发过程的新技术，是丰田“准时制”（JIT）生产系统的基础。尽管生产软件是一种创造性的活动，因此不同于批量生产汽车，但管理生产线的基本机制仍然可以应用。
软件开发过程可以被看作是一条管道，特征请求进入一端，改进的软件从另一端出现。在管道内部，会有某种过程，从非正式的临时过程到高度正式的分阶段过程。
在本文中，我们先假设一个简单的分阶段过程：
（1） 分析需求
（2）开发代码
（3）测试成果
瓶颈问题
我们想象一下：若干粗细不一的管子连接成一个管道，其中管道中的最细的那根管子限制了整个管道的流量，或者叫整个管道的吞吐量。我们姑且称之为“瓶颈”。
以我们的开发流程为例：如果测试人员每周只能测试5个功能，而开发人员和分析人员每周有能力生成10个功能，那么整个管道的吞吐量将仅为每周5个特性，因为测试人员是一个瓶颈。
如果分析人员和开发人员没有意识到测试人员是瓶颈，那么积压的工作将开始堆积在测试人员面前。
如此一来，不可避免地，质量会受到影响。为了跟上步伐，处于瓶颈部分的人员开始偷工减料。生产过程中产生的问题会给用户带来问题，并浪费未来的管道容量。
另一方面，如果我们知道瓶颈在哪里，我们可以重新部署资源来帮助缓解它。例如，分析人员可以帮助测试，开发人员可以在测试自动化方面工作。
但是，我们如何知道在任何给定的流程中瓶颈在哪里？当它移动时会发生什么？
使用Kanban动态地揭秘瓶颈
Kanban非常简单，但同时也非常强大。在最简单的形式中，Kanban系统由墙上的一块大板组成，上面有卡片或便条，放在顶部有数字的列中。
这些卡片表示工作项，因为它们在由列表示的开发过程中流动。每列顶部的数字是对每列中允许的卡数的限制。
限制是看板和任何其他视觉故事板之间的关键区别。在流程的每一步限制在制品（WIP）的数量，可以防止生产过剩，并动态地揭示瓶颈，以便在瓶颈失控之前解决它们。
举个栗子
下面的Kanban板显示了这样一种情况：在测试人员释放出一个槽并拉入下一个工作项之前，开发人员和分析人员无法继续工作。此时，开发人员和分析人员应该考虑如何帮助减轻测试人员的负担。
请注意，我们已经将一些列分成两部分，以指示正在处理的项和已完成并准备好由下一个团队流程拉取的项。你可以用几种不同的方法布置黑板。这是一个相当简单的方法。拆分列顶部的限制包括“正在”列和“已完成”列。
一旦测试人员完成了对一个特性的测试，他们就会移动卡并在“test”列中释放一个插槽。
现在“Test”列中的空槽可以由“development“done”列中的一张卡填充。这将释放“development”下的一个插槽，下一张卡可以从“analysis”列中提取，依此类推。
上面简单介绍了一下敏捷开发的Kanban模式。
顺便说一句，在中国大陆，几乎每个开发团队都在搞“敏捷”，很多团队都声称自己做的是Scrum，实际上他们做的介于Scrum和Kanban之间。
作 者： Testfan kitty
出 处：微信公众号：自动化软件测试平台
版权说明：欢迎转载，但必须注明出处，并在文章页面明显位置给出文章链接