转自：http://blog.sina.com.cn/s/blog_48258fbe0100eehi.html
敏捷开发实践
最近要在公司做的一次技术分享，实际上敏捷实践不到一年，接触敏捷还是从实习公司的一次敏捷培训开始，从那个时候起便深深地被影响。我记得那次培训是2011年的元旦假期，距今也有一年多了吧，期间也翻阅了一些敏捷思想的书籍，也有自己的一些思考和总结。原来是什么样子的，我不知道，写出来分享，记录和研究。阅读本文，也可以直接下载分享的PPT。
【我总是那样做】
大多数人习惯使用右手来操作手机（大多数），那如果现在颠倒过来，使用左手会发生什么事情？一部分人会不习惯，发送短信也会很变扭，甚至经常性打错字。总之，没有我们习惯的右手来得顺利。
为什么颠倒了习惯，我们会笨手笨脚？
很难有正确的答案来回答这个问题，当然这样做的目的也仅仅是为了使大家关注这个话题。我们平常的经验和习惯帮助我们建立了一套可以完成一项任务的体系，除非必要情况，我们很少会采用另外的方式来完成目的。当然，目的为导向的思想会告诉你这没有意义，我已经知道一种可以达到目的的方法，为什么我需要学会第二种？我想我没有办法反驳这点，这也不是我的目的，现在的问题是：为是为什么会笨手笨脚？我是因为我的固有的思维方式和习惯（你是什么原因？）。我从来没有想过可以使用左手来使用手机，我不习惯这么做，所以采用这种方式我做不好。可能你会见到过这样一些人，他们明明是右撇子，却偏偏使用左手来使用筷子，甚至有些人左右手都可以使用筷子，如同足球运动员左右脚都可以踢球一样。更多的方法可以帮助我们更好地解决问题，我想这是有意义的。
是什么在阻碍我们尝试新方式？
记得做奥数的时候，我们为找出解决问题的办法而绞尽脑汁，当然也会发现，总有那么一些人，他们明明已经有解决问题的办法了，但是他们却期望找到一个更好的方法。今天，我们坐在这里，思考如何能够提高我们的工作效率，使自己成为一个伟大的“代码设计师”，那么面对我们每天要完成的任务，我们是只求解决，还是力图完美？哦，能够完成任务的人并没有什么不好，那么是什么导致了我们有不同的思维方式？是什么让我们对任务有不同的态度？
如何避免旧的习惯对我们学习新事物的影响？
变的“无知”，现在，请扔掉我们以前的经验，我们都是一群渴望知识的小学生。当然，不要担心，在分享之后，我会把它们还给你们的。
【穿越到过去】
2001年之前，大型软件的开发采用“瀑布”过程，经常出现软件交付延期的情况。瀑布过程依赖太多的假设条件，其中有些风险过高，如：假设集成能够顺利进行、项目的复杂程度是可以控制的、计划是可以被遵循的。然而，项目的计划似乎并未考虑上述可变因素，风险随时出现。
用什么来保证软件质量和开发周期？
一些软件开发者通过经验总结如何保证软件质量和项目进度，其中一些解决方法是：
1. 依靠出众的个人及其经验
2. 总结犯错并建立约束条件
当有新的错误出现时，便增加了新的人为控制和建立新的约束条件。
最终，导致约束条件相互冲突、预算超支、进度反而无法保证、程序复杂业务凌乱。
2001年，业内一些软件聚在一起，概括了一些能够让软件团队具有快速工作、应对变化的价值观和原则，他们称自己为敏捷联盟。随后的几个月，他们创建了一份声明。这份声明也就是敏捷联盟宣言，我们称之为：敏捷原则。
【敏捷联盟宣言】
它包括：
12条原则
4个价值观
目的是：建立易维护的软件代码，提高团队工作效率，保证最终软件符合需求，保证项目按时完成
【价值观】
1. 个体和交互 比 过程和工具 重要
2. 可以工作的软件 比 面面俱到的文档 重要
3. 客户合作 比 合同谈判 重要
4. 响应变化 比 遵循计划 重要
人是获得成功的关键因素，如果团队中没有优秀的成员，那么使用再好的过程也无法拯救失败的项目，但是不好的过程却可以使优秀的成员失去效用。优秀的成员如果没有良好的沟通，从而作为团队来工作，那么即使拥有一批很优秀的成员，也会失败。
合适的工具对于成功来讲非常重要，如：编译器、IDE、SVN等，但是跟成员相比，我们认为人更重要。
没有文档的软件是一种灾难，代码并不是传达系统原理和结构的理想媒介。团队更需要编制易于编写和阅读的文档。但是应当适当的控制文档的数量，毕竟可以最终工作的软件是我们最终想要的。当代码更新时，文档的更新问题也是一个让人头疼的事。
软件外包公司经常会面临这样的客户：客户扔下一笔钱，写下自己期望的软件的样子，然后离开直到截止日期的时候，询问软件是否完成。当他看到软件的样子的时候，他经常会惊讶：这不是我想要的！合同谈判无法帮助开发人员理解客户的需求，通过和客户更多的交流来帮助开发人员理解客户的需要，从而开发出不偏离客户需求的软件。经常地保持沟通是一项重要的措施来帮助软件符合需求。Scrum要求每个迭代开发出可用的软件，同时用这个开发后的软件与客户交流，如果客户发现问题可以即使修改。
应对软件环境的变化是敏捷开发的一个重要的特性。尤其近年的互联网快速发展，互联网产品的生命周期相对较短，加上各个公司的竞争，谁能尽快推出自己的产品，谁就能走在市场的前端。一个计划一年的计划，在软件开发完成之后可能就已经跟不上时代的步伐。敏捷团队欢迎变化，敏捷设计也是针对变化而出现，传统的软件开发担心需求的变更，敏捷开发将需求控制到短期内需求稳定。
一个好的策略是，做两周内的详细计划，做3个月的粗略计划。
【1. 目的：使客户满意】
MIT Sloan管理评论杂志刊登的一篇论文，发现了很多对于最终系统质量有关系的实践，其中一个实践表明：尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。论文中指出：
明确了我们软件开发的目的：使客户满意
每次开发一个功能的创建或改进，并与客户交流，若得到客户确认，则可以直接作为最终产品的功能直接使用；若客户有提议，则按照在此基础上进行改进。
这样做的好处在于，它帮助软件团队永远不偏离需求和客户，围绕着需求和客户，同时也保证了开发出的产品是客户满意
【2. 态度：欢迎需求变更】
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
要求：软件保持灵活性
要求：团队成员学习能力
这是一个关于态度的原则，声明敏捷团队是不惧怕变化的团队。
团队认为改变需求是好的事情，因为改变意味着团队可以学到更多。
同时，这也是对敏捷团队和软件本身的要求，意味着团队成员具有较好的学习能力和软件具有很好的灵活性来应对这种变化。
这也是为什么敏捷开发被互联网接受的原因。
互联网的产品随时在变，传统的软件开发由于更新速度问题，成为创新和与时俱进的绊脚石。
【3. 关注：客户需要的软件】
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
交付的是软件和功能，而非文档
尽早地、经常性交付(2~4周)
可以集成运行的版本
每次给客户提交可以运行的软件，并通过客户确认来逐步完成软件开发
【4. 合作：推倒那堵墙】
Business people and developers must work together daily throughout the project.
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
软件需要被引导
团队成员和客户需要关注软件进度
团队成员和客户能相互理解彼此想法
有些公司的产品经理和开发人员中间相隔一堆墙，甚至有些公司的业务人员和技术人员不在同一层楼上。这导致了一些话题：
产品经理认为将这件产品的需求写明确，也发给了开发人员，而开发人员也按照自己的理解来开发产品，软件开发出来之后，
产品经理往往不解：软件怎么是这个样子的？
技术人员：这不就是你想要的样子么？
【5. 核心：团队成员】
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
项目成功最重要的因素：人！
在敏捷项目中，人是项目取得成功的最重要的因素。所有其他因素被认为是次要的，如：过程、环境、文档、管理、技术，当这些东西对团队成员有负面影响时，需要对它们进行改变。
前面提到，办公室环境的“墙”对我们的沟通造成影响，那么需要推倒它一样，来帮助我们面对面沟通；如果传统的文档对我们造成压力，我们可以通过其它方式来简化它或者转化它为我们喜欢和接受的方式。
改变的原则：以团队成员为核心。
【6. 沟通：面对面】
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
文档不是默认的沟通方式，交谈才是
敏捷项目中，默认的沟通方式是面对面的交流，而非冗余的文档。有的时候会编写文档，项目的所有信息可能不会在文档中体现。当然，这种情况适用于在稳定的敏捷团队中使用。
这里并不是赞成移除文档。在非标准的事情上建立标准是一件有意义的事情，产品经理期望通过需求文档来告诉架构师我们即将要开发的产品，架构师单纯从文档来获取需求的信息是不完全的。通过面对面的沟通可以帮助架构师更全面地了解即将要开发的产品。
然而，在一些技术交流中，文档可以作为辅助作用帮助开发人员沟通，如：接口文档、类库文档等。所有这些接口可以帮助开发人员熟悉接口标准。
对于接口的标准，一些设计原则中会有体现（这里不多做介绍）。
【9. 追求：技术卓越和设计良好】
Continuous attention to technical excellence and good design enhances agility.
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
关注新的技术和好的设计会增强敏捷能力
随时准备对项目使用最好的设计
在当前的需求下，当前的设计是最好的
高的产品质量是获取高的开发速度的关键。
尽量保证软件的简洁、健壮是快速开发的途径。所有敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。
他们不会制造混乱的代码后告诉自己需要更多的时间来清理它们。如果今天制造了混乱，今天清理。
另外，它的另一个含义是：绝不过渡设计。在当前需求的情况下，当前的设计是最优的设计。
如果我们编写一个hello,world，不需要使用庞大的框架来考虑数据设计要求，除非这个helloworld是通过数据库来进行数据传递的，否则绝不会考虑对数据库的引入。
【10. 根本：简洁】
Simplicity--the art of maximizing the amount of work not done--is essential.
以简洁为本，它是极力减少不必要工作量的艺术。
不做过渡设计和华而不实的设计
新需求到来再考虑它（重构）
使用最简单的方式来实现需求，是敏捷开发的一项艺术所在。当有更多的需求到来时才考虑如何实现。
另外，代码的质量需要另外的原则来保证：随时重构。
重构是在实现新需求的过程中，清除掉出现的冗余代码。随时重构是防止系统混乱的重要途径，常常也是一项必备技能之一。
【11.团队：自组织】
The best architectures, requirements, and designs emerge from self-organizing teams.
最好的架构、需求和设计出自自组织团队。
敏捷团队是自组织团队
敏捷团队是义务和责任的“原子”
敏捷团队对成员有较高的要求：自组织
敏捷团队是自组织团队，任务不是以人为单位被分配的，而是以团队为单位来分配。再又团队来确定完成任务的最好的办法。
作为原子，敏捷团队成员共同解决所要完成的需求。每一个成员有权利参与这个过程的所有方面，如PHP开发人员可以参与JS部分的工作等。不存在单一的成员对系统架构、需求或者测试负责的情况。
整个团队共同承担责任，每一个团队成员都能够影响它们。
另外，敏捷团队对成员的要求较高。敏捷团队的每个成员被要求成为多面手，使得他们可以做参与到任务的各个方面来。同时，在使用结队编程等团队开发方式的情况下，
【12.调整：定期反思】
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
总结不足，如何解决
（SCRUM）反思会
敏捷团队会不断对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境不断变化，并且知道为了保持团队的敏捷性，必须要随着环境一起变化。
敏捷要解决的一个问题便是快速应对变化。因此，随时地对自身进行更新，是应对变化环境的一种途径。
在scrum中，每一次迭代之后会有反思会的进行，反思会总结过去一个迭代中遇到的困难，提出解决途径。
【对比】
|
敏捷宣言原则 |
我的传统做法 |
冲突/共鸣 |
|
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 |
实现所需功能 实现某项技术 完成给定工作 |