有人在使用看板吗？

Question

是否有人使用看板(或scrumban)来进行敏捷管理实践？您使用看板的经验是什么？它如何在依赖于瀑布项目的大型复杂环境中工作？

Answer 1

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

他有一个相当沉重的幻灯片在那里筛选。

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

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

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

• 分析时间: 18个月
• 开发时间:9个月
• QA和发布时间:4个months
• Customer采用和返工: 12个月

总计: 43个月

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

你需要开始战斗，把精益思想带给上层管理，并证明真正的成功在哪里……这就是整个流程的重新设计。

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

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

• Lean Thinking
• Beyond Budgeting
• Throughput Accounting
• The Toyota Way
• Freedom from Command & Control
• Lean Product & Process Development
• Implementing Lean Software Development: From concept to cash

Answer 2

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

• Multi-tasking /工作的重载。看板通过其即时和队列系统解决了这些问题。队列中有足够的空间让每个人都很忙，但又不会超载(这是通过估计和有效的速度监控来练习的)。而且JIT确保人们不必进行多任务处理，从而不需要在下游发布松散的productivity.
• Unpredictable。如果您在大型软件组织中工作，则您正在开发的部分可能只是大型软件并列中的一部分。因此，可能会有下游团队等待您的功能。看板的队列系统以及它的有时间限制的交付计划确保了在发布中有一定的可预测性。

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

依赖于瀑布项目的

大型复杂环境

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

可以在here上找到一篇关于看板、流量和Cadence的文章。

Answer 3

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

是的，我正在使用:-)

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

在我们的环境中，我们有超过500名开发人员，所以它是相当大的。我的团队是第一个使用看板的团队，主要用于维护工作，现在用于开发。我们的日常工作非常艰难，因为其他依赖团队遵循经典的开发和管理技术，他们喜欢(他们仍然这样做)推动工作，看板是关于拉动。

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

在看板之前，我们的吞吐量是90% (换句话说，当有10个项目进入时，我们只交付了9个)，而在看板之后，我们有100.4%的吞吐量，而且还在增加。作为一个额外的结果，其他团队开始过来询问看板，因为他们喜欢我们的结果，并希望实现他们自己的看板系统。目前我知道大约有5个团队，他们在我们的组织中开始了看板。

HTH，

Zsolt