中小团队如何落地敏捷开发?

You can't manage what you don't measure. - Peter Drucker

你如果无法度量它,就无法管理它。

这是现代管理学之父,彼得·德鲁克的一句名言。项目管理、敏捷开发的前提,还是需要把数据串起来,进行可视化、数据化,这样才能看到它,管理它。本文将以公司SaaS产品为例,介绍下“中小团队”是如何进行敏捷研发的落地的。

一、为什么要实施敏捷

  • 需求的进展不透明,不知道现在到哪里了
  • 需求延期发布成为了家常便饭,不知道什么时候会发布上线
  • 需求发布上线后,心里总是忐忑不安,不知道什么时候会出现问题和故障
  • 团队沟通成本太高,经常性出现RD、FE、QA、PM信息不一致
  • 需求插入随意、频繁,不计成本
  • 不清楚,研发团队的工作量,是正常、超负荷、还是有人不饱和

在互联网初创公司里,需求和有限的资源,永远是矛盾命题如何在矛盾中寻找平衡,把有限的资源专注于符合公司战略的需求,保持团队的节奏和良好的情绪,就是要实施敏捷管理的痛点,也是我们为什么要实施,敏捷管理也可以很好的回答上面出现的各种问题,给出答案。

二、使用的工具

The tools you use shape the way you work.

你使用的工具塑造了你的工作方式。

下面是我们所使用的工具,PingCode Wiki 主要是知识库和文档的汇集,PingCode Agile 是敏捷开发管理工具,PingCode Testhub 是测试管理,供大家可以参考

三、如何做好这件事情

需求评审 ➡️ 设计评审 ➡️ 研发实现 ➡️ 测试 ➡️ 验收 ➡️ 发布 ➡️ 后评估为了让产品和研发过程可视化,更加可控,信息互通,我们采用4个模型进行敏捷管理实践,具体过程介绍如下:

公开需求看板(Kanban 项目)

通过「看板」建立一个公开需求池,向跨部门成员广泛收集需求,一切市场反馈及时传递到位。看板类型为Kanban项目 :

需求列表(Scrum 项目)

为需求生命周期搭建流程,按「需求池 - 评审 - 排期 - 设计 - 开发 - 发布」设立多个阶段,需求流转可视化。

任务进度板和迭代概览(Scrum 项目)

为需求预设好发版时间,所有人都可以及时预知逾期风险;产品、开发和需求提出者随时发起沟通,及时同步需求变化或者开发进展。

Sprint概览

详细任务板

缺陷列表

通过看板查询,迭代中的各种类型的BUG数量情况,清楚明了。

四、公开需求管理

公司属于教育类SaaS,其公开需求主要来源有下面几类:

  • 重要客户(学校)
  • 用户日常使用反馈(教师、学生、家长)
  • 销售渠道

甄别和过滤伪需求和次要或者不符合战略的需求,在这里进行,但是“业务方”提出的众多的需求如何管理,也是一件头疼的事情,主要的公开需求来源一般有以下几种:

  • 销售
  • 市场
  • 内部(基于产品规划 / 其他)
  • 用户使用体验

客户成功同学、销售同学或者其他干系人,都可以在这个看板内,提交公开需求,产品同学会过滤、调研,转化为产品需求,到产品需求池内,下面是公开需求看板,卡片的内容主要包含了:需求描述、公开需求来源、报告人、经办人等(增减字段都可以自定义)。

  • 判断价值很低或者肯定不会做的需求,直接将状态改成【已关闭】
  • 判断有一定价值或需要在分析的需求,拖到技术支持确认,最终确定后,再拖到下一环节。

五、产品研发需求管理

需求分类

产品研发内部,我们把需求分成2类:

  • 产品需求:PM提出的迭代、紧急、日常类需求
  • 技术需求:研发内部为了稳定性、扩展性、维护性而进行的技术重构类需求

需求等级

为了让研发同学知道需求的重要和紧急程度,需求等级划分是特别需要的一件事情。

产品需求等级划分

最高:紧急任务,必须穷尽所能,最短时间完成;可以调人支援,可以停止其他项目,需要加班

较高:非常重要任务,有Deadline,并且不可以Delay;如遇到【最高】,那么就需要加班保证【较高】的Deadline

普通:重要、有影响力的任务,有Deadline,如遇到【最高】和【较高】,可以顺延(应该是大部分任务)

较低/最低:锦上添花的正常任务,优先级最低技术需求等级划分最高:重大性能和漏洞,需要加班加点进行修复较高:扩展性和性能风险问题,一般是单独任务进行修复普通:设计或者一般性能缺陷,一般是随着迭代进行相关改进

产品需求管理(需求列表)

PM和研发同学,通过PRD的方式进行沟通和交流,研发同学最终也是通过PRD进行开发、测试工作,所以第一步是需要创建PRD,PRD的管理方式采用相对灵活的方式,PM写PRD的工具有的是蓝湖,有的墨刀,我们这里为了统一归档,在PingCode Wiki 做了归档的统一管理(PRD的详细链接可以是任何工具的链接), 在PingCode Wiki创建时选择模板创建,见下图:

主要包含了

  • 背景描述
  • 业务目标的描述
  • 需求链接和功能列表(即Story)

我们首先会在需求规划阶段将需求分为技术需求和产品需求,并拆分成特性、用户故事等更小的层级,并通过最高、较高、普通、及以下进行优先级划分

技术需求管理(需求列表)

类似数据结构的变更、技术架构的改进,比如:更换配置中心为Apollo,这类需要简称技术需求,其数据显示和过程管理,和产品需求基本一致,也显示在需求列表内。

六、技术任务管理(迭代概览和任务板)

这个阶段,主要是从需求阶段进入到了研发阶段,这个阶段主要包含如下类型的任务:

  • 开发任务:RD、FE
  • 开发自测:RD、FE
  • 测试用例编写:QA
  • 测试用例执行:QA

技术任务类型的问题,主要来源于2个方面

  • 产品需求
  • 技术需求

对于此类任务管理,在开始之前,我们需要在Backlog内,将需要进行迭代的技术需求或产品需求,移入接下来迭代中。

然后,以拆分后的产品用户故事或技术用户故事为父任务,创建子项目,界面如下:

创建好后,可以查看父子任务详情,并有工作量体现:

开始Sprint,团队可随时查看到期时间以及工作项进度,如下图:

在每天下班前,填写其任务的工作量即可达到任务工作量跟踪的效果,如下图:

七、测试、缺陷管理(缺陷列表)

在Sprint中产生的BUG都会显示在BUG列表中,工作流主要是打开 ➡️ 处理中 ➡️ 已解决 ➡️  已关闭,如下图:

我们所采用的BUG类的问题类型有以下几种:

  • 功能错误
  • 界面优化
  • 功能优化
  • 性能问题
  • 安全相关

在这个迭代结束后,测试人员,会根据BUG的统计报告数据,分析得出本次迭代的测试报告,测试报告,我们使用PingCode Testhub 自动生成测试报告,主要内容如下:

  • 报告概览
  • 测试用例执行结果分布
  • 缺陷情况
  • 成员执行情况分布
  • ......

小结

需求和效能的生命周期管理,这里仅仅是按照目前产品和团队的需求和阶段,规定了一些适合我们的方法,这个周期管理,还是需要随着人员和阶段的不同而进行不断的改造和演进的,下面是我们在PingCode Agile和Wiki 使用的一些核心流程和方法:

4个模型

公开需求看板:处理市场、销售前端部门提出的“大客户需求”和“用户使用体验问题”

需求列表:主要是管理技术需求和产品需求

迭代概览和任务板:主要是管理开发阶段,RD & FE & QA的任务和工作量,跟踪其任务合理性

缺陷列表:主要是管理迭代内产生的5类BUG问题,功能优化 & 功能错误 & 界面优化 & 性能问题 & 安全相关

2个模板

产品需求模板:产品需求的管理

测试报告模块:迭代后,针对BUG和其他问题,进行的测试相关的总结

立即使用智能化研发管理工具PingCode学习敏捷