我沒有什么敏捷、什么XP編程的概念，所以我這次的格斗沒有套路。
從去年開始我擔任了項目經理一職，已經負責公司的三個項目的開發和實施了。
我可以籍以此發表我的看法。
本主題內容是極限開發
首先說說我概念當中的極限開發。
項目特點：面向應用、面向服務的中小企業應用。
先哆嗦一下業務需求：
我們在實際調研企業現狀后，最大限度的了解與我們應用范圍相關的實際業務。隨后進入業務需求分析，其實就是抽象實際業務到軟件功能設計。同時考慮到我們應用
范圍外的業務，用戶可以不太關心這一塊，但是我們必須得做。最終的業務需求分析由公司內部評審，（盡管我們的管理不完善，但是我有權力讓什么也不懂的領
導參與），再與客戶去交涉。直到取得最終評審。
極限開發之前：
我們首先要做概要設計，其實是對前業務需求分析的細化，當然這文檔是面向業務的，這個文檔是修改最多的，所以在你開始寫這個文檔以前一定要做好版本管理（包括有效版本的管理）。
概要設計長話短說吧，就是對企業實際業務管理的理想模型，是盡可能的去理想（理智的想象，而不是單純的想象），同時不能夠把軟件的功能劃分在合同的需求功能之外（這個一定要把握一個度的問題）。
概要設計是一個相對漫長的過程，這個過程馬虎不得，一定要有耐心說服用戶和有權力的領導，說什么能做，什么不能做，我們為什么這么做，以及變通的業務實現等等。
極限開發之數據庫設計篇
大家可能不理解，為什么我首先要對數據庫進行設計呀，這個完全和我的習慣有關。（我的地盤我做主）
在對以上概要設計完以后，我的心理就對實際的軟件功能有具體的描述了，當然這個是我最清楚了，我在寫概要設計的時候會把這些映射成軟件的具體實現，并且使
用一些工具比如VISIO在寫完概要設計的實際業務時，我會把軟件的實現圖、邏輯圖同時畫出來，害怕以后沒有時間來想這些，呵呵。
所以在其后的工作當中，我對軟件的具體實現就胸有成竹了，所以我直接進行數據庫設計。
數據庫設計我使用DB Design，這個工具很好用，我在數據庫設計時有兩個準原則：
原則一：數據庫表對應程序功能模塊，一個模塊一個前綴，并且如果無太多關系的業務模塊對應一張表，并且這些表沒有關聯關系，都是獨立的。
原則二：所有的表如果無復雜關系都使用統一的UUID做為主鍵，同樣，如果處理同樣的事務，字段名能夠統一的話就統一命名，或者有統一規則生成等。
根據以上原則，我的數據庫表沒有想象當中的復雜，所以在程序實現時就不用考慮數據庫間的關系。
極限開發之程序實現－統一增加、刪除、修改數據庫
數據庫設計完以后，就建立映射成實體，并根據現行的軟件架構實現統一的對數據庫的增加、刪除、和修改的操作，比如現在的STRUTS+SRPING+
HIBERNATE的架構，我根據數據庫表，生成對本數據庫表的增加、刪除和修改的類接口，剩下的工作由下面的員工完成，（很想自動生成，但沒有時間來寫
這些東西。以后這個東東肯定會有人發明）
極限開發之程序實現－封裝業務邏輯層
我一般使用VISIO或者現在的WEB FLOW給手下的員工畫出程序實現方式，讓他們來完成，我的工作是檢查他們的代碼是不是符合規范，是不是能夠符合
業務需求，所以這個時間我的主要工作是質檢和修改程序實現的業務邏輯，（有些剛剛畢業的大學生，你要給他講明實現的業務關系呀，還不如告訴他你應該往哪個
表插入什么數據來得快，這是一個怪圈）
極限開發之程序實現－關鍵業務實現
關鍵業務的實現是至關重要的，這個我一個可能是不行，而且可能當時用戶的需求在改變或者改進等，所以我就要找一個比較實在、能力比較強的員工來擔任這個職務，要盡可能的給他講明實際的業務和用戶需要的效果和目的，說不定他還能幫助你的思維呢。
這個是個重要的環節，所以生產的重點就是這里，在最復雜的業務邏輯時，對程序的處理，一定要畫個VISIO或者什么圖告訴員工每一步的實現如何做，包括很
多的錯誤處理等。如果你在這里偷懶了，說明你這個項目的有很多的隱患在其中，這個工作比較艱巨，變數也多，需要多多鼓勵員工。
極限開發之程序實現－單元測試
單元測試不是很嚴格，由公司相關人員測試，不過經過我質檢過的代碼，一般沒有太多問題。
極限開發之程序實現－業務測試
根據項目的實際業務來測試，由我和能力很強和人來測試，最后由測試人員來測試，
極限開發之用戶試運行及上線
這個就不用說了，要用服務的意識來幫助客戶來認知這個東東，就好象到理發店讓小妹妹給你按摩一樣，不要害羞。也好象很累了到冼足浴室一樣，無微不至引導消費。
我的這三個項目分別是庫存管理+財務管理、EAI項目和CRM+服務。
用人最多的時候不超過6人，開發周期沒有超過2個月的。
庫存管理+財務管理 6人 1.5個月
EAI項目 3人 20個工作日
CRM+服務 5－6人 不到兩個月
所有項目均是新寫。