敏捷初体验
2010-09-22 23:20 袁国彬 阅读(2896) 评论(23) 编辑 收藏 举报(考虑到公司保密,略有修改)
第一次对敏捷有具体印象是因为看到的一则新闻,微软最新的visual studio2010包含了基于Scrum开发实践的敏捷开发流程模板。第一次正面遭遇敏捷还是公司的敏捷考试,且来势汹汹。不得不承认,考试对于普及一项知识,有着其他手段几乎无法代替的杀伤力。于是,众人纷纷“被敏捷”。
在学到敏捷不鼓励以“work harder”的方式来完成工作时,大家都向往着程序员的美好时光是否真的就要到来,尽管不停的有人说这只是一个很傻,很天真的想法,要尽早断了这个念想。但是,在公司紧锣密鼓的培训和部署下,敏捷已逐步走进我们的生活。
到目前为止,迭代零已经基本结束,我所经历过的敏捷实践主要有:每日站会,持续集成,结对编程,TDD(测试驱动开发)等。毛主席说:“实践是检验真理的唯一标准”,我将从我所经历的这几个实践中谈谈我的体会。我不是敏捷教练和专家,并不是要检验真理,也并不能指导别人,而仅仅是一种初次闯入敏捷世界的一些体验,这种体验可能是局部的,琐碎的,当然,如果你觉得是荒唐的,请一笑而过。仅以共勉。
每日站会
据我观察,也可能是据所有人观察,各FB差不多都是以“每日站会”宣告着自己进入敏捷开发的。我也在每日站会着。我想这主要跟它的特点是有关系的,首先它好操作,大家围一围按照模板说三句话就行了。其次,它有很强的标示性,大家早上一来看见一伙人围在一起,就明白了,“哦,那伙人已经敏捷了”。你没有“每日站会”自然出去都不好意思跟人打招呼。
每日站会我想应该是有这么几个要素的:首先,每日站会的主要目的就是要让别人了解你的进度,和你当前的困难,以及了解别人的进度和困难。这就是一种类似“接口”形式的交流,所以不能多讲跟其他人无关的细节。既然是接口,自然就只关心你能提供的功能,不关心实现,除非你遇到了实现上的困难。其次,就体现在“站”字上,既然要站着,就是提醒大家不要说太多,打持久战。一站会开一小时,累的大家腰酸背疼腿抽筋。其他的就不多说了,总而言之,“你今天站会了吗?”。
持续集成
持续集成对于我们FB来说,可能不是初体验了。2.0很早的时候就开始了持续集成的工作。其带来的好处,我们深有感触。还记得那年,我们刚来公司,在1.0.1,那时,我们的生产工具还很落后,基本用例回归只能靠双手。“版本升级,PATH分裂,小区合并,双光纤,各种RRU级联,各种情况打电话,小区BLOCK/UNBLOCK 100次…”,版本一个接着一个,那是相当多的版本在晚上的10:00以后编出来,回归完已是第二天的事情了。怕一个人回归寂寞,于是每次都安排两人,我们就从这里体会着“人性化”。而版本回归也构成了1.0.1的重要记忆。
有了持续集成之后,就不用担心你回归的不是用例,是寂寞了。因为你可以把寂寞交给电脑。而2.0之后手动回归基本用例也基本成为历史。
结对编程
以前还在上学的时候,在图书馆经常会看到“极限编程”之类的书,大多望而却步。因为,看到“极限”二字,常常会让我联想到“要练此功,必先自宫”。觉得这种境界的书,不是一般人能看的。万没想到的是,参加完敏捷迷你培训之后才知道,原来“极限编程”是这个意思,而结对编程就是其中一个经典的案例。
结对编程的思想就是codereview到极限,时时codereview。两个人用同一台电脑写代码,初来觉得很怪,会觉得别扭。也觉得可能会在“兄台先”,“不,兄台你先”的相互谦让中降低效率。而事实上codereview发现缺陷的成本是最低的,结对编程的目的本质是要降低这个成本。同时两个人写代码正好是一个反着的木桶原理,就是最后代码的风格,设计的好坏,是以最好的那个为准的,这个最好可能不光是两个人当中的最好,还包括你自己跟自己以前比,你会很不好意思把代码写的很难看。两个人在一起写代码还有一个好处是,你可能会学到你之前在写代码时不知道的优秀的东西,这些东西可能是从对方那直接学来的,也可能是两个人讨论碰撞得来的。而我也非常有幸在迭代零跟专家组同事一起搭档结对编程,受益匪浅。
TDD
TDD也是极限编程的一种,鼓励把测试做到极限。之前因为跟专家组同事搭档TDD过,专家组叫写过一总结。现在看看感觉有些地方现在的体验可能稍稍有些不同,但是既然是初体验,我想它是在刚刚做完TDD之后的第一时间写的,应该更能代表我本来的想法。所以原封不动的帖出来。
TDD的优势:
1、 TDD因为先有测试例再写代码,这样会强迫自己担任两个角色,“提需求”和“实现需求”(结对编程的时候这两个角色可以由两个人交替担任)。通过这两个阶段,更能接近或达到最终的正确目标。
2、 TDD写出来的测试用例目的是驱动开发,能有效避免后面补充测哪个试用例是为了补质量活动的敷衍心理,所以这样写出来的测试用例质量更高。
3、 对不是采用TDD开发的特性,目前实际开发的流程是:code,codereview,OT,WBIT,MT。这不符合开发的典型流程,MT(单元测试)活动的意义被大打折扣,根据以往的经验,这个阶段的MT能发现问题的概率微乎其微。
TDD注意事项:
1、 由于完成代码编写在项目上会被作为一个很重要的里程碑,而TDD在完成编码的速度上不具有优势,所以决定采用TDD的时候,需要本人与相关决策人沟通好进度。相关决策人也需要了解这一点,并给予支持。这点很重要。
TDD的劣势:
1、 不适合赶进度的项目。
2、 改变多年的编程习惯,需要一定的成本。
以上就是我关于敏捷的一些浅显的、新鲜的体验,相信很多也已经敏捷了的人应该也有很多跟我相同或不同的体验。而随着敏捷不断的深入推行,这些细微体验也将汇合成各种经验,从而帮助我们更好的理解敏捷的理念。而当面对推出来的各种名目繁多的敏捷实践的选择,我想可能跟选老婆一样:她很好,却未必适合你。