• 白话SCRUM 之二:product backlog


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

    1 product backlog

    2sprint 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之类的,最直观的最朴素的办法是采用不干贴纸,直接贴在办公室的白板上,让大家都能随时看到!

  • 相关阅读:
    Go之运算符
    前端开发之工具库
    MVC与MVVM
    开发工具之Vscode编辑器
    常用名词汇总
    python常见错误总结
    Python之常用第三方库总结
    PHP程序员的成长路线
    web 应用常见安全漏洞
    redis和memcached的区别详解
  • 原文地址:https://www.cnblogs.com/morganlin/p/11986977.html
Copyright © 2020-2023  润新知