project-management - 看板作为实践中的软件开发过程

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。




Improve this question




有没有人用过kanban method用于软件开发管理？

我正在评估看板作为一种技术，并且很想听听任何在实践中实际应用它的人关于它的有效性。我见过这样的问题:is-anyone-using-kanban , kanban-vs-scrum , 和 apply-kanban-in-an-agile-team但他们没有解决我的担忧。

我特别感兴趣的是:

它是否真的提供了动态识别瓶颈方面的优势？

在实践中是否容易执行，或者是否存在您需要管理的后勤挑战？

它是否可以很好地扩展到具有许多并行工作流和许多开发人员的项目团队？

它与关键路径分析(在 MS Project 中实现)相比如何，有何不同？

应用看板还可以获得哪些其他好处？

谢谢。

Answer 1

看板方法首先是持续改进流程的催化剂。这不是一个快速修复或一组固定的步骤/实践。该方法具有一些基本原理和核心属性，如 David J Andersons recent blog post 中所述。 ，这可以引导您持续改进流程。
对于您的问题:

看板方法本身并不能识别瓶颈。当对流程实现在制品限制时，会给您的流程带来压力，您最终将创建一个拉动系统，然后更容易识别流程中的瓶颈。可视化看板和累积流程图等工具将帮助您识别流程中的瓶颈。

如果你应用了基本原则和核心属性，并且你有耐力/耐心/奉献精神，那就不太难了。您需要像每次组织变革一样管理变革过程，但看板方法旨在进行小而无威胁的变革。

是的，有很多记录在案的案例。

看板方法没有确定用于计划和预测 future 交付的特定方法。大卫 J 安德森在 Theory of Constraints 有背景并且在我读过的大部分文章中都使用 TOC 作为模型。我认为使用 MS Project 风格的大预先规划和许多看板实现中使用的基于经验的规划之间的实际区别是很大的区别。在项目开始时处理在 MS Project 中设计的项目计划时，您对实际问题域知之甚少，并且会做出假设。基于这些假设，您制定了一个计划。基于这些假设计算关键路径。有了稳定的看板系统，并且您使用 TOC 作为模型，您计划“仅”在关键路径上设置约束/瓶颈。您会考虑通过约束的工作的历史可变性，并在瓶颈周围创建缓冲区，并具有您想要承担的适当风险。这个想法是，在瓶颈处每损失一个小时，整个系统就会损失一个小时。

看板方法的主要好处是它是持续过程改进的催化剂。它从你得到的东西开始，并做出持续的非威胁性改变。看板是一种方法，即 Made to Stick