泛海精灵项目的回顾与反思

泛海精灵项目从2010年12月15日开始，到现在已经过去三个月了。三个月学到了很多新知识，关于代码构架，关于团队协作，关于团队建设，还有一些关于软件工程的理念。总体来说，泛海精灵是个失败的项目。

计划\目标

前期的准备不足，是泛海精灵失败的重要原因。

开始开发前，我们本应该仔细阅读《移山之道》中关于调研和开发的意见。我们甚至不知道测试员的具体工作前就开始分配角色了。

一个严重后果是，我们按照以前的小软件开发习惯开始了泛海精灵项目。没有用户场景（UserStory），没有时间估算，只有每天增长的代码。 1月1号前

这是我们开始时做的NABC调查

Need 需求

无数的跨校考研生，无数的寂寞党，当然，还有众多热衷促进高校交流的好学生，都会很期待泛海精灵的问世。

Approach 实现

高校BBS发贴，从来不用验证码。发表新贴简直是轻而易举。昨天Hui已经成功让程序自动登录百度知道发布问题了。其它feature的实现，需要MicroTeamer的软件工程能力。

FQ、代发贴不存在技术障碍。因为Hui和Liuhang以前写过类似QQ的聊天软件。

Benefit 好处

让灌水来得更容易些（0），让回复来得更及时些（4），让等待更少些（7），让关注更多一些（5、6），让大学永远保存（1）

FQ(8)，代发贴（9）的好处不用解释

Competitors 竞争

如此骇人的想法，除了如此苦思的我们，还有谁能想到？

我们最大的竞争对手，应该是行将就木的高校BBS。他们会对我们的行为不满。那又能怎么样呢？早该开放些，给力些了

现在看来,这份NABC调查很空泛.

需求分析方面,我们本应该做实际用户调查，而不是妄加揣测。因为没有调查数据，所以整个项目过程中我们都不十分肯定用户需要什么。这造成，花大量时间开发一个用户不关心的功能。

实现方面深入分析就更重要了。因为不深入分析的话，就没法准确估算时间。错误，或者说是”乐观“，地估计一个任务，的后果有时可以很严重。比如我们乐观估计了一个功能的实现（登录状态下抓取数据），在1月2号这几天都没有进展，遇到瓶颈。

所以,我们的"版本计划",很不符合客观规律......

  

进度

Alpha阶段(1月16日前)的估计/实现非常混乱,因为前面提到的原因.

Beta阶段,我们吸取了教训,很好地预估了时间. 2月27日前计划的任务基本完成.但因为对用户不了解,往后,又添加了很多实现"可能"对用户有用的功能的任务.很明显地看出,因为没有提前预估,2月27日后的效率比之前的效率降低很多.这是因为不合理的任务分配造成.

 

资源

MicroTeam人少,所以把大量经历放在代码编写上了.这是个严重的错误.因为用户需要的是产品,而不是代码.用户分析,典型用户调查,竞争对手分析这些方面的数据缺失,造成编码工作很没效率.所以用户分析调查应该分配足够多的人力."用户代表"应该多给力.

 

测试

因为前面提到的原因,测试原在Beta阶段参加了开发工作.这似乎也是个错误的决定.因为我们的开发员要花大量时间不培训"新员工".(肯定的,对新员工是很有益的). 然而新员工的工作效率不如期待中那么高.

后期,没有专门的测试员.推出的第二个版本存在致命Bug.这很让用户伤心.

MicroTeam Hui