正在阅读：经验之谈:我是这样领导一个学生项目的经验之谈:我是这样领导一个学生项目的

　　风险管理拖到现在才最终完成，主要是RMMM的问题，有几个人没弄清RMMM文档的部分内容的含义，有一个内容是风险跟踪，我的理解就是出现了相关风险情况时就加以记录，可是有几个人撰写的时候就在这儿胡乱填了一些东西，挺奇怪的，可能我没有交代清楚。英文的文档就是这个不好，大家沟通起来不方便，这有点违背了文档的本意。记得一本书上说过，如何避免陷入文档驱动的黑洞中呢，很简单，只制作对未来有益和利于沟通的文档，我觉得可以这么说，文档就是用来沟通的。既然英文文档不利于沟通（至少现在感觉上是的），为什么还要采用，呵呵，学生项目嘛，一个直接目的是获取高分，形式上的东西是必要的，尽管可能不很合适。我也不知道今后的工作中是不是一定要用英文文档，英文究竟占据多大的地位也不清楚，先在做些准备不是什么坏事。

　　现在Chief Architect开始进行设计了，因为我们赶上了预定进度，时间上宽裕了起来。我很相信他的能力，我想作为组长对组员的态度就是用人不疑。我很清楚为什么我会被推选为组长，因为我的设计和编码能力是最强的，我想大多数学生小组选组长都是这个原则。然而现在我不应该去做这件事情，尽管我很乐意，但这是对他能力的怀疑，是对他的不尊重，更何况他也有很强的实力。越权不是一个好主意。当然，我在交付给他设计文档模版时还是给了一些必要的思路和建议，比如按照MVC的要求设计类，比如底层的RMI机制。另一方面，在评审时我可以将我的意见提出来，有很多方式可以让我自己参与到设计中来，当然，前提是第一个版本一定要让该做的人去做，任何事情都一样。这是对制度的遵守，对人的尊重。

　　不幸或者有幸的，我现在正式成为了第二个小组的组长，这是一个本体采集小组，与现在的酒店管理系统有很大的区别，当然管理上的区别可能不是很大。之所以这样是因为软件工程的教师正是我今后研究生阶段的意向导师，他有意让跟他的四个人单独出来组个小组做个东西，一方面增加交流，另一方面可以尽早接触今后的研究领域。于是有了这个小组的诞生，我还成为了组长。时间分配可能会更紧张，毕竟两个组都不能出岔子，未来的两个月会很忙。同样的，学习的机会也更多了。第二个组的工作我又要重新开始从计划做起了，呵呵，希望自己能好运。

　　下一阶段的任务，设计，主要就是完成类图了，其他大的方面大家都心中有数了，就差类图了，然后可以开始编码，大约一周之后吧，五一之后完成编码吧，编码怎么分工我还没考虑好，有能力参与的有四个人，GUI只有我比较熟悉，我们拥有一个数据库专家，称之为专家是因为他的数据库编程经验在我们之中是最丰富的，另外的方面我还不清楚，我不很清楚大家在编码方面究竟有多大的能力和潜力，我不想走一步算一步，可能让每个人自己选择负责的部分是一个好主意吧。说实话，需求做得很详细，功能上还是要实现很多东西的，我不时地想起来，总觉得全部实现有困难，导师说过，这是一个允许失败的项目，我可不想失败。我现在能做的就是先去做一个原型系统，把界面大概勾勒一下，让大家心中有数，然后，我们开始。

　　忘了强调一下Rational SoDA，这是个很棒的文档自动化工具，可以和Rational其他的组件结合得很好，比如根据Rational Rose的use-case diagram可以自动生成相应的文档，很方便，很值得一试。

　　这一周是忙碌的。

　　需求分析基本完成了，use-case图几经修改，我们在绘制use-case之前进行过多次的讨论，试图完全明确所有的功能，然后再绘制use-case，企图一次成功，现在回过头看这个想法太天真了。不过经过充分的讨论，第一版的use-case已经基本符合要求了。大概是我们对use-case认识还不是十分明确，做出来的图比较简单，主要体现在各个用例之间似乎没有多大的联系，当然也可能是这个系统本身太简单的缘故。其实在刚做完use-case时，我们都以为这只是应付老师的一个图表罢了，对于项目过程而言没有多大的帮助作用，我仍然记得绘制图表的原则：只绘制对今后有用的图表。然而后面的分析设计中，这个use-case图却真正成为了我们的工作准则。因为这是一个经过充分讨论的成果，得到了所有人的认可，在后面的分析设计中，碰到过一些有争议的地方，一切符合use-case成为了事实的标准，然而这多少成为了一种约束，当然这种约束可能是有益的和必需的。不得不承认的是，这个use-case终究还是有一些遗漏的功能，然而我们后来在分析设计时发现之后，大家都不愿意再修改use-case了，因为相关的文档已经完成，加上时间紧迫，于是只能去掉那些可要可不要的功能，我们的借口就是：要符合use-case。这样做，我们事实上还是在采用瀑布模型，如果按照迭代的方法，这里是应当对需求分析进行修改的。幸好我们没有真正的客户，否则显然不能这么糊过去。自然的，我们失去了一次训练需求变更的机会，有些遗憾。反思为什么会这样：可能可以归结为时间不足，进一步考虑大概是因为进度表制定的不合理，再进一步考虑原因也许在于系统的范围还是定得太大了一点，使得我们的训练广度是保证了，然而精度不够。看来学生项目出于训练的目的，范围应当尽可能的小，甚至是一个HelloWorld都可以接受，因为项目的目的是尽可能熟悉和掌握软件工程的各个环节，软件本身不用很强大，想起一句话：麻雀虽小，五脏俱全。一个小的软件已经足以训练大部分的内容了。

　　需求文档也完成得很顺利，有了use-case一切都变得简单。对每一个use-case要做一个specification，也就是对它的一些简要说明、这个功能的输入输出、前置后置条件等等，这费了很大的功夫，犯过许多错误。一个典型的：我们需要将一部分信息组织成一个记录写入数据库，这个功能的输出（outputs）以及目的地（destination）是什么：起初的考虑是输出为信息，目的地是记录。然而后来发现这样似乎是有些荒唐的，因为输入也是信息，难道输入和输出不经修改是一样的，那这个功能还做了什么事情。后来改为了输出为记录，目的地为数据库，这是大家比较容易接受的结果，尽管我们也不很确定究竟怎么才算准确。想起以前和老师讨论一些问题时老师的一句话：当碰到两难时，
选择那种符合大多数人习惯，能让大多数人接受的方案。我想这里是适用的。

　　之后想起来应当做一份glossary（词汇表，或称为数据词典吧），就是对需求分析中用到的一些词加以解释，这些词可能贯穿于整个开发过程中，有这样一份词典后面看文档的人碰到陌生的用语时有据可查。这份文档做得晚了，我就被一件事情困扰过。我们做需求分析的组员对于“续住”这个功能（还记得我们做的是酒店管理系统吗）用的英文单词是continue，这倒无妨，只是我看文档时对着这个单词琢磨了半天也不能参透这个功能的意义，后来和她交流才知道是续住的意思，试想如果当时就有glossary将省多少事。更可怕的，如果我误解了后果将很严重（其实我起初的理解是由登录窗口进入主窗口，叫做continue，呵呵，幸好和她有一个交流）。