敏捷简介：什么是敏捷开发？

时间 2019-12-11

标签敏捷简介什么开发繁體版

原文原文链接

敏捷软件开发

敏捷是世界上使用最普遍，最受承认的软件开发框架之一。大多数组织已经以某种形式采用了它，可是在采用计划的成熟度方面还有很长的路要走。本系列教程的惟一目的是将技术和非技术专业人员融入敏捷世界。程序员

咱们将逐步引导您完成敏捷之旅，直到您了解使用敏捷背后的理念，优点以及如何实践它。本系列旨在使读者可以将敏捷和Scrum学习应用到他们的工做中。这个特别的教程专门向您解释为何须要敏捷以及如何建立它。这里的基础是让您了解软件开发行业中敏捷采用的概念。数据库

敏捷的历史

敏捷出生在一个晴朗的日子，当时有17我的具备不一样的开发方法背景，在一块儿探索可能的替代软件开发解决方案，能够共同进行头脑风暴，寻求可能会缩短开发时间并减小文档的需求量。编程

当时，软件开发过去发生的时间太长，以致于当项目准备交付时，业务已经向前发展，需求已经发生变化。所以，即便项目可以实现其既定目标，也没法知足业务需求。数组

所以，这些不一样软件工程技术的精英汇集在一块儿，他们会议的最终结果就是他们所谓的“敏捷宣言”，咱们将在本系列的下一个教程中详细讨论。架构

可是那天出生的敏捷并非咱们今天在组织中看到的。专家们赞成的方法被称为“轻量级”且速度快。可是，本次会议的主要成果是认为更快的产品交付和持续的反馈是实现软件开发成功的关键。框架

现有的瀑布技术过于繁琐，在最终产品准备交付以前没有提供反馈。这意味着没有进行要求修正的余地，而且在整个产品准备好以前，客户对进度没有任何见解。这就是这些专家想要避免的。他们想要一个可以持续反馈的解决方案，以免后期返工的成本。ide

敏捷挑战

当时现有的瀑布技术过于繁琐，在最终产品准备交付以前没有提供反馈。它被称为开发的瀑布模型，由于团队首先完成了一步，而后才进入下一步。函数

这意味着没有进行要求修正的余地，而且在整个产品准备好以前，客户对进度没有任何见解。这就是这些专家想要避免的。他们想要一个能够持续反馈的解决方案，以免在之后阶段返工的成本。这就是为何敏捷也是关于自适应和持续改进的缘由，同时也是关于持续反馈和交付速度的缘由。工具

什么是敏捷承诺？

敏捷承诺单元测试

敏捷不只仅是在开发软件时应用设定的实践。它还带来了团队思惟方式的变化，这促使他们构建更好的软件，协同工做并最终让他们成为一个满意的客户。

敏捷的价值观和原则使团队可以转移他们的注意力并改变他们构建更好软件的思惟过程。

敏捷究竟是什么？

敏捷不是一套规则。敏捷不是一套指导方针。敏捷甚至不是一种方法论。相反，敏捷是一套原则，鼓励灵活性，适应性，沟通和工做软件超越计划和流程。它在所谓的敏捷宣言中很是简洁地被捕获。

敏捷软件开发使团队可以在开发复杂项目时更有效地协同工做。它由练习迭代和增量技术的实践组成，这些技术很容易被采用并显示出很好的结果。

在将敏捷应用于行动中，咱们有各类基于敏捷的方法去知足软件开发行业的全部需求，从软件设计和架构，开发和测试到项目管理和交付。

不只如此，敏捷方法和方法还为流程改进打开了一个范围，做为每一个交付的一个组成部分。

敏捷是一种软件开发的实践理念，建构一个自给自足且跨职能的团队致力于经过迭代进行持续交付，并经过收集最终用户的反馈在整个过程当中发展。

如何练习敏捷？

各类多样化行业都有各类敏捷方法论。

然而，全部这些方法中最流行的方法是：

Scrum
看板 (Kanban)
极限编程 (XP)

全部这些方法都侧重于精益 (Lean) 软件开发，并有助于有效和高效地构建更好的软件。

这就是敏捷引言的所有内容。该部分的结构旨在帮助您了解团队在敏捷模式和思惟模式下工做时应采用的核心价值观和原则。

敏捷方法论和模型

敏捷方法论简介：

众所周知，敏捷是一种软件开发方法。咱们还了解了敏捷创始人在敏捷宣言中提到的价值观和原则。在咱们最初的讨论中，咱们还避开了敏捷和传统瀑布模型之间的差别。在本教程中，咱们将了解敏捷方法的优缺点。

咱们会看到什么是scrum？它与敏捷有何不一样？而后咱们将了解不一样组织正在使用的各类敏捷方法，以及如何使用它们实现敏捷。您还将可以理解这些方法的不一样之处以及优缺点。

敏捷方法论的优势

下面给出了敏捷方法的各类优势：

客户在每次迭代 (iterative) /冲刺 (Sprint) 结束时不断得到项目进度的外观和感受。
每一个sprint都为客户提供了一个工做软件，该软件根据他们提供的完成定义知足他们的指望。
开发团队对不断变化的需求作出了很好的响应，即便在开发的高级阶段也能适应变化。
持续的双向沟通 (feedback) 使客户参与其中，所以全部利益相关者 (Stakeholders) - 业务和技术 - 都能清楚地了解项目的进展状况。
产品设计高效，知足业务需求。

敏捷方法论的缺点

虽然敏捷方法有几个优势，但它也有一些缺点。

他们是：

＃1）不但愿使用全面的文档，这会致使敏捷团队错误地解释这一点，由于敏捷不须要文档。所以严谨性会因文档而丢失。应该经过不断询问本身这是不是足够的信息来避免这种状况。

＃2）有时，在项目开始时，要求并不十分清晰。团队可能会继续发现客户的愿景已经从新调整，在这种状况下，团队须要整合许多变动，并且很难衡量最终结果。

敏捷方法的类型

世界各地都有几种敏捷方法。咱们将详细了解最受欢迎的四个。

＃1）Scrum

Scrum很容易被认为是最流行的敏捷框架。“scrum”一词被大多数从业者认为是“敏捷”的同义词。但这是一种误解。Scrum只是您能够实现敏捷的框架之一。

Scrum这个词来自体育橄榄球 (Rugby)。球员们在一个互锁的位置挤在一块儿推着对手。每一个球员在他们的位置上都有明确的角色，而且能够根据状况的需求发挥进攻和防守的做用。

一样，IT中的Scrum相信赋予自我管理的开发团队有三个具体且明肯定义的角色。这些角色包括 - 产品负责人（PO），Scrum Master（SM）以及由程序员和测试人员组成的开发团队。它们在迭代时间盒装持续时间中一块儿工做，称为冲刺。

第一步是PO建立产品待办事项。这是scrum团队要作的事情的待办事项列表。而后scrum团队选择优先级最高的项目并尝试在称为sprint的时间框内完成它们。

记住全部这一切的更简单方法是记住3-3-5框架。这意味着scrum项目有3个角色，3个工件，5价值和5个事件。

这些是 -

3 角色： PO，Scrum master和开发团队。

3 工件：产品Backlog，Sprint Backlog和产品增量。

5 价值: 集中，勇气，开放性，承诺，尊重。

5 事件： Sprint，Sprint计划，Daily Scrum，Sprint评论和Sprint回顾。

咱们将在后续教程中更详细地了解每一个内容。

＃2）看板 (Kanban)

看板是日语术语，意思是卡片。这些卡包含要在软件上完成的工做的详细信息。目的是可视化。每一个团队成员都了解经过这些视觉辅助工做要完成的工做。

团队使用这些看板卡进行持续交付。就像Scrum同样，看板也能够帮助团队有效地工做，并促进自我管理和协做的团队。

可是这二者之间也存在差别 - 好比在scrum sprint期间，团队正在处理的项目是固定的，咱们没法向sprint添加项目，而在看板中，若是有可用容量，咱们能够添加项目。当需求常常变化时，这尤为有用。

一样，另外一个区别是，虽然scrum已经定义了PO，Scrum master和开发团队的角色，可是在Kanban中没有这样的预约义角色。

另外一个不一样之处在于，尽管scrum建议对产品待办事项进行优先排序，但看板没有这样的要求，并且彻底是可选的。所以，看板须要较少的组织并避免非增值活动，而且适用于须要对变化作出响应的过程。

＃3）精益 (Lean)

精益是一种专一于减小浪费的理念。它是如何作到的？

在精简中，您将流程划分为增值活动，非增值活动和基本的非增值活动。任何可归类为非增值活动的活动都是浪费，咱们应该尝试在过程当中消除这种浪费，使其更加精简。

更精简的流程意味着更快的交付和更少的工做浪费在任务上，这无助于实现团队目标。这有助于优化软件开发周期中的每一个步骤。这就是精益原则从精益制造转变为软件开发的缘由。

经过应用如下所示的七项精益原则，能够在任何IT项目中使用精益软件开发：

正如他们的名字所暗示的，这些都是不言自明的。消除浪费是第一个也是最重要的精益原则，咱们看到了如何作到这一点，咱们只是将活动分类为价值和非增值。

非值添加活动能够是代码的任何部分，可能使其不那么健壮，增长所涉及的工做量并占用大量时间而不添加合理的业务价值。它也多是模糊的用户故事或不良测试或添加大图中不须要的功能。

第二个原则放大学习再次易于理解，由于团队须要各类技能，以在快速变化的环境中提供产品，新技术能够在短期内出现。

作出迟到的决定能够在减小返工的状况下得到回报，就像预期会有任何变动，而后更好地延迟，以便团队没必要在业务需求变化时重作工做。

可是这里老是存在一种权衡，由于团队须要平衡这一点与提供更快速的第四个原则。推迟决策不该影响总体交付，也不得减小工做节奏。一只眼睛应该始终在完整的画面上。

赋予权力的团队如今也很是广泛，这甚至是敏捷的建议。赋权团队更负责任，能够更快地作出决策。拥有权力的团队的全部权意识能够带来更好的结果。为了赋予团队权力，应该容许他们本身组织并本身作出决定。

所以，咱们看到精益和敏捷有不少共同之处，只有一个明显的区别 - 精益团队能够帮助改进产品，敏捷团队就是实际构建产品的团队。

＃4）极限编程（XP）

极限编程是另外一种最流行的敏捷技术。根据extremeprogramming.org，第一个XP项目于1996年3月6日开始。他们还提到XP以五种不一样的方式影响软件项目开发 - 沟通，简单，反馈，尊重和勇气。这些被称为XP的值。

其中，一切都始于沟通。XP团队按期与业务团队和其余程序员协做，并从第一天开始构建代码。这里的重点是在其余视觉辅助工具的帮助下尽量地进行面对面的交流。

极端程序员还会构建一个简单的代码，并从第一天开始得到反馈。重点是不要过度或预测还没有共享的要求。这使设计简单，只生产出知足要求的最小产品。

反馈有助于团队改进并提升工做质量。这有助于他们在彼此学习的过程当中创建对彼此的尊重，并学习如何分享他们的观点。

这也给了他们勇气，由于他们知道他们已经收集了每一个人的最佳想法，并根据其余人的反馈产生了一个好的产品。所以，他们也不惧怕包含变动或收到有关其工做的进一步反馈。

这在需求常常变化的项目中特别有用。持续的反馈将帮助团队以勇气包含这些变化。

所以，咱们已经看到了不一样的敏捷方法，如Scrum，XP，看板和精益，以及它们各自的优缺点。

如今，咱们能够轻松区分它们，也欣赏它们之间的微妙差别。咱们还了解了每种方法的基本原理，并了解了如何在须要时将它们应用于咱们的项目中。

在下一部分中，让咱们了解Scrum的一切。

Scrum框架 (Scrum Framework)

SCRUM是敏捷方法中的一个过程，它是迭代模型和增量模型的组合。

传统瀑布模型的主要障碍之一是 - 在第一阶段完成以前，应用程序不会移动到另外一阶段。并且，若是在周期的后期阶段发生一些变化，那么实施这些变化就变得很是具备挑战性，由于这将涉及从新审视早期阶段并重作变动。

SCRUM的一些关键特性包括：

自我组织和专一的团队。
没有巨大的要求文件，而是有一个很是精确和重点的故事。
跨职能团队做为一个单元一块儿工做。
与用户表明密切沟通以了解功能。
有一个最长一个月的明确时间表。
Scrum不是一次完成整个“事物”，而是以给定的间隔作一些事情。
在提交任何内容以前，会考虑资源功能和可用性。

要很好地理解这种方法，理解SCRUM中的关键术语很是重要。

重要的SCRUM术语

1）Scrum团队

Scrum团队由7人组成，其中包括+或 - 两名成员。这些成员是能力的混合体，由开发人员，测试人员，数据库人员，支持人员等组成，还包括产品全部者和Scrum主管。

全部这些成员经过紧密协做一块儿工做，以递归和肯定的间隔，开发和实现所述特征。SCRUM团队的坐姿安排在他们的互动中起着很是重要的做用，他们从不坐在小隔间或小木屋里，而是一张巨大的桌子。

2）冲刺 (Sprint)

Sprint是预约义的时间间隔或时间范围，其中必须完成工做并使其准备好进行审查或准备进行生产部署。这个时间框一般在2周到1个月之间。

在咱们的平常生活中，当咱们说咱们遵循1个月的Sprint周期时，它只是意味着咱们在任务上工做了一个月，并准备好在该月底以前进行审核。

3）产品负责人 (Product Owner)

产品全部者是要开发的应用程序的主要利益相关者或主要用户。产品全部者是表明客户方的人。他/她拥有最终权力，应始终为团队提供。

当任何人有任何须要澄清的疑问时，他/她应该能够到达。对于产品全部者而言，了解而且不在sprint中间或sprint已经开始时分配任何新要求很是重要。

4）Scrum Master

Scrum Master是Scrum团队的推进者。他/她确保Scrum团队富有成效和进步。若有任何障碍，scrum master会跟进并为团队解决问题。SCRUM Master是PO和团队之间的中介。

他/她让PO了解Sprint的进展状况。若是团队存在任何障碍或问题，请与PO讨论并解决问题。就像团队的每日站立时同样，天天都会有一个关于PO的SCRUM Master的站立。

5）业务分析师（BA）

业务分析师在SCRUM中扮演着很是重要的角色。此人负责完成要求并在需求文档（基于其建立用户素材）中起草。

若是用户故事/接受标准中存在任何含糊之处，他/她是技术（SCRUM）团队接洽的人，而后他将其接收到PO或者若是可能的话自行解决。在大型项目中，可能有超过1个BA，但在小规模项目中，SCRUM Master也可能做为BA。

项目启动时得到学士学位老是一个好习惯。

6）用户故事 (User Story)

用户故事只不过是必须实现的要求或功能。

在scrum中，咱们没有那些巨大的需求文档，而是需求在一个段落中定义，一般具备如下格式：

做为<用户/用户类型>
我想<一些可实现的目标/目标>
实现<作某事的某些结果或理由>

例如：

做为[管理员]，我想[要密码锁]，实现[以防用户连续3次输入错误的密码以限制未经受权的访问]。

应该遵照用户故事的一些特征。用户故事应该简短，逼真，能够估计，完整，可协商和可测试。用户故事永远不会在Sprint中间被更改或更改。

SCRUM Master和BA（若是适用）负责确保PO使用适当的“验收标准”正确起草用户故事“。若是要进行任何会影响sprint发布的更改，那么这些故事将从sprint中撤出，或者按照可用时间完成。

每一个用户故事都有一个验收标准 (Acceptance Criteria)，应由团队明肯定义和理解。

验收标准详细说明了提供支持文档的用户故事。它有助于进一步完善用户故事。团队中的任何人均可以写下验收标准。测试团队根据这些验收标准肯定测试用例/条件。

7）史诗 (Epic)

史诗是模棱两可的用户故事，或者咱们能够说这些是未定义的用户故事，并保留用于将来的冲刺。

试着把它与生活联系起来，假设你要去度假。当你下周去的时候，你已经准备好了全部的东西，好比你的酒店预订，观光，旅行支票等等。可是你明年的假期计划呢？你只有一个模糊的想法，你可能会去XYZ的地方，但你没有详细的计划。

史诗就像你明年的假期计划同样，在那里你只知道你可能想去，可是在这个时间点你不知道全部这些细节的地点，时间，对象。

以相似的方式，存在未来须要实现的特征，其细节尚不清楚。大部分功能都以Epic开头，而后分解为能够实现的故事。

8）产品积压 (Product Backlog)

产品待办事项是一种存储全部用户故事的存储桶或源。这由产品负责人维护。产品待办事项能够设想为产品全部者的愿望清单，产品全部者根据业务需求对其进行优先级排序。

在计划会议期间（参见下一节），从产品待办事项中获取一个用户故事，而后团队进行头脑风暴，理解并完善它，并在产品全部者的干预下共同决定要采起哪些用户故事。

9）Sprint Backlog

根据优先级，用户故事一次一个地从Product Backlog中获取。Scrum团队的头脑风暴决定了它的可行性，并决定了在特定冲刺上工做的故事。Scrum团队在特定sprint上工做的全部用户故事的集合列表称为Sprint backlog。

10）故事点 (Story Point)

故事点是用户故事复杂性的定量指示。基于故事点，肯定故事的估计和努力。

故事点是相对的而不是绝对的。为了确保咱们的估计和努力是正确的，检查用户故事并不重要是很重要的。用户故事越精确，越小，估计就越准确。

每一个用户故事都根据Fibonacci系列（1,2,3,5,8,13和21）分配到故事点。数字越高，复杂就是故事。

确切地说

若是你给出1/2/3的故事点，那就意味着故事很小并且复杂度很低。
若是你给分数为5/8，它是一个中等复杂的
13和21很是复杂。

这里的复杂性包括开发和测试工做。

为了肯定一个故事点，头脑风暴发生在Scrum团队中，团队共同决定一个故事点。

开发团队可能会为特定故事提供3个故事点，由于对于他们来讲可能有3行代码更改，但测试团队给出了8个故事点，由于他们以为这个代码更改会影响更大的模块因此测试工做量会更大。不管你给出什么样的故事，你都必须证实这一点。

所以，在这种状况下，头脑风暴发生，团队集体赞成一个故事点。

不管什么时候决定故事点，请记住如下因素：

故事与其余应用程序/模块的依赖关系。
资源的技能组合。
故事的复杂性。
历史学习。
用户故事的接受标准。

若是您不了解特定故事，请不要调整大小。

每当故事大于或等于8分时，它就被分解为2个或更多故事。

11）烧掉图表

刻录图表是一个图表，显示了scrum任务的估计v / s实际工做量。

它是一种跟踪机制，经过该机制，对于特定的冲刺，跟踪平常任务以检查故事是否正在朝着完成提交的故事点的方向前进。

示例：要了解这一点，请查看下图：

我假设：

2周冲刺（10天）
2个实际在冲刺上工做的资源。

“故事” - >此列显示为sprint拍摄的用户故事。

“任务” - >此列显示与用户素材关联的任务列表。

“努力” - >此栏显示了努力。如今，这项措施是完成任务的总工做量。它没有描述任何特定我的的努力。

“第1天 - 第10天” - >此列显示完成故事的剩余时间。请注意，小时不是已经完成的小时，但仍然是剩下的小时数。

“估计的努力” - >是努力的总和。对于“开始”，它只是整个单独任务的总和：SUM（C5：C15）

必须在1天内完成的总工做量是70/10 = 7.所以在第1天结束时，努力应该减小到70 - 7 = 63.以相似的方式，计算全部的直至第10天，估计的努力量应为0（第16行）

“实际努力” - >顾名思义，其实是完成故事的努力。也可能发生实际努力增长或减小的估计值。

您可使用内置函数和Excel中的图表来建立此燃尽图表。

刻录图表步骤将是：

输入全部故事（A5列 - A15列）。
输入全部任务（B5 - B15列）。
输入天数（第1天 - 第10天）。
输入起动工做（总结任务C5 - C15）。
应用公式计算天天（第1天至第10天）的“估计工做量”。在D15（C16- $ C $ 16/10）输入公式并将其拖动一成天。
对于每一天，输入实际的努力。在D17（SUM（D5：D15））输入公式，用于总结剩余的实际工做量，并将其拖动到全部其余日期。
选择它并按以下方式建立图表：

12）速度

Scrum团队在sprint中归档的故事点总数称为Velocity。Scrum团队经过其速度来判断或引用。话虽如此，但应该记住，这里的目标不是达到最大的故事点，而是要得到高质量的交付，尊重Scrum团队的温馨程度。

例如：对于特定冲刺：用户故事总数为8，故事点以下所示。

因此这里的速度将是故事点的总和= 30

完成的定义：

当全部故事都完成后，Sprint被标记为完成，全部开发，研究，QA任务都标记为“已完成”，全部错误都是固定关闭的，不然能够在之后完成（如不彻底相关或不过重要）在备份日志中提取并添加代码审查和单元测试，估计的小时数已经达到了任务中的实际小时数，最重要的是，已经向PO和利益相关者提供了成功的演示。

在SCRUM方法论中完成的活动

＃1）规划会议

计划会议是Sprint的起点。这是整个Scrum团队汇集的会议，SCRUM Master根据产品积压和团队头脑风暴的优先级选择用户故事。

根据讨论，Scrum团队根据Fibonacci系列决定故事的复杂程度并根据其进行调整。团队肯定任务以及完成用户故事实施所需的工做（以小时为单位）。

不少时候，计划会议以前都是“预先计划会议”。这就像scrum团队在参加正式计划会议以前所作的一项功课。团队试图在计划会议中写下他们想要讨论的依赖关系或其余因素。

＃2）执行Sprint任务

顾名思义，这些是scrum团队完成任务并将用户故事带入“完成”状态所作的实际工做。

＃3）每日站立

在冲刺周期中，scrum团队天天都会遇到，不超过15分钟（多是一个直接的电话，建议在一天开始时）和状态3点：

昨天团队成员作了什么？
团队成员今天计划作什么？
任何障碍（障碍）？

促进此次会议的是Scrum大师。若是任何团队成员遇到任何困难，scrum master会跟进以解决问题。在Stand ups中，董事会也会进行审核，并自行显示团队的进展状况。

＃4）审核会议

在每一个sprint周期结束时，SCRUM团队再次会面并向产品全部者演示实现的用户故事。产品全部者能够根据其验收标准交叉验证故事。Scrum大师再次负责主持此次会议。

一样在SCRUM工具中，Sprint关闭，任务标记完成。

＃5）回顾会议

回顾会议在审议会议以后召开。

SCRUM团队会见，讨论并记录如下几点：

Sprint（最佳实践）期间进展顺利？
什么在Sprint中表现不佳？
获得教训
行动项目。

Scrum团队应该继续遵循最佳实践，忽略“不是最佳实践”，并在随后的冲刺中实施经验教训。回顾会议有助于实施SCRUM流程的持续改进。

流程如何完成？一个例子！

阅读了SCRUM的技术术语。让我试着用一个例子来演示整个过程。

例：

步骤1：让咱们拥有一个由9人组成的SCRUM团队，其中包括1个产品全部者，1个Scrum master，2个测试人员，4个开发人员和1个DBA。

步骤2：Sprint决定遵循4周的周期。因此咱们从6月5日到 7 月4 日开始为期一个月的Sprint 。

步骤3：产品全部者在产品待办事项中具备优先级的用户故事列表。

步骤＃4： 团队决定于 6月4 日举行“预先规划”会议。

产品全部者从产品积压中获取1个故事，描述它并留给团队进行头脑风暴。
整个团队直接与产品全部者讨论并进行沟通，以便清楚地了解用户故事。
以相似的方式，采用各类其余用户故事。若是可能的话，团队也能够继续调整故事的大小。

在全部讨论以后，我的团队成员回到他们的工做站和

肯定每一个故事的各自任务。
计算他们将要工做的确切小时数。让咱们来看看会员如何结束这些时间。

总工做小时数= 9
减1小时休息，减1小时会议，减去1小时电子邮件，讨论，故障排除等
因此实际工做时间= 6.Sprint
期间的总工做天数= 21天。
总可用小时数= 21 * 6 = 126.
该成员休假2天= 12小时（每一个成员有所不一样，有些可能请假，有些可能不休。）
实际小时数= 126 - 12 = 114小时。

这意味着该成员实际上能够在此sprint中使用114小时。因此他将打破他的我的冲刺任务，总共达到114小时。

第五步： 6月5 日，整个Scrum团队召开“规划会议”。

产品待办事项中的用户故事的最终判决已完成，故事将移至Sprint Backlog。
对于每一个故事，每一个团队成员都会声明他们肯定的任务，若是须要，他们能够讨论这些任务，能够调整大小或调整大小（请记住Fibonacci系列!!）。
Scrum主人或团队在工具中输入他们各自的任务以及每一个故事的小时数。
完成全部故过后，Scrum主人注意到了最初的Velocity并正式启动了Sprint。

步骤＃6：Sprint启动后，根据分配的任务，每一个团队成员开始处理这些任务。

第7步：团队天天开会15分钟并讨论3件事：

他们昨天作了什么？
他们今天打算作什么？
任何障碍（障碍）？

步骤＃8：Scrum master在“Burn down chart”的帮助下天天跟踪进度。

步骤＃9：若是遇到任何障碍，Scrum主管会跟进解决这些问题。

步骤＃10： 7 月4 日，团队再次召开审查会议。成员向产品全部者演示实现的用户故事。

步骤＃11： 7 月5 日，团队再次召开会议，讨论回顾

什么进展顺利？
什么不顺利？
行动项目。

步骤＃12： 7 月6 日，团队再次召开下一次冲刺的预先计划会议，并继续进行循环。