敏捷初体验

　　(考虑到公司保密，略有修改)

　　第一次对敏捷有具体印象是因为看到的一则新闻，微软最新的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、  改变多年的编程习惯，需要一定的成本。

 

以上就是我关于敏捷的一些浅显的、新鲜的体验，相信很多也已经敏捷了的人应该也有很多跟我相同或不同的体验。而随着敏捷不断的深入推行，这些细微体验也将汇合成各种经验，从而帮助我们更好的理解敏捷的理念。而当面对推出来的各种名目繁多的敏捷实践的选择，我想可能跟选老婆一样：她很好，却未必适合你。