精益产品开发体系
2020-04-07 14:39:26 0 举报AI智能生成
敏捷scrum
作者其他创作
大纲/内容
原则
探索和发现有用的价值
探索
不确定性
承认自己无知
探索准确的目标用户
发现
本质问题？
如何建立有效渠道？
怎样的解决方案？
如何让他们买单？
如何建立合理的成本、收入模型？
怎样设计交互过程(场景)
聚焦和提升价值流动效率
聚焦
聚焦流动效率，而并非资源效率
提升
撬动组织之间协作，提升组织的绩效（质量、效率、可测性）
工程实践
自动验收测试
测试驱动开发
持续集成
持续重构
领域驱动设计
服务架构
部署流水线
自动化运维
运维和业务数据监控
目标
顺畅：指价值交付过程要顺畅，最短时间完成用户价值的交付，而非断断续续，问题连连
高质量：符合要求，避免不必要的错误，与探索而进行必要试错并不冲突
有用的价值：交付的价值应该符合市场和用户的哟求，并产生业务影响，促进组织绩效
管理实践
精益创业、创新实践
商业模式设计
验证步骤规划
精益产品设计
定性验证
精益数据分析
影响地图
精益需求分析和管理
场景分析
用例设计
领域建模
需求地图
发布规划
实例化需求
精益看板方法
可视化价值流动
用户价值可视化
用户价值端到端的流动过程
用户价值流动问题和阻塞
现实化流程规则
流转规则
协作规则
控制在制品数量
帮助团队暴露瓶颈问题
暂缓开始，聚焦完成
束水和攻沙
湖水岩石效应
管理工作流动
需求池管理
需求就绪（承诺）会议
标准
需求足够清楚，原则上不会变
考察产品需求的分析能力
考察产品需求的挖掘能力
考察产品需求的规划能力
已向开发团队澄清的需求，且理解一致
考察产品需求实例化能力
考察用户故事编写能力
考察产品需求拆解能力
考察产品需求的沟通能力
考察产品协调与组织能力
开发团队承诺尽快完成
原则
节奏过低的危害性
降低觉得质量，缺乏足够的业务信息
导致范围蔓延，可能有用或出现的需求计划，导致很多猜测的需求
不能很好地支持有效学习和创新，交付后反馈速度慢甚至不了了之
降低团队灵活响应市场变化的能力，一次填入很多需求，发生变化需要等待下一次填充
降低需求澄清的关注度和小伙，需求就绪后等很久才能做，难以保证澄清效果
节奏过高带来额外成本
相关人员都需要准备，很高的协调成本
市场、技术、开发的不确定性越高，需频繁的填充队列
选择适当数量的满足标准的需求
选择高优先级需求
澄清需求
定义验收标准
需求过大时需要拆分
评估需求的技术风险
确认关联方
二级队列
外部信息变化频率较低，需求池长周期更新
内部频率较高
计划
就绪
看板会议
准备
每天
固定时间
看板前
看板已经提前更新
原则
从右到左检视
从右到左拉动
关注
瓶颈，积压行程的队列
中断，某环节输入不足
需要重点关注的需求，涉及重大商业利益或风险的重点需求
被阻碍的需求，由于依赖(外部或内部)，无法正常进行的
即将或已经到期的需求，没有在承诺中达成的
长时间无进展的需求，长时间停留的时间
发布评审
建立反馈并持续改进
利特尔法则
平均交付周：需求从进入开发团队到完成交付的市场
并行需求数：整个系统中并行需求的数量，是处于各个阶段的需求书总和
平均交付速率：指单位时间交付的需求数
阻碍原因分布矩阵图
纵轴：原因分类
需求不明确
设计
第三方依赖
供应商
工具、研发
其他
横轴
从阻碍发生到解除阻碍所需的时间
前置时间控制散点图
纵轴：需求就绪到交付所花费的时间
横轴：交付日期
控制线：1-3个方差之间
质量反馈图
纵轴：系统模块
横轴：缺陷分类
累计流图
实战
用户故事为基线
用户需求->用户故事->模块拆解->开发任务&测试任务&bug
原始需求，进入需求池，整理和过滤
选取优先级较高的需求完成设计，进入待澄清
澄清需求确保需求立志一致性，明确验收标准，转化为用户故事
用户故事拆解和开发实现
测试人员验证用户故事
产品经理做用户故事的最后验收，确保与最初设计的一致并解决了用户问题
看板系统建模
价值体现
用户和业务的以及产品团队的需求
技术预研以及验证市场的尝试
支持交付工作，代码重构开发环境的改善和运营支持
反映协作
团队之间的协作
环节内的协作
集成协作
暴露问题
价值流动的问题，需求不明确，技术障碍
测试bug
需求积压
0 条评论
下一页
