为什么你需要专门的看板软件

本文由David J. Anderson发表于LeanKanbanUniversity。
这个月我已经在微软Team Foundation Server产品团队工作了10个年头。第一周，我收到了这个跟踪软件的规范，我需要对其进行评审。第四天，我找到了我的上司，并告诉他“这个产品的设计不符合真实软件团队工作的方式。真实的团队不会采用仅用了一天拼凑出来的规定的、预定义的流程，相反，他们会增量地使用实践，并且他们的流程是不断演进的。”问题在于TFS进行项目跟踪需要载入某种过程定义和一系列工作项类型定义的这种机制。这些在项目开始之前就必须确定下来。一旦载入了定义，项目就只能使用这些固定不变的工作项定义，这些工作项定义在项目进行中不能被改变。诸如此类的机制成为了流程改进的障碍。这个问题不只存在于Team Foundation Server，在许多流行的工作跟踪产品中普遍具有这个问题。

工作跟踪软件的工作方式中，使用了如此静态的工作类型和状态转换定义，原因如下：
首先，设计这些产品功能的产品经理使用产品的方式，与开发人员、分析人员、架构人员和测试人员使用的方式不相同，并且他们没有管理过不断变更流程的软件开发团队。
其次，构建一种灵活的工具，使工作类型和状态变化在过程中变化非常困难。虽然可视化变化很微不足道，但是如何处理已有数据？如何处理在制的工作项？这些工作项需要从最初所设想的一系列状态转换为一系列新的状态。并且当状态转化模型发生变化时，在图表中，如何控制数据报表的显示？

LeanKit和Swift Kanban这类看板工具的设计和架构便是从解决这个问题的背景出发的。这些看板工具旨在促进演进式过程改进并且做得相当优美。

当客户向我的公司进行咨询或者参加我们的LeanKanban认证培训班时，他们毫无疑问会说他们希望使用看板方法来管理他们的创造性知识工作服务，例如软件开发。在这种情况下，他们会说他们一定会用演进的方式来进行改进，但是通常他们正在使用某种工作跟踪产品，而这些产品不支持演进式改变，而且由于成本或政策原因他们疲于切换到新的产品中。如果无法采用这种为”消除变革障碍“而设计的看板工具，这将会影响到你的预期——现有的软件将产生惰性并成为看板方法成功运用的障碍。

甚至更糟！一般的跟踪软件不会产生用看板方法进行管理所需的数据。流行的产品JIRA甚至在默认情况下不会产生时间段数据。你可以通过导出数据到Excel和MiniTab来产生前置时间直方图（分布柱状图）或者累积流图。你还可以写代码调用API的方式获得。TFS至少还能够原生的获得这些。

对一些客户来说，他们快速地使用了一种双模式方法，既使用物理看板墙也使用现有的跟踪软件。物理墙会很快演变并且这个流程很快就会与工具中定义的流程产生不一致了。这带来了更多问题：什么时候更新工具并且什么时候至在物理墙上移动一个工作项？与此同时，数据的收集只能靠人工进行了。

如果你真要更好地管理创造知识工作者的企业，如果你真的要进行演进式改进来获得更好的健康度和更好的顾客满意度，你就必须在一款合适的看板软件产品上进行投资。你必须为工具切换进行投资。不要为你正在使用的工具的提供商所供应的所谓”看板“所分心。TFS的看板模板对于没有流程并且希望试用一个看板系统的团队来说是个不错的开始，但TFS底层架构还没有改变。TFS的Kanban过程模板不能够促进演进式改进。JiraAgile也不是。太多的工具厂商认为看板方法只是提供了更好的可视化。他们的产品架构不支持演进式改进。我们的社区中活跃5-7年的这些人所做的才是真正的看板软件产品，因为这些软件真的为了使用看板方法而设计。

所以问问你自己，我们是否真的要改进，是否真要获得持续保健与优秀的顾客服务？如果是，帮你自己一个忙，用一用真的能够让你成功的工具。如果你还没有准备好使用这样一款工具，再问一问你自己，我们真的想要改进和更好的顾客服务吗？或者所有这些活动只是个借口伪装？