Scrum(1) | 敏捷入门与 Scrum 计划会

敏捷项目是从计划会开始的。计划会的开展，一般需要两个小时以上，详细规定了项目的方法面面的规范，目的是选择和估算本次迭代的工作项。

1. 敏捷开发测试背景知识

1.1 Scrum过程

Scrum概览

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

Snap1.jpg

不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。

在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。

在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。

在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。

在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代中的成功与失败之处做出总结，并在以后迭代中进行改进。

两个清单
- Product Backlog
  
  产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。
  - 功能、缺陷、增强等都可以是待开发项。
  - 一般以条目化的方式描述。
  - 客户和用户必须能够理解。
  - 描述怎样使用而非怎样制造。
  - 整体上从客户价值优先级排序。
  - 总工作量一般需要0.5～10人天。
  - 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。
- Sprint Backlog
  
  冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务。
  - 在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。
  - 在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。
三个角色
- Product Owner
  
  Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。
  现实世界的产品负责人
  - 部门经理、产品经理、策划人员等都可能做产品负责人。
  - 产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。
  - 大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。
- Scrum Master
  
  Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。
  现实世界的Scrum Master
  - Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。
  - 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。
  - 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。
- The Team
  
  Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。
  现实世界的开发团队
  - 实际团队常常不是“扁平的”，而是仍有项目经理、小组长等职位。
  - 工作中他们以“共同估算”“跨职能工作”“共同跟进”等方式自组织工作，而不是完全依赖层层指令。
  - 项目经理、小组长的领导、指导、协同职能大于其指令职能。
四个仪式
- 计划会：Sprint Planning Meeting
  - 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
  - 产品负责人逐条讲解最重要的产品功能。
  - 开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。
  - 产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。
- 每日立会：Standup Meeting
  - 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。
  - 团队内部利用每日立会来沟通进度。
  - 开发团队利用燃尽图来展示整体进度。
  - 如无特殊原因，迭代期内无变更。
- 评审会：Review Meeting
  - 小组向产品负责人展示迭代工作结果。
  - 产品负责人给出评价和反馈。
  - 以用户故事是否能成功交付来评价任务完成情况。
- 反思会：Retrospective Meeting
  - 在每个迭代后召开简短的反思会。
  - 总结哪些事情做的好，哪些事情做的不好。
  - 制定改进计划。

1.2 用户故事

用户故事：描述具体的需求的卡片。

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

角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。
功能即用户能亲自执行的操作。应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。
价值是完成操作后，客户所得到的好处。价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。

需求分解为任务，由开发完成，实现功能。

需求费解为用例，有测试完成，验证功能。

1.3 敏捷日常跟进

看板
- 看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式。从形式上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。
- 故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。
- 看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。
燃尽图
- 在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算。我们可以创建一个表来是使数据可视化，就是燃尽图
- 根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。

2. 计划会

计划会准备的内容
1. 每个人准备做（测试）哪几个需求？
  1. 手工
  2. 自动化测试UI
  3. APP测试
2. 自动化测试（验收、回归、批量）方案？
3. APP测试
  1. Android模拟器
  2. Android真机（adb） iphone真机（手工）
计划会的步骤
PO 产品负责人产品经理
1. 业务背景介绍
  - 整体的介绍产品的业务
  - 产品可以做什么事情
  - 产品有多少种平台：
    - Web (B/S)
    - PC (C/S)
    - Android
    - iOS
  - 产品有什么样的版本：
    - 免费版
    - PRO版（付费）
  - 有多少种竞争的产品
    - Worktile
    - 明道
    - Leangoo
    - teambition
    - trello
2. 准备 product backlog （更新产品待开发项）
  - 产品经理登录禅道
  - 创建产品
  - 提需求，构成产品待开发项
3. 挑选 sprint backlog （选择该迭代要做的冲刺待开发项）
  - 项目经理登录禅道
  - 创建迭代（项目）
  - 关联产品
  - 关联需求（从第二步创建的需求中，选择一部分，构成冲刺待开发项）
  - 团队设定
4. 讲解 sprint backlog 的具体需求（用户故事）
  - 产品经理讲解每一个被关联的需求
  - 确定验收标准
PM 项目经理 Scrum Master 敏捷教练
1. 确定 sprint 周期长度 1 week？ 2 weeks？
  - 2周/Sprint
2. 认领 sprint backlog，预估时间
  需求（开发，xxx，多少时间；测试，xxx，多少时间）
  - 项目经理登录禅道
  - 选择本次迭代
  - 打开需求
  - 依次选定每一个需求 | 编辑
  - 编辑备注：
    1. 开发：XXX，2h
    2. 测试：YYY，3h
3. 确定评审会的日期
  - 开几次？
  - 每次评审什么需求？
  - 确定演示会的次数
  - 确定每次评审会的需要评审的需求
  - 确定每次评审会的时间
4. 每日立会开会时间
  - 09:05每天

计划会输出文档

sprint 开始日期，结束日期
sprint 周期

表格（sprint backlog表格）

sprint backlog 列表
任务认领 + 估算

编号	需求名称	[所属模块]
105	登录/数据提交[手工自动化安全抓包]	xxx
106
109
-	APP Monkey测试

每日站会时间
评审会表格
1. 日期
2. 评审需求

3. 每日立会

汇报内容
1. 我昨天做了什么事情（完成什么需求的测试？开发？）
2. 我今天准备做什么事情
3. 我目前有什么用的困难（挑战）
  1. 缺乏数据库权限
  2. 缺乏服务器系统用户权限
  3. 技术问题
  4. 业务问题
  5. 时间问题
燃尽图

统计需求：产品本身的需求（或者需求分解的任务总数） + 产品级对应的测试任务数
每日站会中，每个团队成员需要回答3个问题。通过这3个问题，我们可以得到两个层面的信息：
- 团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；
- 同时是否存在障碍
每天团队都会得到反馈，并可以根据得到的反馈做出调整。

如果不是每天开站会，那么就可能：
1. 团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；
2. 团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；
3. 团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。

4. 项目迭代

Web手工测试准备
自动化测试环境搭建
APP测试准备
SVN配置
禅道项目管理工具配置

敏捷 Scrum 流程①| 敏捷入门与 Scrum 计划会