• 2007-12-25

    圣诞聊敏捷

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/12705285.html

    在ThoughtWorks待了大半年,听的见的经历的最多的当然是敏捷。圣诞之夜,不妨整理一下现时心目中的敏捷。

    提及敏捷,主要是两种反映,济世良药或是洪水猛兽,当然,也有人置身事外。其实,敏捷只不过是一种软件开发方法而已,与传统软件开发方法开发方法并无本质区别:敏捷也需要知道到底软件要干什么,所以,分析需求不可或缺;敏捷最终也是把软件提交给客户,所以,也要一行行把代码写出来;敏捷出的软件也会有错误,所以,测试阶段是不可缺少的;敏捷出的软件业务也会变化,所以,代码也需要维护;敏捷的情况下,为了在给客户展示,所以,偶尔也要加班……

    如此说来,敏捷是不是和传统软件没有分别了呢?显然不是,任何事物一旦拉高到本质的高度,恐怕都没有区别了,就像“人”可以涵盖人这个物种,但事实上,人还有男人、女人、好人、坏人……等等众多区别手段。

    相信大多数人有这样的感觉,念书的时候,总有那么一些怪物,看起来,玩得不比别人少,书读得不比别人多,但考试成绩总比别人。这样的怪物是怎样炼成的呢?说起来,很简单,他们懂得了一些学习的方法,所以,他们可以在同样的时间内,取得比别人高许多的结果。

    做事,是有方法的。

    好的做事方法绝对是大幅度的提高效率的。相对来说,敏捷就是一种好的工作方法。

    敏捷重视人在软件开发中的价值,所以,在敏捷团队中,开发者在团队中地位很高,这让我们在心理上得到了极大的满足,于是乎,心情很是愉悦。在很多强调传统软件工程的团队中,开发者不过是一颗螺丝钉,一个可有可无的角色,受重视程度自然很一般,除了自力更生,心情上与敏捷团队不可同日而语。两种团队,我都经历过,差异极大。其实,无论在什么样的团队中,我们都要完成类似的工作——编写代码,但是,想必人人都清楚,心情对于一个人工作的影响。

    除了完成工作,我们需要的还有发展。专业技能上的成长,除了自己摸索,更重要的还有吸收来自别人的营养。在传统的方法团队中,除了读书,只有偶尔大家的交流才能让人得到向别人学习的机会,大多数情况下,我们所能做的就是单枪匹马的孤军奋战。幸运的话,也许能够走上的正确的道路,大多数人必然会绕很大的圈子,更不幸者,也许就此失去了对软件开发的兴趣,或默默忍受编程带给自己的痛苦,或干脆离开这个是非圈。

    在敏捷团队中,过程本身采用的一些方法就是前人经验的总结,比如测试驱动开发。结对编程可以让人有机会观察别人是如何工作的,从中吸取养分,这些细节是几乎不可能从书本或是课堂学到的,比如,在ThoughtWorks工作之前,我从未意识到快捷键对工作的帮助如此之大,当看到其他人按键如飞后,我决定在今后的开发中,尽可能多的使用快捷键。在两个人共同开发的过程中,我们有机会看到自己同伴对于一个问题思考的过程,这对于我们的提高绝对是有益的,特别是和一些高水平的人合作。良性循环和恶性循环显然不是一回事。

    软件是为人服务的。软件开发是为了将软件创造出来,而不是为了为难开发团队。如果你曾经在传统开发团队工作过,提到这一点,脑子中多半会浮现出“文档”这两个字。敏捷团队也会写文档,但我们写的是那些对客户有价值的文档,而不是把时间浪费在那些为了过级而编写而且完成之后便会束之高阁的文档。不给自己找麻烦是很必要的。

    敏捷和某些传统软件开发过程可以说是殊途同归,比如,CMM到了最高的级别,会向自适应的方向发展,而敏捷本身也是在过程中不断的进行自我调整,做到兵来将挡。当然,走到一起之前,二者的差别显得还是很大。

    以上这些都是站在我——一个开发者——的角度体会的敏捷,显然,并不全面。某些人提到敏捷,还会有更加伟大的角度,比如,业务之类的,那不是我所擅长的。

    既然敏捷如此之好,为什么敏捷团队还是如此有限?回到最初那个读书的比喻上,优等生的方法不见得是每个人都知道的。即便知道了,相信、学习到掌握还要有一个过程。敏捷是不是终极解决方案,我想不会,天外总有天,如果哪一天,我知道更好的方法,我愿意接受。

    写下这些文字的时候,Ruby 1.9.0发布了,感谢Ruby开发团队带给大家的圣诞礼物!

    分享到:

    历史上的今天:

    圣诞随想 2005-12-25
    圣诞快乐! 2003-12-25
    引用地址:

    评论

  • 如果敏捷是一种好的工作方法,那么,具体应用应该取决于个人的悟性了
    回复陈老师说:
    我无意说敏捷究竟是好是坏,每个人对于敏捷的看法各不相同,有些人喜欢,有些人不喜欢。

    我想说的是,每个人都应该有一套适合自己的有效的工作方法,而不是把时间浪费在不该浪费的地方。
    2008-01-03 23:11:40
  • 敏捷应用在大项目中不知道多不多, 但肯定会比小项目难. 众人的个人价值和想法要调和地实现肯定会有更多的交流成本. 所以参加过的成员多一点的项目都是传统方式, 只许少数人发挥, 多数人跟着就行, 绝对不能别出心裁.

    这好象是民主还是独裁的问题.

    而结对编程可能又是另一个话题.

    -----------------------------------
    圣诞快乐! RHG的事现在有我可以做的吗?
    回复jiangcf说:
    敏捷中谈到的某些东西,并不局限于项目大小,比如单元测试,这肯定是有益的。
    2008-01-03 23:14:38
  • 很对,不被重视是每一个developer的悲哀,无法发挥自己的个人价值和想法。可惜国内的公司大多如此的“愚蠢”,似乎敏捷开发就意味这项目的无限dely.可悲。

    能不能把你的blog上的评论框放大一些呢?太不友好了吧:)
    回复killvin说:
    首先想个问题,人家为什么要重视你,价值何在。

    不是每个人都有想法的,大多数人的想法与工作内容无关,也许最多的是抱怨。
    2008-01-03 23:18:48