是否有人使用kanban method进行软件开发管理？
我正在评估看板作为一种技术，并且很想知道任何在实践中实际应用它的人是否有效。我看到过类似的问题：is-anyone-using-kanban，kanban-vs-scrum和apply-kanban-in-an-agile-team，但它们并没有解决我的问题。
我特别感兴趣的是：
感谢。
答案 0 :(得分：3)
看板方法首先是持续改进工艺的催化剂。这不是一个快速修复或一组固定的步骤/实践。该方法具有一些基本原则和核心属性，如David J Andersons recent blog post中所述，可以引导您进行持续的流程改进。 对你的问题：
看板方法本身并不能识别瓶颈。在对流程产生压力的流程中实施工作进度限制时，最终会创建一个拉动系统，然后更容易识别流程中的瓶颈。视觉看板和累积流程图等工具将帮助您识别流程中的瓶颈。
如果您运用基本原则和核心属性，并且您有耐力/耐心/奉献精神，那就不难了。您需要像每次组织变更一样管理变更流程，但看板方法旨在进行小规模且无威胁的变更。
是的，有很多记录在案的案例。
看板方法未确定用于规划和预测未来交付的特定方法。 David J Anderson拥有Theory of Constraints的背景，并在我阅读的大部分文章中使用TOC作为模型。我认为使用MS Project风格大前期规划与许多看板实施中使用的基于经验的规划之间的实际差异是最大的区别。在项目开始时使用在MS Project中设计的项目计划时，您几乎不了解实际的问题域并做出假设。根据这些假设，您可以制定计划。基于这些假设计算关键路径。使用稳定的看板系统并使用TOC作为模型，您只需“计划”以在关键路径上拥有约束/瓶颈。您考虑了通过约束的工作的历史可变性，并且您在瓶颈周围创建了具有您想要承担的适当风险的缓冲区。我们的想法是，在整个系统中，每个小时都会因为瓶颈而损失一小时。
看板方法的主要好处是它是持续改进工艺的催化剂。它从你得到的东西开始，并使非威胁性的变化坚持下去。看板是一种Made to Stick
答案 1 :(得分：2)
在文章Applying Kanban to PC Deployment中，团队必须考虑以下设备：
......我们正在探索使用看板来管理短期功能 项目。此示例重点介绍如何使用看板创建透明 通过一些复杂的跟踪设备流程的过程 步骤，不会产生追踪软件的额外费用， 复杂的过程和培训，或重复劳动。改进 部署过程的一致性或质量也将有助于改进 故障排除和维修时间的效率以及确保 文档与软件和许可的高度一致性 标准。
上面的页面还包含应用看板的链接...
答案 2 :(得分：1)
我也没有很多经验，但我想我可以提供一些见解。 1＆amp; 4：看板与其他技术（如CPM）之间的主要区别在于，在正确的实施中，看板会强制您强制执行在制品限制。这创建了一个拉动系统，因为工人只有在有能力时才接受新项目。这不同于MS项目类型项目，其中任务被预先分配给工作人员（即推送）。
在拉动系统中识别瓶颈要容易得多，因为工作项目将在流程的某个阶段排队。在推送系统中，工作被推送到系统中（无论是否“完成”），因此很难找到瓶颈。
拉动系统的另一个优点是，您可以开始根据实际结果（超前和周期时间）确定工作时间表，而不是预测。是的，故事的大小和粒度确实会影响这一点，但是通过累积流程图等技术，这变得不那么重要了。
2：大多数实现都非常简单，其中有一些技术优势。我想如果你在技术的后勤方面遇到问题，那你就错了。看一下here一个不错的'kickstart示例'。
答案 3 :(得分：1)
在跳入差异之前很少要关注的定义：
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之间的区别
Roles – Scrum依赖于Scrum所有者，并分别由他们处理。看板独立于跨职能团队成员和并行角色。
发布周期– Scrum使用的冲刺持续时间从一周到两周不等。然后，将用户案例用于开发，测试和错误修复。看板不遵循任何周期，并且该过程本质上是连续的。
跟踪参数– Scrum在计划未来的sprint时利用了速度，同时考虑了上一个sprint中完成的用户案例的复杂性和数量。看板确保在“进行中”列中限制用户故事，以避免出现瓶颈。它跟踪从头到尾完成任务所需的时间。
改进范围– Scrum不鼓励更改正在进行的sprint。在项目完成之前，看板可以进行任何更改。本质上是灵活的。
适合的因素– Scrum适用于具有明确定义的用户故事的项目。客户对于及时完成项目的认可使它很合适。看板本质上是灵活的，可以根据当前情况改变优先级。
选择过程– Scrum从产品待办列表中选择整个用户故事进行开发。看板遵循列中允许的最大任务数，以保持框架的完整性并避免瓶颈。
交付– Scrum根据冲刺计划进行交付，并根据客户给出的规格确定优先级。看板根据业务需求遵循连续交付模型。
如果您能够直观地看到它们，上述几点很容易记住。理想情况下，scrum遵循一组相当预定义的原则。看板得到了灵活性原则的支持。它使您可以跟踪对交付至关重要的任务。
答案 4 :(得分：0)
我没有在软件中使用看板的具体经验，但从制造的角度来看我对这种做法很熟悉，所以我对实施感到好奇。阅读你的链接，让我感到困惑的事情就是对工作单元（特征，故事，无论如何）的相同大小的基本假设。虽然保持“故事大小”的目标是一个很好的目标，但是经常会有大型和小型故事混合在一起，因此管道中的少量数据限制似乎是人为的。如果目标是突出瓶颈，我认为站立和冲刺计划和回顾会做得那么好。如果目标是促进优先级排序，我认为按类型对任务数量施加约束不会那样做，只是简单地从上到下排序。
我想我真的不知道它的添加有什么价值;话虽如此，我并没有看到尝试它并采用任何工作的伤害。
答案 5 :(得分：0)
1。在动态识别瓶颈方面，它实际上提供的优势是什么？
这是我的经历。通过设置WIP限制以反映可用容量，如果有工作需要使用该容量但必须等待它可用，那么您将看到它作为工作队列在瓶颈之前备份。我已经看到这种情况发生在有一个过度工作的QA团队与一个上游开发团队继续生产，即使它没有机会被QA看到。我们采取的解决方案是将一些开发人员借给QA团队，然后帮助缓解瓶颈。
2。在实践中是否容易执行，或者它是否存在您需要管理的后勤挑战？
这取决于许多因素，这些因素将特定于您应用它的上下文。看板的一大优势是它不需要立即对您当前的工作进行“全有或全无”改变。大卫安德森的“看板”一书中的“成功秘诀”一章提供了一种很好的方式来接近变化，从“关注质量”开始
3。它是否适用于具有许多并行工作流和许多开发人员的项目团队？
在我第一次使用它的项目中，我们最终得到了一个由17名开发人员组成的团队，我们也将四人的QA团队也加入了我们的团队。我们还有许多外部依赖项，我们使用看板进行建模。
4。它与关键路径分析（在MS Project中实现）相比如何，它有何不同？
从未使用过
5。应用看板可以获得哪些其他好处？
有许多，但我要说的是，它为您提供了对团队以及与利益相关者和团队以外的其他人一起讨论和指导工作的真正有用的指标。具体而言，使用“吞吐量”和“周期时间”可以为您提供工作完成时的概率。