scrum敏捷为目前敏捷框架中的一种使用最多，最流行的框架。
一、scrum敏捷开发
Sprint是受时间盒限制的，无论工作完成与否都会在特定日期结束，并且不延长。
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。每个迭代不超过4周（通常2周），并且无间歇地相继进行。
在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。
Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。
在scrum敏捷开发中，项目被分为很多个sprint迭代增量的进行。以下为一个sprint的过程。两个图表达的内容是一致的，表达方式有些不同。
二、scrum中5个重要的会议
适合团队的就是最好的，以下为个人理解并整理的5个会议的输入输出、人员、时长、召开阶段、内容。可能会有所误差。
在每个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择。团队对于在Sprint结尾他们可以交付哪些目标达成一致意见，这些交付应该是有形的并且能被真正“完成”的。
1、产品待办事项列表梳理会议（Release Planning）
产品待办事项列表存在（并演化）于产品的整个生命周期，它是产品的路线图。
当一个团体计划向Scrum过渡时，在首个Sprint可以开始之前，他们需要有一个（按1、2、3顺序）排好优先级的、以客户为中心的特性列表，即产品待办事项列表。
2、sprint计划会议（Sprint Planning）
这是一个为Sprint做准备的会议，通常分成两部分（第一部分关于“做什么”，第二部分关 于“怎么做”）。
在Sprint计划会议第一部分中，产品负责人和团队审视产品待办事项列表中产品负责人有兴趣在这个Sprint中实现的那些高优先级的事项。通常，这些事项应当已经在前一个Sprint中（的产品待办事项列表梳理会议里）被很好地分析过了，因此在这个会上只有较少的需要在最后时刻澄清的问题。
Sprint计划会议第二部分关注于如何实现团队决定要开始做的那些事项。团队预期他们在Sprint结尾能够完成多少事项，从产品待办事项列表的顶部开始（换句话说，就是从对于产品负责人来讲最高优先级的事项开始），并依次查看事项。以下是Scrum中的关键实践：由团队决定将完成多少工作，而不是由产品负责人分配给他们。因为团队是基于他们自己的分析和计划，这使得预期更可靠。
Scrum的支柱之一是，一旦团队设置了Sprint的目标，任何增加或者改动都只能推迟到下个Sprint。这意味着如果在Sprint的中间产品负责人希望团队进行一个新的事项工作，直到下个Sprint之前他将不能做出这个改动。如果有外部环境情况的出现严重地改变了优先级，并使得团队继续工作下去变成浪费时间，那么产品负责人或者团队可以终止这个Sprint。团队停下来，开始新的Sprint的Sprint计划会议。这么做所带来的破坏通常是有好处的，它抑制了产品负责人和团队诉诸于这种戏剧性变化的动机。
3、每日站立会议（Dailly Scrum）
团队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。
有人要把这些阻碍记录下来，ScrumMaster负责帮助团队成员解决它们。在每日Scrum会议中只有很少或不会有深入的讨论，其形式只是做回答那三个问题的报告。如果的确需要讨论，那么在每日Scrum会议后马上就会有一个或多个并行的跟进会议，但在Scrum中没要求任何人必须参加这些会议。
4、评审会议（Sprint Review）
Sprint评审会议，人们会评审这个Sprint。出席会议的人有产品负责人、团队成员以及ScrumMaster，再加上客户、利益相关人、专家、领导层和任何有兴趣的人。对于两周的Sprint来讲最长为两个小时。任何参与者都可以问问题和提意见。
在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint中的反馈。
5、回顾会议（Sprint Retrospective）
针对流程和环境进行审视并调整。
Sprint之间没有间歇期，团队通常在某个下午开Sprint回顾会议，第二天早上就直接进入下一个Sprint计划会议（不包括周末休息）。敏捷开发的一个原则是“可持续的步伐”，团队只有保持合理水平的常规工作时间才可以一直继续这一周期。生产力随着团队实践的演变和铲除影响团队生产力的障碍而增长，而不是通过加班加点或降低质量来取得。
