这个项目需要什么样的团队

最近被敌人一顿折磨.

所在的项目大,巨大,强大... ...

最近又购入了1.5w的债权/1300w交易

而且主工程要对应4种业务模型,也就是4套版本.

而一个独立版本又分为4种:本地版,网络版,共享版(本地),,共享版(服务器)

吹点牛说,就是4*4=16种版本.

 

本来是放在baidu的一篇随笔,拿出来晒晒,javaeye的大侠们,帮看看

这样的一个项目需要怎么样的一个团队,比如人数,技术层面等.

进而知道自己在什么位置,以防,那天一蹬腿,找不到工作啦:D

(PS: 这里划表格太恐怖啦,看到的达人,能改一改吧,用wiki的或a9text的都行啊)

 

*) 项目概要
   Credit是一个信贷系统,包括个人/企业,有担保/无担保贷款业务.
   现有债权数10万,贷款额134.5亿,是需求,设计,编码一起从0开始

   2004-04 立项.
     2004-12 营业.
     2005-09 Cafis/Jic/DNP 合作.
     2006-01 livedoor事件,业务萎缩,裁员.
     至今,credit和业务一样还在努力的活着...

*) 功能摘要
   申请: web,mobile,ivr(自动语音电话)
   管理: 管理工具(swt),Mypage(web)
   服务: 文书类,ATM(Cafis),JIC(全国信用情报机构)
   报表: 营业日本,营业月报

*) 应用技术
   java(桌面应用程序,批处理程序,Web/Mobile,专项服务)
   bash(监控脚本)
   python(辅助程序)

*) 服务器数
   14台业务服务器,分别提供
   db2/mysql/postgres
   tomcat/apache
   vpopmail
   samba/ftp
   jic/ivr/cafis

*) 代码规模(*.java 不包括*.jsp)

活跃工程	文件数	总行数	代码行	注释行	空行
admin	2360	1134297	853090 (73.81%)	185621 (16.06%)	117098 (10.13%)
core	1404	503255	293730 (57.53%)	142670 (27.94%)	74178 (14.53%)
common	408	78703	50532 (63.13%)	19814 (24.75%)	9695 (12.11%)
batch	522	153308	118059 (75.29%)	22115 (14.10%)	16631 (10.61%)
cafis	106	21522	15974 (72.57%)	3422 (15.55%)	2616 (11.88%)
jic	325	89312	68407 (69.96%)	19300 (19.74%)	10073 (10.30%)
web	230	47512	35219 (72.06%)	7675 (15.70%)	5980 (12.24%)
mobile	54	11057	7971 (68.94%)	2083 (18.01%)	1509 (13.05%)
web_mypage	142	17529	13028 (73.42%)	2504 (14.11%)	2212 (12.47%)
mypage_mobile	80	13567	9387 (68.59%)	2431 (17.76%)	1867 (13.64%)
mypage_bkserver	45	6307	4460 (70.44%)	729 (11.51%)	1143 (18.05%)
总计	5676	2076369	1469857 (69.61%)	408364 (17.75%)	243002 (12.64%)
所有工程	10576	4337779	3206555 (72.51%)	772760 (17.48%)	442641 (10.01%)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

*) 数据库规模
   DB2 Schema 共有1043张表
   CODE表449
   主力表239

   DB2 全备份文件(*.tar.gz) 3.5G

 

*) 名词解释

jic 是日本全情连
ivr  是一套语音服务系统,可以通过电话自动提供服务
cafis 就是ATM取款机的系统啦

评论

32 楼 cuiyi.crazy 2008-05-30  

gigix 写道

cuiyi.crazy 写道

我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？

6月21日北京的第三届敏捷中国技术大会，你来参加吧，我们的客户会来亲身讲解

北京诸如之类的会议和研讨很是很吸引人的。哎，不很凑巧，无缘参加了。
如此说来，那应该还是很不错的，谢谢gigix。

31 楼 maoone2003 2008-05-27  

仅仅就这么一点信息，去分析需要什么样子的团队，好像略显盲目阿，一般而言，需求做不到一定程度，项目计划是无法保证其准确、合理的程度的，何况这不是一个小项目；先做初步的需求调研，有必要的话做一些技术架构及业务流程的预演，可能会好一些。。。个人意见，呵呵

30 楼 gigix 2008-05-27  

cuiyi.crazy 写道

我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？

6月21日北京的第三届敏捷中国技术大会，你来参加吧，我们的客户会来亲身讲解

29 楼 cuiyi.crazy 2008-05-27  

这样项目的负责人应该是被当宝贝一样看待的吧。
要是这样的人走掉，估计涉及的所有人都要抱一起哭了。


我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？

28 楼 abang 2008-04-23  

trydofor 写道

在肉搏战,巷战和地理环境复杂的情况下,空降兵来多少挂多少:)
打伊拉克那种一片荒沙的还可以,不知美军二战时,在越南空投了多少眼泪,
还有黑鹰坠落,企业也一样,只不过牺牲的不是士兵

说的在理，所以做这个项目起码要做好来一批走一批的风险应对

27 楼 trydofor 2008-04-22  

在肉搏战,巷战和地理环境复杂的情况下,空降兵来多少挂多少:)
打伊拉克那种一片荒沙的还可以,不知美军二战时,在越南空投了多少眼泪,
还有黑鹰坠落,企业也一样,只不过牺牲的不是士兵

26 楼 pig345 2008-04-18  

gigix 写道

jimmy_c 写道

只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了）

这就是我们这些人存在的价值啊…
帮项目经理们得罪组织内需要得罪的各种人，帮他们要来资源，帮他们扛住压力，让他们有可能干出一些别人干不出的成绩
当然也可能会把他们跟别人遇不到的难题扔到一起
风险、成本和收益总是紧密关联，还真不是随便说说的

“外来的和尚好念经”就是这个道理了，很多时候高层似乎更相信空降兵对事情的看法，呵呵。

25 楼 gigix 2008-04-12  

jimmy_c 写道

只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了）

这就是我们这些人存在的价值啊…
帮项目经理们得罪组织内需要得罪的各种人，帮他们要来资源，帮他们扛住压力，让他们有可能干出一些别人干不出的成绩
当然也可能会把他们跟别人遇不到的难题扔到一起
风险、成本和收益总是紧密关联，还真不是随便说说的

24 楼 jimmy_c 2008-04-12  

引用

有的话大家都去喝风去了。都让tw来作吧

引用

这个，其实我也没辙。有些遗留系统几年来就这么遗留着，赶工的时候补丁摞补丁的往上垒，所谓维护其实也只是bug fix。代码质量不断劣化，到眼下就已经变成了鸡肋。继续做吧，实在不敢下刀；扔掉吧，重做的成本更高，而且还不能确定就一定比以前的做得好。对这种系统重构的成本无疑会很高，因为是在还很多年积累下来的债。如果有一种魔法般的手段可以低成本就把这个问题解决了，哪还会有那么多教人头疼的遗留系统呢？

其实我只是陈述一个事实给楼主参考，并没有否定gigix的意思。我还是很赞赏gigix的，能够把这样一个令人头疼的事情给做下去，并且真正搞出结果来。
只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了）

23 楼 gigix 2008-04-12  

jimmy_c 写道

抛出异常的爱 写道

对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx

gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。

这个，其实我也没辙。有些遗留系统几年来就这么遗留着，赶工的时候补丁摞补丁的往上垒，所谓维护其实也只是bug fix。代码质量不断劣化，到眼下就已经变成了鸡肋。继续做吧，实在不敢下刀；扔掉吧，重做的成本更高，而且还不能确定就一定比以前的做得好。对这种系统重构的成本无疑会很高，因为是在还很多年积累下来的债。如果有一种魔法般的手段可以低成本就把这个问题解决了，哪还会有那么多教人头疼的遗留系统呢？

22 楼 sslaowan 2008-04-12  

没我们的项目复杂，大

21 楼 抛出异常的爱 2008-04-11  

jimmy_c 写道

抛出异常的爱 写道

对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx

gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。

有的话大家都去喝风去了。都让tw来作吧

20 楼 jimmy_c 2008-04-11  

抛出异常的爱 写道

对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx

gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。

19 楼 抛出异常的爱 2008-04-11  

对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx

18 楼 trydofor 2008-04-11  

>抛出异常的爱
gigx 是那位? URL多少?
重构的可能性不太,时间上也不允许,不过最近正在学习这方面理论.
比较认同RCFans说的
"这样的项目……还是需要一些编码能力强的人以保守姿态进行维护吧，稳定的运行最重要
估计项目中那种特杂乱竟然又能神奇正确运行的代码特别多"
现在的实际情况也的确如此.
另外因为业务方面一直在折腾,项目也没停止过新功能的开发,原功能的修正,bug修补,数据调查等.

>ALL
感谢大家的关心,分析和建议,没想到晒出这么多贴来.
补充点文档方面的统计吧,方便大家估算需求.

=======================
JIC业务 文档
other:24(472.2K)
word:62(33.6M)
excel:54(19.5M)
visio:20(8.5M)

业务文档
other:1190(299.4M)
word:275(139.9M)
excel:285(128.1M)
visio:49(19.5M)

合计:1959个文档 共648.9M

以上只是需求文档,不包括运营手册,技术资料等
===========================

这是个日本项目,文档也是日本人写的.
项目期初是livedoor集团的内部项目(可看06年的活力门事件)
虽然livedoor成了历史,但项目一直活着,蛰伏在另外一个集团.
现在似乎又有了复苏的迹象.

17 楼 jimmy_c 2008-04-11  

1.产品化
2.测试/产品质量
3.拒绝加班
4.需求管理

16 楼 抛出异常的爱 2008-04-11  

找gigx去看看。。。他刚刚写了篇文章，用来重构老项目

15 楼 trydofor 2008-04-11  

admin(管理工具),担心设计公司数据和顾客信息,暂时无法截图上来,总之是个超级复杂UI(SWT),曾经试图把C/S改成B/S的,但调研中发现,目前的web表现层无法满足,也极难维护.即便是现在ajax,yohooUI等成熟框架,方案如此丰富的现在,开发起来也要比swt痛苦的多,flash就更不用说啦,如果可以从头再来,也许会选择B/S,赶ajax的风,但似乎船大掉头难啊.

200多万的代码,的确有很多冗余和不必要的,除去历史背景和客观原因,单从代码上看,admin要有60+%的折扣,core要40+%吧,其他工程都是很实在的,尤其是common,像名字一样实在.

一步步走到现在,不同的历史时期有不同的特征,有其自身的背景和客观原因.
因此很难用简单的文字来恰当的重现整个过程.(或许等有时间,纠集原班人马,出书吧),只能晒晒现在的数据.加班是在所难免了,记得Darren说分3个时期(早9晚9,早9晚11,黑白颠倒),很多项目的发展期应该都加班吧.

现在已经分叉成5个版本了,因为,业务上有5个公司(部门),处理不同的业务,需要必要的隔离,处理个别的逻辑,执行非共通的批处理等等吧.

项目还在滚雪球,也暴露和埋下了一些问题,有待发现,解决,避免和改善.
是速度的竞争,业务需求速度和解决问题的速度,后者快,则生,前者快则苦.
(还有一种就是die,但,百足之虫,死而不僵,也许很多人不让他死,哪怕是植物人,也得活着,哈哈)

项目现在活的还很硬朗,在和业务与时俱进,业务方面还在收购,并购一些小公司,要大发展.

14 楼 rocwon 2008-04-11  

还没看明白，是这个项目需要维护/重构,还是重新做?

13 楼 jimmy_c 2008-04-10  

whitesock 写道

core主要是业务逻辑，admin是个后台的swt管理工具

那么admin的工作量也是大打折扣的，看来取最小值就可以了，分成3个team，每个team8~15人就可以了。
core作为项目肯定可以细分的，这部分应该是最花时间的。像admin之类的，就是堆代码，改动也不会太大。