GHawk

导航

<2005年12月>
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

统计

常用链接

留言簿(7)

随笔分类

随笔档案

Blogs

搜索

最新评论

阅读排行榜

评论排行榜

过程的代价

这个月刚进入公司,加入了一个10人左右的团队,用Java做一个网站后台。

客户是日本公司,他们做了项目的大部分分析(Requirements, Use cases, Domain model...)。我们负责的是详细设计和开发。我是项目开始几星期后才进的公司。Schedule也已经为我分配好了。大家都按照schedule上的安排工作着。

上星期开会的时候得知,日本这次采用的是agile过程。而我们的schedule更类似于RUP这样的过程。RUP这个学院派和Agile这个造反派狭路相逢,问题也就出现了。

大家工作都很卖力,为了能按进度提交制品,有时还通宵达旦解决问题。我们这支团队的战斗力和信心是不容怀疑的。可是大家努力的结果换来的却是用户的抱怨。大家都困惑不解。问题究竟出在哪儿?

日方在项目中强调的是Agile过程,我们采用的则是传统的过程。一开始,两个过程方法之间的差异并不大;对我们提交的制品,客户也没有什么异议。但是,直到客户提出问题之前,我们所提交的制品都是一些设计文档。而我们的制品也仅限于此——没有一个可用的EAR包、没有写过 test case。很明显,我们犯了agile的大忌。

Agile所强调的是快速的构建、轻量级的迭代、TDD等。由于之前没有写test case,详细设计也没有test case可以参照。设计本身是不是合理,是不是testable也不得而知。致使在设计test case的时候无从下手,很多类甚至都没有办法测试。整个架构的可行性很难估算。

往后考虑。一次大规模的重构可能是少不了的。虽然agile过程本身提倡以TDD为基础的重构。但是现在的重构可能造成的代价已经不是一次轻量级的增量迭代了。

说到这里,总结几点,希望能在以后的工作中引起注意:
1. Agile很难管理,项目早期应该对各种风险有尽可能全面的评估,schedule的设置中应该定义好 test case 和 build 的时间点。
2. 设计不必太详细,用频繁的测试和重构完善设计。
3. Test case 优先设计,这样在架构中就会对testability有足够多的考虑。
4. 团队内部对共同的难题应该及早进行讨论和解决,问题的解决方案应该传递到每个组员,尽可能保证团队的能力同步。

posted on 2005-12-14 09:57 GHawk 阅读(1194) 评论(5)  编辑  收藏 所属分类: 软件过程

评论

# re: 过程的代价 2005-12-14 10:56 Agile

双方没有约定迭代周期? 没有对每次迭代确定feature? 日方要走Agile,而你们不是,管理上的问题  回复  更多评论   

# re: 过程的代价 2005-12-14 11:19 GHawk

在Agile的实施方面有没有比较好的Guide?
请高手多多赐教!  回复  更多评论   

# re: 过程的代价 2005-12-14 19:59 luffy520

会用心记得^_^  回复  更多评论   

# re: 过程的代价 2006-01-06 00:46

敏捷要求的是一个团队中大多数的人起码都是OO的高手,不会写出一些很垃圾的代码来,机械的使用agile的过程可能适得其反

如果是团队的问题的话,那也没有办法啦,再加班也是枉然  回复  更多评论   

# re: 过程的代价 2006-01-06 09:48 GHawk

现在的越来越像是用面向过程的方式开发的了,OO的踪迹越来越浅了。也许是因为我没系统地用过C,或是我用不好面向过程方法,我觉得非OO的设计正在把这个系统变得越来越丑陋。(我没有贬低面向过程方法的意思,好的面向过程设计应该也有它优美之处吧^_^)大家花费时间和精力写出来的代码没有什么重用性可言。大家在设计上下的工夫太少了……  回复  更多评论   


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


网站导航:
博客园   IT新闻   Chat2DB   C++博客   博问