敏捷开发纵横谈(3)

　　2.站立会议

　　每天早上项目组全体开5-10分钟会议，所有人站立讲话，简单讲述昨天工作概要、今天计划、需要别人协调或解决的问题。站立的目的就是让大家言简意赅，提高会议效率。每天开这个会，是保证大家有足够的及时的口头沟通。极限编程认为，口头沟通才是最有效直接的沟通。

　　在我们的项目中，我也会推行站立会议，但不一定是早上，当然也不一定非要站立，但是会议一定必须是高效的!口头沟通很有效，但必要的记录还是应该有的。一些公司推行站立会议，往往是没有会议记录的。而我的做法是会议中如果有决定、有代办工作，我会要求记录下来。口头沟通算然来得直接，但容易理解错、容易忘记等缺点是避免不了的，应该辅以适当的书面记录。

　　3.小版本发布

　　分小版本多次发布，最符合客户的利益，客户可以先使用部分功能，可以在此基础上更好地思考后续应该做什么。

　　小版本到底应该有多小呢?国外很多书会建议3个月，不过3个月对于国内的项目来说，太长了!我们经常要在很短的时间内做出一个大系统!

　　我们公司每个版本的发布周期以前大概是一个月，现在已经缩小到2-3周了。

　　4.每周工作40小时

　　加班是我们IT人的家常便饭，极限编程反对加班!那么是不是我们只要工作时间到了，哪怕很多事情没有做完，就直接下班呢?

　　这条实践的真正意思是我们应该充分利用好工作的40小时，少做最好不做无用功，少返工。实际上我们很多加班是因为我们做了很多无用功、返工导致的。

　　人的脑袋每天能高速运转8小时其实已经很了不起了，如果还要加班，那么只能带来更多的bug，得不偿失!不过我们很多公司的老板喜欢看到我们这些打工仔忙，看到我们加班，而不管实际的效果，这真是悲哀啊。

　　极限编程的各条实践是有关系的，我觉得最基础的最重要的是测试驱动与自动化测试，这两条做不能做好，重构、代码共用等实践就难以实施。

　　极限编程很多东西很讲究灵活，但测试驱动这条是最死的要求最严格的，整个灵活的体系其实就是靠这一条来保证质量的。很多公司实践极限编程时，不能做到测试驱动，就简单设计，就随便改代码，随便因应需求变化而变动代码，这些工作都没有了质量保障的基础。

　　极限编程我们需要整体来理解各条最佳实践，并根据实际情况加以调整，为我所用!

　　下面将会稍微简单一点介绍另外了两个比较常见的敏捷开发。

　　敏捷开发

　　有一种敏捷开发，就叫敏捷开发。你可以认为这种是“狭义”敏捷开发，而本文标题所说的敏捷开发是泛指所有带有敏捷特点的开发模式。

　　这种敏捷开发有这样的特点：

　　1.个体和交互胜过过程和工具。

　　以人为本，注重编程中人的自我特长发挥。

　　2.可以工作的软件胜过面面具到的文档。

　　强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

　　3.客户合作胜过合同谈判。

　　客户与开发者的关系是协作，不是合约。

　　开发者不是客户业务的“专家”，也不是为了开发软件，把开发人员变成客户业务的专家。

　　要适应客户的需求，就要通过客户合作来阐述实际的需求细节。

　　4.响应变化胜过遵循计划。

　　设计周密是为了最终软件的质量，但不表明设计比实现更重要。

　　要适应客户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”、“自我良好”。

　　要不断根据环境的变化，修改自己的设计，指导开发的方向。

　　你可能会感觉到这些特点与极限编程的相似与不同之处，同时你也会感觉到这些特点很多与传统的重型开发针锋相对的。

　　RUP

　　统一软件过程，英文全写为：Rational Unified Process。

　　下面这两张图最能反应RUP的特点：

　　以上两图来自互联网

　　为了方便大家理解，我弄了中英文两张图，两者是一个意思，不过内容组织稍微有点不同，大家注意一下就行了。

　　要精确理解RUP的意思还是有点难度的，简单谈谈我对RUP的理解。

　　按照时间顺序，项目分为初始(inception)、细化(Elaboration)、构造(Construction)、交付(Transition)四个阶段，

　　每个阶段会有很多个小迭代。这四个阶段其实很难说有明显界限的，我觉得大家大概了解每个阶段的工作内容就可以了。

　　按照工作的性质，项目的工作可以分为以下几类：

　　商业建模(Business Modeling)

　　需求(Requirements)

　　分析和设计(Analysis & Design)

　　实现(Implementation)

　　测试(Test)

　　部署(Deployment)

　　配置管理与变更管理(Configuration & Change Mgmt)

　　项目管理(Project Management)

　　环境(Environment)

　　以上这些工作，在项目的不同时期工作量分布是不太一样的，如：商业建模、需求这些工作往往是头大尾小，分析与设计、实现等是中间大两头小，项目管理、环境方面的工作一直都会持续进行。

　　RUP的思想打破了“需求-设计-编码-测试”这样的传统瀑布模式，需求、设计、编码、测试这些工作其实一直都在进行的，只是不同时间比重不一样。这个思想是很符合“敏捷”的特点，也和实际情况非常吻合。

　　大家理解这个意思后，我觉得完全可以按照自己公司的实际情况重新定义时间上的阶段，也可以自己重新定义项目的各类工作，以及思考各类工作在项目不同时间的工作量分布。

　　关于敏捷开发的流派还有很多，如：自适应软件开发、水晶方法、实用编程等等，我觉不同流派其实本质还是很类似的，这里就不一一介绍了。

原文转自：http://www.cnblogs.com/umlonline/archive/2010/03/17/1687760.html