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）讨论所有故事，开发人员单独估计承诺他们的任务

（编辑：西安站长网）

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