本文目录导航：
关于矫捷开发的含意、准则、目的和机制
了解矫捷开发，咱们可以先了解一下瀑布式开发。
瀑布开发形式把开发分红一系列阶段，如需求、设计、开发、测试，就像下图它画进去的，看起来很像瀑布，所以叫瀑布开发。
疑问是需求的交付难道不都是要阅历这些阶段吗？ 瀑布开发的实质疑问并不是阶段，而是批量。
需求批量地在一同启动设计，而后是批量地开发，批量地测试、交付等等。
批量有什么疑问? 首先，批量让价值交付提前，一切需求在最后的阶段才干交付，价值交付比拟晚。
Google口头董事长施密特提出过反摩尔定律，表述为： “假设18个月之后咱们只能卖出跟当天一样的物品，咱们就只能获取一半的支出。
”价值的交付时期将间接影响支出。
矫捷的目的 矫捷开发有第一个目的就是更快的交付价值，这里的快指的不是相对速度，而是更早的交付。
在名目完结的时刻，必定是对产品和名目的常识了解最充沛的时刻。
这显而易见，咱们在名目进程中积攒了常识特地是当向用户交付产品后，用户反应： “我要的不是这个啊，我说的明明是……”，这时刻你瞬间狂涨常识，并慨叹道“你怎样不早说呢？”。
这两边或许有沟通疑问，但更多或许的是，用户这时才清楚或能够形容他们要的是啥，更有甚者，咱们或许一开局连用户是谁也未必能准确地定义。
产品和业务开发原本就是一个探求的环节，开局时必定是最无知的时辰。
名目中的大局部决策也必定是在名目开局的时辰做出的，这将有一个严重的悖论，在最无知的时辰，做出了最关键而且是绝大局部的决策，并把它作为随后口头的依据。
面对不确定的技术、市场环境，传统开发形式已无法顺应要求，悖论越发突出。
矫捷开发将经过迭代应答这一疑问，只做初始决策，定大抵的方向。
经过市场反应不时批改对产品的认知，增量的决策和调整。
产品开发环节中，技术环境、市场环境、竞品战略、团队认知都会出现变化。
面对变化的环境，咱们必定抵赖自己的无知，在开发环节主动有效地学习，不时地吸取反应，灵敏地调整。
这也是矫捷的第二个业务目的，有效学习和灵敏照应变化。
矫捷开发工具 矫捷开发是一种以人为外围，以迭代形式墨守成规开发的方法，其软件开发的环节称为“矫捷环节”。
在这一环节中，软件名目的构建被切分红多个子名目，各个子名目的成功都经过测试，具有集成和可运转的特色。
在2001年年终，一些业界专家成立了矫捷联盟，起草了矫捷软件开发宣言。
该宣言针对一些企业的现状，提出了让软件开发团队具有极速上班、极速应变才干的若干价值观和准则，其中包括4个便捷的价值观以及矫捷开发方法应遵照的12条准则 。
矫捷开发的价值观 1.团体和交互胜过环节和工具。
2.可以运转的软件胜过面面俱到的文档。
3.客户协作胜过合同谈判。
4.照应变化胜过遵照方案。
矫捷开发应遵照的12条准则 1.经过尽早的、不时地提交有价值的软件来使客户满意。
2.即使到了开发的前期，也欢迎扭转需求。
矫捷环节应用变化来为客户发明竞争长处。
3.以从几个星期到几个月为周期，尽快、不时地提交可运转的软件。
4.在整个名目开发时期，业务人员和开发人员必定天天都在一同上班。
5.以踊跃向上的员工为中心，建设名目组，给他们提供所需的环境和允许，并对他们的上班予以充沛的信赖。
6.在团队外部，最有效、效率最高的传递消息的方法，就是面对面的交换。
7.测量名目停顿的首要依据是可运转软件。
8.矫捷环节倡议可继续的开发，责任人、开发者和用户应该为能够坚持一个常年的、恒定的开发速度而致力。
9.时辰关注技术上的如虎添翼和好的设计，以增强矫捷才干。
10.便捷是最基本的。
11.最好的构架、需求和设计出于自组织的团队。
12.每隔必定时期，团队要反省如何才干更有效地上班，而后相应地调整自己的行为。
矫捷组织提出的矫捷开发模型的全体框架关键有三个： Scrum、XP（eXtreme Programming）、OpenUP 这3个矫捷通常。
矫捷开发的准则 1.凝聚人的力气，严密协（合）作。
包括业务担任人、开发团队、客户、治理者之间的相关，一切这些相关在以前都是形成名目危机的要素之一，那么，在矫捷时代，咱们要求这些角色 严密协作，最大限制的施展各个角色的力气. 2.聚焦客户价值，消弭糜费（如何聚焦用户价值，即频繁的交付用户可上班的软件，极速收到用户反应）矫捷团队运作机制 1.一个团队有自己的代办事项，对代办事项启动拆小。
2.按客户价值启动优先级排序，产品经理担任价值排序。
3.小而稳固，跨职能团队。
4.多个团队松耦合（依赖性比拟低），对齐迭代时期和战略目的。
关键的团队角色 产品担任人 Scrum主管（流程主管） 开发团队 产品担任人（Product Owner） 担任治理产品backlog（代办事项）的惟一担任人 代表客户/名目如责任人 定义产品的一切个性 担任产品的投入产出 担任最大化产品和开发团队上班的价值 Scrum Master（流程主管） 起到教练的职责，指导团队成功Scrum的通常以及表现其价值。
扫除团队遇到的艰巨，使得团队严密协作，使得团队团体具有多方面职能的上班才干。
确保团队能胜任其上班，并坚持高效的消费率。
包全团队不遭到外来无故影响 关键的团队优惠 每日例会：每日5分钟左右的一个便捷例会，尽或许多的开发人员介入出去对紧要疑问的探讨。
评审会：要求在迭代周期的最后一天召开，1个小时左右就可以了，要求客户缺席，假设客户不能缺席，则要求产品经理缺席 迭代回忆会：迭代回忆会是在每个迭代完结时启动，总结上班中的阅历和经验，时期维持在30-60分钟内，整个团队都要求参与（Scrum Master、Product Owner、开发团队以及客户）。
迭代回忆会包括两局部，第一局部是定量剖析，第二局部是定性剖析。
其中定量剖析又蕴含团队能否成功了迭代目的，搜集并评审迭代度量目的（包括速率、迭代燃尽图、迭代方案故事和实践成功故事、方案颁布日期与实践颁布日期、客户满意度、团队满意度、消费环境Bug数、消费Bug处置时期、用户故事等）。
定性剖析蕴含哪些上班良好（应该继续坚持），哪些做的不好（应该中止）；哪些可以改良（团队选出1－2条在下一个迭代成功）。
矫捷开发框架案例： /Home/VerificationForm 原文：windy
[矫捷开发：人比流程关键] 软件矫捷开发流程
与传统软件开发方法相比，矫捷开发更注重人在软件开发中的作用，强调极速迭代、继续集成以及测试驱动开发等，从而满足不时变化的业务需求。
20世纪60年代开局的软件危机引发了人们对软件开发的思索，并由此降生了《软件工程》这门学科。
它将软件开发分为需求剖析、设计、编码、测试、保养等几个阶段的瀑布式开发软件方法至今依然在大少数软件开发组织沿用。
但是，《软件工程》学及其瀑布式开发方法并没有彻底处置软件危机。
如何满足不时变化的软件需求不时就是传统软件开发方法无法处置的难题。
而矫捷开发正是为了处置上述疑问而提出，从2001年矫捷开发方法正式出现以来，越来越多的开发人员开局接受这一方法，市场也出现了一批以矫捷开发为关键方法的软件开发和咨询服务公司。
ThoughtWorks公司就是其中的佼佼者，日前，本报记者专访了ThoughtWorks公司中国区总经理郭晓，请他就如何实施矫捷开发等疑问启动引见。
推翻 传统软件开发方法 矫捷开发作为一种开发方法始于2001年，过后世界十分有名的10多位软件开发的巨匠集中在一同，对过后出现的一些新的编程方法启动演绎，并用矫捷这个词来概括这几种相似的方法流程。
“只需你的软件开发方法遵照矫捷的四条准则（即集体和交互胜过环节和工具、上班的软件胜过面面俱到的文档、客户协作胜过合同谈判、照应变化胜过遵照方案），就算是矫捷一类的开发方法。
比如ThoughtWorks自身的通常就集成了Scrum和极限编程，是这两种方法的组合体。
” 郭晓通知记者。
郭晓从20世纪90年代开局接触极限编程等矫捷开发方法，其后的10多年不时从事矫捷开发，起初又从事软件开发的治理上班，这使得他可以从更高的档次过去看矫捷这种对大少数程序员依然比拟生疏的开发方法。
郭晓以为，矫捷宣言最为外围的思维有两点。
一个是人比流程关键。
矫捷和传统的开发形式最大的不同点在于，传统的软件开发形式遵照了20世纪大规模工业化消费的思绪: 每团体在这个流水线上担任一项上班，只需流程设计得完美，人就不关键，这也是《软件工程》学所谋求的一种境界。
而实践上，软件开发是一个常识性、发明性的上班，是无法能齐全模拟流水线的。
矫捷开发强调一批有软件开发才干的人组成一个团队，至于团队经常使用哪种矫捷方法，齐全由团队依据自己的特点来选择。
它强调流程是为人服务的，注重施展人最大的发明力。
另一个是能够上班的软件其价值要比文档关键。
传统的软件开发方法分为需求剖析、设计、编码等不同的阶段，区分由不同的人担任，文档在其中表演驱能源的角色，不同角色经过文档来启动常识传递和交互。
而矫捷开发以为文档是为软件服务的，强调经过极速迭代和继续集成，让各种不同角色的人员可以基于目前曾经开收回的软件启动间接沟通交换。
这就带来了两个好处: 极速反应和严密的协作。
“注重交付、严密协作、极速反应正是矫捷的不凡之处，这些特点保障了矫捷开发能够满足变化的需求。
”郭晓说，“而用传统的软件开发方法开收回的软件成功与否很大水平上建设在需求剖析能否有足够的远见，能把未来的需求都思索在内，而实践上，这简直是无法能的。
” 结对编程 有必要吗？ 说起矫捷开发也就不能不提到它的结对编程，矫捷开发要求代码的编写应该同时有两人介入，两人独特经常使用同一台电脑、一个键盘和一个鼠标。
在采访环节中，记者特地向郭晓提出了这一不懂: 结对编程有必要吗？ 郭晓通知记者，结对编程在大少数状况下是适宜的。
在反常状况下，一个程序员并不是终日都在敲键盘输代码，他要思索，实践上真正敲键盘的时期只要20%～30%。
因此，两团体独特经常使用同一套电脑，并不象征着效率降低。
矫捷开发要求一团体在编写代码的同时，另一团体对这个代码启动评审，评价代码能否正确、能否有更佳的编写方法，而后相互沟通交换。
这样写出的代码品质要远远高于单团体写。
结对编程的另一个好处是降低了名目危险。
现代软件开发分工很细，每个软件开发人员独立担任一局部，一旦程序员离任或许换岗关于软件开发会很不利。
而结对编程时，每段代码都至少有两团体了解，人员变化给名目带来的危险要低得多。
结对编程还有一个好处是有助于传、帮、带。
经过结对编程，名目新来者可以很容易地融入出去，而这个环节不损失代码数量，还能够带来常识的共享等好处。
郭晓补充说，只管矫捷开发强调矫捷编程，但并不是机械地要求任何代码都要结对成功。
关于一些很便捷、妇孺皆知的代码，也可以只由一团体担任。
实践上，记者曾观赏过ThoughtWorks公司的软件开发现场。
记者看到，在大少数公司经常出现的格子间不见了，取而代之的是一个个长方形的大圆桌。
这里的开发人员以两团体为一组，只管两团体背地各有一个显示器，但都接在同一个服务器上，其中一团体在编代码，另一个在启动评审。
“咱们的实践阅历也证实了这种方法的先进性。
咱们有员工反映说，结对编程参与了他们的上班压力，由于结对时，两人简直不再会做与上班有关的事件了。
” 郭晓笑着说。
矫捷开发 能走多远？ 矫捷作为一种软件开发方法其先进性和正当性无须置疑，但是这种方法的实用范围如何？它适宜大型软件开发组织驳回吗？ “矫捷开发从2001年正式提进去的时刻就有人提出，它不适宜于大型软件开发团队、不适宜于周期长的名目。
理想上，这些年来，这些说法正在不时地被打破。
”郭晓说，“当然矫捷自身也在不时裁减，从而能够顺应越来越广的畛域。
” 郭晓引见说，ThoughtWorks公司自己就曾在100人的名目上驳回过矫捷开发。
实践上，ThoughtWorks就是因此才和矫捷开发结缘的。
1999年的ThoughtWorks还只是一个从事软件开发的公司。
过后有一个100多人介入的大名目堕入了主动，不得已请来了业界颇负盛名、起初被称为矫捷开发“教父”的Martin Fowler和Ward Cunningham来做咨询上班。
他们经过引入矫捷开发让公司解脱了困境。
这也让ThoughtWorks感遭到矫捷开发方法的魔力。
另一个例子是英国电讯（BT），它在印度有一个1.8万人的开发团队，在英国外乡和其余中央也有几万人的开发团队，它如今简直一切的软件名目都是用矫捷的方法来开发的。
当然，矫捷开发作为一种软件开发方法也并不是万能的，也存在一些局限。
换句话说，要保障矫捷开发成功要求一些前提条件。
郭晓说: “矫捷开发要和客户严密地沟通，才干够不时地取得客户的反应。
而实践上，通常客户很忙，抽不出这么多时期。
另外，还有一些产品开发依赖于产品经理来了解需求，而他其实并不是真正的客户，这给矫捷开发带来艰巨。
” 此外，客户对开发方的充沛信赖也是矫捷开发成功很有必要的一个条件。
矫捷开发最佳的运行场景是用户不时提出新的需求，而名目合同多少钱也随着需求不时调整。
郭晓说，这在实践开发环节就是一个疑问，特地是第一次性协作时，客户就会很担忧名目的最终老本。
而假设是公司自己的开发队伍，这将不是疑问。
从这个角度上说，矫捷开发最大的市场是公司外部的开发团队。
“不论怎样说，这几年咱们曾经显著感遭到接受矫捷开发思维的人越来越多，从要求咱们提供咨询服务的客户数量可以看出这种趋向。
咱们置信，矫捷开发必定会确立自己在软件开发畛域的一席之地的。
”郭晓信念十足地说。
以亲自阅历解读矫捷软件开发（一）什么是矫捷软件开发
矫捷开发以用户的需求退化为外围，驳回迭代、墨守成规的方法启动软件开发。
在矫捷开发中，软件名目在构建初期被切分红多个子名目，各个子名目的成绩都经过测试，具有可视、可集成和可运转经常使用的特色。
换言之，就是把一个大名目分为多个相互咨询，但也可独立运转的小名目，并区分成功，在此环节中软件不时处于可经常使用形态。
价值观
矫捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、便捷、反应、勇气，此外，还裁减了第五个价值观：谦虚。
互联网是个神奇的大网，软件框架也是一种形式，假设你真的想做，可以来这里，这个手技的开局数字是一八七两边的是三儿零最后的是一四二五零，依照顺序组合起来就可以找到，我想说的是，除非你想做或许了解这方面的内容，假设只是凑繁华的话，就不要来了。
矫捷开发是针对传统的瀑布开发形式的弊病而发生的一种新的开发形式，目的是提高开发效率和照应才干。
除了准则和通常，形式也是很关键的，多钻研形式及其运行可以使你更深档次的了解矫捷开发。
沟通
建模岂但能够促成你团队外部的开发人员之间沟通、还能够促成你的团队和你的project stakeholder之间的沟通。
便捷
画一两张图表来替代几十甚至几百行的代码，经过这种方法，建模成为简化软件和软件（开发）环节的关键。
这一点对开发人员而言十分关键－它便捷，容易发现出新的想法，随着你（对软件）的了解的加深，也能够很容易的改良。
反应
Kent Beck在Extreme Programming Explained中有句话讲得十分好：“适度自信是编程的职业病，反应则是其处方。
”经过图表来交换你的想法，你可以极速取得反应，并能够依照倡议行事。
谦虚
最低劣的开发人员都领有谦虚的美德，他们总能意识到自己并不是一无所知的。
理想上，无论是开发人员还是客户，甚至一切的 project stakeholder，都有他们自己的专业畛域，都能够为名目做出奉献。
一个有效的做法是假定介入名目的每一团体都有相反的价值，都应该被尊重。
准则
矫捷建模（AM）定义了一系列的外围准则和辅佐准则，它们为软件开发名目中的建模通常奠定了基石。
其中一些准则是从XP中自创而来，在Extreme Programming Explained中有它们的详细形容。
而XP中的一些准则又是源于妇孺皆知的软件工程学。
复用的思维随处可见！基本上，本文中对这些准则的论述关键并重于它们是如何影响着建模上班；这样，关于这些自创于XP的准则，咱们可以从另一个角度来看待。
外围准则
◆主张便捷
当从事开发上班时，你应当主张最便捷的处置方案就是最好的处置方案。不要过火构建
矫捷开发
（overbuild）你的软件。
用AM的说法就是，假设你如今并不要求这项额外配置，那就不要在模型中参与它。
要有这样的勇气：你如今不用要对这个系统启动过火的建模（over-model），只需基于现有的需求启动建模，日后需求有变卦时，再来重构这个系统。
尽或许的坚持模型的便捷。
◆拥抱变化
需求时辰在变，人们关于需求的了解也时辰在变。
名目启动中，Project stakeholder或许变化，会有新人参与，也会有旧人退出。
Project stakeholder的观念也或许变化，你致力的目的和成功规范也有或许出现变化。
这就象征着随着名目的启动，名目环境也在不停的变化，因此你的开发方法必定要能够反映这种理想。
◆你的第二个目的是可继续性
即使你的团队曾经把一个能够运转的系统交付给用户，你的名目也还或许是失败的－－成功名目投资者的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够顺应日后的裁减。
就像Alistair Cockburn常说的，当你在启动软件开发的竞赛时，你的第二个目的就是预备下一场较量。
可继续性或许指的是系统的下一个关键颁布版，或是你正在构建的系统的运转和允许。
要做到这一点，你不只仅要构建高品质的软件，还要创立足够的文档和允许资料，保障下一场较量能有效的启动。
你要思索很多的要素，包括你现有的团队是不是还能够参与下一场的较量，下一场较量的环境，下一场较量对你的组织的关键水平。
便捷的说，你在开发的时刻，你要能构想到未来。
◆递增的变化
和建模相关的一个关键概念是你不用在一开局就预备好一切。
实践上，你就算想这么做也不太或许。
而且，你不用在模型中容纳一切的细节，你只需足够的细节就够了。
没有必要试图在一开局就建设一个囊括一切的模型，你只需开发一个小的模型，或是概要模型，打下一个基础，而后缓缓的改良模型，或是在不在要求的时刻摈弃这个模型。
这就是递增的思维。
◆令投资最大化
你的名目投资者为了开收回满足自己要求的软件，要求投入时期、金钱、设施等各种资源。
投资者应该可以选取最好的形式投资，也可以要求你的团队不糜费资源。
并且，他们还有最后的发言权，选择要投入多少的资源。
假设是这些资源是你自己的，你宿愿你的资源被误用吗。
◆有目的的建模
关于自己的产出，例如模型、源代码、文档，很多开发人员不是担忧它们能否够详细，就是担忧它们能否太过详细，或担忧它们能否足够正确。
你不应该毫有意义的建模，应该先问问，为什么要建设这个产出，为谁建设它。
和建模有关，兴许你应该更多的了解软件的某个方面，兴许为了保障名目的顺利启动，你要求和初级经理交换你的方法，兴许你要求创立形容系统的文档，使其他人能够操作、保养、改良系统。
假设你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保障模型足够正确和足够详细。
一旦一个模型成功了目的，你就可以完结上班，把精神转移到其它的上班下来，例如编写代码以测验模型的运作。
该项准则也可实用于扭转现有模型：假设你要做一些扭转，兴许是一个熟知的形式，你应该有做出变化的正确理由（或许是为了允许一项新的需求，或是为了重构以保障繁复）。
关于该项准则的一个关键暗示是你应该要了解你的受众，即使受众是你自己也一样。
例如，假设你是为保养人员建设模型，他们究竟要求些什么？是厚达500页的详细文档才够呢，还是10页的上班总览就够了？你不清楚？去和他们谈谈，找出你想要的。
◆多种模型
开发软件要求经常使用多种模型，由于每种模型只能形容软件的单个方面，“要开发现今的商业应
矫捷开发
用，咱们该要求什么样的模型？”思索到现今的软件的复杂性，你的建模工具箱应该要容纳少量有用的技术（关于产出的清单，可以参阅AM的建模工件）。
有一点很关键，你没有必要为一个系统开发一切的模型，而应该针对系统的详细状况，筛选一局部的模型。
不同的系统经常使用不同局部的模型。
比如，和家里的修缮上班一样，每种上班不是要求你用遍工具箱里的每一个工具，而是一次性经常使用某一件工具。
又比如，你或许会比拟青睐某些工具，雷同，你可会偏爱某一种模型。
有多少的建模工件可供经常使用呢，假设你想要了解这方面的更多细节，我在Be Realistic about the UML中列出了UML的相关局部，假设你宿愿做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。
成功
随机应变
要到达矫捷的成功—交付撑持业务的最佳软件—软件专家也可以援用这些规定。
自主权
专一于上班，交付正确的软件，而不是被他人的愤怒心情所影响。
分享阅历
构建完美软件开发流程，并没有一致的形式。
但是在这个畛域，矫捷技术，加上继续的运行和改良，都能够到达矫捷的成功。
