小米Q派敏捷转型(上部):欲练神功,先打基础

2020-11-20 17:53:44
敏捷助理
原创
320
摘要:本文记录了Q派于2019年12月份开始的敏捷转型之旅。

一、转型之前

Q派转型前,门派的人架构是这样子:业务长老、业务专家长老、产品长老、开发长老、测试长老们各司其职,小步快跑,两周一迭代,但是仍会存在User story拆分不足,交付不及时或者节点交付不明确的问题。

有一天,Q派从武林盟主(敏捷转型常委会)获悉,可以邀请敏捷教练入驻门派,帮忙门派提高敏捷管理效率,提升门派整体实力。整个门派欢腾起来……
在武林盟主的帮助下,Q派全派上下,积极主动配合,用最快的速度,特邀王明兰教练作为光明使者入驻门派。Q派选用Q平台重构项目作为试点工程。此项目刚好处于启动阶段,正是应了天时、地利、人和,项目成功的几率大大提高。
到Q派的第一时间,光明使者敏捷教练给大家安排了基础知识导入培训。

在改革启动之前,掌门先行确认项目的基本工作协议: 
  • 指定工作守则,明确惩罚制度,比如会议迟到罚一个红包,产品在迭代中期变更需求自罚一个红包,迭代进行中发现开发的需求实现有误,开发自罚红包等等。
  • 明确工作目标,不忘初心:通过售后质量管理模块功能试点开发。
  • 确定工作基本分工以及工作进度期望。

在光明使者的帮助下,通过如下步骤开始了风风火火的改革,整个Q派动了起来。

二、6步打通任督二脉

第一步:明确开发团队,定义角色和职责

明确了角色分工和组织架构,改版的Q派是这样的:

业务专家长老:

  • 与业务长老沟通,梳理业务流程,转换业务需求为IT产品需求。
  • 需求评估后确定初步产品方案,要求产品经理实现产品原型。

产品长老:

  • 将PRD转换成用户故事,录入Jira Backlog,每个User Story的“描述”字段填写原型获取路径、验收条件;确定每个User Story的优先级排序。
  • 创建版本,确定版本中包含的User Story。
  • 把Backlog中的User Story分配到指定的Sprint。
  • 根据迭代活动日历,更新和维护Sprint的User Story。
  • 根据迭代活动日历,组织与业务和研发的产品方案和原型评审,确保在迭代启动前准备好定稿的产品方案、原型、User Story。
  • 根据测试长老设计的测试用例测试User Story,计划测试完成时间,并在每日站会上汇报测试进度。
  • 对迭代目标做承诺并负责达成目标。

舵主(Scrum Master):

  • 引导和组织Scrum的流程,包括每日站会、Sprint计划会、回顾会、演示会。
  • 引导团队识别Sprint交付的风险和障碍,推动解决。
  • 引导团队持续改进和绩效提升,最终达到自管理的状态。
  • 对迭代目标做承诺并负责达成目标。

分舵弟子:

  • 交付迭代计划制定的开发任务、技术调研任务。
  • 对迭代目标做承诺并负责达成目标。

测试长老:

  • 根据每个 User Story提测点计划测试任务,确定测试计划。
  • 在每一个User Story提测之前设计完成相应的测试用例。
  • User Story指派产品经理认领。
  • 对迭代目标做承诺并负责达成目标。

第二步:明确迭代日历,搭建实时看板

敏捷不仅仅是简单的快,而是短周期的不断改进、提高和调整。产品需要提前做好充分沟通,确认后续迭代任务,保证团队内部需求充分沟通,避免开发过程因理解歧义返工。
因此,我们确定了迭代日历,明确关键节点,保证团队全员在迭代过程中,不遗漏任何工作。

采用实时看板,帮助大家掌握整体情况,确认各项任务进度:
  1. Backlog看板,大家可以清晰看到当前Sprint以及即将开发的任务情况。
  2. 活动Sprint看板,可切换Sprint,查看不同团队任务情况,查看各个User Story拆解的子任务进度情况,并可快速查看各个成员的工作完成情况。
  3. 在每天的日站会之前,所有成员必须更新自己的任务进度情况以及剩余工预估时间。

第三步:规划版本,拆分产品,划分迭代

在光明使者的帮助下,确定了用户故事拆分原则,与团队明确项目管理软件更新规则:
  • 产品长老录入User Story。
  • 开发长老与弟子根据User Story拆分开发任务,需要录入任务初始时间。
  • 测试长老录入测试用例任务与测试任务(产品、测试),需要录入任务初始时间。
  • 所有成员必须在日站会之前更新工作状态与剩余预估时间。

第四步:产研不分家,测试对产品培训,产品协助测试

由于测试工作只有一位测试长老作为质量担当,为了确保产品质量,掌门决定让产品长老介入测试,确认产品需求和业务流程在产品中正确落地。为此,测试长老对所有产品经理进行了测试基本功的培训。测试长老用一则《捕鱼说》,让每个产品长老深刻理解了测试工作,至今记忆犹新:
  • 测试工作就像捕鱼,捕的是不符合要求的鱼,相当于测试人员发现的是不符合需求的缺陷;
  • 为了避免有漏网之鱼,捕鱼人需要考虑整个捕鱼的策略和计划,用什么渔网(使用何种类型的测试用例)、捕什么鱼(确定测试类型)、何时撒网(确定测试计划)和在哪里撒网(确定测试重点和范围)这些工作都由捕鱼人来制定;
  • 鱼网的好坏直接关系到捕鱼的效果(测试用例设计的好坏直接关系到能发现多少BUG),因此,鱼网需要不断改进及修补(测试用例设计人员需要不断的维护及完善测试用例);
  • 编织什么类型的网需要根据鱼的类型来考虑,(根据可能的缺陷类型设计不同类型的的测试用例,如功能测试,性能测试等),因此,需要根据不同类型的鱼来设计与之相匹配的渔网。

第五步:质量活动前移,测试给开发提供测试用例自测

测试长老在开发开始自测前,完成每个模块的测试用例设计,重点注明开发自测关键点,便于开发自测提前发现问题,提高开发质量与测试效率。

第六步:北京武汉两地每日视频会议电子看板同步进度

由于团队跨武汉和北京两地,跨地域协同是个很大的困难。我们每天采用视频日站会,通过Sprint 看板,按以下议题确认进度
  • 每个开发长老&测试长老讲3个问题(昨天,今天,障碍)。 
  • 舵主审视当前迭代是否有风险。
  • 产品长老讲后续迭代的需求是否需要研发评审或讨论 。
  • 掌门介绍项目是否有消息告知大家。

三、结语:打通任督二脉,未完待续

Q派通过以下六步来打基础:
  1. 定义角色和职责
  2. 设计迭代日历,搭建看板,满足北京、武汉两地协作
  3. 拆分产品,规划版本,划分迭代
  4. 产研不分家,测试对产品培训,产品协助测试做功能测试
  5. 质量活动前移,测试设计测试用例,供开发自测
  6. 北京、武汉两地每日视频会议,同步进度,保证沟通无障碍。
通过这一段时间的敏捷转型,团队打开了任督二脉。整个Q派扎扎实实打好基础,练好基本功。老子说,合抱之木,生于毫末:九层之台,起于垒土;千里之行,始于足下。练好基本功,欲速则不达,为的是后续团队整体能力提升。
联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105