2004中国软件技术大会 观后感(第二天)

《 系统级软件产品开发——管理与技术 》

一大早起床赶集，选的第一节就是朱律玮的讲座。

但是我听了半天才发现，我误解了演讲的题目了T_T

我本以为这里的系统级的软件，就是像服务器软件一类的操作系统级的底层软件。

到后来才发觉朱Sir讲的是企业应用平台这一类的软件。

……

…………

这分明是应用软件嘛！最多叫企业级应用软件，干嘛叫系统级软件呢@_@

 

讲座就在我脑袋混乱的期间悄悄地结束了，我只记住了一下三点： (^_^;)

一、为员工留下发展的空间，以免优秀员工因为无法继续发展而跳槽。

二、需求由支持部门和市场部门来决定。（我的理解：其实就是让需求尽可能的贴近客户）

三、评审的改进：进行评审一个月之前提交被评审的物件；进行评审一天之前收集完评审意见，并加以分级；评审的时候只讨论高等级的问题，保持评审过程短小精悍。

 

对了，其间朱Sir给出了一个项目组的组织方式。是一个简单的按职责划分的方式：

 

项目经理------产品经理

   |-----------------------QC

   |_________________________

   |            |           |

开发组长    测试组长    支持组长

   |            |           |

开发组长    测试小组    支持小组

 

个人感觉这种模式并不适用于大型软件开发。按照我的经验，可以采用如下的方式来组织：

 

项目经理------产品经理

     |___________________________________________________________

     |          |                |               |              |

     |      功能A小组长       功能B小组长    功能C小组长    功能D小组长

     |          |                |               |              |

开发组长----A功能开发人员---B功能开发人员---C功能开发人员---D功能开发人员

测试组长----A功能测试人员---B功能测试人员---C功能测试人员---D功能测试人员

支持组长----A功能支持人员---B功能支持人员---C功能支持人员---D功能支持人员

QC组长------A功能QC人员-----B功能QC人员-----C功能QC人员-----D功能QC人员

 

按功能划分（A/B/C/D）的小组长负责功能相关的事务——业务指导、工作分配、成果检查、进度follow等。

按职能划分（开发/测试/支持/QC）的组长则负责人员相关的事务——人员调度、技能培训、工作统合等。

这样，两种组长各司其职，形成牢固的矩阵，这样才能把大型项目的开发工作管理好。

 

 

《 Use Case实践的困惑与改进 》

尤克滨做的关于UseCase的精彩讲座。哈哈，赚到了！Lucky～～♪

尤Sir一上来就阐明了UseCase的本质：是场景和步骤，用来组织需求。

它既是一种沟通的形式（过程），也是一种信息的组织结构（结果）。

UseCase适于表述大部分功能性需求。

UseCase的适用环境是：

一、具有比较复杂的外围环境

二、系统与外围环境的交互由若干种典型场景组成。

UseCase不适用的环境是：

一、外围环境简单（没有必要）

二、典型场景不明确，存在大量可能的路径组合，比如IDE操作（无法表达）

UseCase就是为了把需求组织起来，达到条理清晰的效果。

要从用户的利益（而不是动作）来划分UseCase，

UseCase是随着对需求的理解深入而逐步补充、细化的。如果用户没有细致的想法，千万不要擅自加入自己的臆测。

同时提到了一个误区：好多人是把系统分析好了，然后才做UseCase。

这时和UseCase的目标背道而驰的。不是要用UseCase表达自己的想法，而是要用UseCase获取用户的想法。

需求和设计是在步骤这一层上对应的。

 

后来有一个人问尤Sir为什么UseCase图那么简单。尤Sir的回答我觉得不是很明确。

呵呵，按照我的观点，首先要阐明的是UseCase图不是UseCase。

UseCase通常是使用UseCase表格来定义的（执行者、前置条件、主成功场景、扩展……）。

而UseCase图则是把Actor和UseCase画出来，研究它们之间的关系，确认目前这些UseCase所代表的问题域是不是满足客户的目标景愿，是不是闭合（是否存在遗漏）。

因此，UseCase图是简单的，它附带的信息不是很多。

但是UseCase本身是需要细致定义的。这种复杂隐藏在UseCase表格中了。

其次，要阐明作为后续阶段的输入数据的是UseCase而不是UseCase图。

程序设计、编写帮助、制作用户手册、实施功能测试都需要使用UseCase作为输入，而提纲挈领的UseCase图对它们来说并没有太大的价值。

 

 

《 欲穷千里目，更上一层楼——搭建成熟开放Web应用框架，构筑强健J2EE企业应用系统 》

这是付金涛作的关于构架的演讲。

他首先分析了一下J2EE企业及应用的特点，然后列举了一些特殊问题，随即进入到Framework。

他把Framework比作企业应用的地基，列举了Web应用框架的优势：

1，通过重用提高了生产效率

2，降低了开发门槛

3，使用成熟的构架能够降低开发风险

4，提供可维护性

5，还能对系统进行统一规划，减少信息孤岛，提高整合度

随后分析了分层技术的发展过程： jsp --> jsp + servlet --> MVC

然后讲了一个大概的框架： 展现层 --> 交互层 --> 应用层 --> 领域层 --> 资源访问层 --> 资源。 

 

 

《 岔路口的抉择 ―― 在变革的前夜看软件业的技术突破方向 》

这个讲座很有意思。讲是马科讲的，但是稿子署名却是宋兴烈（12期程序员上有这篇文章）
呵呵，这又是一篇讲MDA的文章。

首先马Sir提出，软件业面临适应技术变化和需求变化的挑战。这既是方向，也是检验的标准。
然后指出分离模型与实现是迎接挑战的关键。同时介绍MDA的三个模型：PIM、PSM、CODE。
之后引用《人月神话》里布鲁克斯的话（所有软件活动包括根本任务——打造构成抽象软件实体的复杂概念，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言），指出表达模型才是根本任务。

我觉得到此为止没有什么新的东西。在热炒MDA之前，需求模型（夜幕模型）、设计模型、CODE三个层次的说法也是很流行的。
MDA最标新立异、骇人听闻的部分，也是最受争议的部分——模型间的自动转化马Sir还没有谈及。
这个问题网上吵得天翻地覆，我也层掺和着写了篇老长的文章说MDA（至少在近期）不现实。
首先是DMA倚赖的UML还不适于作精确定义，然后是软件开发不是简单的翻译型过程，最后是自动化不适用于高度定制的环境。

随后进入到了精彩的部分。
马Sir分析了3G语言问题。
软件的发展到目前为止都只是提升计算平台的抽象层次。3GL其主体手段就是采用过程性表达，用指令告诉计算平台如何做。3GL是贫语义的，它们的语义集中在计算上而不是业务上。目前已经有了许多领域专用的表达语言，比如SQL，比如工作流语言（XPDL、BPEL、XLANG、WSFL、BPML、WSCI）、规则描述语言、权限描述语言、页面描述语言等等。这些语言都被赋予了对应领域的具体语义。
但是领域通用的模型表达语言很难实现（UML也不太理想，所以才会打个OCL的补丁）。
目前的软件都是弱语义关联的，接口、API基本上不能提供语义约束。模式、IOC似乎减少了语言上的依赖，但是对语义依赖没有丝毫的改变。

听了这部分之后感觉经验值暴涨。这个东西与最近很火的DM（领域模型）、DDD（领域驱动开发）似乎也有暗合之处，唔，有抽时间好好研究一下。

 

《 下一代开放源码: 分布式协作与敏捷实践 》

灰狐的程勇在这里介绍了开发源码组织是如何进行协作开发的。

使用CVS进行代码管理，使用xUnit进行单元测试，使用Maven配置夜间构建，使用wiki共同编写文档，使用BBS/NEWS讨论问题交换意见，等等等等。
当然这些做法早已经过广泛宣扬，都是不是什么新idea。不过能够切实地实践这些做法的组织却不多。

《 成功走出死亡之旅——软件项目管理的奥秘 》

ちゃんちゃんちゃん～♪

新一代项目管理权威周浩宇所做的关于项目管理的讲座。

跟其他的人不同，周Sir的讲座热力十足，真让人怀疑他是营销出身的……

呵呵，反正我就从他的演讲中不停地联想到余世维——对了，还有那个幽默风趣牙尖齿利的独孤木。

周Sir首先分析了现状，列举了一堆统计机构的数据——绝大多数项目都是死亡之旅。

然后开始分析项目成为死亡之旅的原因：
1，政治斗争——急需业绩来挤垮对手
2，相关人员的幼稚陈诺——初生牛犊不怕虎，而且没有准确的度量方法
3，盲目乐观主义——这似乎是软件开发人员的通病
4，工作狂心理——据说在日本很普遍
5，残酷竞争——在高压力下的达尔文式的竞争
……
还有好几条。不过我听得太兴奋，反而不记得了 (^_^;)

之后，开始分析死亡团队的类型。
1，Mission Impossible型。这是一支梦幻团队去完成不可能任务的项目。比如施瓦辛格电影里的项目，比如《神偷谍影》里的项目，比如方世玉的项目。这些Team的Member都有超强的Skill，而且相互之间还有很好的Collaberation。
2，自杀型。这是一支由消极怠工者组成的团队。反正项目注定要失败，没有人期待它成功，那么在项目里浑水摸鱼，最后也不会被责怪。这种团队表面上看起来很忙，但是其实生产力很低。
3，神风特攻队。这是一支受到强烈的激励、所有成员都处于CPU热暴走状态的团队。他们会说：我们要打倒魔王，我们要救出公主！
4，珠峰症。这种成员对征服困难有一种难以抑制的狂热冲动。就算他们只穿这小裤头，他们也会义无反顾地去攀登珠穆朗玛峰。

接下来开始分析如何带领死亡团队。
1，Mission Impossible型的团队正如例子所示，都是一些名导+名角在荧幕上的演出，通常不会发生在普通人身边，所以可以不予考虑。
2，……（忘了……等拿到大会的VCD再重温一下）
3，对于神风特攻队队员，就要让他们足够忙，使得外界的不和谐音不能干扰到他们。
4，对于珠峰症患者，一定要替他们捎上棉衣棉裤窝窝头，以免他们在半道冻死饿死。同时，也要让他们一直确信他们在攀登的就是珠穆朗玛峰，以免他们失去兴趣撒手就走。

（此时会场气氛及其热烈，而我也进入的CPU热暴走的状态，所以接下来的内容就记不太清楚了）
接着周Sir开始分析方法、环境与人，指出流程不能决定行为，只有环境才可以。
然后介绍了一些项目管理方法（包括WBS），接着介绍了一种对应于敏捷开发的XPM——一种JIT PM，即时（Just In Time）项目管理。这种管理只做眼前的计划。
随后指出了一些项目管理的误区：
1，看重技术和工具，忽略基础
2，只注重执行，忽略理解和个人发展
3，看重流程，忽略人员差异
最后以《Is your lights on》这个故事作为结尾（什么时候扯到温伯格的书上去的！？看来我真的被侃晕了），在一片热烈的掌声中结束了这场精彩的演讲。