有人使用看板吗？
有人使用看板（或 scrumban）进行敏捷管理实践吗？ 您对看板的体验如何？ 它如何在依赖于瀑布项目的大型复杂环境中工作？
Is anyone using Kanban (or scrumban) for the agile management practices? What is your experience with Kanban? How does it work in large complex environments with dependencies on waterfall projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我知道 BBC 广泛使用它。 有关更多详细信息，请参阅大卫·乔伊斯的博客
http://leanandkanban.wordpress.com/
他在那里有一个相当大的幻灯片可供筛选。
我认为关于精益思想要记住的一点是，你必须将价值流作为一个整体来考虑。 虽然您可以使用看板等技术来超级优化开发团队，但更重要的是整合上游（管理/分析）和下游（质量保证/部署/支持）以充分获得回报。
因此，询问这如何适应瀑布或复杂的过程（超出您的个人影响）并不是一个正确的问题。 更重要的问题是如何开始影响整个价值流。 我知道这听起来像是宗教精益狂热的开始，但它是您实现精益流程的真正价值的方式。
例如，考虑一个典型项目的以下场景：
总计：43 个月
如果通过将精益应用到开发流程中，您将改进 100%，即开发时间为 4.5 个月，新的总计时间为 38.5 个月。 这样您的总价值流仅增加了 10% 多一点...微不足道！！
您需要开始战斗，并将精益思想带给高层管理人员，并展示真正的成功所在……这在于整个流程的重新设计。
请记住，精益不是一个开发过程，它可以应用于业务的各个方面。
关于如何将这种讨论扩展到开发团队之外的一些有趣的书籍包括：
I know the BBC use it quite extensively. See David Joyce's blog for more details
http://leanandkanban.wordpress.com/
He has a quite hefty slide deck in there to sift through.
I think the thing to remember about Lean thinking is that you must consider the value stream as a whole. Whilst you can super optimise the development team using techniques such as Kanban, it is more important to incorporate both up stream (Management/Analysis) and downstream (QA/deployment/support) to fully reap the rewards.
Therefore, to ask how does this fit into a Waterfall or complex process (beyond your personal effect), is not quite the right question. What is a more important question is to ask how can I begin to effect the entire value stream. I know this sounds like the beginning of religious Lean zealotry, but it is how you will realise the true value of a lean process.
For example, consider the following scenario for a typical project:
Total: 43 months
If by applying Lean to the development process you improve by 100%, ie a development time of 4.5 months, bringing a new total of 38.5 months. You have then only increased the total value stream by just over 10%... insignificant!!
You need to begin to fight the fight and take the Lean thinking to upper management and demonstrate where real success lies... which is in the re-design of the entire process.
Remember Lean is NOT a development process, it can be applied to every aspect of the business.
Some interesting books on how to take this discussion beyond the the development team include;
首先，重要的是要认识到软件开发中看板试图解决的问题：
看板通过其
准时制和排队系统。 那里
队列中足以保留
每个人都很忙，但并不超负荷
（这需要练习
估计和有效速度
监控）。 JIT 确保了
人们不必同时处理多项任务
因此生产力下降。
大多数情况下，其他敏捷实践也尝试使用不同的技术解决类似的问题。
如果您依赖于一个不遵循敏捷的项目，那么这会变得很困难，因为那么您的输入队列将不可预测。 如果非敏捷项目依赖于您，问题可能会减少 - 但您最终可能会生产出超过消耗的产品（精益术语中的“muda”）。 因此，理想情况下，您希望所有相关项目至少遵循一些敏捷实践，即使不是看板本身。
此处可以找到一篇关于看板、流程和节奏的好文章。
Firstly, it is important to realize the problems that Kanban in software development tries to solve:
Kanban addresses these by its
Just-in-time and Queue systems. There
is sufficient in the queue to keep
everyone busy, but not overloaded
(this comes with practice with
estimation and efficient velocity
monitoring). And JIT ensures that
people do not have to multi-task and
hence loose productivity.
Mostly, other agile practices also attempt to solve similar problems with different techniques.
This makes it hard if you have a dependency on a project that does not follow agile as then your input queue will not be predictable. If a non-agile project depends on you, the problem might be lesser - but you might end up producing more than can be consumed ('muda' in lean terminology). So, ideally you would want all dependant projects at least following some agile practices, if not kanban itself.
A nice article on Kanban, Flow and Cadence can be found here.
是的，我正在使用:-)
在我们的环境中，我们有超过 500 名开发人员，因此规模相当大。 我的团队是第一个，使用看板，主要用于维护工作，现在用于开发。 我们的日常工作非常辛苦，因为其他依赖团队都遵循经典的开发和管理技术，他们喜欢（他们仍然这样做）推动工作，而看板则拉动 >。
我们的做法是尽可能多地沟通，使我们的工作透明，但由于环境的不情愿，我们只专注于我们的内部工作。 WIP 限制帮助我们保持专注，通过可视化工作流程，我们知道谁目前在做什么。
看板之前我们的吞吐量是 90%（换句话说，当 10 个项目进来时，我们只交付了 9 个），看板之后我们的吞吐量是 100.4%，并且还在增加。 另外一个结果是，其他团队开始过来询问看板，因为他们喜欢我们的结果，并且想要实施他们自己的看板系统。 目前我知道有 5 个团队在我们的组织中启动了看板。
HTH，
兹索尔特
Yes, I'm using :-)
In our environment we have >500 developers, so it is quite large. My team was the first, which used Kanban, mainly for maintenance work, and now for development. Our daily work was very hard, because the other depending teams were following classic development and management techniques, and they liked (they still do) to push the work and Kanban is about pull.
Our approach was to communicate as much as possible make our work transparent, but due to the reluctance of the environment we were focusing on our internal work. The WIP limit helped us stay focused, and with the visualize workflow we knew who is doing what at the moment.
Our throughput before Kanban was 90% (in other words, when 10 items came in, we delivered only 9), and after Kanban we had 100.4% and it was increasing. As an additional result, other teams started to came by and ask about Kanban, because they liked our results, and wanted to implement their own Kanban system. At the moment I know about 5 teams, which started Kanban in our organization.
HTH,
Zsolt