序
迭代开发基本需求
- 迭代要有固定时长（被称为“时间盒——timebox”），不能超过六个星期。
- 在每一次迭代的结尾，代码都必须经过QA的测试，能够正常工作。
Nokia的Scrum标准
- Scrum团队必须要有产品负责人，而且团队都清楚这个人是谁。
- 产品负责人必须要有产品Backlog，其中包括团队对它进行的估算。
- 团队必须要有燃尽图，而且要了解他们自己的生产率。
- 在一个Sprint中，外人不能干涉团队的工作。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
简介&名词解释
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
敏捷宣言遵循的原则
我们遵循以下原则：
我们最重要的目标，是通过持续不断地
及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，
相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，
项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是
面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于Scrum和XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。
什么是Scrum？
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。
Scrum开发流程中的三大角色
-
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
-
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
-
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
Scrum流程图
下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。
下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。
什么是Sprint？
Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。
如何进行Scrum开发？
我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
Scrum Team根据Product Backlog列表，做工作量的预估和安排；
有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
下面是运用Scrum开发流程中的一些场景图：
上图是一个 Product Backlog 的示例。
上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。
怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...
编写产品BACKLOG
至少要包含以下要素：
- ID
- Name
- Importance
- Initial estimate
对于工作量的估算，最小单位是故事点(story point)，相当于人天(man-day)。 - How to demo
如何在Sprint上面演示 - Notes
准备SPRINT计划
检查清单：
backlog必须存在
backlog重要性评分
产品负责人理解每个故事的含义
制定SPRINT计划
Sprint计划会议的成果：
- sprint目标。
- 团队成员名单（以及他们的投入程度，如果不是100%的话）。
- sprint backlog（即sprint中包括的故事列表）。
- 确定好sprint演示日期。
- 确定好时间地点，供举行每日scrum会议。
内部质量和外部质量
外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。
内部质量一般指用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
最佳的sprint长度是三个星期
团队怎样决定把那些故事放到Sprint里面？
- 本能反应
就是根据直觉选择 - 生产率估算
第一步，得出估算生产率，第二步，在计算不超出估算生产率的情况下可以加入多少故事。
使用计划纸牌做时间估算
核心是让每个人都进行思考而且估算，在每个人给出不同的估算值之后，讨论交流得出合适的估算结果。
我们怎样编写SPRINT BACKLOG
任务板
所有任务都开始贴在左侧，然后随着每个任务的完成进度，任务会移动到右侧。每天可以手动描出燃尽图中的一个点，然后手动绘制出任务完成的曲线。
燃尽图
虚线代表的是估算完成率，实线代表实际完成率。如果完成率过快，或者过半，就要考虑增加或者减少任务数量
我们怎样做SPRINT回顾
回顾是sprint中第二重要的事情，因为它是做改进的最佳时机。
我们怎样组合使用Scrum和XP
结对编程
- 结对编程可以提高代码质量
- 结对编程可以让团队的精力更加集中
- 结对编程令人精疲力竭，不能全天都这样做。
- 常常更换结对是有好处的。
- 结对编程可以增进团队间的知识传播。速度快到令人难以想象。
- 可以把代码审查作为结对编程的替代方案。
- “领航员”（不用键盘的家伙）应该自己也有一台机器。不是用来开发，而是在需要的时候稍稍做一些探索尝试、当“司机”（使用键盘的家伙）、遇到难题的时候查看文档，等等。
- 不要强制大家使用结对编程。鼓励他们，提供合适的工具，让他们按照自己的节奏去尝试。
测试驱动开发(TDD)
- 测试驱动开发意味着你要先写一个自动测试，然后编写恰好够用的代码，让它通过这个测试，接着对代码进行重构，主要是提高它的可读性和消除重复。整理一下，然后继续。
增量设计
- 这表示一开始就应该保持设计简单化，然后不断进行改进；而不是一开始努力保证它的正确性，然后就冻结它，不再改变。
持续集成
代码集体所有权
充满信息的工作空间
代码标准
可持续的开发速度/精力充沛的工作
- 很多有关敏捷软件开发的书都声称：加班工作在软件开发中会降低生产率。
- 经过几次不情愿的试验之后，我完全拥护这种说法！
我们怎样做测试
这是最难的部分
进行验收测试
- 把验收测试阶段缩到最短
- 把测试人员放到Scrum团队来提高质量
- 在每个sprint中少做工作来提高质量
Sprint周期 vs. 验收测试周期
问题是如何协调在新的sprint周期中修复旧的sprint bug
方案一：在旧版本可以产品化之前，不构建新的特性
方案二：可以开始构建新的东西，但是要给“将旧功能产品化”分配更高的优先级
方案三：只关注新的东西
方案一最慢，而且不一定可靠，因为即使产品化了旧的功能，仍然会存在bug，问题没有解决。方案三忽略bug会让用户发疯的。只有方案二是合理的选择。
参考文章
- 《硝烟中的SCRUM和XP》
- 敏捷开发之SCRUM扫盲篇
