论坛首页 入门技术论坛

正确认识scrum和xp

浏览 9816 次
该帖已经被评为新手帖
作者 正文
   发表时间:2010-09-06  
可问题是他说“我写得程序,不需要单元测试用例,写完之后,自己心中有常见的测试用例,照着测一遍”
0 请登录后投票
   发表时间:2010-09-07   最后修改:2010-09-07
引用
也许在实际项目中我没法完全按照自己的理解去推行XP的实践,但没法推行并不等于不正确。正如现实生活中有丑陋,善良并不总能实现,可这不妨碍我认为善良是好的。如果你认为这是偏激的话,那么我承认。


善有很多种,tdd是好东西,我并没有否认。但你也不能推断,没有tdd的东西,就不是善。

我没有做过tdd,单元测试做过一些。系统的自动化测试,我做了三年。我的经历会特殊一些,开发,测试,我都做过。先来说下单元测试。

单元测试这个概念,对于绝大部分的开发人员来讲,是一个观念的转变。很多开发人员会想,还要我写单元测试?所以即使在我们原来的部门,有老大们倡导推行着,单元测试的覆盖率也是小的可怜。

再来说说tdd,这个理念让人接受就更难了。先不写代码,先写测试用例。然后编写代码,保证这些用例通过。

tdd和unite test根本的区别,在于先后。所以,只是写了单元测试用例,不叫做tdd。

为什么说tdd对团队的要求很高?最最起码的一点,团队的开发人员要接受这种理念。理念的改变,往往是最难的。还有就是测试人员的安排。他们如何溶入到这个实践中来?要知道,国内的测试人员,能写程序的,寥寥。

tdd对于真正的高手来讲,是不需要这些的。世界上多如牛毛的开源软件,基本上都是一个人写出来的。你看看他们的代码中,有没有tdd?可能单元测试都没有。但这并不妨碍他们成为优秀的作品。

知其然,更要知道其所以然。要知道xp里面的很多实践,有它的文化基础,和团队基础。所有的东西,都照搬过来,会成问题的。

大家考虑问题,不要只是站在开发的角度来考虑。强迫自己站在管理者的角度,比如,让你来作master,你要在团队里面推行tdd,会不会遇到什么问题?如果大家站在这个角度考虑问题,很多观点就会变的。
0 请登录后投票
   发表时间:2010-09-07   最后修改:2010-09-08
wwccss 写道
再来说说tdd,这个理念让人接受就更难了。先不写代码,先写测试用例。然后编写代码,保证这些用例通过。

tdd和unite test根本的区别,在于先后。所以,只是写了单元测试用例,不叫做tdd。

为什么说tdd对团队的要求很高?最最起码的一点,团队的开发人员要接受这种理念。理念的改变,往往是最难的。还有就是测试人员的安排。他们如何溶入到这个实践中来?要知道,国内的测试人员,能写程序的,寥寥。

感觉这个问题受两方面影响:
1,传统的测试观念先入为主;
2,测试驱动开发这个名字起得不够好,容易让人误解。TDD写的不是测试,是文档(寂寞 ):
ozzzzzz 写道
测试是测试,测试驱动是测试驱动,别把两个东西搞混了。说白了测试驱动还是需求驱动,而测试则需要考虑更多的东西。

gigix 写道
在编写一段代码之前你所写的测试,不是为了确保这段代码不出错,而是为了描述你想要做的事情。

gigix 写道
withoutmewang 写道
gigix 写道
withoutmewang 写道
我不知道拿到一个任务时,你们是如何起步写测试方法的? 同学们分享下经验啊

如果不写测试那你第一步做什么?

如何起步写测试,从哪儿开始?
我的想法是从界面开始一层层往下剥,一直到数据库为止。

我在问你呢
如果不写测试你第一步做什么?
回答了这个问题你就知道该怎么起步写测试了。

==============================================================================================
wwccss 写道
tdd对于真正的高手来讲,是不需要这些的。世界上多如牛毛的开源软件,基本上都是一个人写出来的。你看看他们的代码中,有没有tdd?可能单元测试都没有。但这并不妨碍他们成为优秀的作品。

问题是我们不是高手。
==============================================================================================
wwccss 写道

大家考虑问题,不要只是站在开发的角度来考虑。强迫自己站在管理者的角度,比如,让你来作master,你要在团队里面推行tdd,会不会遇到什么问题?如果大家站在这个角度考虑问题,很多观点就会变的。

会遇到问题。但我认为如果推行的是一个好的东西,遇到问题首先应该考虑如何解决,而不是放弃。前提是master自己对要推行的东西有个深入的了解,确定它能为团队和公司带来好处。
0 请登录后投票
   发表时间:2010-09-07   最后修改:2010-09-07
呵呵,我并没有说,不能实施tdd。tdd是好东西,但真正能够推广下去,需要很大的努力和风险。这可能涉及到人员的变动,组织结构的变化,还有就是所有开发人员观念的转变。我不敢妄谈在团队里面实施tdd,是因为我知道困难有多大。

至于高手之说,我只是在批驳“不实施tdd,就不敏捷”的这种说法。不管是否是高手,写出来的程序,质量很高,这是我们追求的东西。只要达到这种结果就好了。不管中间具体的手段如何。
0 请登录后投票
   发表时间:2010-09-07   最后修改:2010-09-07
Scrum 是一种组织协作方式, XP包含了很多是技术实践。
Scrum要比XP容易实施,那是因为XP的实施,更需要一些技术能力。

如果一个项目的瓶颈在于组织协作,那么Scrum会有很好的效果。
如果一个项目的瓶颈在于技术实践,那么Scrum效果就会有限。
一般项目,其实在组织协作和技术实践都会有问题,那么Scrum会使项目有一些改善,但项目仍有可能因为开发团队缺乏技术能力而失败。

所以Scrum的组织方式和XP的技术实践相结合,是目前一种比较好的组合方式。
0 请登录后投票
   发表时间:2010-09-07  
引用
tdd和unite test根本的区别,在于先后。所以,只是写了单元测试用例,不叫做tdd。


unit test和tdd的根本区别在于:
只有搞TDD,你才能有高强度的testcases,你才有安全感。
有了安全感,你才有胆量去重构。
只有敢于重构,你才能在代码级别去拥抱变化。

这两者的产出物(test case)不是时间先后的差别,而是两种不同的产物。无论是从coverage还是unit test的可读性来说,高强度的testcase和事后补充的testcase都是两种不同的东西,前者是真正意义上“代码的一部分”,后者多半会在几次修改后被人@Ignore或直接干掉。

0 请登录后投票
   发表时间:2010-09-07  
to iamlotus:

tdd是好东西,但也不要把它作为解决一切的灵丹妙药。感觉你看待问题太偏激了。这会影响你后面的发展。
0 请登录后投票
   发表时间:2010-09-08  
wwccss 写道
呵呵,我并没有说,不能实施tdd。tdd是好东西,但真正能够推广下去,需要很大的努力和风险。这可能涉及到人员的变动,组织结构的变化,还有就是所有开发人员观念的转变。我不敢妄谈在团队里面实施tdd,是因为我知道困难有多大。

至于高手之说,我只是在批驳“不实施tdd,就不敏捷”的这种说法。不管是否是高手,写出来的程序,质量很高,这是我们追求的东西。只要达到这种结果就好了。不管中间具体的手段如何。


其实从你的回帖里面可以看出,你只是由于“需要很大的努力和风险。这可能涉及到人员的变动,组织结构的变化”这些原因而没有在你的团队里面实施TDD,而并非你不想,所以其实你和iamlotus同学的观点并无矛盾,只是你觉得即使不用TDD你也可以写出高质量的代码而已。既然如此,我倒是觉得做一个iamlotus同学一样的四有青年挺好。
0 请登录后投票
   发表时间:2010-09-08  
to Mr.Game,呵呵,感谢你的第一篇帖子发表在这儿。:)

知其不可而为之,勇也。知其不可而顺之,智也。勇,不可久,智,方是长久之道。
0 请登录后投票
   发表时间:2010-09-08  
知行合一。尊重人性。
0 请登录后投票
论坛首页 入门技术版

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