【基本运作方式】
前面已经说道，我们招募了项目顾问。我们的基本运作方式也是通过和项目顾问共同商量确定下来的。这让我在项目开始前已经感受到开源的作用了。
下面是我们的开发模式（这里暂且称为“千帆开发模式”）与标准的封闭源码开发模式和标准的开放源码开发模式的比较。可以看出我们是在一般的开放 源码开发模式的基础上又借鉴了部分封闭开发模式的内容。 千帆开发模式 开发队伍组织模式：
分散开发人员通过Internet组成开发队伍发布版本时间:
固定时间发布，但有模块完成时尽早发布模块提供源码对象：对公众发布负责测试部 门:
无专门测试部门管理手段：
按照项目生命周期管理，强调协作，自愿参与
为了加强交流，对于能够到会的人员每周进行一次项目例会，不能到会的则参与每周一次的网络会议。项目的第一次例会在4月28日启动，原计划在8月15日结 束，以周为时间划分，共计16周， 【第一次大会】
在4月27日下午，也就是项目启动的前一天，我紧急联系了刚刚招募的在天津的美工王志寿，希望他能在第二天下午之前完成我们的项目网站，好在第二天正式 启动我们的项目团队。我现在还清楚的记得，当天下午我通过QQ和他进行沟通，简单表达了自己的想法后，他在几个小时后，也就是当晚八、九点钟的样子，就给 我展示了网站的首页——一个看上去很成熟的站点首页，并于第二天按时发布了我们的网站。如果这个工作由我个人来做，可能也能够完成，但质量一定远远不如 他，并且一定会影响第二天的会议准备。
那边是美工在忙，这边我也赶紧找来另一个成员陈朝岩，他帮着我们很快假设好了我们的服务器——一台装有Redhat 9 Linux的服务器。
通过大家的不懈努力，我们于4月28日发布了我们的工作网站，并于当天晚上召开第一次项目会议。在这次会议的筹备过程中，大家就已经深深感受到了开源的 魅力——一群素不相识、甚至不能谋面的人因为开源而聚到了一起，并为了共同的目标而兴奋的工作着。
第一次会议大家兴致很高，在各自完成自我介绍后，我向大家畅想了我们美好的“前程”，大家也都谈论了各自对于新系统的一些想法。会后大家合影留念。 【多种开发方法并行】
项目团队建立起来后，就开始了正式的团队运作。
为了规避风险，我们最初曾经考虑全部严格遵循软件工程，并借鉴了TSPi（小组软件开发过程）的思想。整个开发周期计划从4月28日至8月15日，共16个星期 。项目采用迭代式开发，分为两个阶段。
但很快发现一个现实，面对一个松散的开源团队，单纯的较严格开发方式反而并不高效，我们便调整了开发方式。我们在项目总体采用两阶段的需求、设计、 实现、测试的基础上，根据功能的需要，在某些独立模开的开发上采用下面两种并行的开发方式。
一、对于需求非常明确、有相当的把握开发成功的成熟的独立模块，可以交付给熟练的开发人员独立开发，开发人员可以按照自己喜爱的开发方式，只要在规 定的时间内完成开发即可，不必严格遵循软件工程的各个流程、但要保证开发的模块的质量。
二、对于无把握的或需要探索的新功能模块的开发，由于风险很大，也独立提出。要求本模块的开发人员在较短的时间内完成功能演示的开发。因为只是功能 演示，对其代码质量不进行要求，但需要能够明确模块的实现方法，便于真实系统的应用。
这样，整个开源团队就存在这三个并行前进的三条线路：遵循软件工程进行迭代开发的主团队、进行成熟模块开发的小分队、以及进行新功能尝试的探索的探 险队。 【工具的使用】
对于通过网络协作开发的开源项目，协同开发工具自然也不可少。现在想来，我们用到的工具还真是相当的多。
网站：首先建立自己的网站，确保团队内外的人都能明确了解项目的进展，这是整个项目对外的窗口，我们的美工在第一时间完成了一个精美的网站，一下子 给人以高起点的感觉。
版本控制工具：由于代码量越来越大，在开发中，每个成员都要保留一个副本，在开发中非常容易引起冲突。因此版本控制工具是非常必要的。CVS是个可以用 在小组协作环境下的源码版本管理系统。同类的软件有AT&T的SCCS（Source Code Control System），还有PVCS等。CVS是用得最为广泛的，因此我们选择了它，它 从技术上可以提供如下功能：同步修改、维护不同的版本、查找历史记录。
开发工具：因为项目较大，人员较多，我们使用的开发工具也不少。
建模：稍大的系统就需要一个全局的规划，这方面我们使用了Rose和Visio。
代码开发：vi, emacs都是常用的linux下的工具，eclipse +CDT也是一个不错的选择，magic c++是我们发现的另一个有点“神奇”的工具，它可以让你 在windows下通过类似VC的界面来编写、调试linux下的程序，在我们这次开发中也得到了广法的应用。
文档建立工具：doxygen，我们发现是一个不错的文档建立工具，可以通过分析源码中制定的标记建立多种不同形式的文档。
代码格式化工具：这方面虽然工具不少，但我们还没有足够的精力去挑选。唯一使用的工具ident，居然把我们的源码修改错误了，造成编译无法通过。
编译、调试工具：我们选择了应用最为广法的GCC, GDB。
发布工具：随着项目的进行，也许需要发布了，autoconf，automake，tar是必须的。rpm也是现在一个比较流行的发布工具，也可以考虑。
Bug管理：可以考虑使用Bugzilla，不过我们还没有使用任何bug管理工具。
除了上面说的这些开发相关的工具，我们发现最重要的其实还是下面这些用于交流的工具：
空气：“空气是交流工具吗？”，它是我们当面交流时声音传输的媒介啊！没错，经过实践，我们发现当面交流依然是最重要、最高效的交流工具。所以只要 有可能，还是当面交流吧，而不必要通过QQ去和身边的开发者说悄悄话。
即时通信工具：如QQ，MSN等，它几乎已经成为第二高效的交流方法了。
此外，网络语音聊天工具，论坛，短信息，邮件列表，网络会议，wiki，电子邮件等几乎全部能够想到的方式几乎都被我们采用了。而且事实证明——这依然 毫不过分，交流是最重要的！ 【第一个模块的发布】
项目只运作了不到三个星期，我们“进行成熟模块开发的小分队”的谢翰就发布了第一个模块——TCP端口扫描模块，用于搜寻提供FTP服务的主机的扫描 器。这个模块采用了新的方式，把原先需要1个月才能完成的工作提高到只需要几个小时！
第一个模块的发布大大提高了整个开源团队的士气，我们这个项目在民间的影响力也初步体现。 【问题不断】
项目继续进行，第三周很快过去，没有什么特别的事情发生。随着第四周的到来，相当多的成员面临期末考试的压力，只好停止开发工作。整个项目在第 四周的前几天基本上出于停滞状态。我决定改变这个现状，临时招募了几名没有期末考试压力的成员，但因为是半途加入，在很短的时间内工作开展的又不是有效 。
一个百无聊赖的第五周结束后，发现在核心开发人员缺席的这段时间内项目进展的非常缓慢。随着第六周的到来，多数开发人员已经结束期末考试，我们 的黄金开发时期——假期已经到来。但紧接着又出现了新的问题：开发人员一下子多了起来，原先的组织结构已经不能适应新的状况了。 【组织结构的变化】
项目启动之初，人员不多，组织结构也较简单，如下图所示：
考虑到实际对项目的把握和时间投入，项目组长同时也承担了开发经理的工作，并直接领导美工。顾问协作项目组长的工作。每个核心开发人员负责一个具体 子系统的开发，考虑到项目组长工作较重而繁琐，其中一个核心开发人员同时承担一些开发经理助理的工作，项目组长本身不担任核心开发工作。
到了第六周，人员达到了16人的规模，原有组织结构已经不能满足此时的管理要求，调整势在必行。起初我们想按照一般的做法，把开发团队分成2－3个小组 ，每个小组选出组长，组长则向项目领导汇报。如下图：
但这个调整又是相当困难的：一方面开发工作已经开始进行，让原有人员调换角色或者调整开发内容将是非常困难的；另一方面，整个开发团队中除了项目组 长之外，其它人都缺乏对全局的系统的足够了解和足够的工作时间，因此很难选出合适的人员承担小组长的角色。经过和项目顾问的多次商讨，最终的组织结构如 下： 这个看起来略显复杂的结构其实基本思想很简单：
1． 保证已经开始工作的核心开发人员的工作内容基本不变，辅助开发人员配合核心开发人员工作；
2． 为了不增加核心开发人员的管理工作量，没有设置开发小组长的角色；管理工作直接由项目组长负责；
3． 为了防止项目组长事务工作过多，加强开发经理助理这一角色的作用；同时多安排一个辅助开发人员来配合其工作。
总的说来，新的组织结构图在实施中还是比较合理的。但项目组长要承担很多的管理、协调工作，在实际中还有一些开发工作，比别人辛苦。但作为唯一 的全职工作人员，这一点还是可以接受的。
|
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
