敏捷软件开发（摘录）

 

什么是敏捷软件开发？

敏捷软件开发是一个处理软件工程项目的概念性框架，它 拥抱并促进 在项目的整个生命周期中 产生的 演进式 变化 。

Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. （ wikipedia ）

请注意其中的三个关键词：

在项目的整个生命周期中 ：这就涉及到了【敏捷项目管理】、【敏捷需求获取】、狭义的【敏捷软件开发】三个主要的领域和过程。要注意的是，上述三个过程并不是互相分开的，而是你中有我，我中有你。

拥抱并促进变化 ：世界上唯一不变的是变化。不论在任何领域，漠视、甚至否认、抗拒变化，都不是一个理性，严肃的人所应有的态度。学会如何识别变化的大势，并在可能的时候，促使变化向好的方向发展。这才是面对变化的正确应对之法。

演进式 ：虽然上面提到促进变化的发展，但是软件的演化过程，我相信是有其自身内在逻辑的，存在一些根本规律和指导方针；并不是完全以人的主观意识为主导。

老子讲“顺势而为，无为无不为”，我认为是对上述后两点的精确概括与指导。

 

敏捷软件开发宣言

《敏捷软件开发宣言》 (Manifesto for Agile Software Development) 制定了 4 个核心价值观，其核心就是一个词：变革，这些价值观组成了敏捷项目管理的核心价值观：

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

☆     Individuals and interactions over processes and tools

☆     Working software over comprehensive documentation

☆     Customer collaboration over contract negotiation

☆     Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

 

我们正在通过实践和帮助其他人实践，揭示更好的开发软件的方法。我们从实践中得出的价值观是：

☆     人和交互 重于过程和工具。

☆     可以工作的软件 重于面面俱到的文档。

☆     客户合作 重于合同谈判。

☆     随时应对变化 重于循规蹈矩。

 

我们通过实践和帮助他人实践，发掘出更好的 [产品]开发方法，通过上述工作，我们形成如下价值观：

☆     人和相互交流胜于流程和工具

☆     致力于[产品]胜于编制综合性文档

☆     与客户协作胜于合同谈判

☆     适应变化胜于遵循计划

也就是说，虽然右边的条目有价值，但我们更看重左边的条目。

 

关于“敏捷软件开发宣言”的争论

 

Simon Baker的想法是，敏捷宣言中的一些概念是商务群体很难理解的，如果把精益开发中的一些概念（诸如追求卓越，理解并消除浪费，整体优化和排队理论）加入到敏捷宣言中，就可以解决这个问题。

 

Brian Marick接着给出了宣言中所缺少的四种理念： 技能、 纪律、 舒适和 快乐。

 

这并不是 “另一类Agile”。这实际上是一个工作间，人们通过观看我和Chet协同工作，可以以特殊的方式来了解敏捷，并对它产生兴趣。我们认为完善的软件开发过程应当包括优秀的开发技能和严格的纪律约束，同时还需要大家在轻松的环境下全心投入——这就是我们所说的“时尚优雅”。我们的计划是帮助人们理解我们的目标和完成目标的方式，并且让他们能够通过充分的亲身体验来判断这种方式是否适用于他们自己的开发过程。（Ron Jeffries和Chet Hendrickson）

Jason Yip的观点则相反，他给出了重构宣言后的一个精简且风趣的版本：

• 让我们互相交谈
• 让我们构建软件给你看
• 让我们彼此信任
• 让我们对正在发生的一切和我们所学到的东西做出响应

Petit最后总结说： “ 捷径就是两点之间最远的路线。” 看上去半途而废的敏捷实施甚至比它想要取而代之的完整流程还要更坏。

 

敏捷原则

下列敏捷原则构成了敏捷宣言的基础，也是最佳实践的来源。

1.          我们首要目标是通过更早地持续交付有价值的软件来满足客户的需求.

2.          欢迎需求变更，即使是在项目开发的晚期也是这样。敏捷过程适应变化的特性使得客户在竞争中更具优势。

3.          频繁交付可以工作的软件，从几周到几个月，较短的交付周期有更大的优势。

4.          业务人员和开发人员必须在项目过程中每天协同工作。

5.          调动个人积极性，给他们需要的环境和支持，并信任他们完成任务的能力。

6.          面对面的交谈，是最有效和效率最高的项目组内及组间信息传输方式。

7.          可工作的软件是衡量项目进展的主要依据。

8.          敏捷过程提倡，开发是一个持续的过程。项目组织者，开发人员和客户应该维持稳定的项目进展速度。

9.          持续对技术和设计进行优化，使项目有更高的敏捷性.

10.      尽量简化，不做目前不需要的工作，这是一条基本原则.

11.      最好的架构，最好的需求和设计从有自我组织能力的团队中产生.。

12.      项目组要定期总结回顾，思考怎样让团队变得更加有效,并作出相应调整。

 

 

敏捷究竟是什么？（Ivar Jacobson）

敏捷是关于以下三件事情的：

1.        最重要的，敏捷是一门社会工程学。这是敏捷最大的特点。它关注的是，如何以一个团队的形式开展工作，如何激励团队成员，如何相互合作等等。

2.        敏捷是轻量级的。RUP完全依赖显性知识，与此不同，敏捷还依赖隐性知识。在RUP中，我们设法把我们认为是最佳的实践记录下来。然而，人们根本不阅读关于开发过程方面的书，写下这些书也就毫无意义了。相反，敏捷认为，只要有掌握足够知识的人，就可以开发出优秀的软件。当然，这个观点倍受质疑，但是事实的确如此。

3.        敏捷提供技术实践。这其实是敏捷中贡献最微弱的部分。它所提供的技术实践几乎没有包括新技术。迭代与增量式开发，都是存在很久的观点。用户故事，则是某种特殊类型的简化版用例。最为有趣的新想法就是测试驱动的开发。我并不是说敏捷技术实践毫无价值，而只是强调，如果它仅仅就是这些内容的话，我们就不会为敏捷如此痴迷了。

正如你们所看到的，软件工程与敏捷抓住了软件开发的不同方面。软件工程的强处在于技术性实践；而敏捷的优势则是社会工程。因此它们是相辅相成的。

软件工程就像是件紧身衣，束手束脚，而敏捷则十分轻巧，但更难驾驭。问题在于，我们能否从两个世界中取其精华。当然，我们能！

最终，软件工程阵营有一系列技术实践，不同的敏捷方法也有另一些略带重复的实践。那么，我们能找到两者共存的方式么？当然，我们能!

要做到这些，我们必须用新的观念来看待实践。我们不再谈论过程，实践已经取而代之，成为一等公民。过程仅仅是实践的组合。

 

关于敏捷实践（Paul Oldfield）

我常常遇到那些不将制造业和软件开发加以区分的人，他们看到了最佳实践以及高度自动化的生产流程，并希望将其应用在软件开发中。在这里我不会提及他们的名字，我遇到过按照时间和原材料支付工资，利润与人数多少相关的情况，在这里，所谓效率意味着利润的减少，而且客户直到接受不再需要这么多工人的事实才会承认效率的提升。

 

有时候我会想起刚刚接触到敏捷实践的时候，某些实践挑战着我的世界观，幸运的是，我的处世哲学让我乐意探索这些对我的世界观产生挑战的部分，万一在这些问题上我犯了错误呢，万一别人才是对的呢。每一处挑战开始的时候就像一个新的宗教，但是进行探索就会破除盲目崇信。就我所看到的，大多数的人选择符合其已有观念的意见。他们以近乎宗教的方式接受或者拒绝新的观点。他们或许会进行某些肤浅的推理，但他们认为进行详细论证是在浪费时间。这对敏捷的盲目接受者和诋毁者同样适用。

 

Emergent Architecture是最初我认为不符合我世界观的部分。最终我发现其倡议者所建议的正是我在研究项目上7年间所做的。在这个项目中， Emergent Architecture逐渐变为成型的解决方案。当然，与过去相比，敏捷的倡议者提出了更多的规程。应用规程势必会影响灵活性，这些规程之所以有效是因为在现代系统中创新的程度较过去大大降低了。敏捷的倡导者所创造的规程是从完全不同的，非制造业的角度展开的，这样它依然保持着灵活性。 我花了很长的时间才明白没有哪个敏捷实践是可以脱离其他实践单独运作的。在试图了解某一个实践如何指导开发工作之前，我需要对全局有一个清醒的认识。

 

 

极限编程

极限编程（Extreme Programming，XP）是敏捷方法中的一种。

极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

极限编程的有效实践

 

1、完整团队

 

XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

 

2、计划游戏

 

      计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

 

3、客户测试

 

      作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

 

4、简单设计

 

      团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

 

5、结对编程

 

      所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

 

6、测试驱动开发

 

      编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

 

7、改进设计

 

      随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

 

8、持续集成

 

      团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。

 

9、集体代码所有权

 

      任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

 

10、编码标准

 

      系统中所有的代码看起来就好像是被单独一人编写的。

 

11、隐喻

 

      将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

 

12、可持续的速度

 

      团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。