敏捷开发是什么鬼？

身为一个攻城狮如果你没有听说敏捷开发，那么你可能就out了，抱着与时俱进的态度，今天我们就来学习一下敏捷开发是个什么鬼？

敏捷开发模式由来已久，已经被无数的大公司所采用，如Google，faceboo等公司，最近国内的也掀起了敏捷开发的热潮。下面摘取一段百度百科对敏捷开发的解释先来认识一下。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

看了上面的图我们就能很容易理解了，它的核心思想就是：以尽可能低的成本展现产品的核心概念，用最快、最简的方式建立一个可用的产品原型，用这个原型表达出你产品最终想要的效果，然后通过迭代来完善细节。

假如你的产品愿景是一种高级出行工具，比如小轿车。传统的产品设计思路是一步一步，从车轮、车轱辘、外壳、动力装置、内部装饰一个流程一个流程做起，最后得到一个完善的产品。而敏捷开发的思路，我们可能会先做一个小滑板车或者自行车，看看用户对出行工具的认可程度。如果用户认可我们的产品概念，我们可以接下去生产更加高级、完善的摩托车、甚至小轿车。

传统产品迭代思路成本高、速度慢、风险大，花高成本做出来的产品用户可能不认可；敏捷开发策略的优点在于试错成本低、速度快、风险低，能满足产品快速迭代的需求。

  敏捷开发宣言：

1. 个体和互动 高于 流程和文档

2. 工作的软件 高于 详尽的文档

3. 客户合作 高于 合同谈判

4. 响应变化 高于 遵循计划

核心价值观：

1. 沟通：够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。

2. 简单：画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

3. 反馈：Kent Beck在Extreme Programming Explained中有句话讲得非常好：“过度自信是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

4. 谦逊：最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

敏捷开发的原则：

1. 快速迭代：相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

2. 让测试人员和开发者参与需求讨论：需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

3. 编写可测试的需求文档：开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

4. 多沟通，尽量减少文档：任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强得多。

5.  做好产品原型：建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

6. 及早考虑测试：及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。 

看到这里不知道同学们有没有对敏捷开发有一些认识呢？当然要完全的把这种开发模式运用到现实的生产中去还是需要做很多努力，我们数聚传媒的同学们也在积极的探索这种新的开发模式，只有这样才能更加快速高效的完成开发工作，为客户的提供更优秀的产品。