B端产品经理养成记（4）：访谈敏捷项目

这里推荐莫斯科规则（ MoSCoW ) 排列优先级的方法，MoSCoW将功能分为四类：

1. 必须有（Must ) ：指系统的基本功能
2. 应该有 ( Should ) ：很重要但短期内有替代解决方法的功能
3. 可以有 ( Could ) ：如果没有时间可以不予考虑
4. 这次不会有 ( Won’t have this time ) ：客户期望拥有但同时承认需要在后续发布中实现

本项目讨论后确定的优先级如下：

2. 选择迭代长度

团队所有成员一起选择一个适合的 Sprint 长度，一般建议1～4周。本项目的一个sprint的长度是2周时间，分成两个sprint，共四周时间。

3. 任务估算

（1）史诗故事(Epic story)

史诗故事是故事的主干，相当于用户故事的大纲。本项目把按照MoSCoW排序的关注点分解为20个用户场景，相当于20个史诗故事，每个史诗故事包括2-3个用户故事，一共是50个用户故事。

（2）故事点数(Stroy Point）

项目需要估计预算，所以需要估计工作量，这里用到了敏捷中的故事点数。故事点数代表了开发用户发故事所需的全部工作量，故事点通常用于评估交付产品的价值，也可以用于评估成本。

一般情况估算故事点是比较困难的事情，但本次项目比较特殊，由于只需要开发静态页面，所以工作量主要集中在设计和前端开发上。

团队很快确定了通过页面数量确定故事点数的方式，也就是先估计开发页面的数量，有个页面数量开发量就很容易估算了。也就是：

故事点数=页面数量*单个页面的工作量（0.5天）

本项目中每个用户故事分配了1个页面，每个页面分配了2个故事点，所以项目的规模在50个故事点数(相当于25人天)。有了故事点数再乘上平均人工成本，就很容易估算出项目的费用(主要是研发成本)。

4. 建立发布计划

最后一步是将 Story 按照优先级分别分配到每个 Sprint 中。有两种发布Sprint的方式，一种是钉在墙上这样可视化的方式让团队成员每天能看见。

还有一种是Leangoo这样的软件发布电子版本的Sprint计划(见用户故事一篇)。

5. 迭代计划

迭代计划的目的就是确认每个sprint阶段的任务单（ticket）和优先级。这里要引入一个敏捷里的重要实践 – Spint 会议，整个团队通过举行 Spint 会议来为下一轮 Sprint 做计划，会议的内容包括：

（1）讨论故事

通常是对已经排好优先级的史诗故事和用户故事进行讨论，以确保成员理解开发任务。

（2）从 用户故事分解为任务单（ticket）

此步骤是将用户故事分解为颗粒度更小的任务单(ticket），通常写在一个人任务卡上。

（3）开发人员承担每个任务的职责

开发人员可以在分解任务之后对任务进行认领，每个卡片都需要有一个责任人。

（4）讨论所有故事，开发人员单独估计承诺他们的任务

每个开发人员对认领的任务进行详细估算，如果 Sprint 时间内估算超过了开发人员所能承担的工作量，有以下几种选择：请求团队其他成员接受一些任务；与 PO 讨论，放弃其中一个 Story （或者是分解后的一部分）。

6. Sprint评审

Sprint评审的目的在于演示阶段性成果，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。Sprint评审在会议中向最终用户展示工作成果，并获得反馈，Sprint评审可邀请利益相关者参与。

本项目的Sprint评审在每一个Sprint发布后进行，由PO主持，主要评审人为BOSS、事业部主管和销售经理。

7. 站立会议

站立会议是scrum中的一个重要实践，也是笔者认为最容易推广和执行的敏捷活动。会议需要敏捷小组全员参加，会上每个人轮流发言，就4个问题回答：

1. 我们上次开会后你都干了什么？
2. 每个你负责的、正在做的任务还剩下多少时间？
3. 下次开会之前你要做什么？
4. 你的工作被阻碍了吗？

如果有人在会议上提出工作被阻碍，PO在会后要及时解决会议上提出的阻碍，发现并解决问题是站立会议的主要目的。

站立会议一般是封闭的，只有敏捷小组成员参加，如果非团队成员闯入并发言，他会背上一个不好听的名字。

本项目的站立会议每天上午9点准时进行，效率很高，每次15分钟就结束了。每次开会的时候总感觉有一双眼睛在远处默默的注视着我们。

8. 回顾会议

回顾会议在每轮迭代结束后举行的会议，目的是分享本轮迭代好的经验和改进点，促进团队不断进步。一般围绕着三个主题讨论：本次迭代哪些做的最好，哪些能做的更好，下一次迭代准备在哪些方面改进。

写在最后

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!