敏捷软件开发：原则、模式和实践

1，敏捷宣言和原则

1.1 敏捷宣言

敏捷联盟在敏捷大会上发布了他们最主要的主张，称之为敏捷宣言。其主要表述如下：

1，个人和交互胜过过程与工具

2，可以工作的软件胜过面面俱到的文档

3，客户合作胜过合同谈判

4，响应变化胜过遵循计划

虽然后者在软件开发中也具有其价值，但敏捷联盟认为，前者比后者更具有价值。这四点构成了敏捷最核心的要素，但我个人认为就这4点而言，最根本的还是“个人和交互”，这是敏捷方法区别与其他方法和流程的根本性原则。它体现的是一种很朴素的哲学原理--“以人为本”。其潜台词就是：人，才是获得成功的最重要的因素。由此，由生发出另一个关键的问题：既然人这么重要，那么什么样的人组成的团队才能获得成功呢？就像敏捷宣言主张的一样，“人和交互胜过过程和工具”，这就意味着，我们需要的人不是孤立的个体，而是一个融进组织的具有很好的交互能力的团队成员。所以我比较认同作者提出的一个观点：合作、沟通和交互能力要比单纯的编程能力更为重要。同时我认为，最好的团队是有那些技术还过得去，但能够很好的沟通、合作的人组成的，而不是许多技术超一流但不会沟通合作的人组成的。

很多事实都表明，构建一个好的团队是成功的基石之一，而构建一个好的团队的难度远比去构建一个开发环境这类的事情要大得多。因为他很多属于社会科学、属于管理学、心理学以及其他学科的范畴，而开发环境的构建纯粹就是自然科学范围内的事情。

强调人的作用，比不意味着不重视工具的作用。经验告诉我们，很多时候，工具可以大大提高我们的生产率，使我们做起事情来事半功倍。但是我个人觉得，现代社会的趋向是太过依赖于工具，所以工具的应用上，主要还是要防止滥用，应该使用适度的工具。

关于文档，我向来认为，陷入成篇累牍的文案中，是一种吃力不讨好的行为，但我觉得，又必须有一定的文档，以便在维护的时候、在培训新人的时候能够有所帮助。我认为敏捷其实不是放弃文档，而是减少文档在日常工作中的占比，减少文档的量，最重要的是使软件成为一种自组织的、更形象化的文档。是的，我们不需要面面俱到的文档，但是一份记录我们如何决策、设计的详细架构文档还是需要的。

软件开发的根本目的是满足客户的需求，因此让客户加入团队合作，能使产品长的更像它应该像的样子。我们都知道，当客户说“我想要天上的月亮”的时候，其实他想要的只是一个月饼而已。所以需要技术人员循循善诱的让客户和自己清楚客户真正的需求。如果，只有合同谈判，也许费劲心力，都做不出用户满意的产品来。在我的职业生涯中，我所面临的客户一直是公司内部的产品人员，所以大部分时候都采用的是客户合作的方式来。

敏捷为客户创造最大价值的一个手段是，对变化的快速响应。当产品的生产可以快速变化而适应市场的变化，我们为客户赢得的就是机会。“响应变化胜过遵循计划”，对这句话的理解包含两方面，首先是响应变化，我们可以很快的做出改变，去优先完成那些新加入的、对客户有更大价值的事情。这种改变的前提是，在某小一段时间内（比如一个Sprint），我们的需求是稳定的，从而可以专注的做事情。应用到Scrum中，就是下一个个Sprint里要做的事情，是可以改变的，但当前Sprint的需求是不能被改变的。另以方面就是遵循计划。由此引申开来就是，怎么样去做计划，使得计划既可以被遵循，也可以响应变化，作者给出了一个他认为合理的方法：为以后两周做详细计划、为下3个月做粗略计划、再以后就做粗糙的计划。既我们需要详尽的了解这两周我们要做的事情，对以后的3个月有个粗略的任务计划，至于接下来的一年里做什么，有个模糊的想法就行。

1.2 敏捷原则

敏捷联盟在发布四条宣言的同时，也发布了12大原则，进一步阐述他们的主张。下面，我们一一的来解析这12条原则。

（1），我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。从人性角度来讲，越早的让客户看到有价值的东西，越能让客户信任你。此外，尽早的交付，也可以让客户弄明白自己的真正需求，而持续的交付就保证了产品是在朝客户期望的那样在发展。这条原则有两个注意点，一是，初期交付的系统所包含的功能要尽可能少，要留给客户足够的想象空间；另外即便是有了方向性的错误，也可以及时调整。二是，交付要尽可能的频繁，交付越频繁，最终产品的质量就越高，也越能满足客户的需求。

（2），即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。是的，还是在强调“响应变化”。从实践角度来说，响应变化包括需求和设计两方面。从需求来说，保证需求只在一小段时间内的稳定，大部分时候可变是响应变化的主要手段。从设计角度来说，要保持系统结构的灵活性以响应变化。

（3），经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

这一点是对第一点的引申和强调。

（4），整个项目开发期间，业务人员和开发人员必须天天在一起工作。这种方法是客户合作最有效的手段，突出了敏捷方法对“客户合作”的强调。

（5），围绕被激励起来的个人来构建项目，给他们提供所需要的环境和支持，并且信任他们能完成工作。再次回到“以人为本”的根本性遵旨，软件的成功，人是最重要的因素。同时，这一条对团队的管理也有指导意义。作为一个敏捷管理者，他最强大的武器就是支持与信任。首先，他相信团队成员能够把事情做好，然后他创造条件让团队成员能够去把事情做好，这些条件包括提供足够的资源、挡掉不必要的麻烦等等。

（6），在团队内部，最具有效果的富有效率的传递信息的方法，就是面对面的交谈。沟通很重要，有些时候甚至是成败的关键。通过沟通，才能厘清我们到底要做什么、为什么要这么做以及如何去做，我们才能去除理解上的分歧、才能掌控这个项目的进度。面谈则是效率最高的一种沟通，语言加必要的文本或是多媒体辅助，再加上肢体语言，能够最快速地让人明白你的意图，并且可以及时纠正别人理解的偏颇。

（7），工作的软件是首要的进度度量标准。每一次的软件Demo，都是一个里程碑。敏捷团队的进度的把握就是通过这种里程碑来获得的。这种度量标准最直观有效，每一次Demo都应该展示最新加进去客户认为最具有价值的特征（Feature），从而让客户知道，整个事情是朝着他所希望的那个方向发展。如果Demo失败，开发团队也可以和客户沟通，为什么会出现这样的问题或者为什么这不是客户期望的东西，然后迅速作出调整。

（8），敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能保持一个长期的、恒定的开发速度。敏捷项目是马拉松长跑，而不是短距离的冲刺，需要可持续的速度。这个原则表明，敏捷不支持加班加点的工作，而且，敏捷把需要加班加点来突击工作当成一种项目出问题了的信号。一旦出现这种事情，团队需要彻底的厘清问题的所在，然后轻装前进。

（9），不断地关注优秀的技能和好的设计会增强敏捷能力。敏捷是一种能力，不仅是一个团队的过程执行力，也是每个团队成员的项目执行力。所以，团队敏捷能力的增强，是建立在每个团队成员自身能力的成长上的。团队成员的能力的成长，除了对敏捷的认识要更深入意外，就是不断地增强的设计与编码能力以及把控层出不穷的新技术。

（10），简单--使未完成的工作最大化的艺术----是根本的。很多时候，简单的往往是最实用的。敏捷尤其强调保持最简单的设计来适应变化。最好的设计是能够完成现有需求的最简单设计，简而言之，就是不会为未来的改变做过度的设计，只有当这种改变是明确的，且这种改变的确会引起软件结构上的变化时，才应该为这种变化去设计。

（11），最好的构建、需求和设计出自于自组织团队。敏捷团队共同承担起项目成败责任，每个人都清楚自己的角色，都知道自己要做什么，并且也清楚自己的队友在做什么。如果需要帮助他人或者变动具体负责的事情，敏捷团队队员也能迅速的接受改变。

（12），每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应的对自己的行为进行调整。是的，团队的成长是一个不断摸索的过程，在这个过程中，不断地反思和总结才能不断地进步。通过反省做出改变，体现出的就是敏捷拥抱变化的本质，而响应变化不只是响应需求的变化，同时也是响应环境（业界、新技术、人）的变化。

最后，我觉得可以用一句话来对什么是敏捷做一个概括：敏捷开发是一种面临迅速变化的需求的快速开发软件的能力。

2，敏捷实践

2.1 XP的基本概念

敏捷实践中最著名的两种方法就是XP（极限编程）和Scrum。本书主要以XP为例来讲解敏捷的实践应该如何展开。

首先，什么是极限编程？本书没有直接给出答案但是，不难从作者的思想中总结出结论：XP是一种适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法学。极限编程之所以被称为极限，我认为是因为其倡导思想是一种将好的东西无限放大的哲学。其实践就是将大家公认为好的实践发挥到极致，如如果代码评审是好的，那么始终评审，所以提倡结对编程；如果测试是好的，那就始终测试，所以要求单元测试和功能测试；如果设计是好的，那就把它当做每个人日常事务的一部分，所以主张不停地重构；如果简单是好的，那么我们将始终把系统保持为支持其当前功能的最简单设计，所以倡导简单设计；如果体系结构重要，那么所有人将不断进行定义和完善体系结构的工作，所以有隐喻的概念；如果集成测试重要，那么我们将在一天内多次集成测试，所以要持续集成；如果迭代周期短好，那么就将迭代时间放到尽可能的短。

其次，极限编程会到来什么好处？从书中所述总结的来看，我觉得可以分成两方面来说。一方面是对程序员而言，XP可以让程序员更加专注在他们真正要处理的工作上，能够集中全力设计和实现系统，能够去决策该他们决策的东西，他们不会单独的面对糟糕的情况，也不会要求去对他们不熟悉的情况进行决策。另一方面是对客户和管理人员来说的，他们能够清楚地看到他们所关心的目标的具体进度，而且，这种进度是直观的、易于把握的，并且，如果需要做出改变，他们能够只付出较小的成本。

2.2 XP的准则

XP提出了的四大准则：沟通、简单、反馈和勇气，这个也是XP的核心价值标准，它所反映的恰恰是敏捷的核心理念。

沟通。软件开发过程中，沟通的重要性是不言而喻的，但是不同的方法，其倡导的沟通方式是不一样的。构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。

简单。极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。

反馈。在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：

§ 来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。

§ 来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。

§ 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。

反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”

勇气。极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。

2.3 XP的实践

XP的实践是对其准则的具体阐述，而且这些实践也反映了敏捷的原则。具体地说，XP包含了以下实践：

完整团队。所谓的完整团队就是让客户成为团队成员，我觉得这里再次体现出“极限”的态度。敏捷倡导客户合作，XP干脆把这种合作推向极致，让客户成为团队的一员来参与项目的整个过程。本书中，对客户一词进行了新的释义，既XP团队的客户是指定义产品特性并排列这些特性优先级的人活团体。

计划游戏。计划是持续的，循序渐进的。XP倡导短的迭代周期，一般而言，2周一个的迭代期是比较恰当的。XP的计划也是一迭代为周期的，2周内的计划是很详细的，接下来的几个迭代的计划则是初略的。XP强调通过结合使用业务优先级和技术评估来确定下一个迭代应该完成的素材。而且当计划赶不上实际变化的时候，就应该更新计划。事实上，由于XP的计划采用的是事时间定量，所以计划的改变往往是素材的增减。

客户测试。由客户定义出自动验收测试来表明已开发的功能特性是否完成。也就是说，一个功能是否已经真正的完成是由客户决定的，而客户则是通过完整的验收测试来决定的。

简单设计。任何时候，都应该将系统设计的尽可能的简单，如果发现任何不必要的复杂性，则需要果断的将其去掉。本书中介绍简单设计的几条指导原则：（1），采用实现当前素材的最简单设计；（2），基础结构只在认为必须引入的时候才引入；（3），消除任何的重复。

结对编程。所有的程序代码都是两个人一台计算机上完成的。XP强调所有开发成员对所有代码都应该很熟悉，所以结对关系也是随时改变的，以保证对代码的理解能够迅速在团队传播。XP主张，结对的关系每天至少改变一次。从这里，我们又可以看到XP的那种“极限”思想。

测试驱动开发。测试先行，先写一个原有程序不能通过的测试，然后实现该功能，使之能通过该测试。XP认为，可测试的设计或迫使设计者考虑解耦。一般来说，测试主要包括单元测试（白盒测试）和验收测试（黑盒测试）。

重构。持续不断的改进系统的设计。重构是在不改变系统行为的前提下，调整代码结构，去除冗余，使整个系统结构更加清楚，代码更加简洁。XP主张持续的重构，以保证系统设计的简单性。

持续集成。团队总是使系统完整地被集成。XP认为，每天应该进行多次集成，每次集成都只完成一个任务。XP就是要把集成做到极致。

集体代码所有权。整个团队对代码质量负责，且任何项目成员可以在任何时候修改任意一行代码。

编码标准。团队应该制定一个编码规范，统一编码标准，来保证项目的所有代码风格完全一致，就像是出自一人之手。

隐喻。用有关整个系统如何运行的、简单的、众所周知的故事来指导整个开发。隐喻通常可以归结为一个名字系统，这些名字提供了系统组成的元素的词汇表，并且有助于定义他们之间的关系。

可持续的速度。团队应该保持一个恒定的，可持续的开发速度，这一点恰恰就是一个敏捷原则。XP提倡一周工作40小时，这就意味着XP不主张加班，但是XP也给出了一个可以加班的特例。这就是在版本发布前的一个星期，如果发布的目标就在眼前并且能够一蹴而就，则可以加班，以使发布能够准时完成。

3，敏捷设计

3.1 什么是敏捷设计

什么是敏捷设计呢？因为敏捷一再强调简单设计，那是不是敏捷设计就是简单设计呢？其实这个问题的答案需要对敏捷有较深入的了解。一般而言，简单设计是敏捷设计的一部分，但敏捷设计绝不止是简单设计这么简单。

本书中，对敏捷设计的总结是：敏捷设计是一个过程，而不是一个事件，它是一个持续应用原则、模式以及实践来持续改进软件的结构和可读性的过程。它致力于在任何时候都保持系统尽可能的简单、干净、富有表现力。

3.2 敏捷设计过程

既然敏捷设计是一个过程，那么它到底是怎样的一个过程呢？马丁给出了一个模型：遵循敏捷实践去发现问题，应用设计原则去诊断问题，应用适当的设计模式去解决问题。根据对本书的理解，我把这个过程概括为：

（1）简单设计，只考虑当前需求，几乎不做预先设计；

（2）不断重构，应用设计原则去除设计的坏味道；

（3）寻找优雅的解决方案，应用设计模式。