本文目录导航：
关于矫捷开发的含意、准则、目的和机制
了解矫捷开发，咱们可以先了解一下瀑布式开发。
瀑布开发形式把开发分红一系列阶段，如需求、设计、开发、测试，就像下图它画进去的，看起来很像瀑布，所以叫瀑布开发。
疑问是需求的交付难道不都是要阅历这些阶段吗？ 瀑布开发的实质疑问并不是阶段，而是批量。
需求批量地在一同启动设计，而后是批量地开发，批量地测试、交付等等。
批量有什么疑问? 首先，批量让价值交付提前，一切需求在最后的阶段才干交付，价值交付比拟晚。
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
矫捷开发形式有哪些
矫捷开发包括一系列的方法，干流的有如下七种：XPXP（极限编程）的思维源自 Kent Beck和Ward Cunningham在软件名目中的协作阅历。
XP注重的外围是沟通、扼要、反应和勇气。
由于知道方案永远赶不上变化，XP无需开发人员在软件开局初期做 出很多的文档。
XP倡议测试后行，为了将以后出现bug的几率降到最低。
SCRUMSCRUM是一种迭代的增量化环节，用于产品开发或上班治理。
它是一种可以汇合各种开发通常的阅历化环节框架。
SCRUM中颁布产品的关键性高于一切。
该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充散施展面向对象和构件技术的开发方法，是对迭代式面向对象方法的改良。
Crystal MethodsCrystal Methods（水晶方法族）由Alistair Cockburn在20实践90年代末提出。
之所以是个系列，是由于他置信不同类型的名目须要不同的方法。
只管水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵照它。
FDDFDD （Feature-Driven Development，个性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre独特开发，是一套针对中小型软件开发名目的开发形式。
此外，FDD是一个模型驱动的极速迭代开发环节，它强调的是简化、适用、 易于被开发团队接受，适用于需求经常变化的名目。
ASDASD（Adaptive Software Development，自顺应软件开发）由Jim Highsmith在1999年正式提出。
ASD强调开发方法的顺应性（Adaptive），这一思维起源于复杂系统的混沌通常。
ASD不象其余方法那样 有很多详细的通常做法，它更并重为ASD的关键性提供最基本的基础，并从更高的组织和治理档次来论述开发方法为什么要具有顺应性。
DSDMDSDM（灵活系统开发方法）是泛滥矫捷开发方法中的一种，它倡议以业务为外围，极速而有效地启动系统开发。
通常证实DSDM是成功的矫捷开发方法之一。
在英国，由于其在各种规模的软件组织中的成功，它已成为运行最为宽泛的极速运行开发方法。
DSDM岂但遵照了矫捷方法的原理，而且也适宜那些成熟的传统开发方法有松软基础的软件组织。
轻量型RUPRUP其实是个环节的框架，它可以容纳许多不同类型的环节， Craig Larman 竭力主张以矫捷型形式来经常使用RUP。
他的观念是:目前如此泛滥的致力以推进矫捷型方法，只不过是在接受能被视为RUP 的干流OO开发方法而已。
矫捷开发和软件工程能否矛盾，为什么
如今，矫捷开发是一个十分抢手的话题，很多机构的咨询师、很多程序员对“矫捷”曾经到达了一种近乎宗教的狂热的水平。
谈到软件开发，必谈矫捷，必谈TDD，好像不用这个方法，就必定是效率低下的团队和开发方法。
我团体没有细心钻研过矫捷开发（准确说，没有钻研过那几个牛人提出的矫捷开发）。
但是，公司目前在鼎力推进矫捷，而且我去年的一个关键名目也是依照公司推进的矫捷方法启动的（听说，公司从某个驰名的咨询培训机构挖来人，帮咱们做名目治理培训和矫捷推行）。
这篇文章中，我只想谈谈自己对这个方法的感触和想法。
我的总的观念是：矫捷开发是反软件工程的。
我抵赖，矫捷开发中有些通常形式是很好的，值得排汇。
例如在矫捷开发的圣经“矫捷软件开发-准则、形式于成功”一书中，很多设计准则，如“繁多职责”、“开明敞开”、“依赖到转”等，它们只是普通、通用的设计准则，应该运行在任何的开发方法中，这些准则并也不是只要矫捷开发方法才干用，在任何的开发方法中都可以、应该经常使用。
但是，矫捷开发作为一个方法论，则是软件工程的发展。
矫捷开发，更像是软件工程出现之前，小作坊式的软件开发方法。
什么是传统的小作坊式的开发？它最关键的特点包括：1.几团体组成一个小组（小作坊），这个小组中的人独特成功软件的需求、设计、开发和测试。
小组中有便捷的分工并重，但其实每团体都会介入每个阶段。
用矫捷的话讲，这就是产品人员、软件工程师和测试工程师严密配合的一个小组。
工程师须要介入需求剖析、测试工程师须要介入产品的设计、产品人员要不时的经过以后已有的“原型”来开掘、更改需求，当然，这是由于“产品人员无法能在一开局就看到一切的需求”。
2.在这个小组中，文档只是用来辅佐交流的，人们更多的经常使用行动交流来明白一些细节疑问或许是存在歧义的疑问。
文档不许要做到“面面具到”。
当然，这也是矫捷所推崇的。
3.没有严厉的开发环节控制。
4.须要极速的接纳并照应需求的变化，由于需求是不时在变的。
咱们可以看到，这也是“矫捷开发”方法论的关键特点。
那么软件工程的目的是什么？软件工程获取人们的注重真实IBM OS360开发之后。
人们意识到，软件系统曾经越来越复杂，越来越庞大。
上方提到的这种开发方法暴显露越来越多的疑问：对程序员要求过高、软件品质难以保障、软件开发成功后的保养老本渺小等等。
为了处置软件开发的这些疑问，人们自创了传统的工程名目的实施。
建造一个大厦、建造一辆汽车等，这些工程不比软件开发便捷（准确讲，建造一个大厦要远比咱们经常出现的大少数软件复杂），但是这些工程却能被可控地实施并获取品质良好的结果。
由此，人们提出了“软件工程”，它的首要目的，也是最基本的目的就是“将软件开发工程化”。
剩下的疑问是，怎样才干“工程化”？咱们依然可以从修建业和制作业自创他们成功的方法。
咱们上方就来看看工程化的最关键的两个方面。
严厉的环节控制。
先做什么，后做什么，十明显确。
比如先做需求剖析、再做设计、再做结构施工、再做墙壁于管道等。
并且，环节中的每一步都要有确定的（至少在本次工程中不变的）产出，并经过验收。
这个产出的担任人和验收担任人都要在验收报告中签字。
假设这个产出在同一个工程中必定出现变化，那么，这就是一次性工程意外，依据意外的大小，责任人须要负“被开革”到“刑事立功”等不一的责任。
例如，咱们要建造一个20层高的大厦，当主设计师成功结构设计后，他会对这份设计文档签字担任，验收者会在验收报告签字。
大厦的主结构就会依照这份文档中的结构启动建造。
假设到名目的中期，正在启动管道、线缆的部署时，发现，主结构是有疑问的，中央主梁无法接受足够的扭矩。
此时，设计师和验收者的一句“咱们无法在一开局就看到这个，在下一次性迭代中会修复”是相对不会被接受的。
他们要担任任。
雷同，假设此时产品人员上来说，客户的需求变了，是25层而不是20层。
而要到达这个要求的代价是：主设计师就须要将主梁的直径参与20%、局部修建资料须要被交流......我想，关于这种产品人员而言，只能通知他，你曾经在需求文档中签字了，你须要担任抵偿包括返工、资料、工期等方面的一切损失，你该辞职辞职，该坐牢坐牢。
疑问是：为什么软件不能这样呢？是由于软件修正的老本低吗？理想曾经证实了，软件修正的老本不低（计算上后续保养的老本）。
严厉的规格说明。
此处，我用了“规格说明”，其实就是咱们所说的文档。
文档应该做到详细、严厉。
举个例子，在机械制作中，常罕用到螺丝。
在一个机械的设计文档中，会详细指定每个螺丝在规范环境下（比如0摄氏度、5%的湿度、一个大气压）的直径、螺纹间距、螺纹高度、以及热收缩系数等参数，担任制作螺丝的部门，拿到份文档，甚至都不用见设计师自己，就可以制作出合格的螺丝。
这外面，文档才是关键的物品。
哪怕设计师换了、原来的螺丝部门的工人走了，只需有这份文档和合格的工人，就必定能造出与原来一样的螺丝。
我意识一个做配件设计的人，他曾经通知我“你知道配件的bug为什么这么少吗？我不是在用verilog设计配件，我是在用文档设计配件。
拿到我的文档，任何一个懂verilog语法的人都可以编码出合格的产品。
”这就是文档的力气。
只要设计文档才干保障在原本设计、成功一个系统的人走后，后续的人能够很容易的继续保养、裁减这个系统。
上方就是我了解的软件工程。
这个环球上很少有真正的“奇观”，咱们以为的奇观，基本上都是平凡的工程。
