敏捷开发原则

http://www.youkuaiyun.com/article/2012-07-17/2807394

摘要：最近，敏捷、敏捷开发这类词常常围绕在我们耳边。对于它的含义，我们是否真正了解？它是如何让开发变的有趣和高效？如何使用敏捷来进行商务沟通，并且使这种沟通更容易和更有建设性？

敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

什么是敏捷开发？

一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验，创建了敏捷开发宣言(共四句话)，让软件开发工作变的更容易更轻松：

1. 个人和交互重于流程和工具
2. 有效的软件重于全面的文档
3. 客户合作重于合同谈判
4. 因时制宜重于按步就班

 ------------------------------------------------------------------------------------------------

[[
1.个人和交互要胜过过程和工具
2.可工作的软件要胜过全面的文档。
3.客户的协作要胜过合同的协商。
4.对于变更的响应要胜过遵循计划
也就是说，尽管右边的项也有价值，但我们认为左边的项更有价值。
]]

Manifesto for Agile Software Development

软件开发的敏捷宣言

（ http://www.agilemanifesto.org/）

 

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.
也就是说，尽管右边的项也有价值，但我们认为左边的项更有价值。

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Tho

Principles behind the Agile Manifesto

敏捷宣言背后的原则

（ http://www.agilemanifesto.org/principles.html）

We follow these principles:
我们遵循如下这些原则：

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

1. 我们的最高优先级是：通过及早并频繁地交付有价值的软件来赢得客户的满意。

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

2. 要欢迎变动的需求，即便是在开发的晚期也不例外。敏捷过程利用变更来为客户获得竞争优势。

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

3. 频繁交付可工作的软件，从两周到两个月，最好使用较短的时间跨度。

Business people and developers must work together daily throughout the project.

4. 业务人员与开发人员每天工作在一起，直到项目结束。

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

5. 使用有主动性的人来组建团队。给他们所需的环境和支持，信任他们能够完成工作。

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

6. 向开发团队及在开发团队中传达信息的最有效率和最有效的方法是：面对面的交谈。

Working software is the primary measure of progress.

7. 可工作的软件是进度的首要度量。

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. 敏捷过程鼓励可持续的开发。出资人、开发人员和用户应该都能够无限期地维持一种不变的步伐。

Continuous attention to technical excellence and good design enhances agility.

9. 不断追求技术上的卓越和优秀的设计，会增强敏捷。

Simplicity--the art of maximizing the amount of work not done--is essential.

10. 简化（使未完成工作的量最大化的艺术）就是根本。

The best architectures, requirements, and designs emerge from self-organizing teams.

11. 最佳的架构、需求和设计产生于自组织的团队。

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

12. 团队要定期反思“如何能变得更有效率”，然后对自己的行为进行相应地调优和调整。

 

------------------------------------------------------------------------------------------------------

下面本文将会介绍12条敏捷开发原则，对于开创新的软件开发过程，这仅仅是第一步。

客户满意度

通过早期和持续不断的交互有价值的产品，来提升客户的满意度，这并不表示我们的软件会变成全能的。但在开发和每次迭代的时候都要考虑这一特征。

如果我们要开发一个博客引擎，也许会按照下面的步骤进行：                       

1. 创建博客展示页面，交付给客户。
2. 创建用户管理中心和会员制度，交付给客户。
3. 添加评论管理功能，交付给客户。
4. 等等，交付给客户。

上面只是一些简单方法，但是客户会看到软件产品设计的每一步并且在每个新特征上做出反馈。它可能已经很好或者需要做出调整，但是你能迅速做调整，打造一个双赢的局面。

拥抱变化

即使在开发后期，为了提高客户的竞争优势，敏捷开发也允许根据变化做出相应调整。

客户希望很快完成并且尽可能与他们所想的设计相接近。通过倾听和做好随时调整的准备，实现这个就比较简单。如果能够根据需求的变化快速做出响应，那么，我们可能就是客户最好的选择了。敏捷的核心就是关于沟通和改变，从客户那里得到什么，就迅速的实现，因为我们开发软件的每个子项目都可以根据需求进行调整，并不会对其他子项目产生不好的影响，反而会使开发变的快速高效。

频繁交付

从几周到几个月就应该交付更新，间隔越短，越好！

customers feel more confident in us and our product as it is updated。

根据多年的开发经验，你可能会发现，客户对每次的产品更新都很有信心，通过这样来维系好客户关系也是很重要的，另外通过客户每次回馈给我们的信息，做出相应的调整，比如需要改变类、功能、模块或者是架构等让软件更加贴近用户。但在实际操作中，我们很难会意识到这些，往往都是出现错误的时候，才会注意到，下面让我们来看下面的情形：

在一个文本管理器中，你需要创建一个模块来显示一些简单的文本，突然，你必须添加一个form，根据配置里面的地址发送邮件。此外，form要求可定制，用户可以在里面添加新的字段和验证器。所以你基本上要忘记最初的简单文本要求，对于突然的这些变化，你会花多长时间？如果你工作在一个与客户经常打交道，并且项目频繁交付的环境中，对你来说，这些变化都会变的很简单。

常常一起工作

如果你一直采用古老的瀑布软件开发模式，那么要想适应这条原则可能会很困难。作为开发人员，不要采用单一的方式和客户沟通，在我看来，最好的方式之一就是用讲故事的方式进行沟通，告诉他们这个是干什么的？为什么要做？这样会让我们做起来更加简单轻松。另一个比较好的方法就是行为驱动开发（BDD）。

拥抱团队，善待个人

提供和你一起工作的伙伴们需要的环境和技术，然后相信他们能胜任。

一个轻松愉悦的氛围和所有工具都齐全的工作环境对于开发出好的软件是非常重要的。好的员工从公司流失掉，大多数都是因为公司没有真正关心过他们。开发人员使用FTP客户端在一些服务器上面写，测试和部署软件并且对一些需要补充的产品文挡进行编辑，如果你对这种古老的模式没有一点谴责的话，最好现在就开始。

留住好员工还有一个好处就是可以更高效的开发一个好而且大的软件。想想：编写可重用的代码、自动化测试和在服务器上部署（或者在其他东西中）这些都是要花费时间才能完成的。当项目被延迟的时候，会把一些原因归结在学习如何使用有用的工具上。例如Jenkins，GIT，SVN，Gerrit，Behat等。坦白地说，有些工具和概念在以后的项目中是可以重用的。

面对面沟通

把信息传达给客户和开发团队，采用面对面的沟通是最行之有效的方式。

在邮箱里面看到6，255，384份邮件，我想谁都会有点不知所措或者是愤怒吧？因为你们公司的所有沟通都是“表面化”的。面对面的交流会让沟通更方便而且更顺利，得到的信息也会更丰富。队员可以用语言的或者非语言的形式把他们的想法表达出来，这个明显比用邮件更快。

除了上面陈述的，更重要的是要彼此信任，在一个互相信任的环境里，更应该鼓励面面对面沟通。

使用软件来衡量进展

根据自己的软件开发进度可以让工作更自由，软件开发人员不同于其他员工，所以很自然地，他们应该有个不一样的待遇。开发人员并不想让自己做出来的软件很糟糕，而且他们也不会根据自己的喜好来工作。只要他们能够按照团队的进度准时完成项目即可。并且客户只会关心结果，不会去注重过程。

维持一种不变的步伐

敏捷的突出优点如可以随时接受变化，快速做出回馈等，但最好的优点应该是能够精确地确定项目时间或者功能消耗。经过几次交付后，开发团队会产生最有价值的商业编号：容量。容量是指团队在一次迭代中的工作量。在几次迭代后，容量编号仍然是稳定的，并且我们可以避免不合理的截止日期和实验时间，就像“仍一顶帽子出去”当把公司产品提供给客户的时候。

关注工业发展

关注工业领域会提高敏捷性。

我们希望发展和进步，每天都应该继续学习，因为这个行业增长速度是如此的快速。为了硬件和软件都变的更好，必须时刻保持最新的状态；否则，我们会发现自己迷失在“sea of new”里面，并且很难回到正轨。

重构可以解决大多数问题。通过不断地重构(在需要时)，我们可以很容易地应用新技术和更好的我们的软件架构。

简单至关重要

比尔·盖茨曾说过：

If I have some complicated work to do, I will give it to the laziest person I have, because they will find the simplest way to do it.

简单是一个黄金法则。这也并不意味着你很懒，但也说明开发人员很多时候都把工作复杂化，如果你只关心和只做客户想要的，而不去添加额外的功能和改进，那么你的工作就会轻松很多，并且会很快达成目标。从根本上说，客户也只关心这个。

自我组织

最佳的架构、需求和设计往往都是产生于自己的组织团队里。

你是否曾开发过一个大而且费时的应用项目，而且在花了无数个小时候在屏幕前编写代码、阅读文档和查阅资料，你坐下来看那些不好（但是可以工作）的代码时，你会发现，我可以用更好的代码实现。

有这样的一个团队，遵循TDD（Test Driven Development）开发原则，并且重构也是其中的一部分。他们的软件以一种很神奇的方式去开发，并且是有用的、美丽的、易读易写、测试以及可以快速的创建。他们只是一群人，并不会去预知一切。

反映&调整

每隔一段时间，开发团队都会总结怎样让软件更高效并因此进行调整。

这可能花费几个开发周期，但是团队开发将会更和谐，即使是有新成员加入。敏捷开发团队会很快把工作完成，如果在一个友好的环境中，他们也会发现有“旋律的工作”，你也会看到如何快速开发软件。

下面介绍几个敏捷开发方法这里有一些方法是源自并建立在敏捷开发原则上面的。在下面中，会介绍几个有名的方法。请记住：方法并不控制一切，你需要结合自己的实际，来选择适合你的或者通过配置一些方法来满足你的需求。

SCRUM

Scrum是一种迭代式增量软件开发过程。Scrum在英语的意思是橄榄球里的争球。

SCRUM是由Schwaber和Jeff Sutherland创建的，SCRUM是一个面向业务的框架来管理你的软件开发流程。有许多不同类型的SCRUM，需要记住的是主要目标是有效的进行工作并且不需要遵守规则。

Extreme Programing (XP)

该方法是由Kent Back创建的，XP是最佳实践列表，当进行程序开发的时候，程序员需要遵循的。该方法有时也会被称作“扩展的SCRUM”。创建这种方法的原因是为了解决SCRUM不面向业务这一特点。

Lean Software Development

精益开发的两个主要原则是：DALAP（Decide As Late As Possible）和DAFAP（Deliver As Fast As Possible）。这个方法也非常有用。

在敏捷家族里面有许多方法，上面只是简单的介绍最流行的三个方法，如果你决定在你的项目里面采用敏捷开发，你最好多了解一些开发方法，找到最适合你的。

本文只是作者结合自己的工作经验总结的12个敏捷开发原则和3个方法，如果你有更好的实践经验和方法，欢迎留言与大家一起探讨！

英文来自：The Principles of Agile Development