如果QIR能夠換回專案成功,我願用一生敏捷

如果QIR能夠換回專案成功,我願用一生敏捷。

何為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設計的很好，那麼你後面重夠的時候就會很方便。

當然不管什麼方法論，如果你完全沒獨立開發過專案，那都是白談，因為你不可能理解其中的精髓所在，只有你親身體驗了，你才會明白其中的奧妙。

團隊之間必須積累開發經驗庫，所有以前開發過的專案，模組都應該可以共享，可以讓每一個人作為參照。

每一個人都必須具備廣才，就好比一隻足球對，如果每個位置的人都可以進攻，那麼這個球隊就相當讓人敬畏，例如荷蘭的全功全守。呵呵

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1423772