白话SCRUM 之二：product backlog

         在SCRUM方法中明确要求了3个文档：

          1 product backlog

          2 sprint backlog

          3 burn-down chart

        Product backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述，用户故事是一句简短的采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事。既然是故事，就要有人讲，谁讲呢，是product owner来讲，每次讲时可能就有细节的不同，就要有变化，但是万变不离其宗，所以故事本身是有一定的弹性的。故事可以有标准的格式，我称之为三段论式故事，哪三段呢？

          1 用户角色

          2 需要的功能

          3 目的

        比如，有这样一个故事：

            作为一个家庭主妇，我需要一个30平米的餐厅，以便于我可以招待10位朋友来用餐。

        用户角色是家庭主妇，30平米的餐厅是功能需求，招待10位朋友用餐是为什么需要这个功能。千万不要小看这个三段论式的故事，需要仔细琢磨每一段的作用。用户角色表明了是谁使用这个功能，如果一个功能没有明确的使用者，是否可以删除呢？如果一个用户角色不重要，是否这个需求的优先级比较低呢？目的说明了为什么需要这个功能，这个功能解决了什么问题，如果一个功能没有明确的目的，那是否可以删除呢？如果目的不太关键，这个需求是否可以优先级比较低呢？

        优先级？没错，我多次提到了优先级，需求一定要分优先级！谁来划分需求的优先级？Product owner！如何划分优先级？根据商业价值！根据对客户、对最终用户的商业价值来划分优先级。如何区分商业价值的大小呢？比如提问如果不实现此需求，如果晚实现此需求客户是否会不满意，是哪类人不满？不满意到什么程度？也有的专家提出了更专业的方法，其实没必要，如果product owner真的称职的话，相信他，可以凭经验划分出优先级。

        是否仅仅描述了这样一句话就充分了呢？其实还有第四段，即用户故事的验收标准，或者叫用户故事的测试要点，这也是由product owner来完成的，product owner可以先完成前三段，在和team member的沟通过程中，逐步丰富完善验收标准。对于前面我们提到的那个故事，如果你实现了这样一个餐厅，比如是一个2米宽，15米长的餐厅，那位家庭主妇会如何想？哈哈，如果她心理健康的话，估计她立马让你跳楼！如果她心理不健康的话，她会跳楼的。当然在敏捷的方法中不会出现这种现象，在你开发的过程中，product owner会和你随时沟通交流的，在沟通中product owner还传达了这样的信息：

             1我希望这个餐厅是5米*6米；

             2我希望这个餐厅光线明亮；

             3我希望这个餐厅靠近厨房；

            4 ......

        这就是验收标准！也可以换一种角度，从如何验收的角度的来描述：

            1 我会量量这个房间是否是5米*6米的；

            2 我会测测如果在这个房间里白天打扑克，不开灯的话，能否看到扑克的花色和点数；

           3 我会测测从厨房到餐厅需要走几步；

           4 ......

        如果一个故事提不出来验收标准怎么办呢？不实现它，晚实现它，直到明确了验收标准。

        到目前为止我们实际讲了在product backlog中包含了5段：

        Product backlog = 需求 + 优先级

                  = 用户故事 + 优先级 + 验收标准

                  = 用户角色 + 功能 + 目的 + 优先级 + 验收标准

        有的专家把验收标准单列出来，我认为验收标准是需求的一部分，只不过换了一种描述方式而已，所以还是作为product backlog的一部分吧。

        前面我一直在提“功能”二字，没有提非功能的需求，如果有非功能的需求怎么办？两种处理办法，一是如果能明确到某个故事，就描述在故事的验收标准中，二是写一个“技术故事”，单列出来，提醒开发人员注意这些故事，这个故事未必是product owner提出的。

         对于用户故事我们希望能达到如下的理想：

         1）独立性。尽可能避免故事之间存在依赖关系，故事间存在依赖关系会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。

         2）可协商性。故事是可协商的，故事是有弹性的，故事是需要讲的，不是必须实现的书面合同或者需求。

         3）对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。

         4）可预测性。开发者应该能够预测（至少大致猜测）故事的规模，以及编码实现所需要的时间。

         5）短小精悍。一般一个故事在一个迭代周期内一定是可以实现的，而我们提倡短周期迭代。

         6）测试性。所编写的故事必须是可测试的，能够定义出验收标准。

        注意，这是理想！

        Product backlog在项目进展过程中是会发生变化的，只有product owner有权来修改此文档。你可以用EXCEL文件来描述它，也可以采用一些敏捷项目管理的工具来帮助你维护，或者使用一些缺陷的跟踪工具如JIRA之类的，最直观的最朴素的办法是采用不干贴纸，直接贴在办公室的白板上，让大家都能随时看到！