时间: 2021-07-30 11:22:55 人气: 9 评论: 0
敏捷项目以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。本文通过一个真实的案例介绍了敏捷项目的实践过程和产品经理在其中的角色和作用，与大家分享。
在敏捷交付项目中，PO扮演着重要角色。PO确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI（profitability of product）负责，是维护产品需求清单（ product backlog ）的人，代表利益相关者的利益。
PO在敏捷项目中的主要职责如下：
一句话总结PO的职责：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。
毫无疑问，这是一个impossible mission。先看着个需求是怎么来的。
笔者服务过一家做园林绿化的公司，这是一个传统行业，主要承接市政工程项目。老板在寻找新的市场机**，他看到了客户在信息化产品方面的需求，决定投入智慧园林产业。老板希望为客户提供信息化、智慧化的公园物联网平台和整体解决方案，以此增加公司的业务范围，为此公司成了新的智慧公园事业部。
在前期在经历了9个月的的探索并交付了一个内部用户项目后，并没有取得预期的成果，销售部门不知道该卖什么也不了解客户的需求，研发部门面临巨大的交付压力，老板对部门的整个部门的业绩不是很满意。
我作为新项目的高级产品经理，临危受命，目的是就是帮助老板探索新的市场机**，尽早推出产品，让销售的兄弟可以带着弹药上战场。
愿景是描述了项目的发起原因以及预期的最终状态。
–施瓦伯《scrum敏捷项目管理》
第一步是了解项目的需求。这里有两个主要的利益相关者，一个是客户，一个是老板。在经过两周的市场调研、竞品分析后，我决定对老板进行一次访谈以确定需求。经过访谈，确认了老板的关注点：
如果按照以下公式来”一键生成”产品愿景：
今天，当【用户群】 想要【期望的活动/结果】时，他们必须【当前的解决方案】 。
这是不可接受的，因为【当前解决方案的缺点】。我们相信有【一种体验/一个场景/一项服务/…，是令人向往的】，我们通过【技术/方法】达成它。
那么，本项目的愿景就是：”今天，当客户想要了解我们的产品时，他们只能通过画册的方式，这种体验不是很直观，他们看不到设备的状态和运营数据，我们要给客户一种更接近实际效果的产品体验，我们希望通过开发一个演示产品达成它。”
Got it，原来老板就是想做一个演示APP!
通过这个APP客户**可以进行浏览、拖拽、点击等交互操作，可以看到运营数据和设备的状态(演示数据)，甚至可到公园的视频监控画面(提前录好视频)。
本项目和BOSS沟通后决定采用敏捷项目交付产品，主要目的是:
敏捷项目有很多好处。其中一个就是交付可供客户使用和验证的最小可行性产品（MVP），获取反馈后再不断迭代改进，连接真实的设备和数据，最终打磨出真正符合客户需求的爆款产品。
在愿景阶段我们还需要确定任务角色和场景，以及发布产品路线图。
角色可以帮助我们确定目标客户，也就是“谁”的问题；场景可以是我们理解产品如何改变客户的生活角，确定“在什么情况下”“干什么&遇到什么问题”。可采用头脑风暴和业务场景技术确定任务角色和场景，本项目确定任务和主要场景如下：
接下来是创建产品路线图，产品路线图是产品需求的高层次概述，产品路线图 将用户关注点/主题按优先级排序，分成若干阶段，每个阶段都需要一个Sprint计划。创建产品路线图需遵循4 个步骤：
本项目是整个产品路线图的第一个阶段。
发布计划是宣布产品对外发布的时间和功能范围，大部分软件项目以每 2 到 6 个月作为一个发布周期，一般以产品开发线路图开始规划发布。
优先级排序是根据利益相关者的关注点(或主题）确定版本发布的计划。如何排列出关注点(或主题)的优先级呢？
这里推荐莫斯科规则（ MoSCoW ) 排列优先级的方法，MoSCoW将功能分为四类：
本项目讨论后确定的优先级如下：
团队所有成员一起选择一个适合的 Sprint 长度，一般建议1～4周。本项目的一个sprint的长度是2周时间，分成两个sprint，共四周时间。
（1）史诗故事(Epic story)
史诗故事是故事的主干，相当于用户故事的大纲。本项目把按照MoSCoW排序的关注点分解为20个用户场景，相当于20个史诗故事，每个史诗故事包括2-3个用户故事，一共是50个用户故事。
（2）故事点数(Stroy Point）
项目需要估计预算，所以需要估计工作量，这里用到了敏捷中的故事点数。故事点数代表了开发用户发故事所需的全部工作量，故事点通常用于评估交付产品的价值，也可以用于评估成本。
一般情况估算故事点是比较困难的事情，但本次项目比较特殊，由于只需要开发静态页面，所以工作量主要集中在设计和前端开发上。
团队很快确定了通过页面数量确定故事点数的方式，也就是先估计开发页面的数量，有个页面数量开发量就很容易估算了。也就是：
故事点数=页面数量*单个页面的工作量（0.5天）
本项目中每个用户故事分配了1个页面，每个页面分配了2个故事点，所以项目的规模在50个故事点数(相当于25人天)。有了故事点数再乘上平均人工成本，就很容易估算出项目的费用(主要是研发成本)。
最后一步是将 Story 按照优先级分别分配到每个 Sprint 中。有两种发布Sprint的方式，一种是钉在墙上这样可视化的方式让团队成员每天能看见。
还有一种是Leangoo这样的软件发布电子版本的Sprint计划(见用户故事一篇)。
迭代计划的目的就是确认每个sprint阶段的任务单（ticket）和优先级。这里要引入一个敏捷里的重要实践 – Spint **议，整个团队通过举行 Spint **议来为下一轮 Sprint 做计划，**议的内容包括：
（1）讨论故事
通常是对已经排好优先级的史诗故事和用户故事进行讨论，以确保成员理解开发任务。
（2）从 用户故事分解为任务单（ticket）
此步骤是将用户故事分解为颗粒度更小的任务单(ticket），通常写在一个人任务卡上。
（3）开发人员承担每个任务的职责
开发人员可以在分解任务之后对任务进行认领，每个卡**都需要有一个责任人。
（4）讨论所有故事，开发人员单独估计承诺他们的任务
每个开发人员对认领的任务进行详细估算，如果 Sprint 时间内估算**过了开发人员所能承担的工作量，有以下几种选择：请求团队其他成员接受一些任务；与 PO 讨论，放弃其中一个 Story （或者是分解后的一部分）。
Sprint评审的目的在于演示阶段性成果，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。Sprint评审在**议中向最终用户展示工作成果，并获得反馈，Sprint评审可邀请利益相关者参与。
本项目的Sprint评审在每一个Sprint发布后进行，由PO主持，主要评审人为BOSS、事业部主管和销售经理。
站立**议是scrum中的一个重要实践，也是笔者认为最容易推广和执行的敏捷活动。**议需要敏捷小组全员参加，**上每个人轮流发言，就4个问题回答：
如果有人在**议上提出工作被阻碍，PO在**后要及时解决**议上提出的阻碍，发现并解决问题是站立**议的主要目的。
站立**议一般是封闭的，只有敏捷小组成员参加，如果非团队成员闯入并发言，他**背上一个不好听的名字。
本项目的站立**议每天上午9点准时进行，效率很高，每次15分钟就结束了。每次开**的时候总感觉有一双眼睛在远处默默的注视着我们。
回顾**议在每轮迭代结束后举行的**议，目的是分享本轮迭代好的经验和改进点，促进团队不断进步。一般围绕着三个主题讨论：本次迭代哪些做的最好，哪些能做的更好，下一次迭代准备在哪些方面改进。
本项目最终比预期完了三天结束，尽管还有很多不尽人意的地方，但大家都全力以赴，最终结果也得到了公司的认可。回顾**上，大家也都表达了反思和收获，我能看到每个人都在进步和成长，我想这就也正是敏捷倡导的学习型组织的意义吧！
作者：涛哥，微信公众号：涛哥笔谈。前华为高级产品经理，TOGAF认证专家，PMP认证专家，PPV课数据科学社区创始人，数字化转型实践者
本文由 @涛哥 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
