项目实践二：1-计划会

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

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 敏捷教练

  4. 确定 sprint 周期长度 1 week？ 2 weeks？
     • 2周/Sprint
  5. 认领 sprint backlog，预估时间
     需求（开发，xxx，多少时间；测试，xxx，多少时间）
     • 项目经理登录禅道
     • 选择本次迭代
     • 打开需求
     • 依次选定每一个需求 | 编辑
     • 编辑备注：
       1. 开发：XXX，2h
       2. 测试：YYY，3h
  6. 确定 评审会的 日期
     • 开几次？
     • 每次评审什么需求？
     • 确定演示会的次数
     • 确定每次评审会的需要评审的需求
     • 确定每次评审会的时间
  7. 每日立会开会时间
     • 09:05每天

• 计划会输出文档

  • sprint 开始日期，结束日期

  • sprint 周期

  • 表格（sprint backlog表格）

    1. sprint backlog 列表
    2. 任务认领 + 估算

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

  • 每日站会时间

  • 评审会表格

    1. 日期
    2. 评审需求

3. 每日立会

1. 汇报内容

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

2. 燃尽图

   统计需求：产品本身的需求（或者需求分解的任务总数） + 产品级对应的测试任务数

3. 每日站会中，每个团队成员需要回答3个问题。通过这3个问题，我们可以得到两个层面的信息：

   • 团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；
   • 同时是否存在障碍

   每天团队都会得到反馈，并可以根据得到的反馈做出调整。

   如果不是每天开站会，那么就可能：

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

4. 项目迭代

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