【在线研讨】《敏捷开发用户故事分类与组织结构（三期-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
这可以大大节约重新设计的时间。
好，设计的话题说到这里。