看板作为软件开发过程的实践

文中 Applying Kanban to PC Deployment 团队必须考虑以下设备:

• 将部署160台新电脑
• 将部署40台新笔记本电脑
• 120台个人电脑和10台笔记本电脑需要更新和重新部署

... 我们正在探索使用看板来管理短期职能部门 项目本例重点介绍如何使用看板创建透明的 跟踪设备通过多个复杂系统的流程 步骤,而不会产生跟踪软件的额外成本, 部署过程的一致性或质量也将有助于改进 提高故障排除和维修时间的效率,并确保 记录与软件和许可的高度一致性

• 技术支持
• to PC Deployment (见上文引述)
• to a Development Group
• 挑战、附加概念和Wrapup

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

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

3. 是的,这方面有很多记录在案的案例。

4. 看板方法未确定规划和预测未来交付的具体方法。David J Anderson具有以下方面的背景: Theory of Constraints 并且在我读到的大部分文章中都使用TOC作为模型。我认为在许多看板实施中使用MS项目风格的大前期规划和基于经验的规划之间的实际区别是很大的区别。当在项目开始时使用MS project中设计的项目计划时,您对实际问题领域知之甚少,并做出假设。基于这些假设,你可以制定一个计划。根据这些假设计算关键路径。有了一个稳定的看板系统,并且您使用TOC作为模型,您只计划在关键路径上设置约束/瓶颈。考虑到通过约束的工作的历史可变性,并在瓶颈周围创建缓冲区,以承担适当的风险。我们的想法是,瓶颈处每损失一个小时,整个系统就会损失一个小时。

5. 看板方法的主要优点是它是持续过程改进的催化剂。它从你所得到的开始,做出不具威胁性的改变。看板是一种 Made to Stick

一,;4:看板和其他技术(如CPM)之间的主要区别在于,看板在正确的实现中,会强制您施加进度限制。这将创建一个拉动系统,因为只有当工人有能力时,他们才会接受新项目。这与MS项目类型项目不同,在MS项目类型项目中,任务是事先分配给工人的(即推送)。

在pull系统中识别瓶颈要容易得多,因为工作项将在流程的某个阶段排队。在推送系统中,工作通过系统推送(无论“完成”与否),因此很难找到瓶颈。

拉式系统的另一个优点是,您可以开始根据实际结果(提前期和周期时间)确定工作时间表,而不是预测。是的,故事的大小和粒度确实会影响这一点,但使用累积流程图等技术,这一点就变得不那么重要了。

2:大多数实现都非常简单,这就是该技术的优势所在。我认为,如果你在技术的后勤方面遇到问题,你就错了。看一看 here

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使用持续时间从一周到两周不等的Sprint。然后,用户故事将用于开发、测试和bug修复。看板不遵循任何循环,过程本质上是连续的。

跟踪参数Scrum在规划即将到来的sprint时利用velocity,同时考虑到在上一个sprint中完成的用户故事的复杂性和数量。看板确保在“正在工作”列中限制用户故事,以避免瓶颈。它跟踪从开始到结束完成任务所花费的时间。

Scrum的改进范围并不鼓励对正在进行的Sprint进行更改。看板可在项目完成前进行任何变更。它本质上是灵活的。

Fit factor Scrum适用于具有明确定义的用户情景的项目。客户对及时完成项目的确认使其成为合适的选择。看板本质上是灵活的,允许根据当前场景改变优先级。

Pick process Scrum从产品待办事项列表中挑选整个用户案例进行开发。看板遵循列中允许的最大任务数,以保持框架的健全性并避免瓶颈。

如果您能够形象地处理这些问题,那么上述几点很容易记住。理想情况下,scrum遵循一组预定义的原则。看板以灵活性原则为后盾。它允许您跟踪对交付至关重要的任务。

我想我真的不知道它增加了什么价值;话虽如此,我并不认为尝试和采纳任何可行的作品有什么害处。

1.在动态识别瓶颈方面,它是否真的提供了is声明的优势?

2.在实践中是否易于执行,或者是否存在需要管理的后勤挑战?

这将取决于许多因素,这些因素将特定于您应用它的上下文。看板的一大优点是它不需要立即改变你目前的工作方式。大卫·安德森(David Anderson)的《看板》(Kanban)一书中的“成功秘诀”一章提供了一个很好的方法来应对这一变化,从“关注质量”开始

3.它是否能够很好地扩展到具有许多并行工作流和许多开发人员的项目团队?

在我第一次使用它的项目中,我们最终拥有了一个由17名开发人员组成的团队,我们也将一个由4名开发人员组成的QA团队转移到了我们的团队中。我们也有很多外部依赖,我们使用看板来建模。

4.与关键路径分析(在MS项目中实施)相比,它有什么不同?

以从未使用过的方式通过