在IT界中，“ 敏捷”是一个很酷的词汇，“敏捷”的相关理论可谓铺天盖地。
“敏捷”一词实质没有统一定义，各家有自家的说法，本文将让你了解“敏捷”的来龙去脉，抓住“敏捷”本质，并能在工作中实践“敏捷”。
大纲：
“敏捷”陷阱
为什么会有“敏捷”这个说法？
极限编程
RUP
敏捷宣言
敏捷开发的实质是什么？
如何才能敏捷起来？
我将分4篇为大家分享！
极限编程
极限编程英文叫：Extreme Programming，简称叫XP，最开始我接触到XP的说法时，还觉得是Windows XP的XP呢！
我第一次学习极限编程的最佳实践时，让我震撼不已，后来再工作中不断体会，有了自己的见解。我将这些最佳实践分为几类：需求、设计、测试、编码、项目管理。
需求方面的最佳实践：
1.客户故事：强调以客户的语言来表达需求。
需求分析有很多科学系统的方法，采用这些系统方法有时候往往不如使用最原始的土方法，就是用客户的陈述来表达需求！
极限编程认为，客户不能清晰认识自己想要什么是很正常的事情，项目组也没有必要成为业务专家，所以通过这两个最佳实践让客户来引导项目。项目的开发工作讲究短平快，系统会分为多个小版本发布，客户经过多个版本发布会逐步清楚认识到自己想要什么。
这个最佳实践鉴于我国的情况，其实是很难执行的。我们的项目一般合同价钱是签死的，项目时间也是死的，基本都没有机会让我们来回折腾，如果我们不能在项目初期精准地分析出客户真正的需求，项目失败的机会是非常高的。
我在实际工作中往往会通过用户故事来获取原始需求，然后对这些用户故事进行提炼，提炼后的需求再跟客户确认。我认为项目组还是很有必要成为业务专家，项目组中还是很需要有需求分析方面的高手，项目经不起折腾啊！
2.客户全程参与：强调从项目一开始到最后，客户应该与项目紧密联系，发挥更大的作用。
这个实践在实际工作中应该很好地贯彻，不要仅在需求阶段才让客户介入，客户最好就能常驻在项目小组内。下面有一些让客户多参与的建议做法：
1）需求阶段要与各用户反复确认需求。
2）系统做出界面时马上让客户看看。
3）项目计划要让客户知道。
4）每周向客户发送项目进展报告。
5）让客户参与测试软件。
设计方面的最佳实践只有一条：
1.简单设计：不用长远考虑，只要设计能保证当前功能可以实现就行。
软件开发的可谓千变万化，能将功能做出来的最简单设计就是最好的设计，你不需要考虑以后发生变化还能重用这些设计和代码，明天的事情鬼知道，搞定今天的事情就可以了！
这个实践有点剑走偏锋，有人还会因为这个实践不仔细思考软件设计就编码了，我们有很多项目因为设计得太烂而吃了不少苦头。实战简单设计时，我有这样的一些建议：
1）对于没有类似经验的项目，设计应该尽量简单，但简单的设计是需要严谨的思考得到的，你不要认为简单想一个设计出来就是简单设计。
2）思考项目设计时，应考虑有什么东西可以重用，同时适当考虑本项目有什么东西可供以后的项目重用。
测试方面的最佳实践：
1.测试驱动开发：先有测试再有开发。
我们一般的顺序是先开发后测试，然则这个实践要求我们先将测试想好，然后开发来满足这些测试。
这个思路其实就是目标驱动，我们先假设软件已经做好，那么我们先写出测试用例，然后我们编写的开发代码应该能通过这些测试用例。这样思路的好处就是能让我们想清楚目标，所有的开发都是有针对性的，减少无用功，提高工作效率，同时因为测试已经写好了，代码的质量会更加有保障。
这个思路其实是相当优秀的，但这个实践可能是这么多最佳实践中最难成功实施的！我们公司曾经推行过一段时间，最终还是失败告终。难以施行有以下原因：
1）开发人员普遍没有这么高的编程素质。
先不说测试驱动开发，我们往往连单元测试也做不到！测试驱动开发其实就是要求我们先写出单元测试代码，然后再写出满足单元测试代码的代码。
2）编码是一个循序渐进的过程，不太可能一开始接口就想好并且后面不会变了。
我自己编写代码也不太可能一开始就完全想清楚类中的各个属性方法，有时候会觉得方法名字不好会换掉，参数不太合适也会调整。如果我们先写出测试的代码，其实就要求我们先确定各类名称以及各类的公开接口，但往往我们需要不断调整，这样就会导致开发代码与测试代码都需要同时调整，工作量就增大了。
3）达不到自动化测试的技术层次。
自动化测试需要工具支持，并不是所有公司都具备这样的条件。
测试驱动开发的意义还是很重大的，我有这样的一些实践建议：
1）先写开发代码，然后写单元测试代码。
2）编写代码时，应该先想清楚类职责，类公开接口，然后再写具体实现代码。
3）某个类完成时或者阶段性完成了一些功能时，应该马上写出相应的测试代码，并保证开发代码能通过测试。
4）如果不能针对所有类都写出测试类，那至少应该针对重要的、核心的、被使用次数多的类编写测试代码。
5）单元测试应该能做到自动化。
2.自动化测试：自动化单元测试、自动化UI测试。
自动化单元测试，目前很多开发工具都支持，技术上问题不大，问题大的是大家不去执行或者说是能力不够执行不了。
UI方面的自动化测试就有点麻烦了，有这样两点：
1）就算是比较好的自动UI测试工具，也难以捕捉到软件界面上所有的控件以及动作。
2）软件的界面经常调整是很常见的时间，界面不冻结，UI自动化测试寸步难行。
要推行100%的自动化测试难度还是很高的，不过应该还是尽量自动化测试，单元自动化测试与性能自动化测试在技术上是没有问题的，是执行的能力与决心问题。
自动化测试这个最佳实践与测试驱动开发是紧密相关的，这两个最佳实践其实是整个极限编程中最核心、最精彩、要求最严格的两个实践。只要将这两个实践做好，代码随便你改，只要能通过测试就行，不用害怕需求变更带来的代码隐患，变就变，反正有自动化测试全面检查！
编码方面的最佳实践：
1）重构：不讲究一次将代码写好，但需要重构时应该毫不犹豫。
重构的意思是代码的接口和实现功能不变，但修改代码的具体实现，从而使代码的结构、可读性、性能、安全性等更好。
重构因为有测试驱动以及自动化测试这两个实践的支持，故不需要担心重构带来的影响，万一重构失败，取回原来的代码便可。
2）结对编程：两个人，组成一对，共用一台电脑编程。
头次听说这个，还觉得很难想象，两个人坐在一起，只用一台电脑，一个人写代码，另外一个看，过一会两个人可以交换一下。
两个人一起写代码，相当于随时在做同行评审，似乎效率降低了，但代码的质量得到保障，并且能保证所有代码至少有两个人了解的。
另外要注意的是：组成一对的两个人，应该水平相当。
这个实践很有意思，不过往往也是很难实践的。
就我个人来说，我就不喜欢两个人一起编程，我觉得每个人的思考其实很难同步的，每个人都需要静下心来一个人思考问题，思考后才适合与别人讨论，如果思考过程也与别人在一起，很难想象这个思考能有好的效果。
我们曾经将两位编码新手放在一起，让他们结对编程，尝试了这个实践，似乎有一点效果，但我们后期就没有再推行过。
3）代码共有：每个人写的代码都是属于全体的，每个人可以去改别人的代码。
这里强调共享与进步精神，欢迎互相研究代码，欢迎写出更好的代码，只要能通过测试就可以了！这个实践是依赖于测试驱动开发以及自动化测试这两个实践的，如果不能做到那两个实践，就不应该随便改动别人的代码。
4）强调编码标准
对于这点大家应该没啥异议了，现在有不少开发工具支持编码标准检查呢！
项目管理方面的最佳实践：
1.持续集成
持续集成与微软的“每日构建”是一样道理的，强调我们的软件要随时处在可以编译通过可以发布的状态，持续集成让软件的问题提早暴露更快解决。持续集成需要一定的工具和管理措施支持，我有这样的一些实践建议：
1）代码的签入与签出要定下严格的规矩，如：每天工作前先获取最新代码，每次签入前必须先保证编译通过。
2）如果能做到测试驱动测试和自动化测试，那么还应该规定必须通过所有测试才能签入代码。
3）一般来说我们没有条件做到每日构建，也没有这么多工具支持，那么至少一周要编译一次内部版本，检查软件各部分的协调情况。
2.站立会议
每天早上项目组全体开5-10分钟会议，所有人站立讲话，简单讲述昨天工作概要、今天计划、需要别人协调或解决的问题。站立的目的就是让大家言简意赅，提高会议效率。每天开这个会，是保证大家有足够的及时的口头沟通。极限编程认为，口头沟通才是最有效直接的沟通。
在我们的项目中，我也会推行站立会议，但不一定是早上，当然也不一定非要站立，但是会议一定必须是高效的！口头沟通很有效，但必要的记录还是应该有的。一些公司推行站立会议，往往是没有会议记录的。而我的做法是会议中如果有决定、有代办工作，我会要求记录下来。口头沟通算然来得直接，但容易理解错、容易忘记等缺点是避免不了的，应该辅以适当的书面记录。
3.小版本发布
分小版本多次发布，最符合客户的利益，客户可以先使用部分功能，可以在此基础上更好地思考后续应该做什么。
小版本到底应该有多小呢？国外很多书会建议3个月，不过3个月对于国内的项目来说，太长了！我们经常要在很短的时间内做出一个大系统！
我们公司每个版本的发布周期以前大概是一个月，现在已经缩小到2-3周了。
4.每周工作40小时
加班是我们IT人的家常便饭，极限编程反对加班！那么是不是我们只要工作时间到了，哪怕很多事情没有做完，就直接下班呢？
这条实践的真正意思是我们应该充分利用好工作的40小时，少做最好不做无用功，少返工。实际上我们很多加班是因为我们做了很多无用功、返工导致的。
人的脑袋每天能高速运转8小时其实已经很了不起了，如果还要加班，那么只能带来更多的bug，得不偿失！不过我们很多公司的老板喜欢看到我们这些打工仔忙，看到我们加班，而不管实际的效果，这真是悲哀啊。
极限编程的各条实践是有关系的，我觉得最基础的最重要的是测试驱动与自动化测试，这两条做不能做好，重构、代码共用等实践就难以实施。
极限编程很多东西很讲究灵活，但测试驱动这条是最死的要求最严格的，整个灵活的体系其实就是靠这一条来保证质量的。很多公司实践极限编程时，不能做到测试驱动，就简单设计，就随便改代码，随便因应需求变化而变动代码，这些工作都没有了质量保障的基础。
极限编程我们需要整体来理解各条最佳实践，并根据实际情况加以调整，为我所用！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
