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

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

Remaining Work -  3.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


源自 MicroTeam
欢迎转载,务必保留署名和链接。
posted on 2011-03-15 10:06  MicroTeam  阅读(1379)  评论(0编辑  收藏  举报