关于OOD的一点点总结

很多成熟的设计过程摆在面前：用例驱动、XP用户故事、特征驱动FDD、模型驱动MDD、敏捷模型驱动、领域驱动、测试驱动等等等等……到底应该怎么设计呢？
简单的讲，过程内容会分为需求分析和设计。
需求驱动是最根本的，所以在需求阶段，所谓的各种驱动方法其实都是对需求的功能分解，以便日后进行分治的设计以及管理跟踪。
由Use Case -> User Story -> Feature其实是由粗到细对需求分解的不同粒度。
有了需求条目之后，针对每一个条目可以继续进行设计工作。
设计过程的目标其实很简单：

• 类的识别
• 类的结构（例如：继承、关联、聚合、依赖等等）
• 类的属性
• 类的方法
• 系统运行是类之间的消息传递关系。

前三项是在整个设计过程中不断进行更新的，是个逐步细化的过程。分析的早期就可以识别大部分实体类，而在模拟需求条目的场景的过程中，逐步识别边界类（主要来自于页面流程分析）和控制类。主要的工具就是UML类图。
后两项则是通过模拟每一个需求条目所描述的场景来设计类之间的消息传递关系。在这个过程中，自然的完成对类分配方法。主要使用的工具如顺序图、协作图或者CRC分析。

对于MDD, AMDD以及DDD来讲，感觉上是针对非常熟悉的业务需求或者非常有经验的分析设计人员，因此采用了更新颖的设计路径。

而TDD应该理解为一种辅助设计手段。

在Iconix过程中使用协作图

ICONIX过程步骤如下

1. 系统界面原型，初步的领域分析（识别实体类，分析类之间关系，但不添加属性和方法），用例分析（仅关注用例内部的主干流程与分支流程，而忽略诸如前置条件、后置条件等细节）。
2. 健壮性分析（分析用户与系统类之间的关系，在此期间识别边界类与控制类），更新用例，更新领域模型（添加部分类属性）。
3. 详细设计（根据健壮性分析图而细化成顺序图，在此过程中给类分配方法），细化领域模型成为类图（静态模型）。

查阅了一些资料之后，有一个想法：
可以尝试使用UML协作图来代替顺序图。
因为协作图的样子本来就与健壮性分析图非常相似。这样，第2、3步仍然保留，但是产出物可以合并，即直接在健壮性分析图上面进行更新而成为协作图。
协作图中主要表现的是在一个场景中对象所拥有的职责（即所用到的对象的方法）以及对象之间的关联。这样看来，协作图所起到的作用与XP过程中所推荐的CRC分析是完全吻合的。
另外，对于普通的业务系统来讲，系统对时间的敏感程度并不高，这就增加的忽略顺序图的可能性。

如上，系统分析与设计的产物则为：

• 页面流程图与页面布局原型
• 用例分析
• UML类图
• UML协作图
• 部署图与组件图（可选）
  

在哪一个阶段画出操作界面

今天上午项目组内部开了一个会议，讨论需求文档的模板。大部分内容大家都比较一致，比如分成功能性需求和非功能性需求。功能性需求中主要以用例分析为主线，辅助以各个层次的工作流程图以及系统流程图。另外加入业务实体的各种信息等等。
但是在一个问题上面，项目组成员与我的引导无法达成一致：多数项目组成员认为系统操作界面不是需求阶段的产物。而应该是系统概要设计甚至详细设计阶段的产品。理由如下：需求的主要内容应该集中于业务分析，而系统界面更接近于设计的工作。而且在需求阶段需要画出页面的话，需求文档的工作量过大，需求评审阶段如果包括界面的话，那么需求阶段的时间会过长。
我无法说服大家的固有习惯，甚至无法说服大家仅仅写一些重要业务的操作界面。最终只能以大家的多数意见为准了。

这种情况显然是项目组内部对当前的OOAD技术缺乏经验所导致的。我的观点与大家相反，确认操作页面的工作越早越好！

• 需求分析需要分为三个层次：战略目标需求（高层访谈），业务逻辑需求（中层访谈）以及操作需求（一线操作层访谈）。
• 操作页面的确认工作应该是在需求访谈过程中同步进行的，而不是项目组内部闭门想出界面，然后拿给客户进行评审。
• 画界面的工作不会因为推后而减少。
• 需求访谈中对界面的访谈与分析有可能比用例分析还要早一步。示意图方式的界面会很大的消除需求的歧义。会给用户最直观的感受，是我们认识系统的第一个门户。
• 更早的对操作页面进行确认会减少项目的风险。如果在概要设计评审的时候发现有一些界面设计的不合适，然后发现修改这些页面居然还会导致上一阶段的需求分析结果进行改动的话，这样的返工成本就要大很多了。时间压力也会更大。
  

现在公司的项目管理方式

由于手头的项目非常庞大（基本上是50人的团队，1500万的合同），对公司有战略意义，又是新老板来了之后的第一个大项目，因此，管理层对项目非常重视，老板会亲自关注细节。因此，该项目需要做的非常“规范”！当然，如何规范是针对现有公司的标准来讲的。具体特征表现在：

1. 严格按照需求->概要设计->详细设计->编码->测试->发布的模式对项目进行计划。
   （听起来是严格的瀑布模式，呵呵，连一次迭代也没有。不过对于现在的公司来讲，能做到已经不错了。以前是基本没有设计阶段的，而且这次也会基本忽略测试阶段。）
2. 设计过程要求严格，例如一定要先搞出来物理模型并进行评审。然后再对各个模块的输入输出进行严格的定义。
   （典型的面向过程的设计方式。我了解了一下，公司的整个软件部门似乎没有几个人使用过UML进行系统分析与设计，更不用说更加激进的CRC分析之类的了。所以，理所当然，技术人员多数觉得JAVA框架中的ORM一层基本没有什么作用。当你告诉他们OOAD的过程中，物理模型有可能是最后一步时，很多人难以接受。）
   （我想主要的原因很可能是：现在公司的管理层和技术骨干主要都是在90年代末期参加工作的，那时候国内正是面向过程的流行时期。所以大家都已经习惯于这样的设计方式。然后就是这样一代一代的延续下来……）
   
3. 对文档的要求非常严格：包括在项目的第一周就需要提交细化到半年后的某一天的详细项目计划。而且各种文档名目繁多。
   （大家都听说过滚动式规划，但是做起事来还是如此。最后都变成了交差。）
4. 项目计划的全部意义就是那个*.MPP文档。而且一般需要维护1000～2000行吧。
   （既然老板是这样认为的，所以也就没有人敢质疑该如何维护2000行的project文档。）
   
5. 项目管理制度中规定：项目组内部沟通以正式的书面沟通为主，口头沟通作为辅助。
   （学过PMP或者对敏捷开发有兴趣的人会很吃惊是吧？）
6. 加班将作为项目组工作的一种常态。加班的目的是为了营造紧张的项目组内部的气氛。
   （为了加班而加班！当然也有一部分原因是客户造成的。客户是国家机构，嘴里高喊“深入实践科学发展观”，做起事儿来完全“人有多大胆，地有多大产”。）
   
7. 项目经理每天会忙于收发EMAIL，制定各种管理制度，以及制作各种报告等等。
   

不过似乎也不是一无是处，例如：

1. 公司里面有一些强人自己包装了SPRING，开发了很好用的MDA框架。
2. 老板亲自拍板，调集了公司最强的开发资源进入项目组。
3. 暂时不用考虑项目成本问题。
   

当面临的问题是生存时，任何承诺都是骗人的。

Google宣布：停止Notebook应用的开发，并停止其接纳新用户。

这让我想起了上一次的互联网泡沫破裂时的情况：263的老板在前一天还在信誓旦旦说要保留免费服务，转天就开始全面收费。

那一次事件之后，我对国内互联网服务提供商的信用彻底失望，虽然我不是受害者。从那以后我尽量会选用国外的服务提供商。

现在，在全球金融危机的影响下，大若Google都要出现类似的问题了。只不过，比起263，Google采用了很道德的方式。可以理解，当公司面临的问题是生存时，很可能别无选择。

我其实是非常依赖网络服务的：

• Gmail
• Google Bookmark
• Google Docs
• Google Reader
• Google Site
• Google Calendar
• Google Notebook
• Clipperz
• Dropbox
• Meebo
• 等等

这一次，我可有些害怕了。正在考虑一些desktop替代品。例如：

MS OneNote, Firefox, Keepass, Pidgin等等。还是自己的硬盘上的东东可靠啊。

项目才刚刚开始，就收获了不少教训！

CNPL项目才刚刚开始第一周，就收获了不少教训。

上周一的时候项目刚刚启动，PMO的人找我谈话，希望我能配合工作。我当然满口答应。

周二的时候，收到PMO发来的邮件，让我周四就需要提交：人力资源管理计划以及项目实施方案两个文档。这两个文档我在之前都没有听说过，仔细看了看PMO发过来的例子，才发现项目实施方案其实就相当于PMP中所说的完整的项目管理计划了。

于是加班加点写了所有能写的内容，周四的时候发了出去。其实这个时候需求访谈才刚刚开始，项目组内所有的人全都整天在客户方进行需求访谈。所以现在只能有需求访谈计划。我在发出去的邮件中还详细的注明了所有无法填写的内容的说明。

很快PMO就回了邮件，找出了很多问题。而且最郁闷的是，老板也回了邮件，针对我所注明的无法填写的内容一一批驳。话里话外好像是在说我的工作态度有问题。

于是我在周五的时候找我的二老板抱怨了一下。看来是传到老板耳朵里了，老板马上打电话过来安抚。而且，我看了一下老板批驳的邮件，还好，仅仅是发送给了我和二老板，并没有发送给PMO。所以心里也还好过了些。

由此事件，得出了以下一些教训：

1. 我本来真的很重视PMO的工作，因为我有8年项目管理经验，我是PMP，而且我也曾经是上一个公司的PMO部门经理。但是，现在在这一家公司，PMO的需求的优先级并不高，是很有协调余地的。前几个月我还在感慨这个公司对项目管理不重视，PMO的人地位也很低。现在看，可怜之人必有可恨之处啊。只给我两天的时间让我完成庞大文档，而且时机也很是不对，这让我不可能保证质量完成工作。
2. 我犯了一个错误：在项目初期就应该非常重视如何将工作分配到下属手中。
3. 我犯了另一个错误，在分析干系人需求时，非常重视客户方面的满意度，反而忽视了老板的需求。我本不该犯这样的低级错误的，可能是因为在这个公司当前的管理能力下，我对自己的管理经验过分自信了，以后一定需要注意。
4. 现在的客户的习惯是，一旦项目启动，就会立刻需要所有相关的文档。现在的公司也受其影响，老板养成相同的习惯。所以为了应对这样的特殊情况，需要在项目早期就写出非常详细的项目计划（甚至需要计划到9个月之后的某以前需要干什么）。当然，这样的文档没有任何实际意义，仅仅为了交差。而随着需求访谈的进行，项目范围渐渐明确了之后，才需要真正用功编写能够实际应用的项目管理计划。
5. 现在的环境下，项目经理管理工作还有更多的内容，甚至包括长期出差人员的住宿问题、办公场地的桌椅等等细节问题。这些在书本上是找不到的。