论坛首页 综合技术论坛

TL日记

浏览 22028 次
锁定老帖子 主题:TL日记
该帖已经被评为良好帖
作者 正文
   发表时间:2008-09-29  
十一长假干啥?原本计划购物+电影+游戏+运动,今早起来忽然回忆起半个月之前工作中的问题,很多问题想不明白,Google了一下到了JE,拜读了不少高人的大作,感觉就像蒸了一个桑拿,痛快淋漓。从中发现自己很多不足,感觉和高人差距太大,于是心中愤慨,工作8年了还有这么多不懂的地方,一定要振奋起来,看看从我现在的状况达到高人的境界需要几年,计划将今后的工作日志一一在这里贴出来,根据每天所发生的问题,希望能与高人实时互动,得到高人的指点。

先说一下个人情况。81年,中专,2000年开始工作,最初做美工,过了一年转php,过了一年转java,至今。期间有过2年创业,1年部门经理。当前在一个150人的公司,软件部门50人左右,我在一个Java组(3人)。

部门将计划在半年左右扩招Java组到10-20人左右,这给我提出了严峻的挑战。而无论半年后是否会扩招到20人,从个人成长来看也非常有必要提高各项水平。

我个人当前存在的问题:
1、软件工程只是略懂理论,没有真正的实践经验;
2、Java技术只是停留在应用开发阶段,对OOP思想没有真正贯彻,在进行大的系统设计时感到很吃力;

小组内另外两个人的情况:
1、A君:本科,7年经验,Java2年;
2、B君:硕士,半年经验;

小组当前工作情况:
1、我:负责公司主要软件的版本;
2、A君:另外一个软件的版本;
3、B君:配合我和A君的工作;

小组内用到的工具:
IDE:MyEclipse
版本控制:VSS(因为整个软件部门很多C++代码,领导用惯了vss)
Bug跟踪:JTrac

部门内常用的文档:
规格,概设,详设,修改。

回顾前两周工作中存在的问题:
1、一个我自认为我可以5天搞定的项目(项目A),直接给了A、君(我去修改另外一个软件的UI和实现新功能),结果做了10天(包括每天加班到11点)都没有作出合格的版本;领导很生气,后果很严重。部门领导认为我在这个项目中计划、人员分配上有严重的失误。
2、A君和B君在开发过程中没有文档、设计;

针对以上两个问题,部门计划:
1、项目A重写;
2、Java组建立一套严格的规范(我已经草创了一套《JavaWeb开发规范》,但感觉执行起来很困难)

国庆7天之后,我将把每天工作中遇到的问题和心得贴出来,希望高人能够解惑。
   发表时间:2008-09-29  
整个小组先做个回顾会议,群策群力。

可以参考 SCRUM的retrospective的方式。
0 请登录后投票
   发表时间:2008-09-29  
谢谢。
头一次听说SCRUM。之前看过一些RUP,其中的每次迭代最后的“评估会议”和你说的retrospective可能类似。我也有此想法,打算过完10.1就和A君、B君来一次retrospective,回顾一下项目中的过程,总结一些教训。

有几个问题请教一下:

1、RUP和敏捷开发有哪些区别?

2、每一次的迭代是否可以理解为一个“版本计划”。当前我们部门还没有正式的版本发布流程,部门领导也意识到这一点,比如版本目标等,都不是最初设计的,而是忽然市场有哪些需要了,临时确定在某天要出新版本,其目标、需求、规格都是很模糊。上一个项目中的失败中,我们三个人对需求规格理解不够清晰是一个最为显著的原因。

3、每一次迭代都有需求、设计、编码、测试,如果是增量的、在当前版本上进行的新功能增加,那么其中的“设计”是否可以理解为在某一版本基础之上的“修改设计”?那么这个“设计”的输出就是一份“修改设计文档”?


0 请登录后投票
   发表时间:2008-09-29  
这些问题也都不是两三句能说明白的。
推荐一下Crystal Clear,假期有空可以看看,也许能回答这些问题。

水晶项目管理体系(Crystal Clear)
http://tuti.iteye.com/admin/blogs/243678
0 请登录后投票
   发表时间:2008-10-08  
5天完成的,最后10天完了还做的不好,第二天第三天您干嘛呢?
0 请登录后投票
   发表时间:2008-10-08  
对进度的可视度不够,
可以提高工作量来增加可视度
也可以自管理来增加可视度

主要看你想不想花这个精力来作了.
0 请登录后投票
   发表时间:2008-10-09  
试着回答这几个问题

cceyjames 写道
谢谢。
头一次听说SCRUM。之前看过一些RUP,其中的每次迭代最后的“评估会议”和你说的retrospective可能类似。我也有此想法,打算过完10.1就和A君、B君来一次retrospective,回顾一下项目中的过程,总结一些教训。

有几个问题请教一下:

1、RUP和敏捷开发有哪些区别?

2、每一次的迭代是否可以理解为一个“版本计划”。当前我们部门还没有正式的版本发布流程,部门领导也意识到这一点,比如版本目标等,都不是最初设计的,而是忽然市场有哪些需要了,临时确定在某天要出新版本,其目标、需求、规格都是很模糊。上一个项目中的失败中,我们三个人对需求规格理解不够清晰是一个最为显著的原因。

3、每一次迭代都有需求、设计、编码、测试,如果是增量的、在当前版本上进行的新功能增加,那么其中的“设计”是否可以理解为在某一版本基础之上的“修改设计”?那么这个“设计”的输出就是一份“修改设计文档”?




下面Agile,以Scrum为例。

1. 看看RUP和Agile的书可以从理论知道他们的区别,具体的需要自己去实践才知道。 总的来说Agile是轻量级的过程,对<10个人的项目很合适,项目如果很大的话也是可以的。 像我们项目,>70人,也采用Scrum。 Scrum of Scrum,Scrum of Scrum of Scrum呗。 Agile最适合前期需求不明确或者需求变化快的项目,短时间推出一个可以work的版本,对项目成员来说有成就感(激励?),同时也可以得到客户的及时反馈。发现问题可以早解决。
从你们项目来看,Agile应该是一种不错的选择,当然最好自己先学学Agile,理解它的一些Principle,Rule,然后慢慢实践摸索,找到适合的应用Agile的方式。比如说Scrum Daily meeting, 原则早上来了开比较好,我们组是下班前看,因为大家上班时间不太一致,经常10点还有人没到。 又比如一般一个Sprint是4周,我们组4周实行了半年,现在变成了2周。

2. 一次迭代可以认为是一个版本计划,但这个版本并不一定发布,但最好可以Demo,可以看到这个迭代的进展。

3. 是“设计文档”而不是什么“修改设计文档”。 设计文档尽量精简。 我说说我们的情况。一般我们1个人月的工作量,设计用3-4个PPT页面可以涵盖,主要是用来交流讨论用,有high level的设计就可以了(功能是什么,大概怎么做,和其他模块有什么依赖,影响等),真正的detail设计在代码中体现。 注意增加单元测试的覆盖率,虽然有时候这个很难。

另外retrospective貌似很好,发现不足,提出改进意见嘛。 从实际看,这个也很难。有些问题要解决执行很困难。我记得去年提的问题还有很多没有解决。:)  但还是强烈推荐你试一次。
0 请登录后投票
   发表时间:2008-10-12  
谢谢各位的意见。

ladofwind,在发现存在问题的第三天的同时,我正在另外一个软件上,同样是急事。我当时就想干脆我一个人来干,2天内一定解决。当然,对此错误的说法领导严厉的批评了我。后来我想介入,可是发现里面太乱。灰心之余也无济于事。

抛出异常的爱,管理的可视度怎么理解?

ewon,Agile是TDD吗?我找了些资料,还是了解不多。我曾跟领导反映过采用TDD的方式来开发,领导表示以前有过类似的失败案例,不想冒险。另外,领导制定了在产品修改时一定要有非常详细的“修改设计文档”,堪比详设。

国庆之后的一周,新招了一个实力较强的人(C君),以前做过TL。同时,另外两个同事也在忙着自己独立的软件。看着他们那么痛苦,我也是爱莫能助。因此铁了心,下次新的版本时,无论哪个软件,都必须给我把详设和修改设计统统写完整,文档一次不能通过评审就一直重复。

最近领导计划把JTRAC推广到全公司各个开发部门,但需要对JTRAC作一些修改,领导就安排C君负责修改。现在小组内的态势是:
A君:独立负责某软件的1.0;
B君:对上一个失败的产品进行代码整理;
C君:JTRAC修改;
我:某软件的最新版本;

如果是一个人负责一个产品,我就不用花那么多心思了。但这绝不是理想的开发模式,没有团队协作可言。
0 请登录后投票
   发表时间:2008-10-12  
五天完成的东西,还称得上项目吗,A君被你害死了~~~~,超时这么长时间,要么是A君对需求没吃透,思路不清楚,要么就是对公司的类库或开发资源不熟悉。
因为我看你说的,好像A君是新招来的,这说明A君处在磨合期,你就用熟手的标准来下任务~~~,唉

再个,不要把时间耗在无意义的文档和讨论会上,否则会让人有拖延进度的借口,
文档最好有模板,有例子,问答式或填表式的文档模板效率最高,出错最少
0 请登录后投票
   发表时间:2008-10-13  
cceyjames 写道


有几个问题请教一下:

1、RUP和敏捷开发有哪些区别?

2、每一次的迭代是否可以理解为一个“版本计划”。当前我们部门还没有正式的版本发布流程,部门领导也意识到这一点,比如版本目标等,都不是最初设计的,而是忽然市场有哪些需要了,临时确定在某天要出新版本,其目标、需求、规格都是很模糊。上一个项目中的失败中,我们三个人对需求规格理解不够清晰是一个最为显著的原因。

3、每一次迭代都有需求、设计、编码、测试,如果是增量的、在当前版本上进行的新功能增加,那么其中的“设计”是否可以理解为在某一版本基础之上的“修改设计”?那么这个“设计”的输出就是一份“修改设计文档”?



正如上面的dx所说,RUP和敏捷开发的区别不是三言两语就能说明白的,而且这些东西也不是一天两天你就能深刻领悟的,也不是说看一两本书就能掌握的,这些东西绝对不想什么SSH,struts之类的,一个礼拜可以掌握,而是需要长时间的理论及实践,同事还要不断的反思才能不段的去领悟。

这也是通用技术与工具(SSH,struts,这些在我看来算不是技术,仅仅是工具而已)的区别。

对于需求、设计、编码、测试,我还记得我在大学做毕业设计的时候,当时严格的按照RUP的方式来开发,结果就是很多文档,后来单单设计论文就把老师吓坏了,让我少打点。可是,通过这些年的经验下来,我绝对需求最好的纪录方式莫过于bug跟踪系统,即便你采用简单的todo-list都要比那些标准的需求文档要高效的多。因为需求总是不段的变化,你需要的是能够灵活轻便的工具来节省时间,而不是把那些时间都耗在那些所谓的标准文档上。等系统构建完备(如一次迭代完成),再来把这些文档标准化,比如把todo-list转换成标准的需求文档。因为毕竟那些所谓的标准的文档只是用来方便大家阅读。想想看吧,你打开一个txt的todo-ist是不是比打开一个word文档快很多?

同样的,架构设计之类的也是一样,先简单的纪录下来,后面在标准化。

总之一句话,简单的工具能够最灵活的面对变化,因为修改起来也很简单。在变化很频繁之前,我建议先从简单的工具开始。这也是软件开发里简单就是美的一种提现之一。

通常,我不喜欢详细设计,当然架构设计必须要有。因为,在你开始编码之前,简单的设计总是需要的。

当然,我是习惯于TDD的开发方式,也许这样的方式并不适合你,因此,也许你需要做详细设计。

cceyjames 写道

ewon,Agile是TDD吗?我找了些资料,还是了解不多。我曾跟领导反映过采用TDD的方式来开发,领导表示以前有过类似的失败案例,不想冒险。另外,领导制定了在产品修改时一定要有非常详细的“修改设计文档”,堪比详设。


和上面描述rup,敏捷开发一样,和SSH,struts等不一样,像TDD这样的通用技术,不是短时间内能够学会的,从你的言语来看,好像你对Agile和TDD的关系还不是很清楚,从这点来讲,我可以判断你至少还不习惯于TDD的这种开发方式,更何况Agile(如果我看错了,请恕我眼拙),可是,你对TDD都了解的不多,你就跟领导反应采用TDD的方式来开发,我觉得这个问题比较严重。很显然你并没有考虑过风险,也许你考虑过了,但是你不知道。不管怎么样,每个开发人员都应该知道这一点,越新的技术,风险越到,你越不懂的技术,风险越大,就比如,如果你的C++掌握的很好,很精通,可是现在跑出个什么ruby来,人家说怎末怎末好,然后你就要抛弃c++而采用ruby,我是觉得这个很可怕,记住,你不知道的东西,风险往往都是最大的,我原以为对于你这样工作8年的,这些应该都知道,而且,对于一个优秀的开发人员,这些也是必备的。

我建议楼主还是多看看软件工程理论的东西,在你实践之前,理论并不是想象当中的那么没用,否则,这个世界也就没于书了。

最后,我把我以前的一个同事的话转给你,“你评估任何开发时间,一定要以你正常的开发时间 X 3 ”,就如你上面的,你分配给A 君的,应该是5 * 3=15天才对,而且,你应该还要考虑其他情况,比如,你的5天他是否能5天作为,也许你5天做完的东西,他要7天呢。你千万不要这么想,我5天做完,他也必须五天作为,因为,还有一件事情,你拿的工资和他拿的相信以不一样,如果你真的这么想,那可以预见的是,你们这个团队不会久远。

说的比较多,希望对你有所帮助,这仅仅只是偶的想法,仅供参考。

哎,要预见风险啊,偶就是没预见到金融危机这么严重,然后就贸然离职,搞得现在都还在失业呢 ,痛苦。
1 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics