基于对项目过去三个月从无到有实践敏捷的经验梳理，结合自己团队的现状、对于周边做得比较好的同学的观察，谈一谈作为PO怎么实践敏捷。
PO三板斧
PO在敏捷中有三板斧，做得好，个人及团队的整体目标感会好很多，团队的资源能得到更好的利用：
第一板斧是梳理用户故事全景，这需要溯源项目背景，思考未来，要对未来有一定的判断。能够基于调研，基于专业，基于客户价值，同时结合顶层的战略、公司的战役情况和组织的现状做分析。
当PO自身有了一个方向后，就组织团队全员参与，通过讲故事的方式，边拆边贴，拼凑出用户故事全景图。
第二阶段是找到首次发布MVP（最小可行产品）。这一部分非常关键，定义好MVP，哪些事情是不要做的也要讲明白。
这一阶段有时难以一轮解决，需要在调研、原型、反馈的循环中不断清晰和提升。
调研对象由PO去界定，一般是为产品买单的人，包括内部决定项目生死的高层，内部决定架构的领导，to C业务的场景客群，to B业务的公司代表等。
将MVP电子化，随着产品发布情况演变持续更新。
第三阶段是发出Sprint计划会议邀请。
何时进行下一轮迭代的计划会议呢？
答案是前置工作完成时。前置工作是指已拆分具体故事，准备好Product Backlog。
那产品负责人是以一人之力来形成Product Backlog的吗？
当然不是，有两大理由可以证明让产品负责人一个人来完成所有故事行不通：
（1）当需要一个人来完成使故事从模糊变成具体且可开发时，他/她往往会变成团队的瓶颈。
（2）一个人的知识技能和视野往往有限，做不到跨学科和多样化，因而无法得出最佳方案。
《用户故事地图》里建议的一个良好产品机制是：“一个由产品负责人带领的小型的、跨功能的团队来精心安排产品的探索工作。”
我们项目暂时不具备这样的团队，因而在具体实践中，我选择了把项目中其他人都转化为兼职产品设计师，业务、前端工程师、后端工程师、架构师、UI设计师等，我把模糊的故事贴在墙上，通过各种非正式场合的对话跟具备不同技能的人直接协作，明确细节，找出最有价值、可用、可行方案，之后按需准备文档及原型，这一过程贯穿在上一轮整个迭代周期内，当梳理到站在PO经验角度可落地程度时，再召集Sprint计划会议。这一方式可以彻底解决个人知识视野局限性的问题，部分解决瓶颈问题。
网友评论