As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center提供指导。
7年前关闭。
看板可以用于哪种软件开发(项目)，以及实现它的要求是什么？我读了很多有关看板的文章，它有多棒。但是现在我必须写一篇关于它的论文，重点关注看板的需求，尤其是看板不适合什么样的项目。我还不知道。 维护项目。即使您可能希望召开2周(或任何其他时间)的会议来讨论优先级，回顾等问题，您也可能不会每2周进行演示或发布，而且您不太可能会致力于无论如何，接下来2周内的一切。诸如此类的情况是如此动态，以至于每天都有优先事项在变化，因为新的反馈来自客户。在这种情况下，Scrum或其他迭代过程没有意义。 确实需要比您的迭代长度更长的故事。看板与Scrum一样，在小故事(更好的流程，轻松的游戏等等)中蓬勃发展，但是，与Scrum不同，看板在确实有必要的情况下至少允许大故事。 极快的开发速度。持续部署。迭代不再有意义，因为也许您正在响应快速变化的照明，并且可能一天释放多次!
参见code.flickr.com:
Flickr的最新部署是4个小时前，其中包括2人进行的8次更改。
在上周，有19位人员进行了588次变更的85次部署。
您是否认为Flickr在进行2周或什至1天的迭代？我对此表示怀疑。看起来好像他们处于超高速动态流模式下……也许看板了，但绝对看起来像是处于“精益”伞下。 (看板属于精益思想的范畴，并且在Eric Ries的去年著作“精益创业”中，持续部署变得很流行。)
它可能不适用于以下环境:
组织文化无法摆脱预先的计划，过度的工作/ promise ，推动而不是拉动，固定所有进度，范围和成本等。看板将开始在组织中引起持续的改进，其中许多仅仅是除了传统的过度工程，过度记录，孤立，非精益，非敏捷的方法(他们知道和喜欢)以外，其他方法都是瀑布。一些政府合同也可能属于此类，尽管我相信至少国防部正在尝试在其项目中推进敏捷。但是，有些公司如果告诉他们他们需要少做一些事情(即限制正在进行的工作，拥有更清晰的视野，减少完成工作的速度，但总体上要完成更多的工作)，则会心脏病发作。许多(大多数？)公司沉迷于过度劳累，并认为SLACK(这是精益生产的基本原则)是一个四个字母的词。不幸的是，排队理论和约束理论很难让人理解。 :)所以看板可能不适合这些地方。 ;)
7年前关闭。
看板可以用于哪种软件开发(项目)，以及实现它的要求是什么？我读了很多有关看板的文章，它有多棒。但是现在我必须写一篇关于它的论文，重点关注看板的需求，尤其是看板不适合什么样的项目。我还不知道。
最佳答案
KarlM给出了很好的概述。
我认为看板可以在任何项目中使用，因为它需要您现有的过程并对其进行可视化，引入WIP(多任务)限制，并使用拉动来最大化流程和最小化交付时间。我的团队最近迁移到Scrum，到目前为止，过渡非常顺利。
看板特别适用于标准迭代没有意义的情况。
例如，您可能没有频繁发布。也许您想取消一个或多个计划，演示，回顾或发布计划。
很好的例子:
参见code.flickr.com:
Flickr的最新部署是4个小时前，其中包括2人进行的8次更改。
在上周，有19位人员进行了588次变更的85次部署。
您是否认为Flickr在进行2周或什至1天的迭代？我对此表示怀疑。看起来好像他们处于超高速动态流模式下……也许看板了，但绝对看起来像是处于“精益”伞下。 (看板属于精益思想的范畴，并且在Eric Ries的去年著作“精益创业”中，持续部署变得很流行。)
它可能不适用于以下环境:
07-26 00:51