我是一個在程式路上走了五、六年的人，最近看了 Pobert Cecil Martin 的"敏捷軟體開發"，從這位軟體大師在書中內容，比對到我這些年的工作經驗，以下提到的原則對於任何有關軟體開發的所有人，都是明智的忠告，更像是金科玉律，即使你只是參於開發的業務，也可以用來比對你們的軟體團隊是否依照最有效率的方式在執行。
以下是書中的敏捷宣言原則 ，我稍微改變了內容，讓不會程式設計的人容易了解 :
個人及互動勝於流程與工具
人是最重要的因素，溝通良好的一般程式人員比超級程式人員但沒有溝通的人更好。
可用的軟體勝於詳盡的文件
過多的軟體文件比文件太少更糟，產出大量文件耗費時日，甚至得花更多時間來維持文件和程式的同步，如果不同步，它就變成巨大的謊言，成為誤導來源。
文件必須簡短，扼要。除非對文件有立即且重大的需求，否則不產出文件。
與客戶合作勝於合約談判
成功的專案需要客戶定期且頻繁的回饋，通常一開始定義的需求、成本到結束時就不再有意義，與其依賴一紙合約上的工作描述，不如規定團隊需要一起工作的合約。
回應變化勝於墨守計劃
經驗不足的管理者才會先制作一張詳細的計畫表，事實上回應變化的能力才是決定專案是否成功的關鍵，商業環境會變，當客戶看到系統開始運作的面貌後也會改變需求。我們只需要對目標有概念，只對目前的工作詳細計畫。
承上原則的作法
>業務人員與開發者必須在專案全程中天天一起工作。
>開發團隊之內與團隊之間，效率最高且效果最佳的資訊傳達方式是面對面的溝通。
>將系統切割為不能再小的可用軟體，經常交附可用的軟體，頻率可以是數週到數個月，以較短時間隔為佳。
>可用的軟體功能是最主要的進度量測方法。
>經由及早與持續交付有價值的軟體以滿足客戶需求是我們最優先要做的事。
>竭誠歡迎改變需求，甚至巳處於開發後期亦然，敏捷流程掌控變更以維護客戶的競爭優勢。
>用動機強的人來建構專案，給予他們適當的環境，充份的資源，並相信他們可以完成工作。
>敏捷開發提倡能持續的開發步調。贊助者、開發人員以及使用者應當能維持一個可以穩定而恒的步調。
>持續追求優越的技術與優良的設計，以強化敏捷性。
>簡單化－讓不需處理的工作最大化技巧－是不可或缺的。
>最佳的架構、需求與設計皆源自於自身組織良好的開發團隊。
>在規律的時間間隔中，開發團隊思考如何變的更有效率，然後據之適當的調整與修正自己的行為。
