两种敏捷开发方式的工做流介绍

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

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

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

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