流光溢彩

GdieOA项目进行了有3个多月，整个项目组成员废寝忘食全力以赴，不可不谓辛苦。然而最终的效果却不尽人意，付出了比别人多许多却比别人差许多，这实在是一件令人痛心的事。我想每个人都应该从这次项目中吸取足够的经验教训，避免以后再出现这种情况。沉思良久，我总结失败原因主要有以下几点：
1．没有认真做好需求分析。由于种种原因，GdieOA项目刚一上马整个项目组成员便忙于编写代码，这种看似赶进度的方法结果恰恰适得其反。由于需求不明确，大家都是通过对照原javaoa项目的功能进行编码，但这样往往会忽略各个模块之间的深层关系。
      我记得在Samland第一次拿代码回去的前4天，vince突然跟我说他有一个模块发布的功能，而当他的Department发布后会插入到我的module表中且顶层module的parentid会置为null。因为之前我在做module的时候是没有考虑将顶层module的parentid置为空的，急得我只能在接下来3天拼命地对我原有模块进行修改。这工作量不亚于重做这个模块。我想如果我们大家之前把需求都能明确下来，各人了解各人的模块需要什么操作，这些操作会怎样影响他人的模块，而他人的模块又会怎样影响到自己的模块。在全面理清这些需求后再进行编码，往往可以事半功倍。

2．对项目采用何种技术需要认真斟酌。我记得软件工程七大原则中有一条“尽量采用新技术进行开发”。但我想采用新技术也是有条件的，若条件不符合就盲目追求新技术这样是很危险的，尤其是当项目组中没有一个人算得上完全掌握这种技术的时候。
      我想采用新技术至少应考虑下面几个因素：
      1)  新技术成熟度。一个技术的成熟度很大程度上影响了其可使用度。如果技术不成熟，到处找不到有关文档，使用后也不知道有没有副作用，又或者必须牺牲其他性能来换取当前功能的实现，这时这种技术使用起来就很困难，也难以让人放心。
      2)  新技术的可掌握程度。在这里我指的是项目组成员掌握新技术所需的时间、精力和其他代价。当项目组是一边学习一边开发时，这是个不可忽视的因素，因为这将直接影响甚至决定项目能否按时完成。如果项目进度较紧而新技术掌握起来需要相当一段时间，那么此时不推荐使用新技术而应采用其他替代技术。
      3)  新技术的实用性。当然，采用新技术很大程度是因为人们追求新技术带来的新特性和新功能。在某种情况下新技术能提供给我们无以伦比的便利性和旧技术无法比拟的强大的功能，这可以使我们顶住前面两个因素的压力不惜一切去学习并采用新技术。如果这种技术的功能实在是“十里之内只此一家”，那么采用它也是无可厚非的事情。但我想这时候项目的组织者应该充分权衡整个项目的可操作性和开发难度，根据新情况修改项目计划，使项目开发有条不紊，忙而不乱。
      当然应考虑的因素远不止以上几点，但咎于本人才疏学浅目前只能想到这些。把话题说回到GdieOA，一开始选择JSF想必大家都没什么非议，因为一方面是可以学习多一些先进技术的理论，另一方面更可以利用这个项目好好实操一番。然而一个计划为两个月的项目，使用一个星期时间自习，一个星期时间培训，一个星期时间适应，我想这个代价实在不小。这明显违反了上述的第二点。而相比之下，JSF并不是一个非常成熟的技术，它很多方面都需要进一步改进。采用这种技术实在需要承担一定风险。

3．团队合作中沟通重于一切。并不是说几个人坐在一起就算是团队，一个团队是有组织的，分工明确的个人的集合。本人还没上过软件工程这门课，但我初步知道团队的几种组织形式。一种是金字塔形的由基础成员到架构人员的形式，有一种则是扁平的众人平等的形式。金字塔形的模式便于成员调度和统一管理，扁平式则有利于成员群策群力发挥所长，但其决策能力往往不及前者。
      在GdieOA中，我们基本上是采用扁平的组织形式，组长更多的是起着发布信息而非工作调度的作用。在这种组织形式下，成员之间的交流起着非常重要的作用。我想在GdieOA这个项目中，这点上我们还是很欠缺的。8月份因为大家有较多机会聚在一起共同开发，所以技术问题的讨论相对较频繁。可一进入9月，随着大家的事情越来越多，我们这些老友们能够真正聚在一起六人行的机会越来越少。往往遇到问题都无法相互讨论，只能自己找资料解决，这大大降低了开发效率。我想所谓极限编程谓之极限也主要是因为共同开发的两个人之间的交流大大促进了效率的缘故吧。
      在这里我也想再举一个例子，就像我们搞数学建模一样，如果拿我们小组的每个成员一一与别人相比，可能是有不及而无过之。但就因为我们3个人在3天里能充分沟通、彼此信任，所以最终才能取得现在的成绩。我们做项目就像搞竞赛一样，需要的不单单是技术，更多的是沟通。一个人技术很牛并不能转化为整个团队的技术牛，但沟通交流可以让我们做到1+1+1>3。在数学建模比赛中，有一句话令我感触良深：无论何时都要充分相信队友。我想如果没有足够的交流，无论如何也无法达到这种境界。
      实际上，GdieOA的开发中，我们几个人与Gdie之间的交流贫乏也是一个不足之处。虽然这或多或少受到地理因素的影响，但我相信如果我们大家都有相互沟通的愿望，任何客观因素都不是障碍。

4．项目管理人员应充分重视加强团队的凝聚力和自信心。我听老师说过为什么sysu的cser到了大三后都不想搞计算机的原因。就是因为在平时的学习和训练中老师没有重视提高学生的信心和团队的凝聚力。写程序就像打羽毛球一样，每个人都是满怀希望去尝试去学习，但如果换来的是一次又一次的失败，那渐渐地大家都不想学打羽毛球了。加拿大的Waterloo大学计算机系的学生毕业后几乎个个都去microsoft工作，microsoft也非常渴望招收他们那样的学生，甚至还请专机去接送他们。Waterloo大学的cser并不是最聪明的，但是入学后老师们通过无数个project的训练，一个project一个目标地建立学生的信心和强化他们的能力，最终使他们的学生成为计算机界的抢手货。
      可惜在GdieOA中，我们并没有看到这种情况，相反因为过多的挫折造成成员们在后期几乎个个失去信心，如果项目的管理者能够正视这个问题，采取适当措施，我想大家都很乐意继续进行这个项目。

      没想到写着写着就写这么多了，以上观点纯属个人意见，由于本人见识浅薄必定存在许多贻笑大方之处，希望大家不吝指正。有什么意见也希望大家提出来互相讨论。

by zhenghx
2006年11月26日