您的位置： >>
本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第一篇文章，着重讲述敏捷实质。
　　相关文章：
　　从游戏开始&&
　　有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是&老板&，另一个是&员工&，在 2 分钟内，&员工&需要在&老板&的完全指挥下，即&向前一步，向后一步，停，向左一步，向右一步&，完成 60 步移动的任务。&员工&需要执行&老板&的每一个指令，不允许做出相违背的动作。&老板&则不参与行动，只发出指令指挥&员工&的活动。我们体验这个游戏时，当场 60% 的参与者成功完成了任务，大致估计出我们的工作效率是 50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是&员工&还是&老板&都表示非常不满。
　　接着，大家又做了另一组游戏。2 分钟内参与者被要求独立的、自主的完成 60 步移动任务，在这次游戏里，所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现所有参与者不但毫无折扣的按时完成了任务，因而工作效率也达到 100%*100%=100%，而且所有人对于这种新的工作方式更是产生了极大的兴趣。
　　以上两个游戏方式的对比就折射出传统开发（前者）与敏捷开发、测试活动方式的对比，其中优劣不言而喻。
　　而敏捷开发、敏捷测试又是怎样一个概念呢？他们是否能够帮助我们的团队突破束缚，在日益激烈的竞争环境里表现得更为出色呢 ? 请参考我的这个系列文章&&&敏捷测试的最佳实践&。
　　敏捷的价值
　　首先我们解释一下什么是敏捷，在字典中我们得到解释，敏捷，即反应迅速、可以快速变化。如今敏捷开发已成为众所周知的时髦 IT 词汇，在这个领域里敏捷又被诠释为迭代的，快速应对需求变化，轻量级，并且简洁。　　图 1. 面对客户业务复杂度问题提出敏捷解决方案
　　IBM 重视敏捷开发，敏捷的软件开发策略之也被广泛推广开来。中国软件开发中心是 IBM 软件部部署敏捷开发方法的重点实验室之一。我们也是 IBM 中国软件开发中心最早使用敏捷方法的开发、测试的团队之一。这篇文章主旨为帮助那些愿意采用敏捷，和正在采用敏捷开发、测试的团队正确了解敏捷的实质。
　　笔者做敏捷项目已经近两年时间，对于敏捷的理解，认为最为关键的是需要注意两个方面，它们是&高度迭代&和&持续不断的客户反馈&。
高度迭代：迭代就是指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周期活动的叠加中不断得到更新和加强。甚至指在一个迭代周期内产品活动也具显著的周期性。同时，团队间、团队内部成员的高度协作及时帮助解决了各成员的依赖性问题，因此，也促进了各个成员工作的顺利开展，保障了产品活动稳定的持续性、周期性。以测试为例，传统开发模式下，测试人员可以因进入测试阶段的条件不完全满足而继续的等待。而在高度迭代的敏捷项目里，不同的是，我们希望测试人员能够尽可能的做能够做的工作，尽可能的早工作。&等待&在敏捷开发、敏捷测试范畴里已是一种错误概念了。
持续不断的客户反馈：指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润。
　　敏捷开发的商业价值
　　敏捷开发自 2001 年《敏捷宣言》（&AGILE MANIFESTO&）的创生，经过多年的打磨和退火已经成为今天非常流行和有过许多成功案例的开发模式。正如前人所说，传统的东西就是用来打破的，传统的瀑布式开发模式必然逐渐退出历史舞台，敏捷开发、敏捷测试是在新环境里产生出来的打破传统的新开发模式。而敏捷也将会在将来，甚至现在转化成更适合现代化软件开发、测试团队的方法和实践。在本文的第一部分，我们以两个游戏类比了敏捷和传统开发的差异，这里为了进一步帮助大家对敏捷的价值有更清晰的理解，我们借鉴前人的研究结果：　　图 2. 敏捷与传统开发的比较
　　首先敏捷开发过程比传统开发要为项目和产品带来更低的风险（RISK）。为什么呢？传统开发缺乏持续的客户反馈 , 产品一旦从需求阶段退出，整个开发团队近似封闭工作，团队虽努力去实现曾经认定的目标，但因月有阴晴圆缺，市场需求也瞬息万变（例如提出需求的客户已经退休）。这使得产品在数月后，数年后发布时已经失去了占领甚至进入市场的最佳契机。
　　而如果你还在考虑使用传统开发模式用现在乃至将来一、两年的时间来开发一个结构复杂，精益求精而又功能庞大的产品，那么你得好好做好失败的准备了。而正是因为出于对这种风险的考虑，越来越多的人认识到敏捷开发要比传统开发能够为企业带来更大的利润空间和更低的投资风险。
　　其次，利益干系人（Stakeholder）的频繁参，与使得团队在产品开发的各个环节遇到的种种问题得到了及时的解决。因此，我们认为敏捷开发拥着比传统开发更大的透明度（VISIBILITY）。作为老板，项目的负责人一定对这样的开发模式带来的可控性充满了向往。
　　团队或者产品的适应能力（ADAPTABILITY）也决定着其生命力，因为敏捷开发模式鼓励团队采纳新技术，欢迎变化，并能够快速应对之，使得产品和团队自身都有很强的适应力和生命力。而在传统模式里，当需求变更时，复杂的变更管理流程要求通过正式讨论、审批，也备以足够的文档和说明来支持每次&决策&。这不但带来了人力，物力的浪费，更重要的是它严重延长了企业投资到利益回报的周期。而只有拥有反应迅速的敏捷开发才能够帮助企业赢取市场，降低风险。
　　以上我们谈及了敏捷开发拥有的比传统开发能为企业带来更大的商业价值和提供企业更大的发展空间。而对于个人而言，笔者认为敏捷开发也提供给了个人更多的发展机会和提出了更高的要求。以下是笔者从个人角度做出的分析。
　　敏捷开发有益于个人发展
　　敏捷项目首先拥有一支支小规模但职能全面的团队，在这样一个普通的敏捷团队里，拥有具备不同职能的 7 名成员，1 名 UCD(User Centered Designer)，1 名 Visual Designer，1 名测试人员（Tester）， 1 名 Information Developer 和 3 名开发人员（Developer）。因此，每一支敏捷团队中的设计、开发、测试、美工、文档等等工作分属给了这个团队里不同的，唯一的人。每个人在团队里因而必须具有对其所涉及领域强的责任心和领导力。就测试而言，测试人员就是好比一辆跑车里的唯一的驾驶员，项目就好比这辆跑车，测试人员需要及时修正行驶方向的偏差，确保这辆车在正确的道路上稳步前行。
　　如果，测试人员没有具备足够的责任心和领导力，只是人云亦云，恐怕这种测试要与不要没什么分别，敏捷项目的质量也更让人担忧，而敏捷也就失去了原有的意义。因此，作为唯一的测试人员，他（她）将拥有对测试的所有权，计划、设计并且执行所有的测试工作。而也因为拥有了更多的主人翁精神，积极的工作热情，测试人员勇敢的面对工作中的各种挑战，学习新的知识和努力培养自己的工作技能。敏捷无疑对个人发展产生了很大的推动作用。
　　敏捷团队中的每个人，需定时和团队的其他成员坐下来看看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。也需适时的寻求团队中其他成员的帮助解决时下紧要的问题。通过频繁的合作与沟通，个人的协作能力、沟通能力也得到了较大的提高。下面我们具体就这两个方面进一步谈谈敏捷开发是如何帮助提高个人的协作能力和沟通能力的。
　　敏捷开发培养了个人的协作能力
　　与传统开发不同，敏捷开发更加侧重以人为本，发挥人的积极性，以此提高团队的工作效率。真正实现以结果为导向的职场守则。作为团队的一份子，无论是测试、开发人员，还是设计人员，他们都将为团队成败担当不可或缺的责任。团队是高度协作的团队，个人除了做好本职工作外，敏捷开发模式要求个人能够了解和争取更多的扩展性的工作，也能帮助团队其他成员解决他们的遇到的各种独特问题，以加快实现团队的统一目标，即在更少的时间里生产出能够推向市场的可靠产品。
　　这里再次提及高度协作，笔者认为高度的团队协作主要表现为以下特点：
团队成员积极分享经验，知识，自我培养所需技能和自我成长；
团队成员相互帮助，愿意成为他人后备队员，随时做好准备投入新的战斗，因而保障了团队的高昂士气和强大的生命力。
任何决策是团队共同的决策，工作是团队共同的工作，团队工作的最后成果因而也是来自团队中每个人的辛勤培养和贡献。而团队的失败更是整个团队的失败，绝不会是某个人的单方面的过失。这种荣辱与共，共生共息的信念将让团队的力量超过团队各个力量之和。同时，项目团队的工作效率在团队成员技能的提升和信念的巩固中不断提高
　　敏捷开发锻炼了个人沟通能力
　　我们把团队看做一个高度协作整体的同时，不可忽视的是团队内部仍存在的各种矛盾，对这些问题的听之任之将破坏团队的凝聚力、生产力。这中间反映出来的很多问题不是敏捷方式独有，但团队成员因为敏捷，学会了自己解决各种问题。而相应的沟通能力也随着问题的解决得到很大幅度的提高。
　　在过去的项目经验中，我们不难发现种种人与人之间矛盾的产生。而经典的矛盾论也让我们不得不的接受，矛盾是永远存在的，但这并没有什么可怕。而是一旦我们发现了矛盾的存在，就要迅速找到解决办法，这也是团队的相当重要的工作。尤其是在团队组建初期，团队开始采纳新开发模式时，锻炼团队解决如下矛盾的工作非常重要：
测试人员是质量的工程师，开发人员是产品的缔造者，在对质量标准的认同上常有不一致（当然，传统开发也会产生）；
UCD 的设计实时反应用户需要，但有时不能顾及代码的可实现性；
开发人员而却更喜欢用想当然的理解，和习惯的方式填写代码，甚至主观的抵制接受新设计思想和拒绝新类型缺陷的修复，因此与团队的整体目标、出发点产生分歧；
从整个项目组织结构看来，敏捷团队之间（一个项目通常有多个敏捷团队组成，各个团队有自己的侧重点）存在设计，开发的不一致性，这使得产品在整合阶段产生额外的成本。
　　正如前面所论述，矛盾总是有能够解决的途径，敏捷项目的组织中用管理方式去干预是一种直接、快速的方式，而今天敏捷方法论者们更加推崇的是鼓励团队内部进行很好的交流和沟通后自行解决。也正是通过不断加强团队间和团队内部的相互理解，不但矛盾得到很好的解决（解铃还须系铃人嘛），个人的交流和沟通技能也得到了进一步提高。
　　敏捷开发培养了个人的创新意识
　　创新能够为企业带来新发展契机，创造新价值，因此，创新对于企业还是个人而言都非常之重要。不断培养员工的创新能力、鼓励创新活动也是几乎所有企业的人才培养战略之一。而敏捷开发恰恰就是要打破传统的模式，形成全新的敏捷开发、敏捷测试方法、实践和过程，并鼓励团队采用新技术和技术创新。因此，团队的每个人需要能够创造性的工作，并乐于接受新事物，通过不断的改进、突破过时的做法，努力提高团队的工作效率，来适应产品的增量发展需要。
　　而也因为敏捷开发模式对于很多团队仍很陌生，在运用敏捷开发的过程中我们会遭遇许多新挑战、新困难。如何处理这些问题，解决方案本身就是无以借鉴的，自主创新才是唯一出路。
　　举个例子，敏捷项目初期，产品停留在原型论证和底层架构初步设计中，产品功能不多，复杂度较小，一般的手动测试就可以将质量保障做好。产品的中后期，因不断有新需求、新功能的加入，产品复杂度增大。团队倘若仍仅凭固有的手动测试方式来覆盖产品的各个功能、非功能点需求只恐怕是力不从心了。因此，考虑用自动化测试来提高团队工作效率是可取的方法之一。但是，当产品发展到中后期，也没有富余的资源可以被抽取出来做自动化测试了。即使现招聘新人，也因为新人对产品不了解，只怕自动化测试的效果也未如人愿。那我们是否应该在开发活动的初期就尝试自动化测试的设计、并自动化一部分功能测试呢？也未然，因为在产品开发初期，产品的功能和界面的变动会比较大，自动化测试收入产出比异常低。因此，何时、何地、如何设计、运用自动化测试来帮助降低人力成本，提高测试效率是需要我们大胆创新的。
　　敏捷方法的共同点
　　以上我们通过商业、个人发展两个方面讲述了敏捷开发的价值和意义。那什么才是敏捷开发呢？在业界又有那些方法是敏捷开发的具体实现呢？各种方法有什么共同点吗？通过下文对各类敏捷方法的共性分析，我们也将进一步了解敏捷的实质。
　　敏捷方法
　　业界流行的敏捷开发的方法有许多（要了解各类敏捷方法和分类请参阅本文参考资料中文献），我们需要根据项目大小，性质来选择合适自己的敏捷方法。比如说 XP（极限编程，eXtreme Programming）更加适合小型项目 3-5 人的团队。Scrum，DSDM (Dynamic Systems Development Methodology) 等更加适合大型团队的项目开发。而敏捷开发也不是一成不变放之四海皆准的准则，而是一个方法的最佳实践。各个团体和企业也不断定制着自己的最佳游戏规则。VersionOne 的敏捷开发的调研报告中很好的对比了各个方法被业界采纳的比例（见下 ）。这个图表就是 2007 年对来自 71 个国家 1700 多人的调查结果的说明。　　图 3. 流行的敏捷方法
　　除了图例中的方法外还有 Crystal, Lean Software Development, Feature Driven Development, Xbreed, RUP 等等。
　　敏捷方法的共性
　　虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：
拥抱变化（Embrace the change）
　　无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数&唯一不变的是变化&。团队更要信任 利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。
　　而在接受变化的同时，我们应该积极的向 利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。
客户的参与（With Customer Representative on site）
　　首先谁是客户（Customer），客户代表（Customer Representative） 呢？利益干系人（Stakeholder），或者我们可以理解为我们的客户（Customer），产品的最终使用者（End user），内部使用者（Insider），商业伙伴（Business Partner）。利益干系人（Stakeholder）作为团队中最了解业务（Business）的人物将帮助开发团队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务（Business）方面他们需要 利益干系人（Stakeholder）的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个 15 分钟会议，或一封邮件、一个电话便可以解决。
　　但是，如果利益干系人（Stakeholder）各执一词怎么办呢？为解决这个问题，将 Product Owner 引入到讨论中来，作为 Product Owner 他可以作为是 利益干系人（Stakeholder）的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作效率也因而得到很大提高。
　　利益干系人（Stakeholder）能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。
较少的文档（With less documents）
　　敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。
　　敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不会放弃的。
最大化的生产力（Maximize Productivity）
　　敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个、多个任务并行的情况下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。
　　敏捷开发的 Scrum 模式，要求在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺下一个 24 小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得到提高。
测试驱动开发（Test Driven Development）
　　测试驱动开发，是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
自动化冗余工作（Automate the redundant work）
　　将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。
民主的团队（Democracy in team）
　　敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。
尊重团队（Respect to team）
　　敏捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实和表达对其他成员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。
　　你敏捷了吗？
　　你敏捷了吗？经过上面的学习，我们应该已经了解了敏捷的实质，并且笔者认为如果您的团队已经表现出上述的特点，那么您的团队已经敏捷了。但是，往往很难做到如此理想的敏捷。而同时，我们需指出敏捷与否也并非我们的最终目标，我们的目标是能够通过学习敏捷的方法和最佳实践来开发可以适用于自身特点的方法和过程，帮助项目灵敏的适应市场变化，让我们变得敏捷起来。
　　因此，我们依然希望进一步帮助大家了解如何变得敏捷，而首先，还是让我们学习大师留给我们的一套基本准则帮助我们判断项目开发敏捷与否吧。通过按照此标准的衡量，我们将容易得出项目是否敏捷的结论，也能够因地制宜的找到问题所在，最终实现敏捷。
　　Scott W. Ambler 在其文章 How Agile Are You？ 中指出了以下七条原则帮助大家来判断什么项目是敏捷的项目。
项目中有利益干系人（Stakeholder）的参与
团队拥有并且可随时执行的回归测试
关注产品自身而不是冗余的文档
项目开发拥有严格的源码管理、版本控制
开发能够积极面对和响应项目需求变化
团队作为整体直接担负项目责任
能够自动化重复性的活动
　　结束语
　　在敏捷测试最佳实践系列的第一篇文章中，您了解了敏捷实质，敏捷为我们带来的更多的业务价值的提升和一个更好的个人发展平台。对敏捷方法的共性分析中，我们了解了敏捷开发的关键特性，也了解了判别是否敏捷的方法和标准。
　　敏捷测试最佳实践系列的第二篇文章将基于笔者亲身经历的敏捷测试成功案例介绍敏捷测试的实践经验，使您对敏捷测试的结构和部署细节有更加清晰的认识。最后，本系列的第三篇文章将帮助您了解从传统测试转向敏捷测试所需具备的条件和方法，并分享笔者在敏捷测试的实践过程中遇到过的几类问题和解决这些问题的主要方法。
　　附加说明
　　免责说明
　　本文不带有任何明示或暗含的保证。文章提供的建议或最佳实践只作为一般的经验分享，只在作者的特定环境下验证过。作者不保证这些建议或最佳实践在任何情况下都有效。本文的内容有可能不太准确或包含错误，作者对此深表歉意。本文中任何带有主观性的陈述都只代表本文作者个人的观点，不代表 IBM 公司的官方立场。相关细节，请直接咨询作者。
　　关于作者
　　谢明志，2004 年加入IBM中国软件开发中心，拥有 4 年的软件测试经验。2005 年加入 IM 部门敏捷项目开发测试团队，2007 年加入中国软件开发中心 Test Community 开始推广敏捷开发，敏捷测试。
软件测试热门文章
软件测试最新文章[探讨]敏捷开发原则
最近，“敏捷”、“敏捷开发”这类词常常围绕在我们耳边。对于它的含义，我们是否真正了解？它是如何让开发变的有趣和高效？如何使用“敏捷”来进行商务沟通，并且使这种沟通更容易和更有建设性？
什么是敏捷开发？
一群开发经验丰富和才华横溢的开发人员通过关注其他公司和别的开发团队并且结合自身的项目经验，创建了敏捷开发宣言，让软件开发工作变的更容易更轻松：
个人和交互重于流程和工具有效的软件重于全面的文档客户合作重于合同谈判因时制宜重于按步就班
下面本文将会介绍12条敏捷开发原则，对于开创新的软件开发过程，这仅仅是第一步。
客户满意度
通过早期和持续不断的交互有价值的产品，来提升客户的满意度，这并不表示我们的软件会变成全能的。但在开发和每次迭代的时候都要考虑这一特征。
如果我们要开发一个博客引擎，也许会按照下面的步骤进行：&&&&&&&&&&&&&&&&&&&&&&&&
创建博客展示页面，交付给客户。创建用户管理中心和会员制度，交付给客户。添加评论管理功能，交付给客户。等等，交付给客户。
上面只是一些简单方法，但是客户会看到软件产品设计的每一步并且在每个新特征上做出反馈。它可能已经很好或者需要做出调整，但是你能迅速做调整，打造一个双赢的局面。
即使在开发后期，为了提高客户的竞争优势，敏捷开发也允许根据变化做出相应调整。
客户希望很快完成并且尽可能与他们所想的设计相接近。通过倾听和做好随时调整的准备，实现这个就比较简单。如果能够根据需求的变化快速做出响应，那么，我们可能就是客户最好的选择了。敏捷的核心就是关于沟通和改变，从客户那里得到什么，就迅速的实现，因为我们开发软件的每个子项目都可以根据需求进行调整，并不会对其他子项目产生不好的影响，反而会使开发变的快速高效。
从几周到几个月就应该交付更新，间隔越短，越好！
&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是由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个方法，如果你有更好的实践经验和方法，欢迎留言与大家一起探讨！
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：194145次
积分：2016
积分：2016
排名：第17591名
原创：34篇
转载：30篇
评论：26条
(1)(2)(4)(2)(2)(3)(3)(4)(11)(11)(3)(4)(13)(1)}