使用看板的前提条件

Question

什么类型的软件开发(项目)可以使用看板，实现它的要求是什么？我读了很多关于看板的书，以及它有多棒。但现在我必须写一篇关于它的论文，重点是看板的需求，特别是什么类型的看板不适合的项目。我还没弄明白呢。

Answer 1

KarlM给出了一个很好的概述。

我认为看板可以在任何项目中使用，因为它采用您现有的流程并将其可视化，引入WIP (多任务)限制，并使用pull来最大化流程和最小化交付时间。我的团队最近迁移到了Scrum，到目前为止，这是一个非常顺利的过渡。

看板特别适用于标准迭代没有意义的情况。

例如，您可能没有频繁的发布。也许你想解耦一个或多个你的计划，演示，回顾，或发布时间表。

很好的例子：

• 维护项目。即使您可能想要召开两周(或其他)会议来讨论优先级、回顾等，但您可能不会每两周演示一次或发布一次，而且您也不太可能在接下来的两周内承诺所有事情。像这样的情况是如此的动态，随着客户的新反馈，优先级每天都在变化。Scrum或其他迭代过程在这种情况下没有意义。
• ，确实需要比你的迭代长度更长的故事。看板就像Scrum一样，通过小故事(更好的流程，松弛等等)而蓬勃发展，但与Scrum不同的是，如果真的necessary.
• Extremely快节奏的开发，它至少允许大故事。持续部署。迭代不再有意义，因为您可能正在快速响应变化的光照，并且可能一天发布多次！

请参阅code.flickr.com：

Flickr最后一次部署是在4小时前，包括由2个人进行的8次更改。在过去的一周里，有19个人进行了588次更改的85次部署。

你认为Flickr是在做2周的迭代，还是1天的迭代？我怀疑。看起来他们处于超高速动态流动模式..。也许是看板，但看起来肯定像是在精益保护伞里。(看板属于精益思维的范畴，连续部署因Eric Ries去年的书“精益创业”而变得流行起来。)

它可能不适合以下环境：

• Organizational文化无法摆脱前期计划、过度工作/承诺、推而不是拉、固定所有的进度、范围和成本等。看板将开始促进组织中的持续改进，许多人只是反对传统的过度工程、过度记录、孤立、非精益、非敏捷的方法，这就是瀑布。一些政府合同可能也属于这一类，尽管我相信至少DoD现在正试图在其项目中推进敏捷。但是，如果你告诉一些公司，他们需要做的事情更少(即，限制正在进行的工作，有更清晰的愿景，更快地完成更少的事情，但因此更多的事情完成了整体)，他们将会心脏病发作。许多(大多数？)公司沉迷于过度工作，认为松弛(这是一个基本的精益原则)是一个4个字母的单词。不幸的是，排队论和约束理论很难被一些人理解。:)所以看板可能不适合这些地方。;)

Answer 2

要求是，项目中的每个人都同意使用原则和实践：

Principles

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current processes, roles, responsibilities and job titles
4. Encourage acts of leaderships at all levels


Practices
1. Visualise what you do / knowledge discovery
2. Limit work in progress
3. Measure and manage flow
4. Make policies explicit
5. Develop feedback mechanisms
6. Improve collaboratively using models and the scientific method

如果他们不同意这样做，他们就不能使用看板。很清楚。

Answer 3

看板是一个可视化和改进现有流程的工具。如果存在无法工作的场景，则该场景可能具有两个属性中的一个或两个。

1)没有现有的流程，或者现有的流程是一场灾难，以至于它根本无法工作和/或在以混乱的方式不断变化。

2)没有改善的意愿或机会。

缺少第二个并不是破坏交易的因素。看板仍然可以帮助沟通和协调，并且增加清晰度可能会导致改进的愿望增加，或者帮助建立必要的信任，以增强改进实验的能力。这将是低成熟度看板实现导致更高级别的团队成熟度的一个例子。