最近的外包项目总结

Posted on 2008-10-07 09:43 久城 阅读(3006) 评论(9)  编辑  收藏 所属分类: 程序人生

一.   项目基本状况

1.      作业时间200879– 2008107

2.      作业范围详细设计,编码,PT测试。

3.      人员结构 PM1+PJL1+Member5+支援1

二.   这是一个什么样的项目

项目本身很正常,却无法正常去做。

最根本的原因,就是时间不足。

基本状况就是,一个需要六天的任务,只有三天的时间去完成,这种状况普遍存在。

所以,这个项目从一开始,对我们的PMPJL来说,就是一种挑战。

三.   这是一个什么样的问题

时间问题。说到时间问题,每个人都会有不同的主观想法。Member会觉得是工作量过大,领导会觉得是客户太XXXX,客户会觉得是我们的能力不足。

客观的说,就是,以我们现有的水平无法在预定时间内完成计划中的任务。

不管是什么原因造成的,就是这个问题,从项目开始就出现了。

四.   对策

1.      加班。从项目开始一直持续到最后。

2.      加人。先后加了两个人。

3.      以降低质量来换取进度。这一点不是领导说的,是我说的。领导一直在强调,不管进度如何,一定要保证质量。但是谁心里都明白,既要保证质量,又要保证进度,那是不可能的。

五.   对我的影响

式样理解阶段:没有。被挤到DD设计的时间里了。

DD设计阶段:式样没理解透就开始DD,结果质量不好,做的也吃力。达不到指导编码的效果。(项目的最后两天,重新修改DD,若要完全修改的话,我的修改量可达80%

PG阶段:只能说是写完。无法保证质量,PG结束后,对自己的代码仍没有信心。

PT阶段:很多PG的问题残留到PT,导致修改量大。很需要二次PT

交叉测试阶段:我被发现的问题有很多。对我来说,是最重要的5天。

六.   我的流水账

79

项目启动的第一天,大部分时间在开会,了解一下项目的基本状况,以及项目组成立后的注意事项,比如,任务安排,职责安排,作业方式,共通内容等等。

710

按照大工程表的划分,今天开始作业,内容是XXX机能的详细设计,共4天。我自己在小工程表中划了两天的时间作为式样理解。

714

第一个延迟。

延迟原因:

1. 式样理解不足。

2. 没有详细设计模板。

对策:

加班、调整工程表。

从这一天,我的延迟生活开始了,并基本上一直保持到最后。

从这一天,我们项目组的加班生活也开始了,每天930,周六加班,周日看情况。

715

关于DDPG的先后。

做这个项目前,我一直认为,对于我现在的水平,合理的做法应该是先PG,再DD。结果被领导否了,领导说,先PGDD会限制住一个人的设计思路。我开始尝试不编码,直接DD,结果感觉很好。

717

DD的认识,发现两点很重要:

1. 自查时,一定要打印出来,校对格式。

2. DD内容的准则,就是,找一个傻瓜过来,也能看懂你的设计思路。

721

第二个延迟。

延迟原因:

1.  作业量大。

工程表上三天的任务,我在加班的状况下,实际用了八天的时间。

2.       不稳定作业。

开会频繁,无确定时间,作业经常被打断,且占用时间长。

3.       过多的计划外的事。

很多工程表之外的事情需要对应。如WT实施,WT对应,共通类实现等等。

    对策:

    加班、调整工程表。

    724

    领导心情很差,很烦躁,作业气氛开始压抑。

    我决定给领导打起,因为我觉得,无论遇到什么困难,领导在手下面前都应该是自信满满的样子,即使心里极度烦躁。

    725

    一个人严重的问题暴露了,member的问题。

    当前项目组5人在作业,由于技术原因,只有一人能够正常DD作业,就是leader

    其余四人技术上的情况如下:

    Member1:无XX框架经验。没做过前台jsp

Member2,无XX框架经验,自学过一阵子。

Member3,无XX框架经验。

Member4,就是我,了解XX框架,但我的作业只用java,和XX框架没有关系。且java部分无框架。

由于XX框架的特殊性,对DD的要求很高,不懂XX框架的话,DD会很吃力。

    726

    领导的状态恢复了。

    针对项目组的作业状况(普遍延迟),领导的对策是,加一个人。很明智。

    727

    领导的又一个明智的决定,让Member1Member3提前进入PG阶段。

在另一个项目的case study中,也听到了这样的经验,对技术不熟的人,很实用。

    这样能够让这二人,更直接的熟悉框架,提高后期的作业质量,减少风险。

    728

    我们犯了一个错误。

    框架设计和DD设计应该是分开的,而且,框架设计应该在DD设计之前完成。

而我们却是在DD设计的同时各自设计各自的框架,当WT之后才开始统一。

    729

    总结一下这个阶段从领导身上学到的:

1.      在紧张的阶段,要时刻鼓励大家,而不是督促大家。

2.      不怀疑手下的工作方式和工作效率,要相信他。即使不放心,也要私下里说。

3.      不轻易在会议上直接批评别人,也不在别人面前说自己组员的不是。

4.      懂得自我批评。

    82

    总结一下这个阶段学到的开会的学问:

1.      定时。

对于每天的例会,时间上要规定好,这样可以让member避免自己的作业被突来的会议打断,而且还可以让member事先对会议有准备。对于一些临时的会议,也要尽可能的提前通知,不要随叫随开。

2.      效率。

开会人提前做好准备,要说哪些事,要统计哪些事。完事立马散会,不要把会议的内容拿到会议上去想。

3.      语言精炼

一共有哪几件事,需要大家知道什么,需要大家做什么,怎么做。

Member只关心一件事,需要我做什么,怎么做。至于这个问题你是怎么发现的,怎么思考的,怎么设计的,我们不关心,我们关心的只是你最后的决定。

4.      能用邮件说明的,尽量用邮件。

节省时间,还能有所保留。   

    83

    正对目前的作业状况,日方提出方案,改变项目作业方式。

    以机能为单位,分别进行DD->PG->PT。而且,每周按机能向客户提交成果物。还好我当时的DD已结束,接下来要做的就是机能1PG,PT,然后进行机能2PG,PT…….

    这样的好处:可以提前发现一些PT的问题,进而在下一个PG中避免。

    这样的坏处:频繁的修改和维护文档。PG,PT的质量会有影响。

    85

    关于review的问题。

    据说第一次review都要全员参加。

    我们review的方式完全是在模仿日本的review方式:会议室全员review

    结果不是很理想,因为项目组的大部分人技术和经验都没有达到能够直接review的水平。

    这件事让我意识到一个问题,不能盲目的模仿日本的作业方式,应该结合我们自身的实际水平,用适合我们自己的方式。个人觉得,我们项目组的方式应该是这样的:

1.      针对某一个机能,在review前,安排2-3人(或者全员)在自己的机器上review,时间由review者在当天自由安排。

2.      review者将review结果直接告诉给被review者。

3.      review者将共通的问题,以mail的形式全员通知大家(或者利用早会)。

4.      有需要的话,可以在大家都review之后,再去会议室集体review,内容为大家陈述自己的指摘内容,而不是大眼儿瞪小眼儿的在那儿看。

5.      多多鼓励大家主动review,自己写完了,主动找别人帮看一下大概。

6.      参考别人代码的时候,也随时帮别人指摘。比如一些类似的地方,无所谓谁对谁错,只要大家做法统一就好。

总之,我们目前的水平,还不能靠经验来review,只能凭借刚刚做过的内容,再看到别人犯同样的错误时,就能够指摘出来。

86

Review工作改为一对一的方式。由PMPJL担任,分别review我们的各个机能。

这样,PMPJL的工作任务又重了,由于时间的紧迫,使得一些机能无法得到及时的review。增加了一些不必要的修改时间。

这里让我想起某项目的一条经验,就是对每一个担当的第一个成果物要做到100%review。大概就是这个意思,这就是两个项目的差距,他们有式样理解的时间,有WTCR的时间,而我们,这些内容,只能自己挤时间来做。

这样的情况下:

谈质量?谈方法?

87

总监请项目组全员吃饭。

慰问餐。

    812

    测试开始,整理几个问题:

1.      一定要发布到一个专门的服务器上,在服务器上测试。特别是在这种PG,PT交替进行的作业方式的情况下。

2.      测试的过程中,不要使用个人相关或者公司相关的数据作为测试数据,特别是截图。

3.      养成每晚下班前,checkin自己的代码的习惯。

4.      checkin之前,先取得服务器的最新版本,保证代码编译正确。

Java工程中,即使个别文件有编译错误,其它文件依然可以正常编译,但是有些语言的工程是需要全部文件编译无误后,才可以正常编译的。

5.      eclipse中由一个Checked Out FilesView,可以一览所有已checkout的文件。

6.      每天早上来了之后,先取得最新的代码,保证大家代码一致。

814

式样变更的问题让人头疼。

这次让我头疼的不是变更的内容本身,而是在对应变更上。

1.      全员开会讨论,如何对应变更。

这样做没有必要,领导内部讨论完,给member一个方案就成了。

2.      对于某个变更,花了很长时间在全员会议上讲,为什么这样对应,还让大家去想领导的这种方式好不好。

这样做也没有必要,不是自己的机能自己也听不懂。对于member,我承认,需要有自己的主见,但是在那种情况下,member需要的,就是结论。

    819

    我生日。其实很期盼领导跟我说一句,过生日,今天就别加班了,结果一直等到930也没听到,可苦了在家等我的那帮兄弟们。

    824

    延迟白热化。

    延迟原因:

1.      作业量大。

以Member1为例,一个机能,三天写了4000行代码,没写完,最后用了9天多,写了20几个类,净代码6000多行,还包括几个共通的类。

这样的结果是,他在例会上被领导狠批了一顿,因为延迟。

2.      延迟。

因为延迟,所以延迟。就是这样。我的体会就是,一直处于延迟状态,影响我的作业质量和作业效率。

    对策:

    加班、调整工程表、找人分担剩余作业任务。

    我觉得,PG阶段,我们的代码质量可以做的更好,但是,这样的原因,导致,自己编码之后,对自己的代码一点信心都没有。因为我几乎没有认真的从头到尾看一遍自己的代码。

    825

    部长,PMPJL安排项目组聚餐。

    得以小释。

    829

    关于编码。

    我习惯上是先写代码,待代码调通之后,再从头整理代码(格式,补注释以及代码优化)。每个人的习惯都不同,但这次,很吃亏。由于代码逻辑比较复杂,代码量也比较大(几千行),等我调试之后,再回头整理的时候,真的很头疼。

以后决定,编码的同时,写简单注释。

    94

    项目开始走入正轨。主要表现在:

1.      大家对作业内容和作业方式都基本熟悉了。

2.      领导加人和调整工程表后,延迟逐渐向0发展。

3.      领导心情变好了。

这一个月,虽然依然在加班,但是比前两个月好多了。

97

发现两个领导的一个共同优点,随和,不摆领导架子。值得推广。

99

关于汇报进度。

从项目启动开始,每天都要汇报进度,直到现在才认识到一些问题:

1.      项目组要事先定义好进度的标准。

对于一个机能的DD,PG或者PT来说,什么样算100%,什么样算90%,什么样算80%。定义好,会节省很多不必要的再质问的时间。

2.      汇报内容要详细

有人认为这很浪费时间,我觉得很有用,也很值得。

既能整理自己的思路,又能让领导及时准确的了解你的作业状况。

主要说明这样几件事:

1.      今天计划做的内容。(工程表中要完成的)

2.      今天实际做了哪些内容。

3.      延迟情况(是否有延迟,有的话说明原因)

4.      对策(基本上就是加班,说明自己什么时候能过挽回延迟)

5.      遇到的问题。(包括一些横展开的注意点,以及一些无法解决的困难)

6.      PT的话,要说明,测试机能名,预计测多少点,实际测多少点,产生多少bug,对应状况等等。

总之一句话,尽可能的说明白。

这个项目,基本上都在例会上汇报进度。个人感觉,不如改用邮件的方式更好一些。

914

划工程表的一个小失误,没有考虑到节假日。(端午节休息)

916

写邮件时,被领导指摘了。一定要写有意义的title

927

加班生活结束。

104

提交最终代码。

106

修改DD

再回头看自己两个多月前做过的DD时,发现做的真的很烂。

1. 缺少框架的概念。

2. 欠缺共通的思想。

3. 关于异常,Log等细节考虑的不全面。

以后需要注意。

七.   项目之后,谈谈心情

从心里来说,其实从不觉得这个项目累,比起曾经,这样的加班不算什么。但是,这个项目做起来,没有做上一个项目舒服。

做上一个项目的时候,自己一直被领导和身边的人肯定着,我付出的越多,越能帮助大家解决更多的问题,所以,虽然每天加班到很晚,但是做的很开心。

做这个项目的时候,从一开始我就处于延迟状态,每天加班的目的只有一个,就是挽回自己的延迟。别说帮别人分担作业了,连自己的作业都无法完成。这样的加班,不可能是开心,只能让我更加急躁。最烦的时候,甚至开始抵触加班。

那段日子,不只我烦,包括领导,大家都烦。虽然心情会影响到一部分工作,但大家还是一起挺过来了。

我觉得我们是成功的,因为我们都坚持到了最后。

无论遇到什么事,只要坚持住,相信一切都会好起来的。



欢迎来访!^.^!
本BLOG仅用于个人学习交流!
目的在于记录个人成长.
所有文字均属于个人理解.
如有错误,望多多指教!不胜感激!

Feedback

# re: 最近的外包项目总结[未登录]  回复  更多评论   

2008-10-07 11:05 by chinajj
写的挺实在

# re: 最近的外包项目总结  回复  更多评论   

2008-10-07 20:41 by
你这整个一短篇小说啊....
看完了,累死~
听说你混的不错,就知道你肯定会混的不错~
久城,加油啊~~

# re: 最近的外包项目总结  回复  更多评论   

2008-10-07 22:11 by Robin's Java World
对日外包的最大特点:把人做傻!

# re: 最近的外包项目总结  回复  更多评论   

2008-10-08 00:18 by 隔叶黄莺
看到一点,对日外包,打死我也不会
不把人当人

# re: 最近的外包项目总结  回复  更多评论   

2008-10-08 01:42 by 过河卒
来顶你一下,好久不来了 哈哈

# re: 最近的外包项目总结[未登录]  回复  更多评论   

2008-10-08 10:09 by 竹十一
写的不错!

# re: 最近的外包项目总结  回复  更多评论   

2008-10-08 18:08 by ccbobocat
请问
dd pg pt
分别是什么?

# re: 最近的外包项目总结  回复  更多评论   

2008-10-11 12:37 by 久城
@everyone
哈哈,好久不见这么多人了。
@ccbobocat
详细设计,编码,单元测试

# re: 最近的外包项目总结  回复  更多评论   

2009-01-19 19:34 by Rosicky
昨天在google上搜内聚和耦合的概念时搜到你的博客,小样,开新博也不通知我,不厚道啊。

客观的说,久城的博客写的很有含金量。特别是这篇,看完以后收益良多。我现在也在公司做一个项目,发现很多东西其实是互通的。每个人都有自己的惰性,写完code以后很少回去单元测试,更不用说代码重构了。由于我们都是实习生,有一个member回家过年了,恰逢测试阶段,改他代码改到头大……

个人觉得代码重构很重要,好的代码结构易于维护。不知道你们的review做的工作是检查代码的结构性还是功能性。我们的项目里面没有这样一个环节。我觉得定期的review还是很重要的。

另外还有一个问题需要确认一下,久城觉得是否有可能将所有的document用测试用例来描述。如果答案是肯定的,将会减少很大一部分时间,比如文档的维护。关于TDD我只闻其概念,没有什么实际经验。大家可以一起思考这个问题。

有空来上海找我玩。你说09年的愿望是来南方一次,不知道上海算不算。很久不见,miss u, miss 大家。

只有注册用户登录后才能发表评论。


网站导航:
 

Copyright © 久城