有人使用看板吗？

Question

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

Answer 1

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

他在那里有一个非常大的幻灯片筛选。

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

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

例如，请考虑典型项目的以下方案：

• 分析时间：18个月
• 开发时间：9个月
• QA＆amp;发布时间：4个月
• 客户采用和返工：12个月

总计：43个月

如果通过将Lean应用于开发过程，您可以提高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

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

• 多任务/工作超载。 看板通过它来解决这些问题 准时制和队列系统。那里 在队列中保留足够的数量 每个人都很忙，但没有超载 （这附带练习 估计和有效的速度 监测）。而JIT确保了这一点 人们没有多任务和 因此生产力下降。
• 不可预知的下游版本。如果您在一个大型软件组织中工作，那么您正在开发的这个部分可能只是一个大型并置软件中的一个。因此，可能会有下游团队等待您的功能。看板的队列系统及其时间框交付时间表确保了版本中有一定的可预测性。

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

  

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

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

有关Kanban，Flow和Cadence的精彩文章可以找到here。

Answer 3

  

是否有人使用看板（或scrumban）进行敏捷管理实践？

是的，我正在使用： - ）

  

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

在我们的环境中，我们有> 500名开发人员，所以它非常大。我的团队是第一个使用看板的团队，主要用于维护工作，现在用于开发。我们的日常工作非常努力，因为其他依赖团队遵循经典的开发和管理技术，他们喜欢（他们仍然这样做）推送工作，而看板是关于 pull

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

我们在看板之前的吞吐量是90％（换句话说，当10个项目进入时，我们只交付了9个），而在看板之后我们有100.4％并且它正在增加。作为一个额外的结果，其他团队开始过来询问看板，因为他们喜欢我们的结果，并希望实施他们自己的看板系统。目前，我了解了5个团队，这些团队在我们的组织中开始了看板。

HTH，

泽索特