我是大卫·安德森（David Anderson）看板方法的忠实拥护者，我总是说我的“敏捷”品牌在大卫介绍看板之前就已经大量注入了精益。 就像肯特·贝克（Kent Beck）所说的极限编程（Extreme Programming）是关于“将拨盘调高至10”一样，戴维（David）将敏捷背后的精益思想提高到了10，在此过程中，很多人（敏捷社区）被视为已被接受。智慧–诸如迭代和估算技术之类的东西。
从我多年来一直坐在看板社区的角度出发，我注意到了两种趋势。 首先，看板被剥离。 我似乎回想起有人说启动看板的方法是“可视化您进行中的工作，然后从那里进行。” 其次，看板放宽了对软件开发的关注。 现在，它自称是一种管理方法，甚至是“变更管理”方法。 最终结果是，即使看板本身已变薄，其适用范围也已扩大。
除去不必要的元素，可以使看板更易于沟通和理解，但同时却很少说明您应该实际做什么。 看板越来越接近其精益根源。 长期以来，我一直认为精益更多地是一种元方法，而不是一种方法，也就是说：精益不会告诉您如何工作（不同于Scrum），但是它告诉您如何思考工作方式。 我有时会说：“ Scrum和XP会告诉您明天早上9.30做什么，而精益告诉您如何思考明天早上9.30做什么。”
我对看板的运行方式没有异议，我仍然喜欢它作为一种方法，并且我认为正在改变它的人们正在做正确的事情。 （我的机会主义者甚至可能会认为，由于看板公司远离软件开发，这在市场上留下了一个空白， Xanpan处于理想位置，可以加以利用，但是这对我非常愤世嫉俗，并冒着我所有的信誉！）
（我应该提一下，虽然我曾受邀参加过几次我从未参加过的看板“领导人峰会”，但由于我自然的格劳乔·马克思主义倾向和家庭承诺的结合，我选择不参加选举。）
但是...这是此博客文章的重点...。 我认为看板的发展方式会产生悖论。
随着看板变得更简短，更小，则实施看板需要更多的专业知识。
您可以设置看板，跟踪流程和进行中的工作。 您可以设置在制品限制。 但是，如果您不知道如何阅读该板，那么您将不知道如何采取行动。 而且，如果您确实知道如何阅读董事会的行为，那么这并不总是工程学上的讨论：董事会的行为通常涉及办公室政治。
例如，我曾经帮助一家公司创建一个看板，该看板具有很多（太多）步骤和（太多）队列。 几个星期后，问题很明显。 但是，董事会没有采取行动解决问题，而是将其作为证据归咎于责任。
看板可以生成许多度量标准：周期时间，提前期，利用率等。但是，如果您不知道这些度量标准意味着什么，那就毫无意义。 即使您知道他们的意思，知道如何对他们采取行动也是另一回事。
例如，看板依靠排队理论，排队理论建议您做的某些事情是违反直觉的，例如减少进行中的工作，从而减少了工人的利用率以提高生产率。
当然，您可以学习排队理论，可以阅读书籍，可以了解指标，可以为自己的董事会做推理，但是这些事情需要时间。 即便如此，我仍怀疑是否有任何书籍，课程或程序能够从经验中获得经验和知识，从之前的经验和多种实现中获得知识和理解。
在全力以赴的情况下，看板团队无需进行迭代和估算。 他们用统计分析代替了估计–我认为这是一种“更好”的方法，但也需要对统计数据有充分的了解。 大多数人会被迫记住一种发行版，而当他们进行标准发行版时，软件工作不太可能遵循标准发行版，因此除非您知道还有其他发行版，否则您将陷入困境。
然后看重价值，看板（像精益一样）旨在提高价值。 但是，您如何定义价值呢？ 什么对您的组织有价值？ 价值是数量吗？ 当您无法以美元计价时，您会怎么做？ 有人需要了解价值以及如何使用它。
然后是软件开发本身。 在软件开发环境中实施看板还有很多问题。 您需要了解质量，了解软件产品（功能或解决方案）等，甚至在获得技术知识之前！
在我看来，这使看板变得困难。 它需要专业知识。 当然，您可以学习这些东西–立即预订看板课程！ –但是需要时间。 近30年前，我在利物浦图书馆的阅览室开始正确地研究软件开发，但我仍然一无所知。
我发现不仅是我对软件开发的研究，对于帮助团队看板至关重要。 花费了数年的时间研究经济学，花费了数年时间阅读管理书籍，是的，在商学院度过的时间花了我们很多职业（并非没有理由）的学历，但这些使我有了经常使用的理解。 当我帮助团队使用看板时，我会利用所有这些资源。
当然，这对我来说是个好消息，它可以为敏捷/看板顾问（抱歉，教练）工作，但也让非专家更难以练习。 而且大多数尝试看板的人都是软件技术方面的专家，而不是流程和流程方面的专家。
所以这又是看板悖论：随着看板变得更简短，更简单，看板需要更多的专业知识。
Scrum和XP的美丽之处在于您无需专业知识即可很好地练习它们。 您可能永远都不是地球上最伟大的团队，但坦率地说，大多数企业并不关心这一点，他们想要比以前更好的东西（任何东西！）。
您不需要在Scrum / XP上擅长就可以受益：坚持两周的迭代周期（大部分时间），每两周一次明确确定工作优先级，召开例行会议，关于它。 如果站起来很短，如果您不根据需求文档进行工作，如果您进行回顾，尤其是如果您进行某些技术实践，那么请确保它很好。 但是，只要做基础就可以做到民主，每个人都可以理解。
Scrum和XP使开发过程可供实践人员访问，他们可以对此进行推理。 看板做得好得多，但是看板做得不好，不了解？ 我怀疑这很危险。
我不确定看板是否相同，我认为了解看板需要更多的理解，因此看板不是民主的，它更多是一种管理方法，更多是专家方法。 这是一个悖论。
那黄盘呢？
我的Xanpan方法会遇到同样的问题吗？
好吧，但我是最不愿意问的人，我有偏见。 Xanpan是“ Allan Kelly的工作方式” –嗯，确实是，其他一些人现在正在尝试。 也许Xanpan会这么做，毕竟在Xanpan都想吃蛋糕和吃的时候，我会详细说明Xanpan的做法，但同时要说“自己做方法”。 我衷心希望我能使咸潘保持民主。
也许Xanpan只是看板的培训版本。 也许Xanpan是一个缩减版看板，也许是一个绝望的看板。 也许当您对Xanpan进行了一些练习之后，您可以对其进行突变，使其更加看板。 无论如何，谁在乎您的称呼。
翻译自: https://www.javacodegeeks.com/2015/04/the-kanban-paradox.html