软件开发模式

瀑布式开发

在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等， 瀑布式开发最早强调系统开发应有完整的周期，且 必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源投入等。

优缺点

@有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。这种开发模式比较适合硬件、结构开发，一旦确定无法重新再来。

@开发过程一般不能逆转，否则代价太大；
实际的项目开发很难严格按该模型进行；
客户往往很难清楚地给出所有的需求，而该模型却要求如此。
软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。

使用场景

: 硬件开发、结构开发、整车零部件等不易重试的工作

螺旋模型

瀑布模型+快速原型模型，引入了项目风险分析，这种模型比较适合开发复杂的大型软件。

第一，制定计划：确定软件目标，选定实施方案，明确项目开发的限制条件；
第二，风险分析：分析所选方案，识别风险，通过原型消除风险；
第三，开发实施：实施软件开发；
第四，客户评估：评价开发工作，提出修正建议，建立下一个周期的计划。

优缺点

@实质上相当于在瀑布模型的每个阶段开始前引入风险分析，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；由于引入风险分析等活动，测试活动的确定性增强了；螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视。

@主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟糕。

迭代式开发

在迭代开发中，整个开发工作被组织为一系列的短小的，固定的长度(如2-6周)的小项目，被称为一系列的迭代，每一次迭代都包括了定义、需求分析、设计、实现与测试。

采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或者业务逻辑的开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代.。

优缺点

• 降低了在一个增量上的开发风险，如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费
• 降低了产品无法按照既定进度进入市场的风险，通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙
• 加快了整个开发工作的进度，因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
• 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，因此，迭代过程这种模式使适应需求的变化会更容易些。
  ———————————————————————————————————————————
• 初期产品用户规模小，性能并不是主要瓶颈
• 团队里面没有优秀的架构师，优化力不从心。
• 后端架构优化是个慢活，它不像产品功能层面的迭代那样可以快速被感知，对于强产品驱动而非强技术驱动的公司来说，不够重视。
• 后端架构优化更是个细活，它也不像产品功能一样有很明显的“产出”，对于不懂技术的领导或者以KPI为导向的公司文化来说，员工去优化后端的意愿并不强烈。
• 产品交付进度压力比较大，没有时间去思考架构的优化，精力都在聚焦怎么实现功能上面

敏捷开发

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级，完善产品

优缺点

• 敏捷确实使得项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品，敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

• 但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。

历史演进

概述

敏捷软件开发是基于敏捷宣言定义的价值观《敏捷软件开发宣言》和原则《敏捷软件的十二条原则》的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案，换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。

在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件，这份文件基本上代表了不同敏捷方法论的共同点。
当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。

参与者们分享了互相竞争的几种方式：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM），所有这些方式都是“轻量版”的框架，因为这些方法使用更少，更简单的规则来适应快速变化的环境，不少与会者都觉得“轻量”这个术语非常适用。

经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile 一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：敏捷宣言。

参会者将自己命名为“敏捷联盟（ The Agile Alliance ）”，希望能够帮助软件行业中的其他人以新的、更敏捷的方式思考软件开发、方法和组织。 而“敏捷宣言”则被展示在一个网站上（ https://agilemanifesto.org/ ） ，到目前已被翻译成了60多种语言，并作为一种信仰被推广至全球以及非软件行业。

敏捷解读

• 个体和互动 高于 流程和工具；（个体与交互：团队各个成员的能力与团队间的沟通）
• 工作的软件 高于 详尽的文档；(以结果为导向）
• 客户合作 高于 合同谈判；（注重客户参与）
• 响应变化 高于 遵循计划；( 敏捷 要求有开放的工作环境，确保团队及时高效地进行沟通）
• 也就是说，尽管右项有价值，我们更重视左项的价值。

敏捷价值观

个体和互动高于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。
虽然，过程和工具都是好东西，但是它们有时也会成为障碍，面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多，当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

工作的软件高于详尽的文档

可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文档)为客户传递了高价值
一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的，但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的，敏捷通过寻求“刚好足够”的文档来避免这种情况，其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

客户合作高于合同谈判

这对价值观的核心是越接近你的客户越好。
客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误，在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的，定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

响应变化高于遵循计划

任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。
即使底层的技术也在快速变化，新的途径和可能性在不断的被打开，对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。

敏捷准则

• 目的：是客户满意
  我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户
  敏捷团队可以很快将可用软件交付到客户手中，并且是开放式地快速更新，给客户带来优先级最高地价值
• 态度：欢迎需求变更
  欢迎对需求提出变更——即使是在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势
  传统项目管理中地一个原则是设法去影响和控制会导致变化地因素，敏捷项目管理预期到需求会发生变化，并在实际过程中欢迎拥抱这些变化，即使这些变化发生在项目后期，迅速应对和适应变化能给客户带来显著地竞争优势，从而应对新的机遇。
• 关注：客户需求的软件
  要不断交付可用的软件，周期从几周到几个月不等，且越短越好
  不同的敏捷方法论采用不同的迭代周期，但都是相对较短的，关键是能快速把可用的软件交付到客户手上并能利用软件获得有意义的回报，较短的迭代周期为团队提供架构并强化团队持续关注客户的价值。
• 合作：打破隔阂
  项目过程中，业务人员与开发人员必须在一起工作
  敏捷项目管理，让业务人员和开发人员彼此靠近，并时常让他们在同一个地方一起工作，通过这样的方式让业务人员和开发人员之间没有隔阂，是因为业务人员和开发人员的共同目标就是通过可用的软件向客户传递价值。
• 核心：团队成员
  要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
  传统项目管理，常对员工进行微观管理，不仅告诉他们要做什么，还告诉他们如何做，无意间形成自上而下的管理方式，敏捷项目建立了一支强有力的团队并积极避免微观管理，要求一个自律的团队，自发告知开发人员做什么，提供相关资源，给予鼓励，相信团队能够完成任务。
• 沟通：面对面
  无论是团队内还是团队间，最有效的沟通方法是面对面的交谈
  非正式口头的沟通在敏捷项目管理中远比正式的书面沟通更普遍，其想法是两个人坐在一起为一个解决方案努力会比他们用邮件来来往往或交换文件更有效率，面对面沟通是敏捷项目管理的精髓，这种沟通是公开的，任何团队成员都可以自由参与对话。
• 标准：可工作的软件
  可用的软件是衡量进度的主要指标
  计划和文档可能是有用的，但是当最根本的目标发生变化时，它们就可能失去应有的价值，传统项目往往极其纠结的是，项目的不断更新使得文档成为一种负担，真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的。
• 倡导：可持续开发
  敏捷过程提倡可持续的开发，项目方、开发人员和用户应该能够保持恒久稳定的进展速度
  可持续开发的焦点是在团队身上，他们会努力保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工，理想的目标是保持一种可持续的速度，使团队成员不会感到过度的压力和筋疲力尽，而是能够保持在一个理想的强度下工作。
• 追求：技术卓越和技术良好
  对技术的精益求精以及对设计的不断完善将提升敏捷性
  设计的越完善，维护起来就越简单，即使遇到变化，稳定和优质的项目会比劣质的项目更加允许团队快速应对变化
• 根本：简洁
• 要做到简洁，即尽最大可能减少不必要的工作，这是一门艺术
  这个被所有的敏捷方法所拥护，尤其使精益方法，关键点对客户价值保持关注和毫无犹豫的削减不增加价值的活动，保持简单不只是一种愿望，它使最基本的原则。
• 团队：自组织
  最佳的架构、需求和设计出自自我组织的团队
  自我组织是敏捷团队的核心元素之一，当一个团队是自我组织型的时候，说明该团队自己去决定工作如何分配及谁去做某个特定的工作，而不是人力资源部门或管理层来决定，不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的
• 调整：定期反思
  团队要定期反省如何能够做到更有效，并相应的调整团队的行为
  敏捷项目中最可预见的事情就是变更，传统项目里当项目或阶段完成时开会总结是最常见的做法，而敏捷试着通过更频繁的回顾来完成这项工作，在一个回顾活动中，团队查看各迭代周期中已完成的工作或发布，并评估下一次如何改进他们的做法，每日站立会议即每天简单碰头15分钟是另一项协调团队努力方向、团队自我评定和自我调整的重要方式。

敏捷优缺点

敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价值，减少麻烦，敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作，需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。
优点：

• 更快交付价值
  敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。
• 更低的风险
  敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险，即使这个项目失败了，这个失败的代价相对来说小一些。
• 拥抱变化
  因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力，而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
• 好的质量
  每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准等等，同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
• 持续改进
  敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会，另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
• 更高的客户满意度
  敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。
• 更高的团队满意度
  敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍，重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理，更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；
  团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作，通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，“A happy employee is a productive employee”，不是吗？
• 更大的灵活性
  敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等，另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等，还有，验收标准，都可以根据实际情况进行调整。
  缺点
• 很难进行准确的资源规划
  由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
• 很难准确的定义“轻量的“或必要的文档
  敏捷倡导的是用工作的软件即文档**（核心是代码即文档）**。
  整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的，因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）
• 很难把握整体产品的一致性
  增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点
  因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体
• 很难预测有限的终点
  敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向，此外，这意味着项目没有限定的终点，因为从来没有一个明确的 "最终的产品"样子。
• 很难有效地进行度量
  由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看，而 "边走边看 "的特性意味着你不能在项目开始时设置很多KPI，这种长期的游戏使得衡量进度变得相对困难。

敏捷开发现状

• 利益相关者
  敏捷开发保证了项目中所有利益相关者的利益，不论是客户、项目管理、开发团队或测试小组。
  每个人对项目都有清晰的可见性，这是成功的关键点所在，敏捷开发原则上鼓励用户积极地参与，不论是产品开发，或是团体协同的方方面面。这对关键利益相关者提供了非常好的可见性，包括项目的进度或是产品本身，最终这有利于保证产品预期的效果。
• 高效的团队
  Aglie团队是自发组织的，这意味着他们有权利和责任去审核生产所有者直接干预的工作。
  这与大多数non-agile项目不同，项目管理者有责任给团队分配任务，或者甚至是团队成员，这给予团队一种自主感，提高团队士气，最终增加生产率。
• 市场速度
  由于传播速度快，我们能更快地响应市场，因此有更高收入
  这一切增加客户满意度的关键因素是敏捷应用开发。
• 质量
  在项目中梦寐以求的代名词是质量。
  不像传统的瀑布模型，等到开发完成才开始测试，可是在敏捷开发中，我们随着需求的准备便开始进行测试。因此，测试集成贯穿整个开发周期，使得工作产品像开发一样去定期检查。这允许工作所有者有必要时做出适当调整，以及及早的给产品团队检查出任何质量问题。
• 能力提升
  实践敏捷最好的一点就是它很有趣味
  整个团队都积极的参与，使得整个工作空间和氛围均因为这种积极参与和互相之间的协作配合而变得更有意思。有很多有趣的方式比如用计划扑克牌游戏和卡片来评估任务，采用生动新颖的任务面板来讨论工作的进展， 用全新的方式来管控例会以及许多敏捷项目中其他更有趣的东西。据我的经验，这是对每一个人都能受益的方法。

敏捷开发方法

SCRUM是一种迭代的增量化过程，用于产品开发或工作管理，是团队合作开发产品的一种方式，而需求在开发过程中会快速变化。（迭代周期2-4周）
使用Scrum进行产品开发时，会分成几小块，每块都基于先前创建的块，一次只制造一小块产品就可以鼓励创造力，并使团队能够响应反馈和变更，从而准确而准确地构建所需的产品，与XP不同，Scrum方法包括管理和开发过程。

XP（极限编程）

XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。（迭代1-2周）
它提倡在较短的开发周期中频繁地“发布”，每个发布都伴随着几次迭代， 当产品发布具有足够的功能以满足用户需求时，团队将终止迭代周期并发布软件。极限编程的其他元素包括：结对编程，持续集成，仅添加特定版本所需的功能。
用户编写故事，可以帮助团队估计构建发布和定义验收测试的时间， XP团队的一部分用户在构建软件时增加了详细要求。 这使需求随着用户和开发人员定义产品的外观而发展。

Scrum

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

Scrum概览

Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”，在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。
在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。
在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)，产品负责人会逐一挑选最高优先级的部分进行讲解，团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和，一旦迭代开始，这些任务将不会发生大的变化
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈，当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。
经验主义主张知识源于经验, 以及基于已知的东西做决定，Scrum 采用迭代、增量的方法来优化可预见性并控制风险，Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。

透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明，管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容，也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差，在确定检验频率时，需要考虑到检验会引起所有过程发生变化，当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题，幸运的是，软件开发并不会出现这种情况，另一个因素就是检验工作成果人员的技能水平和积极性。

适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整，调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应

• 每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；
• Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；
• Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

三个角色

产品负责人（Product Owner）

Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果

职责

• 与客户沟通、确定客户正在意图、产品交付日期等
• 与团队沟通、共同确定需求
• 考虑团队的研发实力

人选

• 部门经理、产品经理、策划人员等都可能做产品负责人。
• 产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
• 大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。

流程管理员（Scrum Master）

Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

职责

• 负责整个Scrum流程在项目中顺利实施和进行
• 没有行政权力
• 不帮团队做决定、但是可以提出建议

人选

• Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
• 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
• 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。

开发团队（Scrum Team）

Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标

• 负责整个Scrum流程在项目中顺利实施和进行和自组织的开发团队
• 一般5~10人
• 跨职能团队（业务分析师、程序员、测试人员、架构师、数据库设计师）

三个工件

产品待办列表（Product Backlog）

产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。

产品待办列表是一份有序列表，其中包含产品需要的一切可能的东西，也是产品需求变 动的唯一来源，产品负责人负责管理产品待办列表的内容、可用性和排序。

• 功能、缺陷、增强等都可以是待开发项。
• 一般以条目化的方式描述。
• 客户和用户必须能够理解。
• 描述怎样使用而非怎样制造。
• 整体上从客户价值优先级排序。
• 总工作量一般需要0.5～10人天。
• 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

Sprint待办列表（Sprint Backlog）

冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务

Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划，Sprint 待办列表是开发团队对于下一个产品增量所需的那 些功能以 及交付那些功能到"完成"的增量中所需工作的预测

• 在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
• 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。

增量

产品增量是在Sprint内开发团队交付的所有产品待办列表条目的综合，增量必须是符合团队定义的"完成的定义"（Definition of Done）

五个事件

Sprint
也翻译做冲刺，是Scrum的核心，也是一个容器
Sprint是一个时间盒（固定的开始和结束时间），下一个Sprint会紧随上一个Sprint，在这之间没有停顿。Sprint由Sprint计划、每日例会、Sprint执行、Sprint评审及Sprint回顾组成。

Sprint计划
一个Sprint中准备做的所有工作是在Sprint计划会议中完成的。
这份计划是整个团队（产品负责人、Scrum Master和开发团队）共同完成的

目的
Sprint计划最主要完成两件事情：

• 在这个Sprint中要完成什么产品待办列表条目？（What）
• 如何完成这些条目？（How）

流程

• 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
• 产品负责人逐条讲解最重要的产品功能。
• 开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
• 产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。

每日站会
开发团队15分钟同步进度并每日调整的一个事件
在每日站会上，每个团队成员回答以下三个问题（基本的，可以根据情况增加新问题）

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么?
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?

流程

• 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
• 团队内部利用每日立会来沟通进度。
• 开发团队利用燃尽图来展示整体进度。
• 如无特殊原因，迭代期内无变更。

Sprint评审
在Sprint快结束时，Scrum团队在一起检视所交付的产品增量，并调整产品待办列表
Sprint评审不是Sprint演示、也不叫做Sprint demo，一定要包括收集反馈和调整的环节

流程

• 小组向产品负责人展示迭代工作结果。
• 产品负责人给出评价和反馈。
• 以用户故事是否能成功交付来评价任务完成情况。

Sprint回顾
Scrum团队检视和调整工作方法、流程，持续改进的事件

目的
Sprint回顾的主要目的是

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何
• 找出并加以排序做得好的和潜在需要改进的主要方面
• 制定改进 Scrum 团队工作方式的计划

流程

• 在每个迭代后召开简短的反思会。
• 总结哪些事情做的好，哪些事情做的不好。
• 制定改进计划。

产品待办列表梳理（Refinement）
即需求梳理会，每周Scrum团队在一起为下一个Sprint进行准备工作。

五个价值观

• 承诺 – 愿意对目标做出承诺
• 专注– 把你的心思和能力都用到你承诺的工作上去
• 开放– Scrum 把项目中的一切开放给每个人看
• 尊重– 每个人都有他独特的背景和经验
• 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

用户故事
用户故事：描述具体的需求的卡片，按作为一个……，可以……，以便……样式和思路写成的用户需求，就是用户故事
这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素，要想写好用户故事，要改变那种面向功能而非客户需求的纯技术观念。

角色

切记不要总是写“作为一个用户”，而是要把用户区别对待，这样才能更好地理解他们使用什么功能，如何使用，为何使用。

功能

即用户能亲自执行的操作，应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。

价值

是完成操作后，客户所得到的好处，价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。

敏捷日常跟进

看板

• 看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式，从形式上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。
• 故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。
  看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。

燃尽图

• 在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算，我们可以创建一个表来是使数据可视化，就是燃尽图
• 根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。

Scurm开发工具（自学）
上面我们说了Scurm框架的操作流程，下面我们看下支持Scurm开发框架的工具有哪些