1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
This has been my experience. By setting your WIP limits to reflect available capacity, if there is work that needs to make use of that capacity but has to wait for it to become available then you will see it as the queue of work backs up ahead of the bottleneck. I have seen this happen when there is an overworked QA team with an upstream development team who keep producing even though there is no chance of it getting looked at by QA. The solution we took to this was to lend some of the developers to the QA team who then helped alleviate the bottleneck.
2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
This will depend on many factors which will be specific to the context to which you are applying it. One of the great strengths of Kanban is it does not require an immediate 'all or nothing' change from how you are currently working. The chapter 'A Recipe for Success' in David Anderson's 'Kanban' book gives a great way of approaching the change, starting with 'Focus on Quality'
3. Does it scale well to project teams with many parallel streams of work and many developers?
In the project where I first used it we ended up with a team of seventeen developers and we had moved the QA team of four into our team too. We also had lots of external dependencies which we used Kanban to model.
4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?
Pass as have never used
5. What other benefits can be gained from applying kanban?
There are many but the one I will call out is that it gives you metrics that are genuinely useful for discussing and steering the work, both with the team and with stakeholders and other people outside the team. Specifically the use of 'Throughput' and 'Cycle Time' help give you a probabilistic for cast of when work will get done.
看板方法没有确定规划和预测未来交付的具体方法。 David J Anderson 具有约束理论的背景，并在大多数理论中使用 TOC 作为模型。我读过的文字。我认为使用 MS Project 风格的大型预先计划与许多看板实施中使用的基于经验的计划之间的实际差异是巨大的差异。在项目开始时使用在 MS Project 中设计的项目计划时，您对实际问题领域知之甚少，并且会做出假设。基于这些假设，你制定了一个计划。关键路径是根据这些假设计算的。有了稳定的看板系统并使用 TOC 作为模型，您“仅”计划在关键路径上设置约束/瓶颈。您会考虑通过约束的工作的历史可变性，并在瓶颈周围创建缓冲区以及您想要承担的适当风险。我们的想法是，在瓶颈处每损失一个小时，整个系统就会损失一个小时。
The Kanban method is foremost a catalyst for continuous process improvements. It’s not a quick fix or a fixed set of steps/practices. The method has a few foundational principles and core properties, as described in David J Andersons recent blog post, that can lead you the way to continuous process improvements. To your questions:
The Kanban method in itself does not identify bottlenecks. When implementing work-in-progress limits to a process that creates stress on your process you will eventually create a pull system and then it becomes easier to identify bottlenecks in your process. Tools like a visual kanban board and Cumulative Flow Diagrams will help you identify the bottlenecks in the process.
If you apply the foundational principles and core properties and you have the stamina/patience/dedication it is not too hard. You need to manage the change process as with every organizational change but the Kanban Method is designed to make small and non-threatening changes.
Yes there are many documented cases of this.
The Kanban method does not identify a specific method for planning and projecting future deliveries. David J Anderson has a background in Theory of Constraints and uses TOC as a model in most of the writing I have read. I think the practical difference between using MS Project style big up front planning and the empirical based planning used in many kanban implementations is the big difference. When working with a project plan designed in MS Project in the beginning of a project you know very little of the actual problem domain and you make assumptions. Based on these assumptions you device a plan. A critical path is calculated based on these assumptions. With a stable kanban system and you use TOC as your model you plan “only” to have your constraint/bottleneck on the critical path. You take into account the historical variability of the work passing the constraint and you create buffers around you bottleneck with the appropriate risk you want to take. The thinking is that every hour lost at the bottleneck will be an hour lost for the whole system.
The main benefit of the Kanban Method is that it is a catalyst for continuous process improvements. It starts with what you got and makes non-threatening changes that sticks. Kanban is a method that is Made to Stick
120 PCs and 10 laptops to be refreshed and redeployed
... we are exploring the use of Kanban to manage a short-term functional project. This example focuses on using Kanban to create a transparent process to track the flow of equipment through a number of complex steps, without incurring additional costs for tracking software, complex processes and training, or duplication of effort. Improved uniformity or quality of the deployment process will also help improve efficiencies in troubleshooting and repair times as well as ensure a document-ably high level of conformance to software and licensing standards.
The page above has also links to Kanban applied ...
I also don't have a lot of experience with it, but I think I can offer some insight. 1 & 4: the main difference between Kanban boards and other techniques, like CPM, is that a Kanban board, in a correct implementation, forces you to impose work-in-progress limits. This creates a pull system, since new items are accepted by workers only when they have capacity. This differs from an MS project type project where tasks are assigned to workers before-hand (i.e. pushed).
It is much easier to identify a bottleneck in a pull system, because work items will be queuing up at some stage in the process. In a push system, work is pushed through the system (whether it is 'done done' or not), so its difficult to find bottlenecks.
Another advantage of a pull system is you can start to base work timelines on actual results (lead and cycle time), as opposed to prediction. Yes, the size and granularity of stories does affect this, but with techniques such as cumulative flow diagrams this becomes less important.
2: Most implementations are pretty simple, and therein lies some of the strength of the technique. I think if you're having problems with the logistics of the technique, you're doing it wrong. Have a look here for a nice 'kickstart example'.
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].
Few definitions to focus on before jumping onto the differences:
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].
Similarities between Kanban and Scrum
Frameworks of agile methodologies
Used to track the progress of the project
Provide the team transparency in tracking the work progress
Make use of visualization
Differences between Kanban and Scrum
Roles – Scrum is dependent on the scrum owners and is worked upon by them respectively. Kanban is independent of cross-functional team members and parallel roles.
Release cycle – Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Kanban does not follow any cycle and the process is continuous in nature.
Tracking parameters – Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint. Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.
The scope of improvement – Scrum does not encourage changes in ongoing sprints. Kanban is open to any changes before the completion of the project. It is flexible in nature.
Fit factor – Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit. Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.
Pick process – Scrum picks the entire batch of user stories from the product backlog for development. Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.
Delivery – Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.Kanban follows the continuous delivery model based on business needs.
The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.
I don't have specific experience with using Kanban in software but I am familiar with the practice from a manufacturing point of view, so I was curious as to the implementation. Reading your link, the thing that struck me as a possible hitch is what felt like an underlying assumption about the same-sized ness of the units of work (features, stories, whatever). While keeping things "story sized" is a good goal, there are often mixes of bigger and little stories floating around, and the small number constraints in their pipeline therefore seem artificial. If the goal is to highlight bottlenecks, I would think that stand ups and sprint planning and retrospectives will do that well enough. If the goal is to facilitate prioritization, I think that putting constraints on numbers of tasks by types wouldn't do that as well as simply ordering them top to bottom.
I guess I don't really see what value its adding; that being said, I don't see the harm in trying it and adopting whatever pieces work.
发布评论
评论（6）
1.它实际上提供了动态识别瓶颈方面的优势吗？
这是我的经验。通过设置 WIP 限制来反映可用容量，如果有工作需要利用该容量但必须等待其变得可用，那么您将看到它作为工作队列在瓶颈之前备份。我见过这种情况发生，当 QA 团队劳累过度时，上游开发团队仍在继续生产，即使 QA 没有机会检查它。我们采取的解决方案是将一些开发人员借给 QA 团队，然后由他们帮助缓解瓶颈。
2.它在实践中是否容易执行，或者是否存在需要管理的后勤挑战？
这将取决于许多因素，这些因素将特定于您应用它的环境。看板的一大优势是它不需要立即“全有或全无”地改变您当前的工作方式。大卫·安德森（David Anderson）的“看板”一书中的“成功秘诀”一章提供了一种实现变革的好方法，从“关注质量”开始
3。它是否可以很好地扩展到具有许多并行工作流和许多开发人员的项目团队？
在我第一次使用它的项目中，我们最终拥有了一个由 17 名开发人员组成的团队，并且我们已将 4 人的 QA 团队转移到了我们的团队中也。我们还有很多外部依赖关系，我们使用看板对其进行建模。
4。它与关键路径分析（在 MS Project 中实现）相比如何？有何不同？
因从未使用过而通过
5。应用看板还可以获得哪些其他好处？
有很多好处，但我要指出的是，它为您提供了对于与团队、利益相关者和其他人讨论和指导工作真正有用的指标。团队之外的人。具体来说，“吞吐量”和“周期时间”的使用有助于为您提供工作完成时间的概率。
1. Does it actually offer the advantages is claims in terms of dynamically identifying bottlenecks?
This has been my experience. By setting your WIP limits to reflect available capacity, if there is work that needs to make use of that capacity but has to wait for it to become available then you will see it as the queue of work backs up ahead of the bottleneck. I have seen this happen when there is an overworked QA team with an upstream development team who keep producing even though there is no chance of it getting looked at by QA. The solution we took to this was to lend some of the developers to the QA team who then helped alleviate the bottleneck.
2. Is it easy to execute in practice, or does it have logistical challenges that you need to manage?
This will depend on many factors which will be specific to the context to which you are applying it. One of the great strengths of Kanban is it does not require an immediate 'all or nothing' change from how you are currently working. The chapter 'A Recipe for Success' in David Anderson's 'Kanban' book gives a great way of approaching the change, starting with 'Focus on Quality'
3. Does it scale well to project teams with many parallel streams of work and many developers?
In the project where I first used it we ended up with a team of seventeen developers and we had moved the QA team of four into our team too. We also had lots of external dependencies which we used Kanban to model.
4. How does it compare to critical path analysis (as implemented in MS Project), how is it different?
Pass as have never used
5. What other benefits can be gained from applying kanban?
There are many but the one I will call out is that it gives you metrics that are genuinely useful for discussing and steering the work, both with the team and with stakeholders and other people outside the team. Specifically the use of 'Throughput' and 'Cycle Time' help give you a probabilistic for cast of when work will get done.
看板方法首先是持续流程改进的催化剂。这不是一个快速解决方案或一组固定的步骤/实践。该方法有一些基本原则和核心属性，如 David J Anderson 最近的博客文章中所述< /a>，这可以引导您持续改进流程。
对于您的问题：
看板方法本身并不能识别瓶颈。当对流程实施进行中工作限制时，会给流程带来压力，您最终将创建一个拉式系统，然后更容易识别流程中的瓶颈。可视化看板和累积流程图等工具将帮助您识别流程中的瓶颈。
如果您应用基本原则和核心属性，并且您有耐力/耐心/奉献精神，那么这并不太难。您需要像每次组织变革一样管理变革流程，但看板方法旨在进行小而无威胁的变革。
是的，有很多记录在案的案例。
看板方法没有确定规划和预测未来交付的具体方法。 David J Anderson 具有约束理论的背景，并在大多数理论中使用 TOC 作为模型。我读过的文字。我认为使用 MS Project 风格的大型预先计划与许多看板实施中使用的基于经验的计划之间的实际差异是巨大的差异。在项目开始时使用在 MS Project 中设计的项目计划时，您对实际问题领域知之甚少，并且会做出假设。基于这些假设，你制定了一个计划。关键路径是根据这些假设计算的。有了稳定的看板系统并使用 TOC 作为模型，您“仅”计划在关键路径上设置约束/瓶颈。您会考虑通过约束的工作的历史可变性，并在瓶颈周围创建缓冲区以及您想要承担的适当风险。我们的想法是，在瓶颈处每损失一个小时，整个系统就会损失一个小时。
看板方法的主要好处是它是持续流程改进的催化剂。它从你所得到的开始，做出持续的、不具威胁性的改变。看板是一种坚持使用
的方法，
The Kanban method is foremost a catalyst for continuous process improvements. It’s not a quick fix or a fixed set of steps/practices. The method has a few foundational principles and core properties, as described in David J Andersons recent blog post, that can lead you the way to continuous process improvements.
To your questions:
The Kanban method in itself does not identify bottlenecks. When implementing work-in-progress limits to a process that creates stress on your process you will eventually create a pull system and then it becomes easier to identify bottlenecks in your process. Tools like a visual kanban board and Cumulative Flow Diagrams will help you identify the bottlenecks in the process.
If you apply the foundational principles and core properties and you have the stamina/patience/dedication it is not too hard. You need to manage the change process as with every organizational change but the Kanban Method is designed to make small and non-threatening changes.
Yes there are many documented cases of this.
The Kanban method does not identify a specific method for planning and projecting future deliveries. David J Anderson has a background in Theory of Constraints and uses TOC as a model in most of the writing I have read. I think the practical difference between using MS Project style big up front planning and the empirical based planning used in many kanban implementations is the big difference. When working with a project plan designed in MS Project in the beginning of a project you know very little of the actual problem domain and you make assumptions. Based on these assumptions you device a plan. A critical path is calculated based on these assumptions. With a stable kanban system and you use TOC as your model you plan “only” to have your constraint/bottleneck on the critical path. You take into account the historical variability of the work passing the constraint and you create buffers around you bottleneck with the appropriate risk you want to take. The thinking is that every hour lost at the bottleneck will be an hour lost for the whole system.
The main benefit of the Kanban Method is that it is a catalyst for continuous process improvements. It starts with what you got and makes non-threatening changes that sticks. Kanban is a method that is Made to Stick
在文章将看板应用于PC 部署团队必须考虑以下设备：
上面的页面还提供了看板应用于
In the article Applying Kanban to PC Deployment the Team has to account for the following equipment:
The page above has also links to Kanban applied ...
我也没有太多的经验，但我想我可以提供一些见解。
1 & 4：看板与其他技术（例如 CPM）之间的主要区别在于，看板在正确的实施中会强制您施加进行中工作的限制。这就创建了一个拉动系统，因为只有当工人有能力时才会接受新物品。这与 MS 项目类型的项目不同，其中任务预先分配给工作人员（即推送）。
识别拉式系统中的瓶颈要容易得多，因为工作项将在流程的某个阶段排队。在推送系统中，工作是通过系统推送的（无论是否“完成”），因此很难找到瓶颈。
拉式系统的另一个优点是您可以开始根据实际结果（交付周期和周期时间）制定工作时间表，而不是预测。是的，故事的大小和粒度确实会影响这一点，但使用累积流程图等技术，这变得不那么重要了。
2：大多数实现都非常简单，这就是该技术的一些优势。我认为如果你在技术的后勤方面遇到问题，那么你就做错了。请查看此处，了解一个不错的“启动示例”。
I also don't have a lot of experience with it, but I think I can offer some insight.
1 & 4: the main difference between Kanban boards and other techniques, like CPM, is that a Kanban board, in a correct implementation, forces you to impose work-in-progress limits. This creates a pull system, since new items are accepted by workers only when they have capacity. This differs from an MS project type project where tasks are assigned to workers before-hand (i.e. pushed).
It is much easier to identify a bottleneck in a pull system, because work items will be queuing up at some stage in the process. In a push system, work is pushed through the system (whether it is 'done done' or not), so its difficult to find bottlenecks.
Another advantage of a pull system is you can start to base work timelines on actual results (lead and cycle time), as opposed to prediction. Yes, the size and granularity of stories does affect this, but with techniques such as cumulative flow diagrams this becomes less important.
2: Most implementations are pretty simple, and therein lies some of the strength of the technique. I think if you're having problems with the logistics of the technique, you're doing it wrong. Have a look here for a nice 'kickstart example'.
在讨论差异之前，需要关注几个定义：
看板和 Scrum 之间的相似性
>看板和 Scrum 之间的差异
角色 - Scrum 依赖于 Scrum 所有者并分别由他们负责。看板独立于跨职能团队成员和并行角色。
发布周期——Scrum 使用持续时间从一周到两周不等的冲刺。然后将用户故事用于开发、测试和错误修复。看板不遵循任何循环，该过程本质上是连续的。
跟踪参数——Scrum 在规划即将到来的冲刺时利用速度，同时考虑到上一个冲刺中完成的用户故事的复杂性和数量。看板确保对“正在进行的工作”列中的用户故事进行限制，以避免出现瓶颈。它跟踪完成任务从开始到结束所需的时间。
改进的范围——Scrum 不鼓励正在进行的冲刺中的改变。在项目完成之前，看板可以接受任何更改。它本质上是灵活的。
适合因素——Scrum 适合具有明确定义的用户故事的项目。客户对项目按时完成的认可使其成为合适的。看板本质上是灵活的，允许根据当前场景改变优先级。
选择流程——Scrum 从产品待办事项列表中挑选整批用户故事进行开发。看板遵循列中允许的最大任务数，以保持框架的健全性并避免瓶颈。
交付——Scrum 遵循基于冲刺计划的交付，并根据客户给出的规范确定优先级。看板遵循基于业务需求的持续交付模型。
如果您能够想象如何处理上述几点，那么就很容易记住它们。理想情况下，scrum 遵循一组预先定义的原则。看板以灵活性原则为后盾。它允许您跟踪对交付最重要的任务。
Few definitions to focus on before jumping onto the differences:
Similarities between Kanban and Scrum
Differences between Kanban and Scrum
Roles – Scrum is dependent on the scrum owners and is worked upon by them respectively. Kanban is independent of cross-functional team members and parallel roles.
Release cycle – Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Kanban does not follow any cycle and the process is continuous in nature.
Tracking parameters – Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint. Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.
The scope of improvement – Scrum does not encourage changes in ongoing sprints. Kanban is open to any changes before the completion of the project. It is flexible in nature.
Fit factor – Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit. Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.
Pick process – Scrum picks the entire batch of user stories from the product backlog for development. Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.
Delivery – Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.Kanban follows the continuous delivery model based on business needs.
The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.
我没有在软件中使用看板的具体经验，但我从制造的角度熟悉这种做法，所以我对实施感到好奇。阅读你的链接，让我觉得可能出现问题的事情是关于工作单元（功能、故事等）大小相同的潜在假设。虽然保持“故事大小”是一个很好的目标，但经常会出现大小故事的混合体，因此管道中的少量限制似乎是人为的。如果目标是突出瓶颈，我认为站会、冲刺计划和回顾就足够了。如果目标是促进优先级排序，我认为按类型对任务数量进行限制并不能像简单地从上到下对它们进行排序那样做到这一点。
我想我并没有真正看到它增加了什么价值；话虽这么说，我不认为尝试并采用任何有效的方法有什么坏处。
I don't have specific experience with using Kanban in software but I am familiar with the practice from a manufacturing point of view, so I was curious as to the implementation. Reading your link, the thing that struck me as a possible hitch is what felt like an underlying assumption about the same-sized ness of the units of work (features, stories, whatever). While keeping things "story sized" is a good goal, there are often mixes of bigger and little stories floating around, and the small number constraints in their pipeline therefore seem artificial. If the goal is to highlight bottlenecks, I would think that stand ups and sprint planning and retrospectives will do that well enough. If the goal is to facilitate prioritization, I think that putting constraints on numbers of tasks by types wouldn't do that as well as simply ordering them top to bottom.
I guess I don't really see what value its adding; that being said, I don't see the harm in trying it and adopting whatever pieces work.