逝水流年

This is a blog to record my life, my work, my feeling …

2015-04-07 Summary Reports

截止4月3日,我来到新公司的第一个项目在一片混乱和加班声中落下了帷幕。这可能是我参加工作至今参加的最最混乱的一个项目。所以有必要整理下思路,将项目中的有缺点(主要是缺点:))总结纪录下,为自己也为他人提供一个参考。

我将问题分为几类,按照软件工程来分吧,反正每个阶段都有一些问题。

一、需求方面主要遇到的问的:

  • 需求不明确: 项目已经开始一周,需求还没敲定。

  • 需求变更频繁: 常常是到测试阶段了,需求还会变化。大boss竟然也会提需求,而且还是必须得实现。

  • 需求在QQ中讨论: 在qq群里讨论需求,导致得后果就是开发不知道需求,或者是很快就忘了。

  • 没有及时更新到文档上: 没有专门的需求文档和设计文档,有也是非常旧的版本,没有及时更新。

二、UI设计

  • UI设计原型图修改后不会及时更新。

  • 效果图不准确,也没有及时更新。

  • 标注图同上。

  • UI没有统一的标准,光颜色值就各自定义各自的。

三、代码管理

  • 代码没有标准。看工程中的代码,各式各样。

  • 没有code review。经常会导致代码覆盖或者是很简单的错误出现。

  • 没有CI,全靠手工打包。效率极低。

  • 模块划分不明确。

  • 业务逻辑和UI逻辑混在一起,无法维护和测试。

  • 无用代码或者无用的文件都混在一起,导致工程很混乱。相同定义出现多次。

  • 后台和前端周期安排不合理,经常前端做完后,后台接口还未完成。非常耽误进度。

四、测试

  • 没有Test cases.

  • Bug系统不支持Mac OS.

  • 测试没有规范及周期,完全依赖研发,测试过程比较混乱,版本追踪困难。

五、其他:

  • 项目周期制定拍脑门,不是根据具体需求细化后,根据每个feature的时间预估周期,而是指定死时间,在过程中不论需求如何变化,人员如何变化,周期永远不变化。也就是说一点风险控制的意识都没有。

  • 项目管理没有风险控制和变更控制。

  • 开发完全无法参与时间制定。

总之,问题很多,不局限我上面所列出的问题。有问题不可怕,可怕的是认识不到问题。从我来到项目结束,除了我及另外一个新来的同事提出过这样做不行,其他人都麻木了。每次我提出问题,总是会说习惯就好, 忍忍就过去了。这不是做事都态度!也不是我做事的准则。我来就是为了锻炼自己能力的,解决这些问题也是我的工作,所以我必须要改变这种状况才行。

很多问题肯定无法一下子解决,所以我将问题分两部分:1,是可以开发内部解决的问题。2,是需要其他部门一起改进的。

对于内部: 1. 我首先使用Jenkins搭建了自动build系统,增加版本号自动增加,将build和版本号对应起来。解决测试问题无法追踪版本及开发手动打包效率低问题。 2. 使用MVVM模式替换原来的MVC模式,分离business logic和UI logic。 3. 统一使用宏定义替换magic number。 4. 建议需求和UI统一管理一份(svn),避免需求和理解的混乱。

对于合作: 1. 积极提出改进建议:如UI规范统一。 2. 接口文档及时更新。 3. 测试统一依据效果图。 4. 对需求变化进行把控。(好像没有效果)

虽然当前项目没有太大的改进,但是在开发方面还是有很大的进步的。坚持好的习惯或者好的规范,也要有好的方法去推进。最近又将《软件作坊》这本书重新翻开,理论联系实践,理解的更加深刻。不论是对自己还是对公司都是又一些贡献。相当于双赢的局面。

Comments