有人使用看板吗？[关闭]

题

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

解决方案

我知道 BBC 广泛使用它。有关更多详细信息，请参阅大卫·乔伊斯的博客http://leanandkanban.wordpress.com/

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

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

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

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

全部的：43个月

如果将精益应用到开发流程中，您将提高 100%，即开发时间为 4.5 个月，新的总计时间为 38.5 个月。这样您的总价值流仅增加了 10% 多一点......微不足道！！

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

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

关于如何将这种讨论扩展到开发团队之外的一些有趣的书籍包括：

其他提示

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

多任务/超负荷工作。看板通过其及时和队列系统来解决这些问题。队列中有足够的时间使每个人都忙碌，但没有超负荷（这与估计和有效的速度监视有关）。JIT确保人们不必多任务处理，从而使生产力松散。
不可预测的下游释放. 。如果您在大型软件组织中工作，您正在开发的部分可能只是大量并置软件中的一个。因此，可能会有下游团队等待您的功能。看板的队列系统及其按时间限制的交付计划确保了发布具有一定的可预测性。

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

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

如果您依赖于一个不遵循敏捷的项目，这会变得很困难，因为那么您的输入队列将不可预测。如果非敏捷项目依赖于您，问题可能会减少 - 但您最终可能会生产出超过消耗量的产品（精益术语中的“muda”）。因此，理想情况下，您希望所有相关项目至少遵循一些敏捷实践，即使不是看板本身。

可以找到一篇关于看板、流程和节奏的好文章这里.

时使用看板（或scrumban）为敏捷管理实践的人？

是，我使用的： - ）

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

在我们的环境，我们有> 500级的开发者，所以它是相当大的。我的团队是第一个，它使用看板，主要用于维护工作，而现在的发展。我们每天的工作是很辛苦的，因为其他因队是以下经典的开发和管理技术，他们喜欢（他们仍然做）到的按的工作，看板是关于拉

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

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

HTH，

泽索特

许可以下： CC-BY-SA 和归因