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

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

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应被标记为已关闭状态。

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

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