【在线研讨】《敏捷开发用户故事分类与组织结构（三期-4）》

一期：活动描述，之一，之二，之三，之四，之五

二期：活动描述，之一，之二，之三，之四，之五，之六

三期：活动描述，之一，之二，之三，之四，之五

之四：非Web和非MVC的MUP设计思路

听说-码农-SH<xwj90@hotmail.com> 13:39:39 
问个问题，多少比例的项目都可以如此容易分解为这样的 {category}/{name}/{action}的模式 
我感觉过去 应该有一些项目没法这样搞 

陈勇-创业-北京(**9107533) 13:40:17 
@听说：是的，但是MVC架构的产品，都可以这样。 

tinny-PM-深圳(**722310) 13:42:10 
我们的内容管理系统可这样来做，但似乎到流程管理的系统，就不太容易这样做了。  

陈勇-创业-北京(**9107533) 13:41:08 
其他的项目，如果能说出你的“模式”，估计也能对应出一种方法。但如果模式本身说不出来，就无法对应了。 
@tinny：估计你们内容管理系统，就是基于MVC设计的。 
tinny-PM-深圳(**722310) 13:43:00 
是的 

陈勇-创业-北京(**9107533) 13:42:23 

“哪些项目可以对应”这个问题，取决于“哪些项目提供了其设计规则”，比如MVC是有他的设计规则的，我就能对应上；如果彻底没有设计规则，那也就没有对应可言了。 
听说-码农-SH<xwj90@hotmail.com> 13:42:32 
我们说的范围是不是仅仅限制于web ui项目？  非web ui似乎都不能这么搞 
陈勇-创业-北京(**9107533) 13:42:33 
这个不是用户故事树的问题，而是设计的问题。 

陈勇-创业-北京(**9107533) 13:42:59 
@听说：好，下面说一下非Web的做法。 
我们的这个思路，是在做一个Web软件的时候建立起来的，尚未在非Web上试验过（未来自己也未必有机会） 
但是，能看到一些“曙光”。 
比如，我们假设一个非Web乃至非UI的东西，甚至假设是一个DLL 
乍一看，这个DLL一点界面都没有，也没有可访问的URL链接。

但它一定包含很多Class，每个Class又有很多method，对吧？ 
其中一些public，一些private 但终究，这些方法要被调用。 
比如，我提供一个敏捷开发的DLL，你可以调用它来操作敏捷开发数据库。 
那么如果让我设计“创建用户故事”这个功能，我一定不会设计下面的类和方法： Agile.CreateStory(int fatherID, ...) 
而是会：Agile.Stroy.Create(int fatherID, ...)，Agile是个命名空间。 
为什么？ 
因为Agile本身太大了，里边的函数会多得让人发疯。那么切分到多大好呢？且分到一个上次提到过的（确切说在第一期活动里边提到的）业务数据作为类，是最好的。 

陈勇-创业-北京(139107533) 13:47:54 
所以，如果一个Web，我会用/Agile/Stories/Create?fatherID=...来设计 
如果是一个DLL，我会用Agile.Stroy.Create(int fatherID, ...)来设计 
两者，都遵循我们在第一期活动中提到的“业务数据-业务操作”的思路。 
陈勇-创业-北京(**9107533) 13:49:09 
这样，我们就能借用需求的管理方法，来直接生成设计。 

听说-码农-SH<xwj90@hotmail.com> 13:48:52 
那这种方式和传统的  面向对象/过程的类设计 以及命名规范/最佳实践比起来 的不同以及优缺点是？ 
陈勇-创业-北京(**9107533) 13:49:38 
@听说：这个方法，和面向过程几乎没有关系，但和面向对象很有关系。 
甚至说接近对等关系。 
听说-码农-SH<xwj90@hotmail.com> 13:49:53 
了解了， 是否可以归纳出 requriment-driven design 
tinny-PM-深圳(86722310) 13:51:44 
是的，其实业务数据就可归到实体类，面向这样的对象设计 
陈勇-创业-北京(139107533) 13:50:23 
业务数据 = 功能点分析FPA中的“文件” = MVC中的Controller = 面向对象中的类（Controller就是类） 
业务操作 = 功能点分析FPA中的“EI/EO/EQ” = MVC中的Action = 面向对象中的方法（Action本来也就是方法） 

陈勇-创业-北京(**9107533) 13:52:27 
MUP的创造之处在于：原来我们写Controller/Actoin/Class/Method的时候，是很随意的，可以随便写大写小；我们原来写用户故事也是很随意的，也可以随便写。 
结果是这些随便的东西碰在一起，就很难有明确的对应关系。 
而MUP中，利用功能点分析的业务数据/业务操作两个概念，将用户故事-MVC-OO这三个事情串联起来。 
串联起来的好处，就是编写代码的时候，会出现@听说说的那句话： requriment-driven design 
这可以大大节约重新设计的时间。 
好，设计的话题说到这里。