logo标签列表

使用看板的前提条件

kanban
4
什么样的软件开发（项目）可以使用看板法，并且实施它的要求是什么？我已经阅读了很多关于看板法的资料，知道它有多好。但现在我需要写一篇论文，重点关注看板法的要求，特别是看板法不适用于哪种类型的项目。我还没有搞清楚。
注：kanban即为看板法。
5个回答
4

KarlM提供了很好的概述。

我认为看板可以用于任何项目，因为它采用现有流程并将其可视化，引入WIP（多任务）限制，并使用拉动以最大化流程并最小化交货时间。 我的团队最近迁移到Scrum，到目前为止过渡非常顺利。

看板在不适用标准迭代的情况下尤其有效。

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

好的例子：

  • 维护项目。 即使您可能希望每2周（或其他时间）进行会议以讨论优先事项，回顾等，但您可能不会每2周演示或发布，并且您不太可能能够承诺在接下来的2周内完成所有工作。 这种情况非常动态，因为客户会提供新的反馈意见，所以优先级每天都会变化。 Scrum或其他迭代过程在这种情况下没有意义。
  • 需要较长故事的情况。 看板和Scrum一样适合小故事（更好的流程，松弛等），但与Scrum不同，如果确实有必要，看板至少允许大故事。
  • 开发速度极快。 连续部署。 迭代不再有意义，因为您可能会快速响应变化，并且可能每天发布多次！

请参见code.flickr.com：

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

您认为Flickr正在进行2周迭代，甚至1天迭代吗？ 我怀疑。 看起来他们处于超高速动态流程模式... 可能是看板，但肯定看起来他们在精益伞下。 （看板属于精益思想的伞下，而连续部署则是由Eric Ries去年的书“精益创业”所流行的）。

它可能不适用于以下环境：

  • 组织文化无法摆脱前期规划、过度工作/承诺、主动推动而非被动拉动、修复全部计划、范围和成本等。看板将激发组织中的持续改进，但很多人只接受传统的过度设计、过度文档记录、孤立、非精益、非敏捷方法（即瀑布模型）。一些政府合同也可能属于此类，尽管我相信至少国防部正在试图在其项目中推广敏捷方法。但是有些公司，如果你告诉他们需要做更少的事情（即限制进行中的工作、更清晰地定义愿景，更快地完成更少的任务，但因此可以更全面地完成更多任务），他们会大吃一惊。许多（大多数？）公司对过度工作上瘾，并认为“空闲”（这是一项基本的精益原则）是一个禁忌词。不幸的是，排队理论和约束理论难以为一些人所理解。 :) 所以看板可能不适用于那些地方。
3

要求每个项目参与者都同意遵循以下原则和实践：

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

如果他们不同意这样做，就不能使用看板了。非常清晰明了。
1
Kanban是一种工具，用于可视化和改进现有流程。如果存在以下情况，则可能无法使用该工具：1）不存在现有流程或现有流程非常混乱且根本不起作用，并且/或者在不断混乱地变化；2）没有意愿或机会进行改进。缺少第二个条件并不是致命的。Kanban仍然可以帮助沟通和协调，并且提高清晰度可能会导致增加改进的愿望或建立必要的信任来赋予改进实验权力。这将是低成熟度Kanban实施导致团队成熟度提高的一个例子。
0
在我看来，看板可以在任何类型的组织和任何行业中实施。
但是...
1. 团队必须准备好进行改变。 2. 改变必须具有进化性质。 3. 组织必须专注于合作而不是执行例行工作。
0
看板是一个简单的工具。如果应用得当，它对于任何项目都很有好处，不仅仅是软件 - 任何项目都适用。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接