维护Mantis项目总结

最近维护公司的Mantis, 以前也做过几次调整, 不同的是, 这次的工期明显要比以往紧张.

项目不大, 但在这个小项目里我还是学到了很多, 透过它我可以清晰的感觉到一个更大的"在高压下紧张运行的项目"的样子.

也更真切得体会到了各种书中的场景. 是的, 我以前的项目都不紧张, 与我而言压力也不大.

 

 

不罗嗦了, 总结如下:

0. 查看mantis文档，省了我很多时间，也为下一步定制找到不少思路

凡事从0开始，mantis的文档也是0，这次改动，发现里面有很多信息。

公司的mantis后续还有定制，比如追加统一用户认证等等，

这些mantis文档里都可以找到线索， 回头有时间顺着研究一下。

 

http://www.mantisbt.org/wiki/doku.php/mantisbt:features

另插播一个广告，这是mantis的features list。

里面有不少不错的功能我们没有使用到，如果把这些功能的威力发挥好，也是一个改进。

 

1. 分多个小功能, 多次release.

这样用户会更适应, release的人也更有信心.

 

2. 按照流程办事.

流程是为人服务的, 所以让流程帮助你防止出错吧.

比如说测试, 如果不测试, 肯定有问题.

 

3. 不要过度自信.

在这次开发中,发生了这样一件事情.

背景: 我们将我们的程序配置在我们内部的服务器上面, 然后日方通过网络访问我们的mantis.
在日本纳期的前一天, 我将程序放到了服务器上. 在这一天里面我们进行测试.
我们内部的测试是在前两天完成的, 就在内部测试完成之后, 我们没有经得住诱惑, 给需求又渡了点金.
删除了一些我们自以为我们可以确定没用的信息(是的,这些信息留在数据库中不会对用户有任何影响).

 

显然对于这个公司内部的项目, 我们自以为不必太为流程所累, 我们以为我们组一致认为没有问题的事就真的不会有问题.

但是我们付出了代价, 就在这小小的镀金过程中, 我们引入了一个bug.

测试完了的东西,不要再动了,如果不是因为有bug.

 

4. 不要需求镀金.

显然我的第三条总结是一个关于镀金的故事, 然而关于镀金的问题还很多,

比如我们又一次要给mantis追加一个批量用户导入的功能.

我们本来想做得很花哨, 但我的客户(也就是领导)说, 这个功能再花哨, 我一年只会点几次。

我们为此付出了额外的工时.

能追求完美的时候,追求完美那是义不容辞, 然而实际项目中还是不要镀金.

 

5. 积极沟通,要保持自知之明, 你的需求永远不是客户的需求. 要牢记使命, 要帮助用户发觉真正的需求.

 

比如, 新的系统的数据库是从老系统来的, 移行之后新老系统还要并行,在移行过来的时候, 我们把bug表的sequence设置成了1, 这样用户登录第一个bug, 编号就显示1, 登录第n个bug, 编号就显示n, 很美的一件事情.

可到了我的头儿那里, 客户提出了一个问题, 将来要把两个bug db合成一个怎么办?

显然sequence不设置是不行的, 因为那样仍不能保证两个系统没有不重复的bug号.

所以最终结果是新系统的sequence被设置从10000开始.

 

很显然, 尽管我们是全新全意为我们的客户,

但如果不是沟通, 我们可能办了坏事, 或者说没有意义的事(搞砸的风险还是存在的).

同样但如果不是沟通, 我们也无法显现我们最终要是是sequence从10000开始增加这件事儿.

 

6. 式样变更.

一定有人会说积极沟通会导致更多的式样变更. 是的, 这点我承认, 如果工期紧张的话，经理应当尽全力保持式样的稳定,

但是, 迟早要变的变化是我们躲不掉的,这些变化晚变不如早变.

其他的变化我们可以和用户说明代价,抵住"诱惑",就如同抵制开发人员的镀金一样.

 

7. 开始pair

这个项目中很多工作pair进行的, pair的形式下进行的, 如果两个人配合得当确实很提早发现很多问题,

这个项目可以作为我支持pair的一个例子.

 

项目总结的总结:

关于软件工程,项目管理方面的书, 我也看了不少, 然而却总是实际操作中体会更深, 尤其在强度和压力大的时候, 这点很好. 继续努力.