只關註產品
[假設]
產品體驗為王、口碑致勝，否則就是垃圾（客戶或市場是判斷的唯壹標準)，但開發者往往只關註代碼邏輯，技術骨幹也往往只關註框架模式，未站在用戶角度去深入體驗和精致要求，盲目或無所謂地遵從產品設計，可實際上產品設計本身就是反復探索、試錯和試驗的過程，於是形成了開發與產品設計的森嚴壁壘，並在反復證錯的過程中，進壹步激化了產品和開發的矛盾，營造出料壹種產品惡性進化的氛圍。
[原則]
把所有註意力只需且必須集中在產品上
無縫交互驅動開發
[假設]
客觀上產品都是逐漸成長的，阻礙這壹過程的就是必須鎖定特定版本的傳統開發模型，即特定需求驅動開發，特定時間、地點和人員進行壹種蹩腳的產品發展的推進，溝通和反饋這壹過程淹沒在時斷時續的交互障礙中，遑論隨需而變。
[原則]
不限制時間、不限制地點、不限制人員的溝通和反饋
極限叠代
[假設]
用時間和成本的方式簡單的評價軟件開發速度和軟件階段版本毫無意義，雖然面對用最少時間和最低成本盡快叠代出壹個可供溝通和反饋的試錯版本直到壹個有基本價值的穩定版卻是日益明確的要求，因為叠代速度的量化標準模糊不堪，而且每次叠代的結束由於其他環節跟不上而帶來較大的中斷並不能有效觸動進壹步叠代的開始。
[原則]
確保連續溝通和反饋的快速叠代
粗暴式簡單
[假設]
簡單往往最容易理解，只有理解才有可能更好地開發、使用、推廣、維護和發展，軟件系統做到足夠的“簡單”，往往最穩定和高效，只有最簡單穩定的東西才有可能被使用；同時，簡單往往最小工作量，少做就是最好，因為可能需求不清楚、場合沒必要、使用有爭議，不能穩定化的需求盡量延後，畢竟，開發者對需求的把握、系統的把握也是壹個成長的過程，不可能壹步到位，否則容易帶來巨大爭議和質量問題。但什麽才是簡單，每個人的秤都不壹樣，簡單之道不簡單！
[原則]
真正的簡單 ，要簡單到粗暴，可以不限特定人、人員數目和技術細節的簡單化
四輪驅動質量控制
[假設]
傳統編程模式下如果沒有顯式規範並加以培訓的代碼必將遵循墨菲定律--反其道而為之，而編碼人員個體的惰性、倦怠、得過且過和自我否定勇氣不夠，程序代碼往往存在眾多質量異味， 在對速度又有額外要求時將更容易忽略眾多潛在風險而形成產品的炸點；實際上，沒能監督約束的代碼肯定會累積較大風險，而風險代碼之間相互依賴將進壹步放大風險，傳統代碼評審耗時費力且難以全面兼顧，而互審由於責權利問題更是不能落實，最終反復叠代後無法繼續重構而失去控制只能推倒重來！
[原則]
軟件規範顯式自動約束，標準質量監查無縫滲透，代碼完備測試透明累積，同壹品次代碼杜絕依賴，從四個方面自驅動代碼質量控制
自動化質量跟蹤
[假設]
引入任何改變，不管大小，則bug必然存在，且可能非開發者的直接原因引起，隱藏很深，危機重重，所以，任何代碼改變，如果沒有相應措施進行確認，普通開發人員將毫無信心，直到改變的勇氣喪失殆盡！
[原則]
任何代碼改變必然伴隨壹次完整的自動化質量檢查並形成質量跟蹤報告
復用同步和節制
[假設]
復用雖是提升品質的根本，但低質量復用很容易引入並帶來嚴重問題，而且復用容易過渡追求而耗費更多時間且最終變成雞肋，復用壹旦跟創新結合更容易變成過於創新，少量使用後往往尾大不掉難以否定。
[說明]
在復用接口基礎上，按軟件本身階段同步驅動復用化，在產品非正式版前節制通用化投入！
可控的開放
[假設]
只要是不開放（無關免費）的東西，中間隱藏的單點故障就會存在，甚至有可能就是放不開的垃圾，除非有良好的服務支持；因此，運行時要避免封閉的中間件（無關信任），避免對操作系統的限制（能靈活、快速安裝部署升級），如果暫時存在則至少解耦可替換，從而確保完全的可控性。
[原則]
要保持開放--全松耦合但建立耦合質量標準
***同設計和統壹路線
[假設]
技術模式和實現路線不被認可，哪怕再“好”，往往也存在不接地氣的毛病，是必須拋棄或說服的，否則，著急的落地和推進，將導致眾多的問題，這些問題不被理解將進壹步放大問題，從而進入惡性循環；尤其是對接其他系統的，如果為了趕時間，導致很多技術路線未完全統壹，如字符集、數據庫、應用整合、數據整合...，這將形成“致命”的軟件缺陷；實際上，如果開發團隊技術定位和框架偏向未預設，應盡量保持大部分開發者的習慣，理解公司高層心理定位，爭取開發團隊的完全理解。
[原則]
***同進行框架、路線和構件的設計，尊重現實、優先復用、融合分歧和分解矛盾以統壹路線，達成相互理解和***同期望
服務是產品的延續
[假設]
傳統的交付多是階段性交付，從而造成產品成長的割裂。
[原則]
產品的真正開始是對產品使用的支持
改變思路才有出路
[假設]
傳統的開發過程，我們壹定會發現：無意義的重復帶來厭倦，按規範手動調整多個地方必定帶來壹致性沖突，可選擇的越多就將出現自由選擇障礙，無監管的自由將帶來破壞即互為覆蓋破壞，對同壹事物的無邊界的修改將導致責任不清分工困難，沒有評審的口頭規範將逐步失控，熬夜等過度加班等將導致節奏失調直到失控，不能對全部進行整體認可、參與而負責的往往就會相互推諉而千瘡百孔，不能全部把握的就會帶來越來越強的抵觸，人為的層次遷變和錯位將隨著時間的流失而變得越來越成本巨大，沒有經過第三方檢驗的代碼充滿憂慮，以人為本和充分尊重等口號毫無意義...
[原則]
思想決定命運，只有根本改變開發者的開發這壹個行為，建立起對傳統開發顛覆性的開發體系，才有可能重塑開發者的定位（擺脫碼農的命運）--完全平等和相互尊重 ，才有可能真正積極、主動和有力地面對雲時代的挑戰。
雲軟件過程管理
[假設]
人有惰性，代碼逐漸熵化，傳統管理往往脫離實際。
[原則]
對開發過程要實施連續不斷的管理--自動化開發過程的管理