敏捷代表快速响应，快速行动。敏捷开发的最高目标：通过尽早持续交付有价值的软件来满足客户的要求；尽最大可能减少不必要的工作。了解了敏捷开发就不得不了解Scrum，文章中进行了简单的描述。
敏捷开发
1. 什么是敏捷开发（Agile Development）？
a) 敏捷开发以**用户的需求**进化为核心，采用**迭代、循序渐进**的方法进行软件开发。
b) 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可
视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小
项目，并分别完成，在此过程中软件一直处于可使用状态。
简单的说，敏捷开发并不追求前期完美的设计、完美编码、而是力求在较短的周期内开发出产品的核心
功能，尽早发布可用的版本，然后在后续的生产周期内，按照需求不断迭代升级，完善产品。
2. 敏捷开发特征
-
迭代式开发（主体是时间周期）
项目按照时间周期进行迭代，比如A功能优先级比较高，则在第一个迭代周期内优先 开发A功能，并上线。第二个迭代周期开发B功能。 -
增量开发（主体是功能模块）
指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是按照新增 功能来划分迭代。增量开发加上迭代开发，才算是真正的敏捷开发。 -
开发团队和用户反馈推动产品开发
敏捷开发提倡用户参与到产品或项目开发的整个流程当中，通过用户反馈使得产品 更加符合用户频繁变动的需求。 -
持续集成
采用敏捷开发的产品在产品初期会上线基本功能，之后的功能是根据收集到的用户 反馈进行开发的，实现功能模块的持续集成。 -
开发团队自我管理
要求团队成员高效交流，以此来提高产品，项目的开发效率，开发质量。
3. 为什么要使用敏捷开发
- 3.1 覆盖快速变化的市场，用户需求，快速响应变化需求：在用户需求不断变化的情况下能够保证软件开发质量，把大的周期变成小周期。
- 3.2 早期交付，大大降低成本
- 3.3 及时了解市场需求，降低产品不适用的风险。
4. 如何进行每一次迭代
虽然敏捷开发将软件开发分成多个迭代，但是也要求，每次迭代都是一个完整的软件开发周期，必须按照软件工程的方法论，进行正规的流程管理。
每一次迭代都要依次完成五个步骤：
1) 需求分析（requirements analysis）
2) 设计（design）
3) 编码（coding）
4) 测试（testing）
5）部署和评估（deployment / evaluation）
了解了敏捷开发，接下来我们需要了解几个概念：
Scrum
字面意思是橄榄球运动员并列在一起相互快速争球，
Scrum 是通过团队合作把项目一步步的推进，这样的开发方式称为Scrum 敏捷开发。
Scrum目的是为了提高软件开发效率，小步快跑，快速的把已知的需求进行迭代产出，
为客户创造最优先可见的价值。
Scrum敏捷开发管理是最为常用的敏捷开发工具之一，其包含的内容：
-
三大角色
Product Owner 产品负责人 Scrum Master 敏捷实施负责人 Team Members 敏捷团队 -
三大物件
Product Backlog 产品需求库 Sprint Backlog 迭代需求库 Burndown Chart 燃尽图 -
四大会议
Daily standup 日常站立式会议 Sprint Plan 迭代规划 Sprint Review 迭代评审 Sprint Retrospective 迭代回顾 -
其他
Story Epic - 史诗故事集 Story Theme - 主题故事集 User Story - 用户故事 Task- 任务 Sprint - 迭代/冲刺
下面进行详细的解释
1. scrum中有三个重要的角色;
-
产品经理（product owner）
负责确定产品特性，同时产品经理会提出产品亮点。
-
scrum master
是整个团队的负责人，负责帮助团队尽其所能完成工作，组织日常会议和保障其他工作。
-
Scrum team团队成员
是由开发人员、测试人员、文案以及其他帮助研发的人组成。
Scrum来实施敏捷开发，整个项目会被分解成不同的小部分。每一个小部分都是有plan,build test review 构成。从而得到几个增量式版本，称为Sprint（冲刺）。
在Scrum中有三种常用的可视化文档：
-
1 product Backlog
产品需求列表或者产品需求库，用来收集产品所有的用户故事，并按照需求本身对用户故事的大概写法进行详细的描述。
-
2 Sprint Backlog
产品经理会先从众多用户故事（user stories）中筛选出优先项，并把它们列入产品开发列表中，需求列表会随着每次的Sprint迭代和更改。
-
3 Burndown Chart (燃尽图)
用以展示整个Sprint代办列表的进度。当燃尽图曲线接近于0时，也就意味着这次sprint即将完工→XY轴组成，Y一般代表剩余的工作量或剩余的UserStory 数等，X代表当前迭代的时间段。
补充；
User stories(用户故事）：是一种表达产品需求的语言格式。
格式为：作为一名----用户，我需要----功能，所以---能够。产品经理通过用户故事来了解需求的细节，
为Scrum团队合理制定任务优先级。最优项的用户故事将进入Sprint代办列表（sprint backlog),剩下的
继续评估优先级，交到下次Sprint中。
3. Scrum方法中有三种不同形式的会议：
-
sprint计划会议
是产品经理 Scrum Master 和开发团队碰头的会议。用于讨论用户故事并估算任务量。 -
Daily Scrum 每日例会
也就是我们熟知的站会（standup meeting),整个团队会简述工作进度，并且讨论是否 有任务需要搁置或是加派人手。 -
Sprint 回顾会议
在Sprint接近尾声时，会进行Sprint 回顾会议，此时研发团队会向产品经理演示开发 好的功能。，然后整个团队讨论是否有需要改进的地方。
Scrum之Epic 的概念和使用场景
Epic 有史诗故事级的意思，是一个比较大的User Story，在敏捷开发工具Scrum中，Epic顾名思义为史诗故事集，一个比较大的User Story，里面可包含很多小的Story。主要应用场景如下:
一个独立的模块：一个模块里会有很多小的Story，放在一个Epic里可保证这些小的用户故事的相关
性，方便上下文的理解，这种情况一般可以把一个模块建设成一个Epic。
相关故事组合的故事集：在梳理User Story时，如果存在一些先后循序和很强的干系关联性，可以
把这些用户故事放在一个Epic里，以便在研发这些故事时不影响正常的依赖关系。
第三方集成相关的需求故事：在模块或者功能开发中，会遇到很多和第三方API或者SDK进行集成，
这个时候可以把系统本身的需求和第三集成的需求放在一起合成一个Epic。
Scrum工作流程：
1 首先产品经理把那些需要上线的产品特性，做成产品需求列表（Backlog），然后由产品经理甄选出最优项，准备交给整个团队讨论。
2 召开Sprint 规划会议（Sprint planning）：研发团队、产品经理和Scrum Master 讨论用户故事优先项。并且决定下次sprint要研发的需求项。
3 根据sprint 规划会议制定Sprint 需求列表（sprint backlog），这个列表就是指经过团队讨论后的用户故事，用于下次的sprint,会议结束后，整个研发团队和产品经理必须要对每个用户故事有深刻的理解。
4 研发团队要在一到三周的时间里开发完成Sprint 列表中的需求。在sprint期间，每日站会用于团队来交流他们做完了什么，正在做什么，以及遇到的问题。
Sprint的产出是一个可以发布的产品版本。是否可发布由产品经理来决定。也可以在发布前增加新的功能。
5 在Sprint结束时会举行sprint回顾会议，由研发团队向产品经理做案例演示，同时团队可以一起反思工作中可以改进的地方。
敏捷开发工具——JIRA，下次接着聊。