【产品笔记】5.敏捷产品管理

敏捷与SCRUM 基本概念：必须要懂的敏捷的事情

 

传统软件产品研发困难：

需求管理、估算（需求拆分成任务，当对需求没那么清楚的时候，和实际的时间，有很大偏差）、变更管理、质量管理、员工感受（如果有需求的改变，用户无法容忍过长时间，需要加班去实现）

 

我们产生了大量的用不着的功能：

经常或总是被用到的功能：20%，很少或从不被用到的功能64%

 

市场瞬息万变：商场需求多样性持续上升，需求的个性化持续上升，产品创新性要求持续上升，全球一体化持续上升。

 

变更带来的痛点：

把资源更多的用在应对错误而不是价值需要

传统复杂项目中需求变更成本太高

变更很难适应

变更控制流程官僚且缓慢

我们应该拥抱变化时抗拒变化

 

业务分析面临的痛点：过度分析、缺乏验证、太多假设、太多文字工作、缺乏合作、较少业务价值且较晚事件、误解：“我是这么说过，但这不是我想要的”

 

什么是 敏捷

客户价值驱动、自组织、合作、反馈、短周期迭代增量式发布、检查和调整、持续改进

 

 

敏捷原则：

1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

*2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

*4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。

*6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

7、工作的软件是首要进度度量标准。

8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9、不断地关注优秀的技能和好的设计会增强敏捷能力。

10、简单——使未完成的工作最大化的艺术----是根本的。

11、最好的构架、需求和设计出自与自组织的团队。

12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

 

敏捷实践

sprint，计划游戏、完成的定义、每日结会、回顾会议

测试驱动，验收测试驱动，结对编程，涌口，简单设计

集中办公，跨职能团队，客户参与

十分钟一次的编译，持续集成，集体拥有代码

 

价值-原则-实践

 

scrum框架  Scrum框架详解总结

 

产品负责人：负责产品设计、需求管理、跟踪过程

scrum master：用scrum的方式去工作，和产品负责人、团队合作，推进目标达成。增加需求一定要通过scrum master，他要去沟通商量是否要真的增加。

团队：实现功能、用迭代增量的方式、反馈、交互。每次迭代得到一个可交互的产品。有的需要上线、发布；有的是潜在可发布。

迭代评审：是否是想要的模块，不是->新的待办列表，排列顺序、负责跟踪

 

发布计划：提炼背景、收集用户故事、估算和计划

迭代计划：产品待办事项列表。迭代计划第一部分：优化调整、确定迭代目标、澄清需求。第二部分：概念设计、拆分任务、估算任务、确认范围、承诺

每日scrum：产品负责人、scrum master不一定参加。 主角只有team。不能超过15min。3个问题：做了什么、今天准备做什么，昨天遇到什么困难解决不了

迭代评审：系那个户合租哦、兑现承诺、整体概况、展示成果、收集反馈、证明团队

迭代回顾：评审团队的工作方式：活跃气氛、收集数据、挖掘洞察力

 

scrum 3条腿

可视化（将一切暴露给所有干系人）、检查（审查与反馈）、调整（依据反馈进行调整）

 

管理工作范围：每日scrum、迭代、发布、路线图、愿景

 

计划和跟踪：愿景-》路线图-》发布123-》迭代123-》任务123

 

质量：团队共同指责、引入质量控制流程、TDO/ATDO、武侠代码、自动化、停止和修复

 

信息雷达

 

产品管理的敏捷思维

敏捷：迅速、轻量级、容易移动、灵活。软件开发层面强调更有效率。先做最重要的事情，看重简洁的价值，小步前进。并在追求价值的途中逐步调整。周期性的交付给顾客。

 

敏捷最大化ROI：更频繁地、逐步地交付价值

变更管理：需求变更机会、评审、获取反馈并调整。多次发布

传统需求管理：不承认现代软件开发的不确定性

敏捷需求管理：拥抱不确定并将其转化成优势

传统软件研发路径：预先计划并管理、完成所有计划中的需求。什么是市场正在需要的？

敏捷软件开发：经验主义的：基于浮现的真实需求，持续监视和调整。

传统研发：瀑布式

敏捷研发：优先级、迭代

 

 

待办事项列表

 

一个人负责，有问题问产品负责人，能得到确定答案即可。定义产品

 

当内容错误的时候，结果一定会做错的

远见性：市场在变

 

 

愿景-计划-优先级排列追踪-确定内容和发布日期-解决问题-PBI排序和维护-优化用户故事-反馈-接收、拒绝团队工作结果

 

 

不管到底能不能交付，不要插手团队的管理安排，破坏他们的合作关系。（。。。这个看具体位置吧……）

 

 

 

不要管理团队（脑力劳动者需要被尊重QAQ）

不要贪心（需求太对，没有时间优化）

 

 

PO 产品负责人 BA业务分析师

 

 

 

协作

客户（就是甲方）、用户：真正使用的人

 

与客户合作，高于合同与谈判

 

跟用户合作：

尽早介入，并持续合作（第一个版本完成后，就评审）

了解真正的问题

获取反馈

尽快发布，并频繁发布（要是过于简单，容易被抄袭，说明没什么过多的技术）

 

提正确的问题，获取用户有效的输入

客户想要用产品来做什么？客户使用产品最终得到什么？客户在使用产品的过程中的痛点是什么？

（更多用户？更多销售额？比竞品厉害？）

 

用户访谈：

开放式提问

5 why： 连续5次追问为什么

寻找例外，并跟踪原因

发现故事和特殊经历

学会倾听

 

九宫格——用户访谈实例

	问题	有什么问题吗？	谁受到此问题的影响	提出解决方案
开放式	告诉我关于 然后呢 得到故事
控制	有多少 多久一次 在哪里 得到事实
确认	你看我理解的对吗？ yes-下一个问题 no-回到开放式问题

       

 

要考虑到 不同干系人，不同干系人对产品的要求不同  

 

 

产品愿景：价值体现载体

 

 

 

需求工作坊，挖掘用户需求

 

 

根据任务场景写出用户故事

 

产品待办事项列表

 

 

先做最重要的选项

 

正常输入-正常输出，错误输入-错误输出，特殊情况

 

好的用户故事，要尽可能的独立，这一版完成就可以验收，一个小的业务流程

 

 

 

 

 

优先级：财物价值、成本（变更成本、人力成本、其他开销）、不确定性（产品的不确定性【拉长时间、增加人、写原型图来降低】、项目的不确定性）、风险（日程风险，成本风险，功能风险，技术风险，业务风险）好的风险，坏的风险

 

那个故事是重要的

评分法排列故事优先级

 

两个团队有相互依赖时，所以多个团队的需求要一起排。

 

SCRUM估算|故事估算法

 

用户故事：以用户的视角，描述一个功能在业务上的应用场景及目标

功能描述：以研发的视角，描述一个即将要实施的业务模块

 

工作量、复杂程度、不确定性

 

 

发布迭代计划

 

 

每次发布由多次迭代构成，迭代收到用户反馈以后再增加新的需求到需求功能列表

 

把骨架开发完，用户才能真正使用。端到端。但不一定足够完善和美化。需要后面去迭代。

验收标准。不能光开发不验收

 

迭代计划|确定目标及如何实施

 

每次迭代以后都会更新需求列表

 

 

 

澄清需求

 

 

概要设计拆任务

 

 

跟踪：

 

 

 

 

 

是不是真的满足用户的需要