本文目录导航：
矫捷开发和软件工程能否矛盾，为什么
如今，矫捷开发是一个十分抢手的话题，很多机构的咨询师、很多程序员对“矫捷”曾经到达了一种近乎宗教的狂热的水平。
谈到软件开发，必谈矫捷，必谈TDD，好像不用这个方法，就必定是效率低下的团队和开发方法。
我团体没有细心钻研过矫捷开发（准确说，没有钻研过那几个牛人提出的矫捷开发）。
但是，公司目前在鼎力推进矫捷，而且我去年的一个关键名目也是依照公司推进的矫捷方法启动的（听说，公司从某个驰名的咨询培训机构挖来人，帮咱们做名目治理培训和矫捷推行）。
这篇文章中，我只想谈谈自己对这个方法的感触和想法。
我的总的观念是：矫捷开发是反软件工程的。
我抵赖，矫捷开发中有些通常形式是很好的，值得排汇。
例如在矫捷开发的圣经“矫捷软件开发-准则、形式于成功”一书中，很多设计准则，如“繁多职责”、“开明敞开”、“依赖到转”等，它们只是普通、通用的设计准则，应该运行在任何的开发方法中，这些准则并也不是只要矫捷开发方法才干用，在任何的开发方法中都可以、应该经常使用。
但是，矫捷开发作为一个方法论，则是软件工程的发展。
矫捷开发，更像是软件工程出现之前，小作坊式的软件开发方法。
什么是传统的小作坊式的开发？它最关键的特点包含：1.几团体组成一个小组（小作坊），这个小组中的人独特成功软件的需求、设计、开发和测试。
小组中有便捷的分工并重，但其实每团体都会介入每个阶段。
用矫捷的话讲，这就是产品人员、软件工程师和测试工程师严密配合的一个小组。
工程师须要介入需求剖析、测试工程师须要介入产品的设计、产品人员要不时的经过以后已有的“原型”来开掘、更改需求，当然，这是由于“产品人员无法能在一开局就看到一切的需求”。
2.在这个小组中，文档只是用来辅佐交流的，人们更多的经常使用行动交流来明白一些细节疑问或许是存在歧义的疑问。
文档不许要做到“面面具到”。
当然，这也是矫捷所推崇的。
3.没有严厉的开发环节控制。
4.须要极速的接纳并照应需求的变动，由于需求是不时在变的。
咱们可以看到，这也是“矫捷开发”方法论的关键特点。
那么软件工程的指标是什么？软件工程获取人们的注重真实IBM OS360开发之后。
人们意识到，软件系统曾经越来越复杂，越来越庞大。
上方提到的这种开发方法暴显露越来越多的疑问：对程序员要求过高、软件品质难以保障、软件开发成功后的保养老本渺小等等。
为了处置软件开发的这些疑问，人们自创了传统的工程名目的实施。
建造一个大厦、建造一辆汽车等，这些工程不比软件开发便捷（准确讲，建造一个大厦要远比咱们经常出现的大少数软件复杂），但是这些工程却能被可控地实施并获取品质良好的结果。
由此，人们提出了“软件工程”，它的首要指标，也是最基本的指标就是“将软件开发工程化”。
剩下的疑问是，怎样才干“工程化”？咱们依然可以从修建业和制作业自创他们成功的方法。
咱们上方就来看看工程化的最关键的两个方面。
严厉的环节控制。
先做什么，后做什么，十明显确。
比如先做需求剖析、再做设计、再做结构施工、再做墙壁于管道等。
并且，环节中的每一步都要有确定的（至少在本次工程中不变的）产出，并经过验收。
这个产出的担任人和验收担任人都要在验收报告中签字。
假设这个产出在同一个工程中必定出现变动，那么，这就是一次性工程意外，依据意外的大小，责任人须要负“被开革”到“刑事立功”等不一的责任。
例如，咱们要建造一个20层高的大厦，当主设计师成功结构设计后，他会对这份设计文档签字担任，验收者会在验收报告签字。
大厦的主结构就会依照这份文档中的结构启动建造。
假设到名目的中期，正在启动管道、线缆的部署时，发现，主结构是有疑问的，中央主梁无法接受足够的扭矩。
此时，设计师和验收者的一句“咱们无法在一开局就看到这个，在下一次性迭代中会修复”是相对不会被接受的。
他们要担任任。
雷同，假设此时产品人员上来说，客户的需求变了，是25层而不是20层。
而要到达这个要求的代价是：主设计师就须要将主梁的直径参与20%、局部修建资料须要被交流......我想，关于这种产品人员而言，只能通知他，你曾经在需求文档中签字了，你须要担任抵偿包含返工、资料、工期等方面的一切损失，你该辞职辞职，该坐牢坐牢。
疑问是：为什么软件不能这样呢？是由于软件修正的老本低吗？理想曾经证实了，软件修正的老本不低（计算上后续保养的老本）。
严厉的规格说明。
此处，我用了“规格说明”，其实就是咱们所说的文档。
文档应该做到详细、严厉。
举个例子，在机械制作中，常罕用到螺丝。
在一个机械的设计文档中，会详细指定每个螺丝在规范环境下（比如0摄氏度、5%的湿度、一个大气压）的直径、螺纹间距、螺纹高度、以及热收缩系数等参数，担任制作螺丝的部门，拿到份文档，甚至都不用见设计师自己，就可以制作出合格的螺丝。
这外面，文档才是关键的物品。
哪怕设计师换了、原来的螺丝部门的工人走了，只需有这份文档和合格的工人，就必定能造出与原来一样的螺丝。
我意识一个做配件设计的人，他曾经通知我“你知道配件的bug为什么这么少吗？我不是在用verilog设计配件，我是在用文档设计配件。
拿到我的文档，任何一个懂verilog语法的人都可以编码出合格的产品。
”这就是文档的力气。
只要设计文档才干保障在原本设计、成功一个系统的人走后，后续的人能够很容易的继续保养、裁减这个系统。
上方就是我了解的软件工程。
这个环球上很少有真正的“奇观”，咱们以为的奇观，基本上都是平凡的工程。
矫捷开发形式和瀑布模型啥意思
瀑布模型（Waterfall Model） 是一个名目开发架构，开发环节是经过设计一系列阶段顺序发展的，从系统需求剖析开局直到产品颁布和保养，每个阶段都会发生循环反应，因此，假设有消息未被笼罩或许发现了疑问，那么最好 “前往”上一个阶段并启动适当的修正，名目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型称号的由来。
包含软件工程开发、企业名目开发、产品消费以及市场开售等结构瀑布模型。
矫捷开发形式是一种从1990年代开局逐渐惹起宽泛关注的一些新型软件开发方法，是一种应答极速变动的需求的一种软件开发才干。
它们的详细称号、理念、环节、术语都不尽相反，相关于非矫捷，更强调程序员团队与业务专家之间的严密单干、面对面的沟通（以为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地顺应需求变动的代码编写和团队组织方法，也更注重做为软件开发中人的作用.
螺旋式和矫捷式软件开发形式有什么不同
螺旋开发，1988年，巴利·玻姆(Barry Boehm)正式宣布了软件系统开发的“螺旋模型”，它将瀑布模型和极速原型模型联合起来，强调了其余模型所漠视的危险剖析，特意适宜于大型复杂的系统。
“螺旋模型”刚开局规模很小，当名目被定义得更好、更稳固时，逐渐发展。
“螺旋模型”的外围就在于您不须要在刚开局的时刻就把一切事件都定义的清分明楚。
您轻松上阵，定义最关键的配置，成功它，而后听取客户的意见，之后再进入到下一个阶段。
如此不时轮回重复，直到获取您满意的最终产品。
矫捷软件开发又称矫捷开发，是一种从1990年代开局逐渐惹起宽泛关注的一些新型软件开发方法，是一种应答极速变动的需求的一种软件开发才干。
它们的详细称号、理念、环节、术语都不尽相反，相关于“非矫捷”，更强调程序员团队与业务专家之间的严密单干、面对面的沟通（以为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地顺应需求变动的代码编写和团队组织方法，也更注重软件开发中人的作用。
