敏捷开发简介

前几天和同事们去西交大作校园宣讲，固然我是去帮忙加旁听的。:-)  HR和同事们介绍了不少关于公司的状况，包括文化，价值观，敏捷开发等等，不少东西我都是第一次学习到，后来我对马同窗说，你那富有激情的关于公司的敏捷介绍让我收获很大，他说我这句话给他很大的鼓舞，呵呵。

　　下面我将马同窗的讲解简单介绍一下，首先看下面这个图:

 

　　这两个圆圈表示不一样的视角上的敏捷实践，包括开发者视角和项目管理的视角。接下来从里向外进行介绍，由于有些实践我了解得不清楚，若是下面有哪些说得不对的地方也请你们指出。

　　Test-Driven Development，测试驱动开发，它是敏捷开发的最重要的部分。在ThoughtWorks，咱们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。而后两我的同时坐在电脑前面，一我的依照Story，从业务需求的角度来编写测试代码，另外一我的看着他而且进行思考，若是有不一样的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另外一我的控制键盘，编写该测试代码的实现。若是没有测试代码，就不能编写功能的实现代码。先写测试代码，可以让开发人员明确目标，就是让测试经过。

　　Continuous Integration，持续集成。在以往的软件开发过程当中，集成是一件很痛苦的事情，一般很长时间才会作一次集成，这样的话，会引起不少问题，好比build未经过或者单元测试失败。敏捷开发中提倡持续集成，一天以内集成十几回甚至几十次，如此频繁的集成能尽可能减小冲突，因为集成很频繁，每一次集成的改变也不多，即便集成失败也容易定位错误。一次集成要作哪些事情呢？它至少包括：得到全部源代码、编译源代码、运行全部测试，包括单元测试、功能测试等；确认编译和测试是否经过，最后发送报告。固然也会作一些其它的任务，好比说代码分析、测试覆盖率分析等等。 在咱们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，若是是黄灯，表示正在集成；若是是绿灯，表示上一次集成经过，开发人员在这时候得到的代码是可用而可靠的；若是显示为红灯，就要当心了，上一次集成未经过，须要尽快定位失败缘由从而让灯变绿。在持续集成上，咱们公司使用的是本身开发的产品CruiseControl。

　　Refactoring，重构。相信你们对它都很熟悉了，有不少不少的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽可能简单、优美、可扩展。在以往开发中，一般是在有需求过来，如今的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程当中有剩余时间了，对如今代码进行重构整理。可是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码以前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽量小，用单元测试来保证重构是否引发冲突，而且不仅是对实现代码进行重构，若是测试代码中有重复，也要对它进行重构。

　　Pair-Programming，结对编程。在敏捷开发中，作任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair作事有不少好处，两我的在一块儿探讨很容易产生思想的火花，也不容易走上偏路。在咱们公司，还有不少事都是Pair来作，好比Pair学习，Pair翻译，Pair作PPT，关于这个话题，钱钱同窗有一篇颇有名的文章对它进行介绍，名为Pair Programming (结对编程)。

　　Stand up，站立会议。天天早上，项目组的全部成员都会站立进行一次会议，因为是站立的，因此时间不会很长，通常来讲是15-20分钟。会议的内容并非需求分析、任务分配等，而是每一个人都回答三个问题：1. 你昨天作了什么？2. 你今天要作什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工做内容，若是有人曾经遇到过和你相似的问题，那么在站立会议后，他就会和你进行讨论。

　　Frequent Releases，小版本发布。在敏捷开发中，不会出现这种状况，拿到需求之后就闭门造车，直到最后才将产品交付给客户，而是尽可能多的产品发布，通常以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而咱们能够从客户那获得更多的反馈来改进产品。正由于发布频繁，每个版本新增的功能简单，不须要复杂的设计，这样文档和设计就在很大程度上简化了。又由于简单设计，没有复杂的架构，因此客户有新的需求或者需求进行变更，也能很快的适应。

　　Minimal Documentation，较少的文档。其实敏捷开发中并非没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API的用法，若是有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。若是用书面文档或者注释，某天代码变化了，须要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的状况，这更加会让人迷惑。而在敏捷中并不会出现，由于只有测试变化了，代码才会变化，测试是真实反应代码的。 这时有人会问：代码不写注释行吗？通常来讲好的代码不是须要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就可以看懂，这时候根本不须要对代码进行任何注释。若你以为这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，须要对它进行重构。

　　Collaborative Focus，以合做为中心，表现为代码共享。在敏捷开发中，代码是归团队全部而不是哪些模块的代码属于哪些人，每一个人都有权利得到系统任何一部分的代码而后修改它，若是有人看到某些代码不爽的话，那他可以对这部分代码重构而不须要征求代码做者的赞成，极可能也不知道是谁写的这部分代码。这样每一个人都能熟悉系统的代码，即便团队的人员变更，也没有风险。

　　Customer Engagement ，现场客户。敏捷开发中，客户是与开发团队一块儿工做的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。若是开发过程当中有什么问题或者产品通过一个迭代后，可以以最快速度获得客户的反馈。

　　Automated Testing ，自动化测试。为了减少人力或者重复劳动，全部的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，可以编写自动化测试脚本或者用工具录制。咱们公司在自动化测试上作了大量的工做，包括Selenium开源项目。

Adaptive Planning，可调整计划。敏捷开发中计划是可调整的，并非像以往的开发过程当中，需求分析->概要设计->详细设计->开发->测试->交付，每个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时做出相应的调整和变化。

　　敏捷开发过程与传统的开发过程有很大不一样，在这过程当中，团队是有激情有活力的，可以适应更大的变化，作出更高质量的软件。