有没有人使用看板方法进行软件开发管理？
我正在评估看板作为一种技术，并且很想听听任何在实践中实际应用它的人关于它的有效性。我见过这样的问题：is-anyone-using-kanban、kanban-vs-scrum和apply-kanban-in-an-agile-team，但它们并没有解决我的担忧。
我特别感兴趣的是：
谢谢。
看板方法首先是持续改进过程的催化剂。这不是一个快速修复或一组固定的步骤/实践。如David J Anderson 最近的博客文章所述，该方法具有一些基本原则和核心属性，可以引导您持续改进流程。对于您的问题：
看板方法本身并不能识别瓶颈。当对一个对您的流程造成压力的流程实施在制品限制时，您最终将创建一个拉动系统，然后更容易识别流程中的瓶颈。可视看板和累积流程图等工具将帮助您识别流程中的瓶颈。
如果你应用基本原则和核心属性，并且你有耐力/耐心/奉献精神，那就不太难了。您需要像每次组织变更一样管理变更过程，但看板方法旨在进行小而无威胁的变更。
是的，有很多记录在案的案例。
看板方法没有确定计划和预测未来交付的特定方法。David J Anderson 具有约束理论背景并在我读过的大部分著作中使用 TOC 作为模型。我认为使用 MS Project 风格的大型前期计划和许多看板实施中使用的基于经验的计划之间的实际区别是很大的区别。在项目开始时使用 MS Project 中设计的项目计划时，您对实际问题域知之甚少，并且您做出假设。基于这些假设，您制定了一个计划。基于这些假设计算关键路径。有了稳定的看板系统，并且您使用 TOC 作为模型，您计划“仅”将约束/瓶颈放在关键路径上。您会考虑通过约束的工作的历史可变性，并在瓶颈周围创建缓冲区，并承担您想要承担的适当风险。
看板方法的主要好处是它是持续改进过程的催化剂。它从你所得到的开始，并做出不具威胁性的改变。看板是一种坚持不懈的方法
在将看板应用于 PC 部署一文中，团队必须考虑以下设备：
...我们正在探索使用看板来管理短期功能项目。此示例着重于使用看板创建一个透明的流程，通过多个复杂步骤跟踪设备流，而不会产生跟踪软件、复杂流程和培训或重复工作的额外成本。改进的部署过程的统一性或质量也将有助于提高故障排除和修复时间的效率，并确保对软件和许可标准具有可记录的高水平一致性。
上面的页面还链接到应用的看板...
我也没有很多经验，但我想我可以提供一些见解。1 和 4：看板与其他技术（如 CPM）之间的主要区别在于，看板在正确的实施中会强制您对进行中的工作施加限制。这创建了一个拉动系统，因为只有当工人有能力时，新物品才会被工人接受。这不同于预先将任务分配给工人（即推送）的 MS 项目类型项目。
在拉取系统中识别瓶颈要容易得多，因为工作项将在流程的某个阶段排队。在推送系统中，工作是通过系统推送的（无论是否“完成”），因此很难找到瓶颈。
拉动系统的另一个优点是您可以开始根据实际结果（提前期和周期时间）而不是预测来确定工作时间表。是的，故事的大小和粒度确实会影响这一点，但是使用诸如累积流程图之类的技术，这变得不那么重要了。
2：大多数实现都非常简单，其中蕴含着该技术的一些优势。我认为，如果您在技术后勤方面遇到问题，那么您做错了。在这里查看一个不错的“kickstart 示例”。
在了解差异之前需要关注的定义很少：
Agile – A structured and iterative framework to track and manage projects. This approach is used in managing software development projects. It allows cross-functional teams to collaborate on users expectations.
Kanban – A framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column. The segregation of a similar type of tasks can be done here. To simplify it, allocate colors to tasks using the swim lanes.
Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the [scrum][1].
看板和 Scrum 的相似之处
看板和 Scrum 的区别
角色——Scrum 依赖于 Scrum 所有者，并由他们分别处理。看板独立于跨职能团队成员和平行角色。
发布周期——Scrum 使用持续时间从一周到两周不等的冲刺。然后将用户故事用于开发、测试和错误修复。看板不遵循任何循环，并且该过程本质上是连续的。
跟踪参数——Scrum 在规划即将到来的 sprint 时利用速度，同时考虑到前一个 sprint 中完成的用户故事的复杂性和数量。看板确保限制“正在进行的工作”列中的用户故事以避免瓶颈。它跟踪从开始到结束完成任务所花费的时间。
改进的范围——Scrum 不鼓励对正在进行的 sprint 进行更改。看板对项目完成前的任何更改持开放态度。它本质上是灵活的。
适合因素——Scrum 适用于具有明确定义的用户故事的项目。客户对及时完成项目的认可使其成为合适的选择。看板本质上是灵活的，允许根据当前情景改变优先级。
挑选流程——Scrum 从产品待办列表中挑选整批用户故事进行开发。看板遵循列中允许的最大任务数，以保持框架的健全性并避免瓶颈。
交付——Scrum 遵循基于 sprint 计划的交付，并根据客户给出的规范确定优先级。看板遵循基于业务需求的持续交付模型。
如果您能够可视化处理以上几点，则很容易记住。理想情况下，Scrum 遵循一组相当预定义的原则。看板以灵活性原则为后盾。它允许您跟踪对交付至关重要的任务。
我没有在软件中使用看板的具体经验，但我从制造的角度熟悉这种做法，所以我对实施感到好奇。阅读您的链接，让我印象深刻的可能是一个潜在的假设，即工作单元（功能、故事等）的大小相同。虽然保持“故事大小”是一个很好的目标，但通常会有大小故事混合在一起，因此他们管道中的少量限制似乎是人为的。如果目标是突出瓶颈，我认为站起来、冲刺计划和回顾会做得足够好。如果目标是促进优先级排序，我认为按类型限制任务数量不会
我想我并没有真正看到它增加了什么价值。话虽如此，我认为尝试并采用任何可行的方法都没有害处。
1. 它是否真的提供了动态识别瓶颈方面的优势？
这是我的经验。通过设置您的 WIP 限制以反映可用容量，如果有工作需要利用该容量但必须等待它变得可用，那么您将看到它，因为工作队列在瓶颈之前备份。我已经看到这种情况发生在一个过度工作的 QA 团队和一个上游开发团队继续生产，即使它没有机会被 QA 看到。我们对此采取的解决方案是将一些开发人员借给 QA 团队，然后他们帮助缓解瓶颈。
2. 在实践中执行起来是否容易，或者是否存在需要管理的后勤挑战？
这将取决于许多因素，这些因素将特定于您应用它的上下文。看板的一大优势是它不需要立即对您当前的工作方式进行“全有或全无”改变。大卫安德森的“看板”一书中的“成功秘诀”一章提供了一种应对变革的好方法，从“关注质量”开始
3. 它是否适用于具有许多并行工作流和许多开发人员的项目团队？
在我第一次使用它的项目中，我们最终组建了一个由 17 名开发人员组成的团队，我们也将 4 人的 QA 团队也转移到了我们的团队中。我们还有很多外部依赖项，我们使用看板进行建模。
4. 它与关键路径分析（在 MS Project 中实现）相比，有何不同？
像没用过一样通过
5. 应用看板还能获得哪些其他好处？
有很多，但我要指出的是，它为您提供了真正有用的指标，这些指标对于与团队、利益相关者和团队外的其他人讨论和指导工作都是真正有用的。特别是“吞吐量”和“周期时间”的使用有助于为您提供工作完成时间的概率。