【用户故事与敏捷方法 1】概要

产品需求工作首当其冲的是沟通。需要产品使用者的人必须同设计、开发该软件的人进行交流。产品需求工作做到位需要依赖很多不同的需求信息,这些需求信息来自不同的角色人员:一方是用户或者客户,有时还包括在分析人员、领域专家等;一方是产品设计人员;一方是技术团队;还有可能是销售人员。一旦有任何一方在沟通中把持绝对的地位,产品就会存在潜在的风险。如果用户或者客户把持绝对地位,他们就会关注自身个性化明显的体验需求,让业务变的复杂;如果开发人员把持了绝对地位,技术语言就会替代用户的业务场景语言,从而导致开发人员无法倾听用户的实际需求。

同时我们需要一种协同工作的方法,让双方都不占绝对主导地位,共同面对感情用事或者团队资源分配的问题。若资源分配完全落在一方,比如只让开发人员来承担这些问题(他们通常会被告知,例如:“我不关心你们怎么做,但请你们在6月份之前完成”),他们可能会牺牲质量来换取进度。如果让用户或者客户来承担资源分配的责任,那么我们常常会在产品项目开始时进行一系列蛮长的讨论,过程中会让一些关键的业务功能被忽略。

通常用户在看到产品的早期版本后,他们会想出新的点子,从而改变他们的看法(这样也包括产品的设计者)。这就造成了产品开发存在着无法避免的不确定性。在产品的最初设计时是无法完美预测产品开发的最终效果。这种不确定性是产品设计、开发人员最大的挑战之一。

那么我们该怎么办?

一般情况下,我们是通过我们已知的信息来做决策。但不要在产品初期就做一套包罗万象的产品功能设计决策。我们要把这些决策分散在产品迭代过程中,为此,我们需要确保在产品初期获取用户的有效信息,越早越好、越频繁越好。用户故事方法是这个过程中最有效的工具之一。

什么是用户故事?

用户故事描述了对用户有价值的功能。包括三个要素:

  • 一份书面的故事描述,用来做计划和作为提示。通常是描述客户的需求

例如,一个共享文件夹的用户故事例子,下列这些故事描述了用户对共享文件夹的需求:

“用户可以上传文件”

“用户可以查看已上传的文件”

“用户可以下载已上传的文件”

这些故事必须代表对用户有价值的功能,如果对用户无价值,就不是用户故事,例如下面这些:

“这个平台需要用Java来编写”

“这个平台需要用关系型数据库”

  • 有关故事的对话,用于具体化故事情节。

针对上面的“用户可以上传文件”仅仅依据这句话开完成设计、开发和测试显然无法实现,这里面包含了大量业务场景(可以称为Epic Story)的细节需要通过更小的故事来描述故事情节,例如:

“用户需要通过浏览器上传文件”

“用户需要选择多文件上传”

“用户需要上传文件夹”

“用户只能将文件上传到自己有权限的文件夹内”

等等,这些细节的小故事描述了用户在实际使用场景中更细致的需求。但我们需要注意的是,这里对大故事的分解需要把握一定的度,在产品初期无需对将小故事覆盖每一个业务场景细节。

  • 测试用例,用于表达故事细节且可以用于确定故事何时完成

产品的开发需要实现到什么程度?我们需要通过测试用例来描述用户的期望,例如针对“用户需要通过浏览器上传文件”,我们需要通过测试用例来描述,例如:

“用IE浏览器试一试”

“用Chrome浏览器试一试”

“用360浏览器试一试”

测试描述可以简短、不完整,可以在任何时候加入或者删除。写这些测试描述的目的是传递故事的额外信息,以便于开发人员知道用户的业务场景和预期。

未经允许不得转载:Mr.开发者 » 【用户故事与敏捷方法 1】概要

赞 (1)
分享到:更多 ()