这个项目需要什么样的团队
最近被敌人一顿折磨.
所在的项目大,巨大,强大... ...最近又购入了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)
.
200多万的代码,的确有很多冗余和不必要的,除去历史背景和客观原因,单从代码上看,admin要有60+%的折扣,core要40+%吧,其他工程都是很实在的,尤其是common,像名字一样实在.
一步步走到现在,不同的历史时期有不同的特征,有其自身的背景和客观原因.
因此很难用简单的文字来恰当的重现整个过程.(或许等有时间,纠集原班人马,出书吧),只能晒晒现在的数据.加班是在所难免了,记得Darren说分3个时期(早9晚9,早9晚11,黑白颠倒),很多项目的发展期应该都加班吧.
现在已经分叉成5个版本了,因为,业务上有5个公司(部门),处理不同的业务,需要必要的隔离,处理个别的逻辑,执行非共通的批处理等等吧.
项目还在滚雪球,也暴露和埋下了一些问题,有待发现,解决,避免和改善.
是速度的竞争,业务需求速度和解决问题的速度,后者快,则生,前者快则苦.
(还有一种就是die,但,百足之虫,死而不僵,也许很多人不让他死,哪怕是植物人,也得活着,哈哈)
项目现在活的还很硬朗,在和业务与时俱进,业务方面还在收购,并购一些小公司,要大发展.
16 楼 抛出异常的爱 2008-04-11 找gigx去看看。。。他刚刚写了篇文章，用来重构老项目 17 楼 jimmy_c 2008-04-11 1.产品化
2.测试/产品质量
3.拒绝加班
4.需求管理 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成了历史,但项目一直活着,蛰伏在另外一个集团.
现在似乎又有了复苏的迹象. 19 楼 抛出异常的爱 2008-04-11 对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx 20 楼 jimmy_c 2008-04-11 抛出异常的爱 写道对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx
gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。 21 楼 抛出异常的爱 2008-04-11 jimmy_c 写道抛出异常的爱 写道对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx
gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。
有的话大家都去喝风去了。都让tw来作吧 22 楼 sslaowan 2008-04-12 没我们的项目复杂，大 23 楼 gigix 2008-04-12 jimmy_c 写道抛出异常的爱 写道对遗留系统组织重构项目
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx
gigix所说的那种重构，成本很高的，不是一种具有普遍性的方法。
这个，其实我也没辙。有些遗留系统几年来就这么遗留着，赶工的时候补丁摞补丁的往上垒，所谓维护其实也只是bug fix。代码质量不断劣化，到眼下就已经变成了鸡肋。继续做吧，实在不敢下刀；扔掉吧，重做的成本更高，而且还不能确定就一定比以前的做得好。对这种系统重构的成本无疑会很高，因为是在还很多年积累下来的债。如果有一种魔法般的手段可以低成本就把这个问题解决了，哪还会有那么多教人头疼的遗留系统呢？ 24 楼 jimmy_c 2008-04-12 引用有的话大家都去喝风去了。都让tw来作吧
引用这个，其实我也没辙。有些遗留系统几年来就这么遗留着，赶工的时候补丁摞补丁的往上垒，所谓维护其实也只是bug fix。代码质量不断劣化，到眼下就已经变成了鸡肋。继续做吧，实在不敢下刀；扔掉吧，重做的成本更高，而且还不能确定就一定比以前的做得好。对这种系统重构的成本无疑会很高，因为是在还很多年积累下来的债。如果有一种魔法般的手段可以低成本就把这个问题解决了，哪还会有那么多教人头疼的遗留系统呢？
其实我只是陈述一个事实给楼主参考，并没有否定gigix的意思。我还是很赞赏gigix的，能够把这样一个令人头疼的事情给做下去，并且真正搞出结果来。
只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了） 25 楼 gigix 2008-04-12 jimmy_c 写道只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了）
这就是我们这些人存在的价值啊…
帮项目经理们得罪组织内需要得罪的各种人，帮他们要来资源，帮他们扛住压力，让他们有可能干出一些别人干不出的成绩
当然也可能会把他们跟别人遇不到的难题扔到一起
风险、成本和收益总是紧密关联，还真不是随便说说的 26 楼 pig345 2008-04-18 gigix 写道jimmy_c 写道只是觉得从楼主的项目背景来看，采取gigix的方法还是要遇到很大阻力的。一方面可能是管理风格的问题，一方面是成本能否接受的问题。
而且做这样的事，没有gigix这样对重构技术极其熟悉的老手坐镇，风险也是相当的大。我并不怀疑楼主公司的技术和管理水平，但是也未必能找到做这件事合适的人选。（这句话有点多余，如果有的话，大概也不会遇到这样的问题了）
这就是我们这些人存在的价值啊…
帮项目经理们得罪组织内需要得罪的各种人，帮他们要来资源，帮他们扛住压力，让他们有可能干出一些别人干不出的成绩
当然也可能会把他们跟别人遇不到的难题扔到一起
风险、成本和收益总是紧密关联，还真不是随便说说的
“外来的和尚好念经”就是这个道理了，很多时候高层似乎更相信空降兵对事情的看法，呵呵。 27 楼 trydofor 2008-04-22 在肉搏战,巷战和地理环境复杂的情况下,空降兵来多少挂多少:)
打伊拉克那种一片荒沙的还可以,不知美军二战时,在越南空投了多少眼泪,
还有黑鹰坠落,企业也一样,只不过牺牲的不是士兵 28 楼 abang 2008-04-23 trydofor 写道在肉搏战,巷战和地理环境复杂的情况下,空降兵来多少挂多少:)
打伊拉克那种一片荒沙的还可以,不知美军二战时,在越南空投了多少眼泪,
还有黑鹰坠落,企业也一样,只不过牺牲的不是士兵
说的在理，所以做这个项目起码要做好来一批走一批的风险应对 29 楼 cuiyi.crazy 2008-05-27 这样项目的负责人应该是被当宝贝一样看待的吧。
要是这样的人走掉，估计涉及的所有人都要抱一起哭了。
我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？ 30 楼 gigix 2008-05-27 cuiyi.crazy 写道我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？
6月21日北京的第三届敏捷中国技术大会，你来参加吧，我们的客户会来亲身讲解 31 楼 maoone2003 2008-05-27 仅仅就这么一点信息，去分析需要什么样子的团队，好像略显盲目阿，一般而言，需求做不到一定程度，项目计划是无法保证其准确、合理的程度的，何况这不是一个小项目；先做初步的需求调研，有必要的话做一些技术架构及业务流程的预演，可能会好一些。。。个人意见，呵呵 32 楼 cuiyi.crazy 2008-05-30 gigix 写道cuiyi.crazy 写道我可以用怀疑的观点问一下么： gigix的重构咨询 真的救活过遗留项目么？我的意思是说有比较大的成功案例么？
6月21日北京的第三届敏捷中国技术大会，你来参加吧，我们的客户会来亲身讲解
北京诸如之类的会议和研讨很是很吸引人的。哎，不很凑巧，无缘参加了。
如此说来，那应该还是很不错的，谢谢gigix。
