敏捷开发之产品经理需要懂的基本点
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应被标记为已关闭状态。
[创问]敏捷开发之产品经理需要懂的基本点
最后,介绍完了敏捷开发,这里还想总结一下,虽然敏捷对于互联网项目而言优点多多,但是瀑布也有自己的优点及适用范围,比如在建一栋楼,造一辆车,造一辆飞机等项目,一定是瀑布开发。
而敏捷式开发永远都是做优先级最高的用户故事。