阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 jianshu.com/p/908cae2e23c5 「michaelliuyang」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

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

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

这是现代管理学之父，彼得·德鲁克的一句名言。项目管理、敏捷开发的前提，还是需要把数据串起来，进行可视化、数据化，这样才能看到它，管理它。

本文将以公司SaaS产品为例，介绍下“小团队”是如何进行敏捷研发的落地的。

为什么要实施

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

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

使用的工具

下面是我们所使用的工具，Confluence主要是知识库和文档的汇集，JIRA是项目管理工具和BUG管理工具，下面是之前写的如何搭建这些工具的文章，大家可以参考

✔️Atlassian Confluence

创业公司基础设施如何搭建（三） -- Confluence（Docker版本）

✔️Atlassian Jira

创业公司基础设施如何搭建（四） -- Jira（Docker版本）

如何做好这件事情

需求评审 ➡️ 设计评审 ➡️ 研发实现 ➡️ 测试 ➡️ 验收 ➡️ 发布 ➡️ 后评估

为了让产品和研发过程可视化，更加可控，信息互通，我们采用***4个看板***模型进行敏捷管理实践，看板名称和功能如下：

公开需求看板（Kanban Board）

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

需求看板（Kanban Board）

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

任务效能看板（Scrum Board）

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

BUG看板（Kanban Board）

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

20201111123104.jpg

公开需求管理

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

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

甄别和过滤伪需求和次要或者不符合战略的需求，在这里进行，但是“业务方”提出的众多的需求如何管理，也是一件头疼的事情，这里主要流程发生有下列几种：

用户使用体验 ➡️ 客户成功同学 ➡️ 记录问题 ➡️ 反馈处理结果
大客户需求 ➡️ 客户成功同学 ➡️ 记录问题 ➡️ 反馈处理结果

客户成功同学、销售同学或者其他干系人，都可以在这个看板内，提交原始需求问题，产品同学会过滤、调研，转化为产品需求，到产品需求池内，下面是*公开需求看板*，卡片的内容主要包含了：需求描述、问题类型、解决状态、经办人

20201111110736.jpg

判断价值很低或者肯定不会做的需求，直接拖到已完成
判断有一定价值或需要在分析的需求，拖到调研讨论，最终确定后，再拖到已完成

产品研发需求管理

需求分类

产品研发内部，我们把需求分成2类：

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

需求等级

古语云：师出有名，需求的提出也是如此，为了让研发同学知道需求的重要和紧急程度，需求等级划分是特别需要的一件事情。

产品需求等级划分

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

P1：非常重要任务，有Deadline，并且不可以Delay；如遇到P0，那么就需要加班保证P1的Deadline

P2：重要、有影响力的任务，有Deadline，如遇到P0和P1，可以顺延（应该是大部分任务）

P3：锦上添花的正常任务，优先级最低
技术需求等级划分

T0：重大性能和漏洞，需要加班加点进行修复

T1：扩展性和性能风险问题，一般是单独任务进行修复

T2：设计或者一般性能缺陷，一般是随着迭代进行相关改进

产品需求管理（需求看板）

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

20201109163916.jpg

20201109163929.jpg

主要包含了

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

需求看板的 泳道有P0、P1、P1以下、技术需求的4个泳道，为了便于搜索，在快捷搜索列加入了常用的搜索关键词，卡片主要包含：需求等级、到期日、需求负责人

技术需求管理（需求看板）

类似数据结构的变更、技术架构的改进，比如：更换配置中心为Apollo，这类需要简称技术需求，其数据显示和看板功能，和产品需求基本一致，也显示在***需求看板***内，看板如下：

技术任务管理（任务效能看板）

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

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

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

产品需求
技术需求

对于此类任务管理，我们使用的看板是*任务效能看板*。在开始之前，我们需要在Backlog内，拖动需要进行迭代的技术需求或产品需求，如下图：

然后，以产品需求和技术需求为父任务，在***需求看板***内，创建子任务，界面如下：

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

点击开始Sprint，并设置好时间，如下图：

RD & QA & FE，在每天下班前，填写其任务的工作量即可达到任务工作量跟踪的效果，如下图：

20201110101104.jpg

测试BUG管理（BUG看板）

在Sprint中产生的BUG都会显示在***BUG看板***中，工作流主要是打开 ➡️ 处理中 ➡️ 已解决 ➡️ 已关闭，如下图：

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

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

在这个迭代结束后，测试人员，会根据BUG的统计报告数据，分析得出本次迭代的测试报告，测试报告，我们在Confluence创建了统一模板，主要内容如下：

小结

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

4个看板

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

需求看板：主要是管理技术需求和产品需求

任务效能看板：主要是管理开发阶段，RD & FE & QA的任务和工作量，跟踪其任务合理性

BUG看板：主要是管理迭代内产生的5类BUG问题，功能优化 & 功能错误 & 界面优化 & 性能问题 & 安全相关
2个模板

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

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

目前，敏捷相关的管理，这个阶段也仅仅是做了一小部分，还有很多实践方法，在后续的变化中，会加入和实施

敏捷管理是为了快速、稳定的交付产品而服务的，切忌不要为了追求敏捷工具的使用而耽误了实际要达成的目标。

芋道源码 —— 纯源码解析博客

小团队如何落地敏捷开发