点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 8:55 更新文章，每天掉亿点点头发...
源码精品专栏
来源：jianshu.com/p/908cae2e23c5
为什么要实施
使用的工具
如何做好这件事情
公开需求管理
产品研发需求管理
技术任务管理（任务效能看板）
测试BUG管理（BUG看板）
小结
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和其他问题，进行的测试相关的总结
目前，敏捷相关的管理，这个阶段也仅仅是做了一小部分，还有很多实践方法，在后续的变化中，会加入和实施
敏捷管理是为了快速、稳定的交付产品而服务的，切忌不要为了追求敏捷工具的使用而耽误了实际要达成的目标。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 20 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
兄弟，艿一口，点个赞！????
1593
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
