是否有人将看板（或 scrumban）用于敏捷管理实践？您对看板的体验如何？它如何在依赖瀑布项目的大型复杂环境中工作？
问问题
2350 次
3 回答
10
我知道 BBC 广泛使用它。有关详细信息，请参阅 David Joyce 的博客 http://leanandkanban.wordpress.com/
他在那里有一个相当大的幻灯片可以筛选。
我认为关于精益思想要记住的一点是，你必须将价值流作为一个整体来考虑。虽然您可以使用看板等技术对开发团队进行超级优化，但更重要的是结合上游（管理/分析）和下游（QA/部署/支持）以充分获得回报。
因此，要问这如何适合瀑布或复杂过程（超出您的个人影响），这不是一个正确的问题。更重要的问题是问我如何才能开始影响整个价值流。我知道这听起来像是宗教精益狂热的开始，但它是你将如何实现精益流程真正价值的方式。
例如，考虑一个典型项目的以下场景：
- 分析时间：18个月
- 开发时间：9个月
- QA&发布时间：4个月
- 客户采用和返工：12 个月
总计：43 个月
如果将精益应用到开发过程中，您将提高 100%，即 4.5 个月的开发时间，带来新的总计 38.5 个月。然后，您仅将总价值流增加了 10% 以上……微不足道！
你需要开始战斗，将精益思想传递给高层管理人员，并展示真正成功的地方......这就是重新设计整个过程。
请记住，精益不是一个开发过程，它可以应用于业务的各个方面。
一些关于如何在开发团队之外进行讨论的有趣书籍包括：
于 2009-07-14T22:28:45.240 回答
6
首先，重要的是要认识到看板在软件开发中试图解决的问题：
- 多任务/超负荷工作。看板通过其即时和队列系统解决了这些问题。队列中有足够的东西让每个人都忙，但不会超载（这伴随着估计和有效速度监控的练习）。JIT 确保人们不必同时执行多项任务，从而降低生产力。
- 不可预测的下游释放。如果您在一个大型软件组织工作，那么您正在开发的部分可能只是一大堆软件中的一个。因此，可能会有下游团队等待您的功能。看板的队列系统及其限时交付计划确保了发布中有一定程度的可预测性。
大多数情况下，其他敏捷实践也试图用不同的技术解决类似的问题。
依赖于瀑布项目的大型复杂环境
如果您依赖于不遵循敏捷的项目，这将变得很困难，因为您的输入队列将无法预测。如果一个非敏捷项目依赖于你，那么问题可能会更小——但你最终可能会产生比消耗更多的东西（精益术语中的“muda”）。因此，理想情况下，您希望所有相关项目至少遵循一些敏捷实践，如果不是看板本身的话。
可以在这里找到一篇关于看板、流程和节奏的好文章。
于 2009-05-29T02:51:07.960 回答
3
是否有人将看板（或 scrumban）用于敏捷管理实践？
是的，我正在使用:-)
它如何在依赖瀑布项目的大型复杂环境中工作？
在我们的环境中，我们有超过 500 名开发人员，所以它非常大。我的团队是第一个使用看板的团队，主要用于维护工作，现在用于开发。我们的日常工作非常辛苦，因为其他依赖的团队都在遵循经典的开发和管理技术，他们喜欢（他们仍然这样做）推动工作，而看板就是拉动。
我们的方法是尽可能多地沟通，使我们的工作透明化，但由于环境不情愿，我们专注于内部工作。WIP 限制帮助我们保持专注，并且通过可视化工作流程，我们知道现在谁在做什么。
我们在看板之前的吞吐量是 90%（换句话说，当 10 件物品进来时，我们只交付了 9 件），而在看板之后我们有 100.4% 并且还在增加。另一个结果是，其他团队开始过来询问看板，因为他们喜欢我们的结果，并想实施他们自己的看板系统。目前我知道大约 5 个团队，它们在我们的组织中启动了看板。
高温下，
佐尔特
于 2011-02-15T06:42:07.633 回答