何為QIR，就是快速原型Quick Prototype 迭代Iterator 重構Refactor.
敏捷軟件過程大家都叫了這么多年了，Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (Agile UP or AUP), Crystal, and Dynamic Systems Development Method (DSDM)每一種其實都是針對特定的問題提出的。當然每一種方法都有他的用武之地。
不過我覺得敏捷最核心的概念，或者說需要實踐的地方只有三個，那就是QIR。
只要這三個概念能掌握好，其它的敏捷方法就可自然貫通。
1 快速原型
原型大家都做過，通常的意義就是設計程序的界面。有人用Visio畫原型，也有人用HTML設計簡單的頁面。
但是這樣設計出來的原型通常意義不大，我這么說的意思是，通常這些設計好的界面圖對項目的真正開發只能起一個很小的參照。光是這樣的原型是不夠的。
什么是快速原型？為什么說需要快速原型?
在這個對項目進度要求越來越高的時代，軟件開發周期內的每一步都必須發揮最大限度的作用，這就好比起跑時候的起跑動作，賽車發動時候的占位等等。每一步都要為后續步驟做鋪墊。
快速原型開發不僅僅是設計界面，而是通過在設計界面的過程中，也能完成所有系統數據表的設計以及編寫好常用的測試數據。也就是說設計界面的時候，心中要想到這些數據在表中如何存取。設計表的時候也要想到這個結構在界面上怎么呈現最舒服。原型還需要有簡單的代碼支撐，這樣我們就可以看出來這個原型那些設計的不合理。
帶著這個思想去做，我們發現在原型設計階段，我們就已經開始對原型進行迭代和重構了。
這樣原型就不簡單的是畫界面了，原型就要求把框架，數據庫全部都連上。如果我要展示一個表單，不能僅僅畫一個html的表單，而要實際的把里表的測試數據從庫里面調出來。這樣就會發現，原來某些表單項可以通過冗余字段來實現，某些表單項必需要彈出窗口來選擇。
當然這樣對原型設計者的要求就比較高，原型設計者必須熟悉常見的界面設計模式，數量掌握各種軟件，包括桌面，web的界面設計技巧，還要懂得數據庫設計的知識等等。對于大項目為了實現快速原型設計，這個工作就不是一個人能夠完成了。因此整個團隊必須對設計的每一步過程都共享。團隊必須能毫無成見的交流，leader要能采納好的建議，給出最佳決策。
人們都說好的開始是成功的一半。其實好的原型也應該是整個項目成功的一半。
2 迭代
迭代要實現敏捷，首先要具備的因素就是快，如果沒有快，迭代就是增加你額開發成本。
既然要談到快，一個重要的前提就是，項目最初的模塊調最核心的做。代碼用最簡單的實現方法。
例如一個CRUD有四個操作。既然要快，我們就只實現CR。代碼中如果需要復雜數據結構的，我們先用一個長的hash表來存儲。查詢界面我們先給出幾個固定的測試值。
這里就對項目完成的監控提出了考驗。因為我無法按要求每天完成n個模塊。也許有人會覺得這樣不好。但是，請你想想，一旦你開發過程中客戶需求發生變化了，你需要重新修改字段，界面的時候，正因為原來的設計都很簡單。因此可以大方的將那些代碼拋棄。你付出的總的代價就最小。
所以這里關鍵要有一種放的下的勇氣，告訴你的代碼，先這樣吧，I'll be back!
3 重構
重構和迭代其實是密不可分的。其實QIR的三個過程都是密不可分的。對一個你從來沒有接觸過的行業來說。你開發的產品一定要經過兩次大的重構，主體架構才會趨于穩定。不要問我這個兩次是怎么得出來的。等你自己做過你就會明白，這是兩種不同思維的人在一起碰撞產生的。
用最簡單，最愚蠢的方法，把程序先運行起來。等閑暇的時候再慢慢過來重構。當然也不能太愚蠢，你的初始代碼也必須具有一定的可重構性，也就說也要遵循一些基本的模式。舉個例子，如果你的CMS的導航結構SEO的URL設計的很好，那么你后面重夠的時候就會很方便。
當然不管什么方法論，如果你完全沒獨立開發過項目，那都是白談，因為你不可能理解其中的精髓所在，只有你親身體驗了，你才會明白其中的奧妙。
團隊之間必須積累開發經驗庫，所有以前開發過的項目，模塊都應該可以共享，可以讓每一個人作為參照。
每一個人都必須具備廣才，就好比一只足球對，如果每個位置的人都可以進攻，那么這個球隊就相當讓人敬畏，例如荷蘭的全功全守。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
