Karl Scotland 讨论研究了看板系统中的工作流程和阶段跟敏捷思想中跨功能协作团队是否互相违背，他指出在看板中的阶段看似瀑布思想中的阶段，接下来的讨论澄清了看板中的阶段不一定是"手递手"方式的工作传递，而且还有其他的见解。
Karl 先剖析了貌似瀑布开发过程的看板系统：
分析 -> 构建 -> 测试 -> 发布
之后他分析了一般 Scrum 工作板，如下：
未开始 -> 开发中 -> 完成
Karl 然后找寻不同方法让这工作板透露更多关于工作流程的情况，在很多环境里，划上"完成"的功能不一定马上发布，或部署上生产环境，在这些情况下，在工作板上 分辨出"可准备发布"以及"已发布"很有作用，如果工作板上显示出"开发中"囤积等待发布，业务人员可能考虑例如以持续部署（Continuous Deployment）来优化开发流程。
Karl 进一步去看如何细分工作板上的阶段，他提出了一些更明确指出工作状态的名字：
培育（Incubate） -> 阐明（Illustrate） -> 实例化（Instantiate） -> 示范（Demonstrate） -> 偿付（Liquidate）
Robin Dymon 后来指出单是改名字是不会改变行为，但更改了名字是更大的方案中的一部份
更好的方法应该是以跨功能团队来简化开发过程，把测验放到在开发过程的前端，让每个人去负责产品质量，包括顾客，在这情况下我会用不同的名字，因为过程中每一步骤没有比团队如何合作付运功能更为重要。
Keith Braitwaite 有以下见解：
我认为如看板开发过程般以线性、关卡、"手递手"方式过程、没打算重做工作的诠释让很多人抗拒。
这观察乎合敏捷思想中寻求避免"手递手"方式的过程以及消除或者缩短序列式操作，以至协调更紧密的回馈，例如測試驅動開發有以下的阶段：
测试 -> 编写代码 -> 重构
实际上，由于开发人员很快地进行这周期，如果在工作板上纪录那么短的周期会是很冗长的工作。
从精益的角度，更重要的是让功能持续地"拉"（pull）进系统中（持续流动），而不是把工作囤积县后一次过完成，传统瀑布开发就是"囤积然后排队"方式的例子，所有的需求过程以批次方式进行，让需求囤积起来直至设计开始，同样地，设计工作完成后才写代码，如此类推。
在一个持续流系统，功能从工作列表中抽出然后持续工作直至完成，如果开发中有任何能分别的阶段，看板就可以分办出当中"开发中"的工作，过程开进就可以针对这些瓶颈来保持工作在系统中有效地持续流动。
一个功能经过很多阶段，由概念到实际部处，使用以至替机构增值，在看板中的工作流程没有强制要求如"手递手"方式过渡每个阶段，同样地也没有要求团队不能以协作方式确保该功能在每个阶段都顺利过渡。
Vasco Duarte 认为这讨论太集中在过程和工具上，而忽略了看板的重点，就是减低"开发中"的工作。
为什么要考虑呢？事实上看板中工作的序列（一个功能由工作列到发布）是一个很短的时间（一日，或者更少）而次序则很像分析、设计、编码。测试等，当然不是线性，但为何需要介意呢？但因为功能现由一个清楚如何实现的小团队去开发，即使这意味会"打破这次序"。
如果看板系统用作确保每个开发的过程都进行，用作执行团队的完成定义，其实简单的清单更为适合。
您会否认为看板系统看似瀑布开发过程中的阶段？如果是的，这是表面地类似还是很根深蒂固的？留下阁下的意见分享观点吧。
查看英文原文： Are Kanban Workflows Agile?
评论