[探讨]敏捷开发原则

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

什么是敏捷开发/strong>

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

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

客户满意度

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

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

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

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

拥抱变化

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

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

频繁交付

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

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

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

常常一起工作

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

拥抱团队，善待个人

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

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

面对面沟通

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

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

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

使用软件来衡量进展

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

维持一种不变的步伐

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

关注工业发展

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

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

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

简单至关重要

比尔·盖茨曾说过：

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

自我组织

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

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

有这样的一个团队，遵循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）。这个方法也非常有用。

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