敏捷需求管理（一）：从用户想法到Product Backlog

如何从最初的客户想法到持续维护的 Product Backlog， 大家的做法各有千秋。这里分享我们的一些做法，见下图：

第一步：独立需求。这里是从愿景开始，根据角色、行为、数据对象拆分为独立的需求

第二步：粗颗粒细化需求。这里的目的是为了分析成本考量，但并不是类似 Use Case那样的细化，只需要包含 90％的用户使用场景即可，有很多做法，其中一个是选择 3个 examples，一个 happy path，另两个是使用频率较高的异常流程。这里主要涉及的是商业规则

第三步：价值 /成本分析，这里要分析价值、成本，在此基础上再次拆分故事，最后完成优先级的排序

第四步： Velocity分析，目的是可以明白团队完成的速度

第五步：制定发布计划，根据发布目标、团队完成的速度，选择故事组，这里要考量发布目标会形成故事的耦合和依赖

第六步： PO组和开发团队分步进行故事细化和故事开发，这里要考量的是 Product Backlog的持续管理、大团队 PO团队和开发团队的协作方式等。

 

故事分为两种：一种是获得客户需求的故事，另一种是准备进入开发的故事。前者不需要细节，后者需要更多的细节。在开发团队进行迭代的过程中， PO团队同步在进行下两个迭代的需求细化，即 PO团队一定会比开发团队领先两个迭代。在 PO的迭代过程中，可以和开发团队的核心人员在一起讨论，讨论的内容包括： PO提供更多的选择，由开发团队从技术的角度反馈，然后约束 PO的选择。这个过程最好在迭代开始之前完成。开发团队在质疑需求的时候，可以从以下角度： Who（使用该需求的角色）是否有更多，他们对应的属性？、做什么、业务规则、业务数据、交互界面、质量标准等