陈勇的博客 - Scrum 敏捷开发培训咨询,绩效管理,团队管理,《火星人敏捷开发手册》...

敏捷开发培训咨询 敏捷开发免费工具 免费培训教材《火星人敏捷开发手册》 IIOM咨询总监 火星人首席架构师兼主程序员...

敏捷开发日常跟进系列之五:用户故事与MVC

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

 

用户故事和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

 

 

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

 

阅读更多
想对作者说点什么? 我来说一句

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

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭