什么是看板_您能从看板中得到什么？

什么是看板

我花了大约一年的时间学习了关于看板的更多知识， 以及如何在软件开发和IT运营中 使用它 。

肯定会引起很多关注 ，我想看看它是否可以帮助我们的开发和运营团队更好地工作。

阅读什么，阅读什么？

关于看板，有很多值得一读的内容，但并非所有内容都有用。 您可以放心地忽略任何试图在日本制造和软件开发之间划清界限的事物。 任何这样做的人都不了解精益生产或软件开发。 看板（大K）不是看板（小K） ， 软件开发不是制造业 。

软件开发中的看板始于David Anderson的书 。 出售看板背后的想法很费力，但不幸的是，事实和例子很少-主要是因为在撰写本书时没有太多的经验和数据可借鉴。 一切都是由小型维护组织中的两个案例研究建立的。

第一个案例研究（您可以在此处在线阅读 ）可以追溯到2005年，当时是Microsoft的一个小型海上维护工程团队。 该团队无法满足需求，因为他们遵循的是疯狂的重量级实践框架（CMMI和TSP / PSP）以及所有他们不得不做的文书工作和浪费的计划工作。 他们花了将近一半的时间进行估算和规划，而这项工作的一半将永远无法完成，因为总是有更多工作要做。

Anderson和另一位Microsoft经理从根本上简化了团队的计划，优先级和估算方法，省去了很多废话，使团队可以专注于实际交付对客户重要的内容。

您可以跳过理论- 鼓式缓冲绳的重要性-无论如何，安德森后来改变了对工作背后理论的看法。 正如他所说： “这是一个有关在需要的地方实施常识性更改的案例研究”。

第二个案例研究是关于安德森在几年后与科比斯的另一个特设维护团队做类似的事情的。 方法和课程是相似的，在这种情况下，我们将重点更多地放在工作的视觉跟踪上，而不再使用维护和中断/修复工作的时间限制，而是使用明确的WIP限制作为强制功能来控制团队的工作。

本书的其余部分详细介绍了跟踪任务板上的工作，设置和调整限制以及及时计划的细节。 还有一些影响组织变革和持续改进的讨论，您可以从任何其他敏捷/精益资源中获得。

科里· 拉达斯 （Corey Ladas）的书《 Scrumban》是一本关于看板的短文集，结合了Scrum和看板。 这本书基本上是围绕一篇论文而写的，该论文采用精益方法来节省时间和金钱，我建议您改为在这里阅读 。 除非您想尝试并遵循Ladas详细阐述他的想法，否则您不必费心处理本书的其余部分。 基本思想与安德森（Anderson）相同（这并不奇怪，因为他们在科比斯（Corbis）一起工作过）： 不要构建现在没人需要的功能。 不要编写超出测试范围的代码。 不要测试超出部署范围的代码。

大卫·安德森（David Anderson）即将出版一本有关看板的新书，不幸的是，这看起来像是对他的某些博客帖子的评论进行了重新整理。 我希望有更多的案例研究和数据，以及对现有案例研究的跟踪，以了解它们是否能够随着时间的推移保持成功。

关于看板的其他著作，包括那些正在尝试的激动人心的人（通常是在初创公司或小型团队中），或者是顾问，他们将看板添加到了他们所销售的产品组合中–毕竟，“ 看板是新Scrum ”。

您可以通过“ 看板”每周综述来了解大多数情况，该摘要每周提供链接和讨论论坛以及新闻组的摘要，以及有关看板和精益知识的演示和培训。 还有一个有关看板开发的讨论小组，也值得一看。 但是到目前为止，无论如何，我始终没有找到任何东西能比从阅读Anderson的第一本看板书中学到的东西多得多。

看板在哪里工作最好？

创建看板是为了帮助破坏/修复维护和维持工程团队。 看板基于拉的任务和队列工作管理与这些团队所做的不可预测，中断驱动和专门的工作相匹配。 看板将名称和定义明确的结构围绕常识性想法，大多数成功的维护，支持和运营团队已经遵循这些常识，这应该有助于经验不足的团队获得成功。 使用看板比尝试弯曲Scrum来适应维护和支持，或者遵循像IEE 1219这样的重量级模型或要替换的模型更有意义。

我还可以看到为什么看板在技术初创公司（尤其是遵循持续部署和精益启动模型的 Web / SaaS初创公司）中变得流行的原因。 看板是关于执行和持续优化，消除瓶颈，减少周期时间以及对立即反馈做出React的方法。 这正是初创公司提出出色想法后需要做的。

但是仅仅控制工作是不够的，尤其是从长期来看。 看板的重点主要是战术上的，即紧接在团队面前的工作，即从微观层面识别和解决问题。 在问题表现为拖延之前，没有什么能让人们昂首阔步，看一看他们可以做，应该做些什么来使事情大范围改善。 您仍然需要看板上的产品管理和风险管理层，还需要像XP这样的技术软件开发实践框架。

我也看不出看板如何或为什么在大规模开发项目中发挥很大作用，因为流程和战术优化并不像管理和协调所有不同的动作部分那么重要。 看板不会帮助您在整个企业范围内扩展工作或管理具有许多相互依赖关系的大型程序。 您仍然需要在看板的微观结构之上进行项目和计划以及项目组合管理和风险管理，以管理日常工作，并且您仍然需要SDLC。

您需要看板吗？

看板是解决人们如何完成工作的工具。 安德森（Anderson）明确指出，无论组织规模大小， 看板本身都不足以管理软件开发 –这只是团队更好地完成工作的一种方式： “看板不是软件开发生命周期或项目管理方法论…您将看板系统应用于现有的软件开发过程中……”

看板可以帮助工作量很大的团队，特别是支持和维护团队。 将看板与分类方法相结合来确定优先级将是解决危机的好方法。

但是，我认为将看板用于一支经验丰富，有效工作的开发团队没有任何优势 。

限制正在进行的工作？ 时间限制已经限制了开发团队一次完成的工作 ，使团队有机会集中精力并完成工作。

尽管有些人认为迭代会增加过多的开销并使团队工作变慢，但您可以减少开销，以免时间装箱妨碍您-从而真正在冲刺。

使团队了解工作流程，使延迟和阻碍可见并明确是看板的重要部分。 但是微软的埃里克·布雷希纳（Eric Brechner）（我的意思是“ IM Wright”） 解释说 ，您不需要看板和任务板来查看延迟和瓶颈，也不需要平衡经验丰富的开发团队中的吞吐量： “好的团队可以直观地做到这一点，避免浪费精力。 他们“调整团队的规模”，并共同努力，共同取得成功。”

而且，任何进行迭代和增量工作的人都已经在做或应该在及时进行计划和确定优先级。

因此，对于我们来说，看板似乎不值得，至少目前是这样。 如果您的开发团队经验不足且无法交付（或不知道他们需要交付什么），或者您属于小型维护或消防团队，则值得尝试看板。 如果看板可以帮助运营和维护团队生存下来，并帮助一些在线初创公司更快地启动，如果这就是人们使用看板所做的一切，那么世界将仍然是一个更好的地方。

参考： 您可以从看板中得到什么？ 来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。

翻译自: https://www.javacodegeeks.com/2012/08/what-can-you-get-out-of-kanban.html

什么是看板