敏捷开发由来
2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪 鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一 份简明扼要的《敏捷宣言》传递给世界，同时即宣告了敏捷开发运动的开始。
《敏捷宣言》
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
敏捷开发模式
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善.
敏捷开发，相对传统软件开发模式，它主要是针对快速变化的需求，不断优化管理流程，最终推出优质软件.
敏捷开发的宣言
一：个体及交互比流程与工具更具价值
二：可用的软件比冗长的文档更有价值
三：与客户的协作比合同谈判更有价值
四：对变化的响应比遵循计划更有价值
5个价值
1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重
Scrum的重要名词
Backlog - 可以预知的任务集，包括功能性的和非功能性的所有任务。
Sprint - 一次迭代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的Backlog。
Product Owner - 这个角色被称为产品经理。他负责定义产品并向开发团队提出需求，最终验收开发团队的工作成果。
Scrum Master - 负责监督整个Scrum进程、修订计划的一个团队成员。 研发项目管理经理 流程经理 敏捷教练 开发主管
Sprint planning meeting - 在启动每个Sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：Product Owner和团队成员将Backlog分解成小的功能模块（即任务），决定在即将进行的Sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。
Daily scrum meeting - 开发团队成员参加，一般为15分钟。每个开发成员需要向Scrum Master汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting - 在每个Sprint结束后，将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting - 对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。
PBI Product Backlog Item 产品待办清单条目,简称PBI
敏捷开发成员架构
Scrum Master
负责管理Scrum流程， 确保Scrum正常运转。Scrum Master是教练， 是牧羊犬，是Scrum项目秩序的维护者。
· 负责监督整个Scrum项目进程，调整项目计划
· 确保开发团队成员的能力能够胜任产品的开发；
· 促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；
· 保证开发团队不受外力的干扰和阻挠；
· 掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
· Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当
产品负责人 Product Owner
负责管理产品Backlog 并使游戏项目价值最大化，代表项目的全体利益相关者。
Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任，他的主要工作是根据市场需求，确定产品的功能，列入Product Backlog中，并为这些功能确定优先级别。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，增加某些功能需求、删除某些功能需求、修改优先级等等，但这些行为只能在各个Sprint之间进行
团队
团队是负责开发软件的跨职能小组。团队是自我管理的，在Scrum Master 的帮助下，团队提出承诺，完成自己的承诺，实现软件价值。
一般由5-10个能全职工作的成员组成较为理想；团队成员横跨各个职能，通常包含开发，测试，文档设计人员等等。
敏捷开发团队原则
最大的分歧
最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一 些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工 作，而且有能力承担他们面前的任务。
发现中立点
团队决定作为一个团队需要做什么，如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色（如，软件测试员或开发员）来定义自己。所以找到一个中立点，列出了小型离线会议，和每周工作之外的小时集体活动所需的事项。
正确执行应用程序
团队找到了让自己感到舒服的新水平。整个项目的工作流程顺利进行，只做一个待办的事情，而不是四个。
Scrum过程简单介绍
1 将整个产品的Backlog分解成若干Sprint Backlog，每个Sprint Backlog是按照目前的人力物力条件可以完成的。
2 召开Sprint planning meeting，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。
3 进入Sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4 整个Sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner。
5 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6 周而复始，按照同样的步骤进行下一次Sprint。
敏捷开发流程
敏捷开发模型流程图
从敏捷开发流程模型图当中可以看出，在敏捷实施过程当中，有四种会议，分别是计划会，每日站会，回顾会，评审会，其中数计划会最为重要。 在敏捷开发模式中，每种会议都有其特殊的职责和使命，不同的会议上所讨论的内容是不一致的，只要把握住会议的关键点，就可以为团队的敏捷模式服务。
Sprint Planning敏捷迭代计划会议
1 Sprint Planning敏捷迭代计划会议
在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。
敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；
计划会议的目标：
1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；
2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；
阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。
会议时长：1-4小时
一般参考进程安排如下：
1、Scrum Master公开迭代时间表；
2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；
3、团队针对Sprint Backlog和优先级达成一致；
4、Scrum Master和团队成员共同确定Sprint Backlog；
阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加
会议时长：1-4小时
一般参考进程安排如下：
1、团队成员针对Sprint Backlog共同分解任务；
2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；
3、团队成员共同认领任务；
4、共同确定DoD，团队达成一致；
5、团队共同确认迭代目标和价值；
如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。
一个典型的Sprint计划会议时间表
Sprint 计划会议：13:00 – 17:00 （建议每小时休息10分钟）
13:00 – 13:30 产品负责人对Sprint目标进行总体介绍，概括产品Backlog。定下演示的时间地点。
13:30 – 15:00 团队估算时间，在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。
16:00 – 17:00 为每日Scrum会议（简称每日例会）安排固定的时间地点——如果和上次不同的话。
Sprint应该多长才好？
时间短就好。公司会因此而变得“敏捷”，有利于随机应变。
短的Sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈 = 在错误方向上花的时间更少 = 学习和改进的速度更快
绘制任务版
任务版中的任务是分解到手头的实际的工作
把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.
开发人员选择任务帖在规定时间内完成任务
敏捷开发遇到的扑克牌（ 计划纸牌 ）
每个人都会得到如上图所示的13张卡片。在估算故事（任务）的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。
如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。
2 Daily Stand-up Meeting每日站会
团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：
1) 昨天我做了什么
2) 今天我计划要做什么
3) 我遇到了什么问题，妨碍了我尽可能有效地工作
Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。
3 Sprint Review 敏捷迭代评审会议
在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog
参与人员：产品经理、Product Owner、Scrum Master、团队所有成员
会议时长：1-4小时，视演示内容而定
主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。
由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。
4 Sprint Retrospective 敏捷迭代回顾会议
在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：
1) 本次迭代有哪些做得好；
2) 本次迭代我们在哪些方面还能做得更好；
3) 我们在下次迭代准备在哪些方面改进；
团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
参与人员：Scrum Master，Product Owner，团队成员。
会议时长：0.5-1.5小时
主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。
Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。
案例分析
案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解 决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨 会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。
问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。
案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。
问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个 人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。
在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起来。
【济南中心】就业面试技巧系列（持续更新中...）
(出处: 黑马程序员IT技术论坛)
【济南校区】Android/php/JavaEE课程笔记同步+面试技巧同步更新
(出处: 黑马程序员IT技术论坛)
收藏
淘帖
踩
