敏捷开发之Scrum扫盲篇

现在敏捷开发是越来越火了，人人都在谈敏捷，人人都在学习Scrum和XP...

 

为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的朋友一起分享交流一下，希望对初学者有帮助。

 

 什么是敏捷开发？

敏捷开发(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开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

 

 

下面是运用Scrum开发流程中的一些场景图：

上图是一个 Product Backlog 的示例。

 

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。

任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

 

每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）

 

 

 上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。

怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时...

 

敏捷开发的4句宣言

个体与交互 胜过 过程与工具

可以工作的软件 胜过 面面俱到的文挡

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

敏捷开发知识体系笔记

敏捷开发知识体系整体框架

敏捷开发工程实践

项目管理

• 迭代开发
• 风险价值生命周期
• 多级项目规划
• 完整团队
• 每日站立会议
• 任务板
• 燃尽图

需求管理

• 需求订单
• 业务流程草图
• 用例驱动开发
• 用户故事

架构

• 演进的架构
• 演进的设计
• 基于组件的架构设计

开发

• 结对编程
• 测试驱动开发
• 重构
• 代码规范

测试

• 单元测试
• 并行测试
• 测试管理

变更管理

• 持续集成
• 自动构建
• 团队变更管理

敏捷开发管理实践描述

• 定义和特征说明
• 主要角色
• 主要活动和最佳实践
• 主要输入输出
• 工作流程

敏捷开发工程实践描述

• 定义和特征说明
• 应用说明
• 案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档工作的软件 高于 详尽的文档客户合作 高于 合同谈判响应变化 高于 遵循计划也就是说, 尽管右项有其价值, 我们更重视左项的价值.
1
2
3
4
5
1
2
3
4
5

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

• 以人为本
• 目标导向
• 客户为先
• 拥抱变化

敏捷开发的原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

• 产品负责人（Product Owner） 
  
  • 通常由市场部门的人担任
• 敏捷教练 (Scrum Master) 
  
  • 通常由开发组组长担任
• 开发团队 (Scrum Team) 
  
  • 包括开发,需求,测试

“鸡”角色

• 用户 
  
  • 软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”
• 利益所有者 (客户，提供商) 
  
  • 影响项目成功的人, 但只直接参与冲刺评审过程。
• 管理者 
  
  • 为产品开发团体架起环境的那个人

主要活动和最佳实践

• 迭代式软件开发
• 两层项目规划 (Two-Level Project Planning)
• 整体团队协作 (Whole Team)
• 持续集成
• 冲刺规划会议 (Sprint Plan Meeting)
• 每日站立会议 (Sprint Daily Meeting)
• 冲刺复审会议 (Sprint Review Meeting)
• 冲刺回顾会议 (Retrospective Meeting)

主要输入输出

• 产品订单(Product Backlog)
• 冲刺订单(Spring Backlog)
• 燃尽图(Burndown Chart)
• 新的功能增量

工作流程

项目管理过程

• 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
• 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

• 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
• 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
• 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
• 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
• 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

• 项目/产品愿景
• 项目/产品路线图
• 版本发布计划
• 迭代计划
• 每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

• 当前的问题
• 机会描述和理由(描述项目的重要性)
• 项目的价值
• 项目如何和组织的战略目标达成一致
• 解决方案综述
• 项目包含的关键功能
• 项目必须服从的技术和约束条件
• 项目范围
• 项目的关键时间线
• 项目收益分析
• 项目和其他项目的依赖性
• 项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

• 根据当前状态确定是否需要对版本计划做出更新
• 为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人（Product Owner）

• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的收益(profitability of the product)负责。
• 根据市场价值确定功能优先级。
• 在30天内调整功能和调整功能优先级。
• 接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

• 负责监督整个Scrum项目进程, 调整开发计划
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
• 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
• 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
• 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决
• Scrum Master需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。
• Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决.

开发团队 (Scrum Team)

• 具有不同特长的团队成员，人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
• 弱化分工, 每个人都参与设计, 开发与测试
• 确定Sprint目标和具体说明的工作成果。
• 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
• 向Product Owner演示产品功能。

团队素质完整性

• 要具备很强的集体协作精神.
• 要具备良好的沟通能力
• 必须能积极主动的接受新的事物, 要具备创新能力
• 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

• Sprint启动会
• 每日站立会议
• Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责，通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员，强调如何实现系统以及如何检验。

• 挑选用户故事
• 为故事写测试
• 实现测试
• 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

• 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
• 主要角色: ST, PO, SM
• 主要输入: Product backlog, 团队的能力
• 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

• 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
• 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
• 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
• 最高分和最低分的组员像团队做出解释
• 全组成员自由讨论几分钟
• 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

• PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
• 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
• 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

• 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
• 需求订单式开放的, 团队每个成员都可以编写和维护
• 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

• 具备可视性
• 具备风险预估, 提醒团队目前完成情况
• 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

• 我们上次开会后你都干了什么
• 在我们下次开会之前你要做什么
• 每个你负责的、正在做的任务还剩下多少时间
• 你的工作被阻碍了吗

任务板(Task board)

• 为项目团队提供一个便利的工具用于管理他们的工作
• 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码