阿里敏捷研发体系&DevOps 最佳实践
2025-09-18 17:11:18 0 举报
AI智能生成
阿里敏捷研发体系&DevOps 最佳实践
作者其他创作
大纲/内容
敏捷产品创新和交付方法体系
最小业务闭环
能产生阶段性结果的目标设定
组织职责对齐
快速反馈
产品规划设计
根本问题:快速高质量交付价值的能力
完整故事
根本问题:快速高质量交付价值的能力
完整故事
持续发布能力
发布频率
发布前置时间
(集成验证耗时)
(集成验证耗时)
需求响应周期
交付周期时间
流动效率
开发周期时间
交付吞吐率
单位时间交付用户需求数量
交付过程质量
缺陷创建和修复时间分布
缺陷库存
交付质量
单位时间问题数目
线上问题解决时长
产品开发中的根本问题
几乎从来不是停止的资源(工程师),而是停止的产品需求(用户价值)。
共创游戏一:最小业务交付闭环和业务目标设定
问题一详述
定义什么样的最小业务交付闭环和阶段性业务目标来实现:
购书商城解决滞销书(有自营、也有第三方)的库存积压问题。
该目标需要想管理层汇报并得到认可。
购书商城解决滞销书(有自营、也有第三方)的库存积压问题。
该目标需要想管理层汇报并得到认可。
作业
商量出6个月的最小业务闭环和阶段性业务目标,以此向管理层汇报,并希望得到认可。
作业要求
要可量化(数量),目标设定要有严谨的逻辑
时间
10分钟讨论,每组3分钟叙述
回答(阿里实践经验)
最小交付闭环
阶段性业务目标
6个月滞销书去库存20%
目标(目标细分)
6个月实现借阅的滞销书书的销量50%的增加
6个月实现因借阅的滞销书销量增加带动商城整体销量10%的增加
共创游戏二:产品方需求产生的技术资源缺口矛盾问题及解决
问题二详述
开发按产品放的需求初步设计,资源初步估算
需要450人日开发工作量(测试不算),实际
只有300人日开发资源(每月100人日)。借阅
(100人日)、在线客服(50人日)、购买(100人日)、
价格抵扣(50人日)、第三方商家引入(100人日)、评价(50人日)。
如何解决资源问题,如何进行需求开发排期?
需要450人日开发工作量(测试不算),实际
只有300人日开发资源(每月100人日)。借阅
(100人日)、在线客服(50人日)、购买(100人日)、
价格抵扣(50人日)、第三方商家引入(100人日)、评价(50人日)。
如何解决资源问题,如何进行需求开发排期?
作业
商量出策略和排期看板、各方(产品、技术)的职责和KPI目标
作业提示帮助
最小闭环、有用的价值
时间
20分钟讨论,每组3分钟叙述
回答
被明确禁止的策略:加班×;外包×;采购×
有用的价值
滞销书去库存→借阅率和评价是第一步
最小的闭环
围绕借阅的基本功能争取1个月(4月30日)上线第一个版本……
需求的探索
虽然购买、在线客服、价格抵扣的产品设计可以先行,
但是否做这些需求要以借阅和评价的市场效果来决策和调整。
但是否做这些需求要以借阅和评价的市场效果来决策和调整。
各方的职责
子主题
【腾讯文档】项目事项排期表
https://docs.qq.com/sheet/DSGdydXBOWlB5dGZF
https://docs.qq.com/sheet/DSGdydXBOWlB5dGZF
KPI目标
产品负责人--业务目标(去库存、借阅率、评价),开发中的需求变更频度
技术负责人(开发、测试)--同样业务目标
共创游戏三:交付推迟问题复盘
问题三详述
需求没写清,边开发边完善产品设计细节,增加了工作量。
导致三周开发(75人日)不够
导致三周开发(75人日)不够
作业
如何是需求在开发前写清楚?
商量出一致的综合性改进策略、各方(产品、技术)的职责
商量出一致的综合性改进策略、各方(产品、技术)的职责
作业提示帮助
原因:没想清楚
以用户价值为核心,而非聚焦资源;
产品设计参与者应该有哪些?
应该如何参加?
产品设计参与者应该有哪些?
应该如何参加?
时间
10分钟讨论,每组3分钟叙述
回答
tips
产品经理发起需求评审会
有用的机制&最小的闭环
各方的职责
职责
产品负责人--产品设计初稿、召集评审、产品定稿归档;
技术负责人(开发、测试)
共创游戏三:交付推迟问题复盘
问题四详述
测试认为开发的周期太长了(开发delay了两天),留给功能测试+集成验证的时间(实际2天)太少。交给测试之后发现版本bug太多,不得不反复验证多个bug fix的版本,导致验证时间太长。
作业
商量出开发提测前各方的职责及KPI目标,,在据此一致的综合性策略和结果。
作业提示帮助
开发周期长的原因
环境稳定性、开发测试手段、开发方式
开发故障多的原因
测试接入时间、策略
时间
10分钟讨论,每组3分钟叙述(先讲职责和KPI,再讲策略和结果)
回答
质量前移
质量问题发现的阶段越早越好,发现的越晚,修复的时间和资源成本越高。
各方的职责
开发要有自测的意识,认识到质量是衡量自己的重要要求之一。
测试要帮助开发自测,降低开发自测的门槛,提升开发自测的效率。
职责及KPI
开发--开发质量:缺陷数,单测成功率;
测试--接口测试覆盖率、测试数据自动化构造
测试环境负责人--测试环境稳定性
共创游戏三:交付推迟问题复盘
问题五详述
产品、运维、开发认为测试验证的周期太长质量差。很多问题到了预投产甚至生产环境才暴露问题,导致发布delay
作业
商量出开发提测后各方的职责及KPI目标,,在据此一致的综合性策略和结果。
作业提示帮助
测试质量差、测试效率低
时间
10分钟讨论,每组3分钟叙述(先讲职责和KPI,再讲策略和结果)
回答(阿里实践经验)
测试质量
各方的职责
职责及KPI
故障数、测试漏测率、集成验证耗时
共创游戏三:交付推迟问题复盘
问题六
回答(阿里实践经验)
有用的价值
阿里敏捷研发需求管理和交付实践
1.敏捷研发下的需求管理
什么是需求?
定义
精益和敏捷需求
服务于用户和业务目标,良好拆分、组织和规划,并被有效分析和澄清的高质量需求
1、从用户问题出发,设计产品和服务
2、聚焦业务目标,挖掘产品需求
3、基于业务场景,组织和规划需求
4、以终为始,高效分析和澄清需求
用户故事地图
挖掘、组织和规划需求
1、沟通业务团队和交付团队的桥梁
2、最大化业务成果而不是最大化功能产出
3、持续演进
目标:内部上线,受控业务跑通
目标:外部上线,小流量导入
需求的来源
高质量需求是高效研发的基础
需求的难题
20%
60%
需求的问题
信息不同步
协作不顺畅
标准不明确
工具不健全
规划不明晰
→变更频繁
业务驱动模式下的需求结构化模型
需求分层交付流程
沙盘实践1:需求的生产交付流程
【腾讯文档】需求生产交付流程
https://docs.qq.com/flowchart/DSEpUdEtlZWhYWWpp
https://docs.qq.com/flowchart/DSEpUdEtlZWhYWWpp
阿里需求生产流程
目标手段
降低修正需求歧义的成本--每个环节提升需求的准确性,减少需求内容理解的差距。
1、定义清楚需求管理协作机制和交付流程
2、定义交付流程中每个节点的相关责任方
流程
用户需求起草→用户需求讨论→产品需求及交互讨论→产品需求及交互定稿→需求工作量评估→需求排期版本计划→……→需求验收及交付
参与角色
业务方PD、技术经理PM、……
各个阶段
用户需求阶段
消除错误需求保证目标正确
回答“做不做”的问题
产品需求阶段
保证产品形态正确
回答“如何做”的问题
需求实现交付阶段(估算、排期、验收交付)
保证如何做最高优先级的事
回答“如何最好地做”的问题
沙盘实践背景
业务介绍
共享书架上线后,通过一段时间的运营,整个业务流程和商业模式得到验证。
通过积累借阅读者的借阅、评价、图书评分信息,能够快速带动某些书籍的口碑提升,实现后期的购买闭环。
通过积累借阅读者的借阅、评价、图书评分信息,能够快速带动某些书籍的口碑提升,实现后期的购买闭环。
共享书架已经上线的功能及需求
用户注册登录、书品展示、搜索
借阅、在线客服、购买、价格抵扣、第三方商家引入、评价
书籍详情页的评价统计信息
沙盘实践2:用户需求起草
问题介绍
共享书架上线后,发现由于上线时间段,借阅用户积累不足,
很大比例的书籍借阅读者的评价数目严重不足无法形成有效的
书籍评分,从而无法从整体上利用书籍质量口碑带动销量,因此
6个月完成提升滞销书销量并带动10%整体图书销量的业务指标风险很高。
针对此问题,业务方提出要引入更多的外部评价内容,导入原图书商城
书籍购买页的评价、当当、豆瓣等第三方图书的评价,迅速建立共享书架
图书评价的规模效应,提升点击后的借阅转化率。
很大比例的书籍借阅读者的评价数目严重不足无法形成有效的
书籍评分,从而无法从整体上利用书籍质量口碑带动销量,因此
6个月完成提升滞销书销量并带动10%整体图书销量的业务指标风险很高。
针对此问题,业务方提出要引入更多的外部评价内容,导入原图书商城
书籍购买页的评价、当当、豆瓣等第三方图书的评价,迅速建立共享书架
图书评价的规模效应,提升点击后的借阅转化率。
作业
请根据背景问题介绍起草用户需求
作业提示
用户需求必须要阐述什么最关键点?
如何做到用户需求清晰明确?
时间
8分钟讨论,每组3分钟叙述
阿里实践--云效用户需求起草模板
1.需求标题
概括,便于后续需求生产交付流程中的查找和筛选。
2.需求背景
若不做该需求,则用户或企业会发生什么困难、发生困难的原因等。
3.需求目标
尽可能量化和明确,避免含糊。
4.用户使用场景
须清楚描述用户需求涉及的所有场景,避免遗漏,此部分内容是产品设计的基础。
5.产品现状截图
“用户使用场景+产品现状截图”
6.ROI评估
为了帮助来决定做还是不做这个需求
产品经理、产研团队,沟通,支持
重要提醒
ד一句话需求”,产品经理可直接打回,要求用户需求撰写者进行修改。
用户需求阶段
用户需求起草的职责权
1.背景
①是否清晰阐述了用户需求背后的原始诉求;
②是否做到了用户需求的清晰明确,无歧义。
2.相关人员的职
3.相关人员的责
需求流转状态
用户需求起草常见的“反面”需求类型
一句话需求,未澄清,不清晰
解决方案式需求
与产品理念相违背的需求
单一定制化无产品通用价值的需求
已有类似功能需求
伪需求
用户需求起草的作用
帮助澄清客户的一句话需求,管理客户预期
挖掘到用户真正的原始诉求,选用合理的解决方案
去除客户的伪需求与不合理需求
用户需求讨论环节
用户需求讨论和确认
1.背景说明
对用户需求的理解一致,并决定是否交付以及初步确定交付优先级
技术经理的一个重要职责是提供需求的技术可行性信息
2.操作步骤
用户需求讨论环节的职责权
业务、PD、PM、技术经理参加讨论,不得缺席,缺席时会议不得召开
做正确的事
真正有价值的需求
产品需求阶段
敏捷需求生产
产品需求及交互设计修改稿
阿里产品定稿会的实践
所有角色都参加
仪式感
定稿会录像
帮助回溯RCA依据。背后的原因和逻辑
需求实现交付阶段
子主题
阿里研发效能提升 DevOps 沙盘实践
技术团队如何更轻松的承担职责、实现考核目标,从而达成业务目标
1、配置管理
1.1代码版本管理
游戏1.1:并行项目的代码版本管理
提示帮助
主干模式、分支模式
游戏1.2:环境配置
提示帮助
代码配置分离原则
打一个包,在多个环境可以使用
1.2
2、单测集成
2.1单元测试
2.2静态分析
游戏2.1
游戏2.2
游戏2.3
游戏2.4
测试方案讨论
讲师-陈霁
1.作为测试同学想一下如果我从功能角度设计测试用例有哪些,条数
讲师-陈霁
2.开发同学想一下如果我从代码级别设计测试用例有哪些几条
1.作为测试同学想一下如果我从功能角度设计测试用例有哪些,条数
讲师-陈霁
2.开发同学想一下如果我从代码级别设计测试用例有哪些几条
代码质量分是生命线
3、测试管理
分层自动化
4、构建部署
5、集成验证
0 条评论
下一页