2011-04-25 18:48:00 cheny_com 阅读数 13092

       作者:陈勇

       出处:blog.csdn.net/cheny_com

      

用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现一直没有定论,只好在这里原创一下。

 

前言:为何需要讨论用户故事的颗粒度

 

其实需求颗粒度的问题由来已久,即使是在传统开发中,也没有提及在需求分析阶段应该把需求做到什么颗粒度才可以开工。所以在下面这些分析之后会发现,其实即使反推到传统开发中,下面提及的方法也依然有效。

为何要对用户故事做一个颗粒度约束呢?

笔者在开发实践中发现,如果大小不一的“用户故事”堆积在一起,很难看出一个产品到底实现了哪些功能(或一个项目到底有哪些需求)。如果回溯到敏捷开发的源头就会发现,由于敏捷开发中设定用户故事是为了描述开发任务(尽管是从客户价值角度)而非产品功能或项目需求,因此并没有区分用户和开发人员到底分别看到什么。

其实各种“用户故事”中,大致可以分为史诗Epic、故事Story、增强Enhancement、缺陷Defect、技术债务TechDebts、重构Refactor等几种。其中史诗和故事大致形成树状结构,很容易勾勒出产品或项目的结构,是最需要展示给用户的;增强和缺陷在一定程度上需要展示给用户,但除了评审中或交付后客户提出来的之外,都可以不展示给用户,而且即使展示,“展示”的层次也应该不同于史诗和故事;而技术债务和重构由于太技术化,不适合直接展示给用户,而更适合展示给Product Owner及开发团队。

本文所讨论的,就是用于“展示产品或项目结构”的史诗与故事的颗粒度问题。

好的用户故事的标准

 

先看看好的用户故事的标准(内容及观点与《敏捷开发与用户故事》中大致相同):

封闭性:完整地交付一个客户价值

针对性:只包含一个用户,因为多个用户常常有细微的差别

独立性:故事间没有依赖

这几条标准中最有价值的观点应该是独立、完整地交付一个客户价值,这在敏捷开发中是至关重要的。传统的开发会说要交付一个软件功能,而敏捷开发则认为用户必须使用这个功能以获得自己的价值(请回忆一下用户故事的编写语法)。

不过仅仅如此就说能方便地划分故事颗粒度,似乎还有点模糊,下面会引用两个成熟体系中对颗粒度划分的标准来做进一步说明。

 

功能点分析方法与用户故事

 

第一个是国际标准功能点分析方法(FPAFuction Point Analysis)中对内部逻辑文件及基本过程的定义。

内部逻辑文件-基本过程树是一个潜在的史诗-故事树的原型。

 

一个ILFILFInternal Logical File)就是一组逻辑上的数据,用户能够理解和识别它,对其进行的操作都是用户的业务操作。

比如如果我们要开发一个“Scrum开发管理平台”,那么有一些明显的“逻辑”数据:系统用户,用户故事,迭代,剩余时间……它们不同于数据库表或程序中的类,因为远在程序被设计之前,就可以判断它们是否存在。

一个基本过程(Essensial Process)就是对用户有意义的一次业务操作,在完成这次操作后客户得到其业务价值,而且数据稳定完整。

比如我们“增加一个用户故事”,需要完成的细节过程很多:显示输入界面,在界面中输入数据,数据校验,数据写入数据库表,显示“成功”信息……但只有这一切都完成,从用户角度看才能获得其业务价值,数据也才稳定完整,因此“增加一个用户故事”就是一个基本过程,而“数据校验”等则不是。

FPA定义中,基本过程还根据分为外部输入/外部输出/外部查询这三种。简单说,我们常说的“增删改查”都是基本过程。为了防止总是从技术角度谈增删改查,常常使用用户业务术语来描述,比如“起草”(输入)、“编辑”(输入)、“发送”(输出)等。

 

使用FPA中的内部逻辑文件-基本过程树作为史诗-故事树的颗粒度原型有下面几个好处:

基本过程有严格的定义,已经形成了ISO标准,歧义少;

基本过程面向客户价值交付,与敏捷开发的价值观接近,也很容易用用户故事描述;

文件和基本过程的数量被业界证实与软件的工作量有很好的对应关系,已经有多个国家如日韩澳荷芬等将其作为软件计价标准,工信部也已经进行国标立项,面向政府、银行、电信等大量软件外包场景中的造价估算,本文作者是技术专家组成员。

 

使用FPA中的内部逻辑文件-基本过程树作为史诗-故事树的颗粒度原型,将作出以下约束:

只有独立完整地交付一个客户价值才算是故事,而缺陷、增强等均不作为有效故事对待;

只有用户可以直接作为业务操作使用的功能(可以是人-机或机-机交互)才算是有效故事,“开发一个某某函数”(即使这个函数很有客户价值)等均不算是故事;

多个过程不能合并为一个故事,比如“……,可以对故事进行增删改查,……”。这样可以防止过于粗糙的功能描述阻碍用户价值的有效传达,也利于合理计算用户故事的数量。

 

MVC与用户故事

 

第二个是MVC中对ControllerAction的定义。

Controller-Action树是另一个潜在的史诗-故事树的原型。

FPAMVC居然能扯上关系?是的,上面提到的FPA中的内部逻辑文件,与MVC中的Controller有很好的对应(有的不能),而基本过程(输入输出查询)与MVCControllerAction有很好的对应关系。比如如果有一个“UserStoriesController”(UserStories可以看作ILF),就会有一堆Create / Edit / Delete / Index……这就是4个基本过程(从前面“增加一个用户故事”的例子可以看出,Create + [HttpPost]Create两者一起才组成一个完整的基本过程)。

基本过程对应Action还是好理解的,但为何对应内部逻辑文件的是Controller而非Model?因为Controller是面向用户写的,而Model是面向实现技术的。何以见得?因为如果要访问“增加一个用户故事”,我们会输入/UserStories/Create,而其中可能会用到几个ModelUserStories, Statuses, Priorities, Owners……用户无法直接访问Model,但可以直接访问Controller。所以MVCModel更像是DataModel,而Controller才是BusinessModel(有时不是),是“一组逻辑上的数据,用户能够理解和识别它”。

 

使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型有以下几个好处:

Action是一类特殊的面向用户业务和价值的函数,还是客户可以直接感知并调用的函数;

Action的数量多,客户可感知的功能一般也就多(相对于一般函数);

Action是一类可单独演示、单独测试的函数,很适合作为故事使用;

Action很容易被程序员所理解,使用MVC的程序员更容易回答“你们的软件有多少真正的用户故事?”。

 

使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型,将作出以下约束:

多个过程不能合并到一个故事中(与前面FPA的观点相同),因为不能用一个Action实现“增删改查”。

ControllerAction将只包含有意义的用户故事。有些程序员为了调用方便,会在Controller里定义一些不期待用户直接调用的函数(尤其是直接定义在controller.cs中),应挪到Model中实现。

 

 

限制与风险

 

实际上在FPA中,文件与基本过程并非树形结构,一个基本过程完全可能访问多个文件;而在史诗-故事树中,很多故事其实也是跨史诗的;只有MVC强制Action必须属于一个Controller,不过“故事结构 Category-Story”到底应该放在CategoriesController中还是UserStoriesController中?这是一个两难的选择。

此外FPA中整体认为OptionsConfig这类内容均非要被“卖给”客户的功能,因此不计算内部文件;但在开发中,却需要为其设计Controller来完成工作,两者立足点不同,处理问题会有所差异。

就像明明分子-原子-中子-质子-电子就可以组成世界了,但上帝还是“额外”设计了几百种夸克一样,关于史诗-故事的正确结构应该如何,与增强、缺陷、技术债务、重构的有机关系应该如何,这些内容的合理展现形式应该如何,还需要同行们更多的讨论。

 

后语:殊途同归的各流派思想

 

FPA,大致产生于1970年左右,由IBM的开发人员为了处理银行业务而产生,其目的是以一种客户可以理解的方式来描述和计数产品功能或项目需求。

MVC,大致产生于????左右,由一些软件开发者为了改善软件结构而产生,其目的是通过分离客户业务与实现技术,增强在客户业务变化时软件的可重用性、可维护性。

敏捷开发,大致产生于1998年左右,由一群资深开发人员为了改善繁重的开发过程而产生,其目的是减少不体现客户价值的中间环节和文档,快速适应需求变更,追求客户价值最大化。

但最后居然大致归于:

 

内部文件 ≈ Controller ≈ 史诗

基本过程 ≈ Action ≈ 故事

 

世界是没有银弹的,为了不同的目的不同的人发明了不同的方法,也遗留下不同的悬而未决的问题,只有各种方法互相包容借鉴,才可能发明出更加完善的解决方案。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2012-04-18 15:38:45 iteye_15987 阅读数 135
Murali Krishna告诉我们:
未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一 个用户故事都是一个“可独立分配”的需求(特徵)单位。要达到“可独立分配”,就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流,端到端(用户界面到后端)的功能单位。

原文:

Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is.

The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with.

最近开始有正规的敏捷开发过程管理,得到一个资深老大的指点,觉得有必要把这部分整理一下。

对于用户故事的理解
用户故事(User Story)是从用户的角度对系统功能的描述。所以,又被称为使用者故事。
尽管在敏捷实践的书中,认为用户故事应当由用户来撰写,实际上这个通常可操作性都不是很好。
这一点上,我觉得可以认为:用户故事就是开发人员(技术、产品)等对于用户描述的系统功能的理解。好吧,要承认,这个对于开发人员的要求大大的提高了,他不仅要能够与用户进行无碍的交流,还要求他有一定的专业背景(否则鬼知道用户在说什么),还要能够具有一定的抽象总结概括能力。

OK,这又回到了以往传统瀑布模型开发过程中需求分析阶段。

回顾下做需求分析的步骤和方法:
清晰定义角色与职责
准备工作:确定需求调查的方式,包括但不限于
1)与用户交谈,向用户提问题。
2)参观用户的工作流程,观察用户的操作。
3)向用户群体发放调查问卷(问题列表)。
4)与同行、专家交谈,听取他们的意见。
5)分析已经存在的同类软件产品,提取需求。
6)从行业标准、规则中提取需求。
7)从Internet上搜查相关资料。
如果要使用调查问卷,那么就需要事先准备。还需要与被调查者建立联系,确定调查的时间、地点、人员等。
执行调查,随时记录调查过程中所获取的需求信息。
分析需求信息,消除错误,归纳与总结共性的用户需求。
撰写用户需求说明书。
需求确认,邀请行业专家和用户(包括客户和最终用户)一起评审《用户需求说明书》。

一般而言,用户需求说明书都有特定的文档。通常,《用户需求说明书》主要内容包括:
•产品介绍;
•描述用户群体的特征;
•产品应当遵循的标准或规范;
•描述产品的功能性需求;
•描述产品的非功能性需求,如用户界面、软硬件环境、质量等需求。

在敏捷开发中,需求最终会被描述成User Story。开发人员依照用户故事中的描述估测完成所需要的时间,并指定该User Story的优先级。这样,最终,所有的User Story组成了Product Backlog。

** 关于Product Backlog的话题咱以后再说,今天只关注User Story。

[b]怎么写用户故事?[/b]

在敏捷中,用户故事是最基本的设计单元,它是从用户的角度出发对功能的一段简要描述。啰嗦一下,用户故事是轻量级的需求描述。用户故事没有什么强制性的语法。但是,按照大致符合这样一个形式来考虑用户故事是比较有益的:

作为【用户的类型】,我希望可以【先这样做,然后那样做,就应该得到...的结果】以便【业务价值】。


例如:“作为购书者,我希望可以根据ISBN来找到一本书,以便能更快的找到正确的书。”

在做用户故事时,需要注意每个用户故事用的是用户的语言,它只描述一个功能(feature),而不要涉及设计或实现上的内容。

从这个角度来说,用户故事应该是直白的。换句话说,它应当是个阐述句,其中应当尽可能少用形容词。它应当一眼看上去,就能明白需要做什么事情。

一般而言,每个用户故事的开发周期不要太长(1-5天),否则用户故事应当切分为多个子用户故事。

不需要一开始对所有的故事都进行详细的描述,但计划放在下一个sprint中的故事应该比较清楚。

在文章Advantages of User Stories For Requirements(http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements)中指出每一个用户故事都包括三方面:
Written description of the story, used for planning and as a reminder
Conversations about the story that serve to flesh out the details of the story
Tests that convey and document details that can be used to determine when a story is complete

[b]用户故事的优点[/b]

在文章Advantages of User Stories For Requirements(http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements)中讨论了用户故事相比较与传统需求用例的优点,包括:
精确(Precise):用户故事强调说话沟通,文字语言而往往不仔细。We act as though written words are precise, yet they often aren’t.
可以很好的预估开发计划。Useful for planning:user stories are written so that each can be given an estimate of how difficult or time-consuming it will be develop. Use case, on the other hand, are generally too large to be given useful estimates. Also, a story is implemented all in a single iteration of an agile project, while it’s common to split a use case across multiple iterations (even though those iterations are usually longer than on a story–driven project).
推迟考虑细节(Spare me the details):在一个长周期的项目开始时,团队只需要建立一个目标级的用户故事后就可以开始开发过程。在需要时,再考虑用户故事的细节,把它拆分为多个更细的子用户故事。User stories encourage the team to defer collecting details. An initial place–holding goal–level story (“A Recruiter can post a new job opening”) can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification.

[b]用户故事的缺点[/b]

Alistair Cockburn,另一位敏捷社区内的名家,从他过往使用用户故事的经验中指出使用用户故事所遇到的问题:

用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情,这行动的内容前文后理,以及在这一刻的高层目标。
用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加,犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢?
跟 完整性有关的是,用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度(原则上他们可以, 只是实际上他们不行)——我不断收到这样的投诉,「我们问客户 (产品负责人)一条问题,他/她用上两星期时间才回覆我们。我们找错了人吗?」不是,他们没找错人,他们是过程出问题——有些问题需要长时间研究,因为不 同部门和用户组要找出什么是正确,平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易,那一个较困难,再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到,这已经太迟。

原文:http://yiqijuechen.blog.51cto.com/605025/441740
2019-08-23 10:09:48 bfqs1988 阅读数 22

最近想学习下项目管理方面的方法论,找PMO借了一本书《用户故事与敏捷方法》 。两天看完,觉得有些内容还是挺有用的,虽然参与敏捷开发模式有两年多时间,实操和业务流程都会,但再回过头看一些理论,会有一些新的启发。特地做了一下笔记。

2019-8-21

第1章 概览

一个需求可被认为是故事(Story),如果一个故事很大,可称之为史诗故事(Epic)

Epic>Story>Task

 

第2章 编写故事

在这一章中,我们将关注故事编写。 为了构造好的故事,我们关注六个特征。一个优秀的故事应该具备以下特点:

独立的(Independent)

可讨论的(Negotiable)

对用户或客户有价值的(Valuable to Purchasers or Users)

可估计的(Estimatable)

小的(Small)

可测试的(Testable)

《探索极限编程》和《重构工作手册》的作者BillWake,建议用英文缩写 INVEST来代表这六个特征(Wake 2003a).

 

可估计的(Estimatable):如果故事无法估计会因为开发人员不张我所涉及的技术,可让一个or多个开发区进行极限编程(XP)中所谓的探针实验(spike),探针实验限制一个最大时间量(时间箱,timebox)。

一个不可估的故事变成2个:

1、一个快速的探针故事;

2、一个故事(真正实现功能)

备注这两个尽量放在不同的迭代中

 

小的(Small):分割故事:史诗故事通常分为:

复合故事(compound story):由多个小的故事组成的史诗故事

复杂故事(complex story):其本身很大且不容易分解的故事

 

故事太小可合并故事

 

第3章 用户角色建模

用户角色 角色建模的步骤:

1、头脑风暴,列出初始的用户角色集合;

2、整理最初的角色集合;

3、整合角色;

4、提炼角色

两个额外的技术:

1、虚构人物(最常用的用户);

2、极端人物(最少用的用户),但投入大量时间不值得

 

第4章 搜集故事

引出和捕捉是不合用的

方法:

1、用户访谈;开放式问题和背景无关问题

2、问卷调查;不建议捕捞故事使用

3、观察;

4、故事编写工作坊

 

第5章 与用户代理合作

用户的经理、开发经理、销售人员、领域专家、市场营销团队、以前的用户、客户、培训师和技术支持、业务分析师或系统分析师、设立客户团队

 

第6章 用户故事验收测试

在写代码之前写测试

客户定义测试

测试是过程的一部分。而不是编码完成后要做的事

测试类型:故事测试主要是功能性测试

1、用户交互测试;

2、可用性测试;

3、性能测试;

4、压力测试

 

第7章 优秀用户故事准则

从目标故事开始

切蛋糕(将大故事分解成小故事)

编写封闭的故事

卡片约束(必须要遵守而不需要直接实现)

根据实现时间来确定故事规模

不要过早涉及用户界面?

有些需求并不是故事

在故事中包含用户角色

只为一个用户编写

以主动语态编写

由客户编写

向故事卡编号说“不”

不要忘记意图

 

第8章 估算用户故事

故事点(story point),NUT(Nebulous Units of Time),一个故事点的工作量作为一个理想日的工作。

小结

用故事点估算故事,故事点是故事复杂度、工作量或工期的相对估算。

应由团队估算故事,估算属于团队而不是个人。

通过和其他估算进行比较来进行三角测量。

团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率,

不是他们的估算。

 

第9章 发布计划

什么时候发布?发布哪些功能?

排列故事优先级(成本改变优先级,如一个次重要功能需要开发时间较长,则可降低优先级)

混合优先级。如果在确定一个故事的优先级时遇到问题,可能要分割故事

高风险故事

根据架构需要安排优先级

选择迭代长度。迭代长度一般1至4周,如果不确定则尽量选择短迭代,因为长迭代更容易犯错

从故事点到预计工期。初始速率:1、使用历史值;2、执行一轮初始迭代,使用那轮迭代的速率;3、猜测。

创建发布计划

 

第10章 迭代计划

迭代计划概览

迭代计划会议一般内容:

1、讨论故事;

2、从故事中分解出任务;

3、开发人员承担每个任务的职责;(一旦确定故事的所有任务,需要所有团队成员自愿执行任务,认领。迭代期间可以调整)

4、讨论过所有故事,并接受所有任务后,开发人员单独估计他们承担的任务。

估算并确认

 

第11章 测量并监控速率

测量速率

计划速率和实际速率

迭代燃尽图(每日燃尽图反映的是剩余工作量,而不是在一个故事或任务上所花费的工作量)

小结

计算速率时只考虑那些已完成的故事,即通过验收测试的故事。 不要计算迭代中团队未全部完成的故事。

为每轮迭代计划和实际完成的故事点数画图是监测实际和计划速率区别的好方法。

不要在一两轮迭代后就忙着预测速率趋势。

完成一个任务或故事所花费的实际小时数对速率没有影响。

在大家都能看到的公共区域贴一些大而可见的图。

累计故事点图很有用,因为我们可以从中看出每轮迭代中完成的故事点。

迭代燃尽图展示了用完成的故事点表示的进度和剩余故事的改变。

每日燃尽图在迭代中十分有用,它展示了迭代中每天剩余的小时数。

设计及检测一个平均每个故事点出现的缺陷数目的图表可以帮助我们发现团队速率的提高是不是以牺牲质量为代价。

 

第12章 故事不是什么

故事区别于其他三种常见的需求方法:用例(use case)、IEEE830软件需求规格、交互设计场景

用户故事和应用里场景类似,但用例往往比单个故事要大

 

第13章 用户故事的优势

有那么多各种各样的处理需求的方法,为什么我们要选择用户故事?本章我们会看看与其他方式方法相比,使用用户故事到底能带来哪些好处.

用户故事强调口头沟通。

人人都可以理解用户故事。

用户故事的大小适合做计划。

用户故事适合于迭代开发。

用户故事鼓励延迟细节。

用户故事支持随机应变的开发。

用户故事鼓励参与性设计。

用户故事传播隐性知识。

 

讨论完用户故事的种种好处之后,本章结束时会给出用户故事几个潜在的不足:

1、在大型项目中,故事之间关系可能错综复杂;

2、开发过程规定要有需求的可追溯性,离不开额外的文档;

3、不适用于特大规模多团队的结构

 

第14章 用户故事不良症兆一览

小结

在本章中,我们了解了以下一些不良症兆:

故事太小

故事互相依赖

镀金

故事中包含太多的细节

过早包含用户界面细节

想得太远

故事划分太过频繁

很难为故事安排优先级

客户不愿意写用户故事,为故事安排优先级

 

第15章 Scrum与用户故事

Scrum 是一种迭代和递增的过程。

Scrum每30天一轮迭代,称为Sprinto晴公珍黛 品气课馆画食外必类人

ScrumMaster相当于传统的项目经理,但更像是领导者和组织者,而不是经理。

一般的Scrum团队包括4~7个开发人员。

产品 Backlog 是一个待开发的功能需求列表,里面的条目要么还没有实现到产

品中,要么还没有计划在当前 Sprint 中开发。

Sprint Backlog是一个团队承诺在当前Sprint完成的任务列表。

在极限编程里面的客户角色,在Scrum 中称为产品负责人。

产品负责人负责给产品Backlog排列优先级。

在Sprint开始,团队从产品Backlog中选择下一个Sprint要完成的任务。

在每日Scrum简会中,每个团队成员需要回答三个问题:我昨天完成了什么?今天我要做什么?我碰到了哪些问题?

每个Sprint都要完成一部分可以潜在交付的产品功能增量。

在Sprint结束时,团队在Sprint评审会议上演示所完成的功能。

 

第16章 其他话题

处理非功能性需求

纸质还是软件?看具体情况

用户故事和用户界面

保留故事(卡片)

把小的缺陷报告用一个封面故事卡装订在一起,并把他们当成一个单一故事

 

第IV部分 一个完整的实例

第17-21章 举了一个购物网站的项目例子

2011-10-12 23:45:45 cheny_com 阅读数 6694

这是敏捷开发日常跟进系列的第五篇。 (栏目目录

 

用户故事和MVC没有关系,因为MVC是实现方法,因此在思考用户故事的时候,不要一下就想到实现方法,很容易把故事写坏。

但是MVC和用户故事有很大的关系,如果用户故事写好了,做MVC的时候,一定要记得参考用户故事。

本人在C++的年代用过MVC,但那个时候MVC还只是一种编程思想,说用了也行,说没用也行。但到了C#之后,就出现了正牌的自称是MVC的东西(现在最新版本是MVC3),本人也在用。Java世界也有MVC的概念,但是没有见识过,下文中所描述的MVC,若没有特殊说明,均指Asp.net MVC;但相信对Java中的MVC也有借鉴意义。

利用MVC实现用户故事的技法

如果您已经认可之六中产生用户故事的方法,那么也就得到了这样的一个用户故事树,右边则是为其量身定做的Controller-Action(来自实际项目): 

======================================

下面是对应的Controller-Actions

UsersController

--Users/Index

----什么也不是

--/Users/Details

--/Users/User2Authorities

--/Users/Users2Roles

--/Users/Freeze

--/Users/Edit

--/Users/Delete

--/Users/BatchCreate

RolesController

--Roles/Edit

--Roles/Details

--Roles/Delete

--Roles/Index

AuthoritesController

--Authorities/URA

--Authorities/Delete

--什么也不是

--Authorities/Index

----什么也不是

--/Authorities/Authorities2Roles

--/Authorities/URGA

=============================================

注意看每个Controller实现了一个史诗故事(要管理的数据),每个Action则实现了一个(偶然多个)用户故事(用户的业务操作),有几个值得注意的地方:

1. 一个Controller几乎正好可以实现一个史诗故事

2. 一个Action因为正好是一个动词,所以几乎正好和一个用户故事对应。

有两个地方违反了,如“角色首页(新建+查看)”和“权限首页(新建+查看)”,因为为了方便我们在两个Index里边放了个新建用的TextBox,方便直接创建(因为角色和权限都只有一个名字而已,所以觉得犯不上做个独立页面了)。

为了能记住这一点,我们在故事的缩写名字上加了(XX+XX)的标记,为了日后能自动计数故事。

3. 用户没有“创建”故事,也没有Users/Create,因为用户只有两种正常的创建方法:Register和BatchCreate,我们选择了后者。因此既没有“创建用户”这个故事,也没有“/Users/Create”这个Action。

4. 几个绿色箭头是“增强”类型的故事(详见之五),它们正好也不对应Action。

 

上面提到的是我们实际的一种用法,未必是普适的但在我们项目中非常适合,甚至应该称为“舒服极了”。

这种史诗-故事与Controller-Action之间偶然的巧合,实际上背后有其必然性。

利用MVC实现用户故事的心法

MVC以往研究的重点,是何为M,何为V,何为C,以及三者之间的关系。

我们在用了一段时间后,发现其中的每一个,都还有更深层次的理念在里边,这里谈的就是Controller及其Action。

在MVC三者呆在一起的时候,问:何为Controller?估计还是挺容易回答的。

但如果不提MV,直接问:何为一个Controller?何为一个Action?却挺难回答的。

如果去一个非MVC的网站或软件,最令人烦恼的,是网站的每个页面未必有自己独立的链接,比如逛了半天,顶上的链接一直是http://xxx.../login=xxxx,想为某个页面加个收藏夹都不行。MVC在很大程度上解决了这个问题:要操作的数据是Controller,要做的操作是Action,而参数则是具体操作谁,比如/Users/Details?user=cheny或CSDN博客上常见的:http://blog.csdn.net/cheny_com/article/details/6616794 样式。

所以如果已经按照之六中提到的数据-操作方法来组织史诗-故事结构了,而且又在使用MVC,则非常推荐编程时将其继续映射到Controller-Action中

可能细心的读者已经注意到本文图中有些故事后面有个链接符号,那个正是我们在已经实现了的即金色的故事的后面,加上了其超链接(全部是/Controller/Action,一一对应,非常舒服)。这相当于一个Action写好了,一个故事(偶然情况是多个)就正好也完了;而测试人员就可以点击那个链接去到Action测试。他测试完了Action,就能说故事被测试完了(而不只是Action被测试完了)。

以这种方式来对应用户故事和开发内容,产品经理和开发人员很容易沟通,因此非常推荐使用。

 

用户故事 vs. FPA功能点分析法 vs. MVC

☺ 功能点分析法(FPA)、敏捷开发用户故事、Asp.net MVC在一定程度上具有相同的目的:作为用户需求与开发人员工作的桥梁,只是侧重点有所不同。因此若能将它们联合应用,就可能用一种组织方式贯穿性地管理估算、需求管理、架构设计三者。

完整地表述三者的关系,大致如下:

 用户故事FPAMVC
数据史诗故事

ILF内部逻辑文件

EIF外部接口文件

Controller
操作普通故事(功能)

EI外部输入

EO外部输出

EQ外部查询

Action

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

没有更多推荐了,返回首页