本文目录导航：
对于矫捷开发的含意、准则、目的和机制
了解矫捷开发，咱们可以先了解一下瀑布式开发。
瀑布开发形式把开发分红一系列阶段，如需求、设计、开发、测试，就像下图它画进去的，看起来很像瀑布，所以叫瀑布开发。
疑问是需求的交付难道不都是要阅历这些阶段吗？ 瀑布开发的实质疑问并不是阶段，而是批量。
需求批量地在一同启动设计，而后是批量地开发，批量地测试、交付等等。
批量有什么疑问? 首先，批量让价值交付提前，一切需求在最后的阶段才干交付，价值交付比拟晚。
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
矫捷开发准则
咱们不时在通常中探寻更好的软件开发方法，身体力行的同时也协助他人。
由此咱们建设了如下价值观： 集体和互动 高于 流程和工具 上班的软件 高于 详尽的文档 客户协作 高于 合同谈判 照应变动 高于 遵照方案 也就是说，虽然右项有其价值，咱们更注重左项的价值。
尽早并继续的交付有价值的软件以满足客户需求。
行为： 以起码的配置尽早交付客户 以最短的周期继续的交付客户 结果： 早期交付配置越少，最终交付质量越高 交付的越频繁，交付质量越高矫捷流程欢迎需求的变动，并应用这种变动来提高用户的竞争长处。
行为：坚持开明和学习的心态，欢迎变卦。
并踊跃应答变卦或许启动翻新。
结果：客户满意度参与，人员技艺和学习才干优化，产质量量提高，团队灵敏度参与。
经常颁布可用的软件，颁布距离可以从几周到几个月，能短则短。
行为：尽早并且经常颁布可用软件，而不是文档。
结果：客户满意度和产质量量提高。
业务人员和开发人员在名目开发环节中应该每天独特上班。
行为： 疏导团队成员独特了解软件 团队成员一同沟通了解名目进度 团队成员一同相互沟通了解彼此的想法 结果： 沟通效率大幅优化，产质量量提高，客户满意度参与以有进取心的人为名目外围，充沛允许信赖他们。
行为：以有进取心的员工为外围，充沛允许并信赖他们 结果：你给我一个时机，我还你一个惊喜无论团队内外，面对面的交换一直是最有效的沟通方式。
行为：无论团队内外，文档不是自动的沟通方式，沟通方式都介绍面对面的交换 结果：沟通效率大幅优化，产质量量提高可用的软件是权衡名目停顿的关键目的。
行为：经常使用可用的软件作为名目的关键目的 结果：需求的成功度和软件的可用水平提高矫捷流程应能坚持可继续的开展。
指导，团队和用户应该能依照目前的步伐继续协作下去。
行为：坚持分歧的速率开发 结果：极速可继续的开展继续关注出色的技术和优异的设计，会增强矫捷才干。
行为： 关注出色的技术和优异的设计 结果： 随时预备对名目经常使用最好的技术和优异的设计 在以后的需求下以后的设计是最好的，技术是最适合的扼要为本——它是竭力简化不用要的上班量的技艺。
行为： 不做适度设计和金玉其外，败絮其中的设计 直到新需求出现时才思考它 结果： 改善用户体验，产品就是说明书，降落学习曲线 简化不用要的上班量只要自我治理的团队才干发明最优秀的架构，需求和设计。
时时总结如何提高团队效率并付诸执行。
矫捷开发的矫捷开发的准则
1. 极速迭代相对那种半年一次性的大版本颁布来说，小版本的需求、开发和测试愈加便捷极速。
一些公司，一年仅颁布仅2~3个版本，颁布流程缓慢，它们仍驳回瀑布开发形式，更严重的是对矫捷开发形式存在曲解。
2. 让测试人员和开发者介入需求探讨需求探讨以研究组的方式开展最有效率。
研究组，须要包括测试人员和开发者，这样可以愈加轻松定义可测试的需求，将需求分组并确定优先级。
同时，该种方式也可以充沛应用团队成员间的互补个性。
如此确定的需求往往比开需求探讨大会的方式效率更高，大家更生动，介入感更强。
3. 编写可测试的需求文档开局就要用“用户故事”（User Story）的方法来编写需求文档。
这种方法，可以让咱们将留意力放在需求上，而不是处置方法和实施技术上。
过早的提及技术实施方案，会降落对需求的留意力。
4. 多沟通，尽量缩小文档任何名目中，沟通都是一个经常出现的疑问。
好的沟通，是矫捷开发的先决条件。
在圈子外面混得越久，越会强调良好高效的沟通的关键性。
团队要确保日常的交换，面对面沟通比邮件强得多。
5. 做好产品原型倡议经常使用草图和模型来说明用户界面。
并不是一切人都可以了解一份复杂的文档，但人人都会看图。
6. 及早思考测试及早地思考测试在矫捷开发中很关键。
传统的软件开发，测试用例很晚才开局写，这造成过晚发现需求中存在的疑问，使得改良老本过高。
较早地开局编写测试用例，当需求成功时，可以接受的测试用例也基本一块成功了。
