2010-05-11-设计-敏捷开发.docxVIP

敏捷开发王小东 2010年5月11日星期二敏捷实验敏捷联盟人和交互重于过程和工具一个优秀的团队成员可能是一个具体有平均水平的程序员，但是能够很好地与他人合作。合适的工具对于成功来说非常重要。建议从使用小工具开始。尝试一个工具，知道发现它无法使用时才去更换它。团队的构建要比环境的构建重要得多。可以工作的软件重于面面俱到的文档没有文档的软件是一种灾难。然而，过多的文档更糟：编制众多文档要花费大量的时间，保持他们的同步要花费更多的时间。编写并维护一份系统原理和结构方面的文档总是一个好主意，但是应该尽量短小而且主题突出：短小是说最多一二十页。主题突出是说，应该仅论述系统的最高层结构和概括的设计原理。Martin文档第一定律：直到迫切需要并且意义重大时，菜编写文档。客户合作重于合同谈判成功的项目需要定期且频繁的客户反馈。一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。成功的关键在于与客户的紧密协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。随时应对变化重于遵循计划较好的做计划的策略是：为下一周做详细的计划，为下3个月做粗略的计划，再以后就做极为简略的计划。我们应该清楚地知道下周要完成的任务，粗略的了解一下以后3个月要实现的需求。至于一年后的将要做什么，有一个模糊的想法就可以了。原则我们最先要做的是通过尽早地、持续的交付有价值的软件来时客户满意。我们欢迎需求的变化，即使到了后期，敏捷过程能够驾驭变化。经常交付可以工作的软件，从几个星期到几个月，时间隔越短越好。我们不赞成交付大量的文档或者计划。在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。围绕斗志高昂的人构建项目团队内部，最有效也是最有效果的信息传达方式，就是面对面的交谈。可以工作的软件是进度主要的度量标准。敏捷过程提倡可持续开发。不是50米短跑，而是马拉松。对卓越技术的和良好设计的不断追求有助于提高敏捷性。简单—尽量减少工作量的艺术是至关重要的最好的构架、需求和设计都源自自我组织的团队。每隔一段时间，团队都要总结如何更有效率，然后相应的调整自己的行为。结论：现在已经有许多的敏捷设计过程可供选择：SCRUM、Crystal、特征驱动软件开发(Feature-Driven Development ,FDD)、自适应软件开发(Adaptive Software Development,ADP)以及极限编程（Extreme Programming,XP）。极限编程概述完整团队我们希望客户、管理者和开发人员紧密地工作在一起。XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。有时，客户是和开发人员同属一家公司的一组业务分析师、质量保证专家和市场专家。用户故事用户故事（user story） 就是正在进行的关于需求的谈话的助记符。它是一个计划工具，客户可以使用并根据需求的优先级和估算代价来安排实现该需求的时间。短交付周期XP项目每两周交付一次可以工作的软件。迭代计划一旦迭代开始，客户就同意不再修改当次迭代中用户故事的定义和优先级别。发布计划XP团队通常会创建一个发布计划来计划随后大约6次迭代的内容。结对编程结对人员中，一个控制键盘并输入代码。另一个观察输入的代码，寻找着代码中的错误和可以改进的地方。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过。并且他们应该参加了本次迭代中所涉及的每项工作。测试驱动开发编写产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试，由于它要测试的功能不存在，所以她会运行失败。然后写代码是测试通过。促使编程人员解除各个模块间的耦合。集体所有权持续集成XP团队每天会进行多次系统构建，他们会从头开始创建系统。可持续的开发速度XP的规则不允许团队加班工作。为了快速地完成开发，团队必须要以一种可持续的速度前进。开放的工作空间程序员们都处于激烈讨论的位置上。充满积极讨论的屋子里工作，生产率非但不会降低，反而会成倍地提高。计划游戏计划游戏的本质是划分业务和开发之间的职责。简单设计XP团队使他们的设计尽可能的简单、有表达力。此外，他们仅仅关注于计划在本次迭代中要完成的用户故事，而不会考虑那些未来的用户故事。考虑能够工作的最简单的事情。你不需要它！只有证据，或者至少有十分明显的迹象表明现在引入这个基础设施比继续等待更加合适时，团队才会引入这些基础设施。有且只有一次！极限编程者不容忍重复的代码。无论在哪儿发现重发的代码，他们都会消除这些重复。重构随着我们添加一个一个的特性，处理一个一个的错误，代码的结构会逐渐的退化。XP团队通过经常性的代码重构来扭转这种退化。重构是持续进行的。隐喻计划测试测试驱动开发原则：除非已经编写了一个不能