Axure下载
产品原型库
在线音乐
Axure函数
产品经理导航
加密解密
源码商城
原型商城
AxureShop
产品经理论坛
情趣用品商城

敏捷开发之产品经理需要懂的基本点

From babykoala与产品设计

敏捷:时间固定,产出不固定

瀑布:时间固定,产出固定

Scrum框架 :

成员介绍

敏捷教练(Scrum Master,SM)

熟悉开发流程的人员担任,一般由CTO兼任,主要职责为帮助team完成工作,提供支持,把控开发进度。

产品负责人(Product Owner,PO)

一般由产品经理或其他管理人员担任,确定产品的方向和愿景,定义产品发布的内容,代表利益相关者的利益。主要职责为收集需求,维护需求清单( product backlog )。

产品经理(Product Manager,PM)

开发人员(Developer,DEVs)

商业分析(Business Analys,BA)

测试人员(Quality Assurance,QA)

相关名词介绍

功能点(Story)

最小可测试的功能

产品列表( Product Backlog)

需求列表,需求的集合清单。

冲刺( Sprint Backlog)

要在冲刺中完成的任务的清单,通常时间周期在3周左右。

SCRUM框架下的流程

1.收集需求阶段

需求来自领导,团队,利益相关者,客户,用户等。将需求列入product backlog,产品人员需要对需求清单进行优先级排序,拆分成Story,绘制低保真原型图(无需详细文字介绍,口头可以描述清楚该需求功能即可)。

Story拆分最小颗粒标准:最小可测试的功能。

2.Groom Meeting

时间:固定时间(如每周二)

目的:评估backlog story pints

内容:

产品将最终修改的原型展示并讲解,同时对用户故事进行排序;

研发团队来估算具体故事点(1个故事点=1人天),一般取多数估的值,如前后端同时估点,分别估了1,3,3,5,那么取3,如果差值过多则由CTO确定最终点数(故事点并非准确的时间,而是该故事的难度,一般有1,3,5,8,13,数值越高代表难度越大);

输出:

输出为有排序的,有故事点的用户故事列表,称之为产品待办事项列表Product Backlog。为接下来的迭代计划会议的输入做准备。

成员:PO,SM,PM(BA),QA,DEVs

3.Sprint planning meeting

在每个冲刺之初,由产品负责人讲解需求,并由开发团队进行估算的计划会议。

时间:每个Sprint开始前几天

目的:承诺当前sprint完成的storys,bugs

内容:

产品提前准备本次Sprint中story的需求文档及原型图;

基于Groom Meeting产生的Product Backlog,根据优先级和时间,确定本次Sprint有哪些Storys,形成Sprint Backlog;

产品对本次Sprint每个Story进行需求宣讲;

Task Breakout即story分解为Task,包含UI,QA,前端,后端;

每个Task进行估算时间,需要精确到小时。

Task认领,定义验收准则(AC);

确定Deadline及Review Meeting,Retrospective Meeting时间;

输出:

Sprint进度甘特图(包含story中的每一个Task负责人,点数,开始时间,交付时间,进度情况,日期)

成员:PO,SM,PM(BA),UI,QA,DEVs

4.开发阶段

1.UI根据进行设计(此时QA开始写测试用例);

2.产品对开发进行详细需求讲解(在产品确认UI图之后,将Story中的前端Task部分交至相应开发任务栏中);

3.开发进行开发阶段(此时QA的测试用例写完,组织产品,该Story负责的开发进行测试用例评审);

4.开发完成Task,对产品人员进行Show Case,产品人员测试主要功能;

5.产品将Story提交给测试;

6.测试提bug,开发改bug;

7.回验;

8.产品确认可打包(Release)版本。

5.Daily Standup Meeting

每日站会,即每天早上团队进行沟通的内部短会。

时间:每天

目的:同步进度,汇报。

内容:

昨日做了什么,今天准备做什么,遇到的问题(会上不详细讲,会后找相关人员解决);

测试汇报昨日测出的bugs,待修复的数量,已修复的数量;

成员:SM,PM(BA),QA,DEVs

6.Review Meeting

时间:每个Sprint结束前

内容:开发给产品负责人演示开发成功并接受评价。

成员:PO,SM,PM(BA),UI,QA,DEVs

7.Retrospective Meeting

时间:每一两个Sprint

目的:提升工作效率,团队改进

内容:对一段时间的工作总结,对团队的建议,意见等

成员:PO,SM,PM(BA),UI,QA,DEVs

工具介绍

在这里笔者仅列举使用过的工具以作参考。

Teambition:需求清单,文件管理,Task领取,会议时间等

石墨:使用在线协同的Excel建立每个Sprint的进度图

禅道:bug管理、跟踪

Teambition

主要通过卡片的形式展示该功能所处的阶段

一般建立以下的栏:

Planning: 需求清单,产品人员将来自不同方的需求收集在该清单,并可进行优先级排序,需要产品在做好原型后将原型地址/文件以及PRD放在卡片备注中

InDesign:UI人员拿到原型图后会将卡片移动至该栏,视为正在设计

Ready To DEV:UI人员设计完成,附上标注地址,且将切图上传至TB文件,之后将链接附在备注中,供开发人员使用。(UI人员拖动至该栏)

In DEV:开发人员在开始进行开发时,在Ready To DEV栏领取自己的卡片,放在该栏,方便其他同事能够了解开始开发时间。(开发人员拖动至该栏)

Ready To Test:开发完成且已为产品show case之后,可进入测试的功能(开发人员拖动至该栏)

In Test:测试人员在开始进行测试时,在Ready To Test栏领取自己的卡片,放在该栏,视为正在测试中的功能。(测试人员拖动至该栏)

Ready to Deliver:(测试环境)测试完毕并回验没有bug,视为该卡片开发完成准备封包上线(测试人员拖动至该栏)

Deliver:线上环境已测试,已发布的功能(产品人员拖动至该栏)

石墨

目的为了给领导或老板来看本次Sprint的时间安排

表头:Story(对应TB中卡片编号)编号、需求名称、开发、开发工作量、测试工作量

同时在表格内标注出:本次Sprint的开发结束时间,测试结束时间,下次封包上线涉及到本次Sprint中哪些需求,下次封包上线时间

禅道

测试测出bug后新建一条待解决的bug当前问题描述、截图、期望描述,指派给负责人。

相关负责人将处理方法附在该条bug中,如已修改,则继续指派给测试,测试进行回验。

验收通过,则该bug应被标记为已关闭状态。

[创问]敏捷开发之产品经理需要懂的基本点
最后,介绍完了敏捷开发,这里还想总结一下,虽然敏捷对于互联网项目而言优点多多,但是瀑布也有自己的优点及适用范围,比如在建一栋楼,造一辆车,造一辆飞机等项目,一定是瀑布开发。

而敏捷式开发永远都是做优先级最高的用户故事。

最后编辑:2019年11月28日 ©著作权归作者所有

发表评论

×