有人使用看板吗？

Question

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

Answer 1

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

他在那里有一个非常大的滑动甲板来筛选.

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

因此,要问这是如何适应瀑布或复杂的过程(超出你的个人影响),这不是一个正确的问题.更重要的问题是问我如何开始影响整个价值流.我知道这听起来像宗教精益狂热的开始,但它是你将如何实现精益过程的真正价值.

例如,请考虑典型项目的以下方案:

总计:43个月

如果通过将Lean应用于开发过程,您可以提高100%,即开发时间为4.5个月,新的总计为38.5个月.那么你只将总价值流增加了10%以上......微不足道!!

你需要开始对抗这场斗争并将精益思想带到高层管理人员身上,并展示真正的成功所在......这是整个过程的重新设计.

记住精益不是一个开发过程,它可以应用于业务的每个方面.

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

Answer 2

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

多任务/超载工作.看板通过Just-in-time和Queue系统解决这些问题.队列中有足够的空间来保持每个人的忙碌,但不会超载(这伴随着估算和有效速度监控的实践).JIT确保人们不必多任务,从而降低生产力.
不可预测的下游版本.如果您在一个大型软件组织中工作,那么您正在开发的这个部分可能只是一个大型并置软件中的一个.因此,可能会有下游团队等待您的功能.看板的队列系统及其时间框交付时间表确保了版本中有一定的可预测性.

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

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

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

关于看板,流程和Cadence的一篇很好的文章可以在这里找到.