下面我簡單介紹一下敏捷式開發的原理。提到敏捷式的開發，大概在60年代的時候，軟件開發是有計劃性的，基本是寫出來，誰也不知道什么時候能交付，大概在60年代的時候，在美國召開一次會議上頭一次提出來，軟件工程學的概念，傳統工程學通常是把項目分成三步或者四步，先把需求確立起來，進行設計構建。應用到軟件里是開始先由分析人員對需求進行分析，然后設計，架構師把整體的東西設計出來，再確定下來交給編程的團隊，編程的團隊把需求文章拿過來，照著這個再弄出來。所有的這些東西是由不同的人在不同的時間完成的。
這種開發計劃性非常強，因為你知道什么人在什么時候做什么事情。但是它會帶來很多問題，主要是軟件開發和傳統的建筑工程學有很多不同的地方，最主要的是客戶需求是不斷變化的。首先是商業軟件，市場本身是在不斷變化，客戶需求也在不斷變化，客戶不知道自己需要什么，過兩天市場一變，他的需求也變了�？蛻舯旧硭X子里并不是很清楚他自己需要什么，他只有自己最后真正看到這個軟件了，才有這個想法，這個東西是我確實需要的，但是使用起來，發現不是這樣的，我想用另外一個方式，這就給工程學帶來了很大的困難。
從工程學來講，不管需求也好、構建也好，在開始的時候改動設計非常容易，但是你如果在投入生產的時候，再進行改動，成本是非常高的。所以工程學里一個核心的概念，變化是最可怕的一件事情，從設計角度也好、分析的角度也好，不管怎么，不要變化，這樣就使成本增加。
如果我們把需求確定下來以后，按照需求一步步做，設計、開發、測試、部署，任何客戶提出任何需求，我都不管他。這種方法，作為一個綜合客戶來說，最后拿到東西，發現其實這是一年以前或者本年以前的東西，他的滿意度可想而知。
如果他滿意了，又要花半年或者一年時間，重新對這個設計分析，還是這個結果，客戶得到的永遠是他半年或者一年以前想到的東西。
敏捷式開發最核心的東西是它對變化采取的是適應性的態度，不是排斥性的。我們作為開發方法來講，不應該避免它的變化，而應該想到使變化成為輕而易舉的事情。敏捷式的開發針對一小部分進行設計測試，對每一個循環時間非常短，軟件從小到大，從很小的一點到不斷的增加擴大，而且增長的過程中是對軟件不斷修改的過程，修改不是可怕的事情，而是必須做的一件事情。
客戶可以對哪些功能開發給予優先，開發的程度可以根據市場來調整，他說這些東西不想要了，可以調整。
從另外一個角度，開發商有需求分析、設計、編輯代碼測試等等，最后交給客戶，敏捷式開發在初期也會做高層的需求分析，或者架構設計，這個設計非常粗略，非常高層，針對一小部分高層設計開發，每一次一旦得到的可以發布的軟件，一步步做下去，最后達到客戶滿意為止。最大的是客戶不用等到做完的時候，而是在每一個環節都可以讓客戶來測試使用。軟件開發的過程控制起來完全在客戶手里，由他決定開發的方向往哪里走。因為他是一個軟件開發的關鍵人。
從軟件投入使用的角度講，產品上市的時間是非常重要的。尤其是競爭非常強的行業里，你如果一個產品提前上市的話，對一個產品的作用是不可忽略的。從架構來講，它對體系架構的應征可以極大的減少風險。
迭代式開發也并不是沒有嘗試過，但是修改成分太高。我們現在可以進行迭代式開發有很多原因，最主要是我們有修改的代碼OO技術，瘦身式的管理JIT帶來的新概念，可以通過快速的反饋來提高質量。通過設計和編程可以使編程對設計形成反饋。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
