两种敏捷开发方式的工作流

敏捷开发时当今很流行的一种开发软件方式，接下来主要介绍一下两种主要的敏捷开发方式的工作流

Scrum flow

项目计划从定义backlog开始，即交付完成的产品时应该完成的用户需求列表。

产品 backlog - 列出团队主要的 “To Do” list。产品的代办事项列表应该包括全部的特性和 bug 修复。以便在项目结束时确认已经完成。产品的代办列表需要在工作中按照新的需求或者发现的错误持续的更新。产品的负责人负责待办事项，使其与客户的反馈和建议以及团队的工作进度同步。一些Item的优先级应该被提升或下降，一些item应该根据需求的变化增加或者减少。
Sprint backlog - 包含在特定sprint中要完成的任务。sprint backlog的项目被选择为在sprint结束时交付一个完成的特性或组件。虽然sprint backlog也允许一定的灵活性和修改，但是sprint的目标应该保持不变，并且变更应该保持在最小。
Sprint goal or increment - 作为sprint结果交付的可用产品。通常，sprint以展示完成的特性或组件的演示结束。在这方面，一个重要的概念是“done”的定义，它指的是要将每个用户工作视为完整的。“done”的定义可能会根据用户的情况而有所不同:它可能包含多个任务，例如开发、测试、设计、文档和表示，还可能涉及不同的团队成员。

每个sprint都从一个计划阶段开始，在下一个sprint中选择任务。对于计划阶段，整个团队通常都会到场，包括产品负责人和Scrum Master。团队决定在sprint结束时可以交付什么，并从产品backlog中选择相应的用户工作。通过这种方式，他们将sprint backlog放在一起。

在sprint期间，团队每天开会进行“每日scrum”，讨论他们的进展以及可能遇到的任何障碍。每日scrum的目的是尽早发现问题，并快速找到解决方案，以免中断sprint流程。

在sprint之后，涉众将审查完成的特性。在sprint评审期间，团队有机会收到关于他们工作的反馈，以及变更建议(如果有的话)。

与此同时，团队开会进行sprint回顾，分析他们刚刚完成的sprint，并找到可以改进的地方。回顾之后，流程被重置，新的sprint从计划阶段开始。

Kanban flow

在 Kanban中，没有要求需要在一个确定的时间点完成一定数量的工作。相反，Kanban专注于平衡团队的当前正在进行的工作的能力。

一个 Kanban 项目流程从一般的backlog开始,包含所有的应该完成的任务。每个团队成员从backlog中为自己挑选一个任务，并集中精力完成它。当任务完成时，成员选择下一个任务，以此类推，直到所有任务完成为止。待办事项列表的优先级是将最紧急的任务放在顶部，由团队首先处理。

在Kanban中，重要的是在项目期间的任何时候，正在进行的工作量都不能超过团队的能力。为此目的，有可能根据现有的能力为任何类型的工作定一个限度。

产品负责人可以尽可能频繁地设置和更改backlog中的优先级，因为backlog管理对团队的性能没有影响。团队只关心正在进行的工作，只有在当前任务完成后才返回到backlog。

每个任务都沿着“To Do”—“Work in Progress”—“Done”路线进行。当然，Kanban也支持“完成”定义的概念，这是每个任务接受的标准。

总而言之，我们可以说Scrum的主要区别在于它试图在指定的时间内完成预定的工作，而Kanban确保正在进行的工作永远不会超过设定的限制。

如何选择

如果你一直在等待这个问题的最终答案，我们可能会让你失望。到目前为止，我们希望已经成功地证明了这两种方法都有它们的优点，并且都可以帮助建立敏捷开发过程。然而，我们提供了一些指导方针，可以帮助您选择最适合您的团队的方法。

使用 Scrim

你可以相对容易地将工作划分为逻辑块，这些逻辑块可以在两周内完成。
你需要对整个项目有高度的可预测性。Scrum专注于将sprint中的变更保持在最小。
你的团队里有很多新成员。使用Scrum，如果需要的话，他们会更容易理解团队纪律并做出改进。

使用 Kanban

你期望项目中有很多频繁的变更。
很难隔离能够在两周内交付的产品组件。
你的团队纪律严明，可以信任他们会在没有严格截止日期的情况下安排他们的活动。