有人用看板吗？ [关闭]答案

【问题标题】：Is anyone using Kanban? [closed]有人用看板吗？ [关闭]
【发布时间】：2010-10-29 18:37:05
【问题描述】：

是否有人将看板（或 scrumban）用于敏捷管理实践？您对看板的体验如何？它如何在依赖瀑布项目的大型复杂环境中工作？

【问题讨论】：

【解决方案1】：

我知道 BBC 广泛使用它。有关详细信息，请参阅 David Joyce 的博客 http://leanandkanban.wordpress.com/

他有一个相当大的幻灯片可供筛选。

我认为关于精益思想要记住的一点是，您必须将价值流视为一个整体。虽然您可以使用看板等技术对开发团队进行超级优化，但更重要的是整合上游（管理/分析）和下游（QA/部署/支持）以充分获得回报。

因此，要问这如何适应瀑布或复杂过程（超出您的个人影响），并不是一个完全正确的问题。更重要的问题是问我如何才能开始影响整个价值流。我知道这听起来像是宗教精益狂热的开始，但它是您实现精益流程真正价值的方式。

例如，考虑一个典型项目的以下场景：

总计：43 个月

如果在开发过程中应用精益，您可以提高 100%，即 4.5 个月的开发时间，带来新的 38.5 个月。然后，您仅将总价值流增加了 10% 以上……微不足道！

您需要开始战斗，将精益思想传递给高层管理人员，并展示真正成功的地方......这就是重新设计整个流程。

请记住，精益不是一个开发过程，它可以应用于业务的各个方面。

关于如何在开发团队之外进行讨论的一些有趣的书籍包括：

【讨论】：

【解决方案2】：

首先，重要的是要认识到看板在软件开发中试图解决的问题：

多任务/超负荷工作。看板通过其解决这些问题即时和队列系统。那里在队列中足以保持每个人都很忙，但没有超载（这伴随着练习估计和有效速度监控）。 JIT 确保人们不必同时处理多项任务和因此生产力下降。
不可预测的下游发布。如果您在大型软件组织工作，您正在开发的部分可能只是大量软件中的一个。因此，可能会有下游团队可能会等待您的功能。看板的队列系统及其限时交付计划确保了发布具有一定程度的可预测性。

大多数情况下，其他敏捷实践也尝试用不同的技术解决类似的问题。

依赖瀑布项目的大型复杂环境

如果您对不遵循敏捷的项目有依赖性，这会变得很困难，因为您的输入队列将无法预测。如果一个非敏捷项目依赖于你，那么问题可能会更小——但你最终可能会产生比消耗更多的东西（精益术语中的“muda”）。因此，理想情况下，您希望所有相关项目至少遵循一些敏捷实践，如果不是看板本身。

可以在here找到一篇关于看板、流程和节奏的好文章。

【讨论】：

【解决方案3】：

是否有人将看板（或 scrumban）用于敏捷管理实践？

是的，我正在使用:-)

它如何在依赖瀑布项目的大型复杂环境中工作？

在我们的环境中，我们有超过 500 名开发人员，因此规模很大。我的团队是第一个使用看板的团队，主要用于维护工作，现在用于开发。我们的日常工作非常辛苦，因为其他依赖的团队都在遵循经典的开发和管理技术，他们喜欢（他们仍然这样做）push 工作，而看板是关于 pull.

我们的方法是尽可能多地沟通，使我们的工作透明化，但由于环境不情愿，我们专注于内部工作。 WIP 限制帮助我们保持专注，并且通过可视化的工作流程，我们知道现在谁在做什么。

我们在看板之前的吞吐量是 90%（换句话说，当 10 件物品进来时，我们只交付了 9 件），而在看板之后我们有 100.4% 并且还在增加。另一个结果是，其他团队开始过来询问看板，因为他们喜欢我们的结果，并想实施他们自己的看板系统。目前我知道大约 5 个团队，它们在我们的组织中启动了看板。

HTH，

Zsolt

【讨论】：