09年寫在的文章，現在轉過來。
敏捷的價值觀如下：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
很多人在不理解敏捷的情況下，簡單的從字面去曲解和批駁敏捷。我就從我的敏捷實踐出發談談我的感想。
1、「個體和互動勝過過程和工具」。
我認為這條主要是針對流程和管理上的觀念。過程和工具是很重要的，但是不能以為有了工具和流程就能無往不勝，而忽略了對執行流程和使用工具的主體——人的關注。德魯克早就指出，對知識型員工的管理，不能簡單的和生產線上的工人一樣對待，而是需要其自我管理。這就需要知識型員工在工作過程中積極的和其他人之間互動，而不是照章辦事、機械執行。只有充分的交流才能掌握需求，才能彼此配合，才能開發出優秀的軟體。敏捷不排斥工具，在敏捷過程中，工具往往具有極其重要的作用，比如ci和tdd對工具就非常依賴。
2、「可以工作的軟體 勝過 面面俱到的文件」
敏捷從來都沒有說不要文件，注意定語。我的理解是不要追求面面俱到的文件，最終的目標應該是可以工作的軟體。文件可以分成兩部分，需要提供給客戶的和內部開發需要的。對於提供給客戶的文件，這是交付的一部分，必須要有的，大家應該沒有異議（這是資料部門的工作）。而對於內部的文件，必要的文件還是必須的，具體需要什麼文件應有開發團隊來決定（例如介面文件、規格書等）。從價值的角度分析的話，最終產生價值的是可以工作的軟體，工作的中心和焦點一定要是它。對於客戶不產生價值的工作都是對資源的浪費。
3、「客戶合作勝過合同談判」
現在的社會節奏很快，軟體需求的變化也很快（有時是因為客戶的需求是逐步明晰的）。如果用合同來約束客戶，往往是雙輸的結果；客戶沒有得到實際需要的，開發團隊按照合同辦事沒有問題，但失去了未來的客戶，勞動沒有產生價值，沒有成功感。只有擁抱客戶需求的變化才能得到雙贏，當然合同也要根據實際情況來調整（這是前提）。實際情況是：這一點可操作性太差，除非是內部客戶否則外部客戶很難參與到專案開發。比較普遍的做法是把marketing、se作為專案的客戶代表，或者邀請客戶參與你的sprint demo。
4、「響應變化勝過遵循計畫」
世界上永恆不變的恐怕就是變化了，想靠制定計畫來完成軟體開發太難了（軟體開發已經達到了非常複雜的程度，制定詳細計畫非常困難，當然生產線上的計畫可能比較簡單、準確）。與其耗費大量人力物力去制定乙個並不可信的計畫，還不如隨時根據變化做出相應的響應。當然初期會制定乙個初略的計畫，然後根據實際情況去不斷的調整和變化。完全按照作戰計畫去指揮的將軍一定會失敗，所以才會有「將在外君命有所不受」，才會有與時俱進。
由價值觀引出的12條敏捷原則：
我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意。
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。
工作的軟體是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度。
不斷地關注優秀的技能和好的設計會增強敏捷能力。
簡單,使未完成的工作最大化的藝術,是根本的。
最好的構架、需求和設計出自於自組織的團隊。
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。
參考文章
我對敏捷價值觀和原則的理解 待續
敏捷的價值觀如下 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 很多人在不理解敏捷的情況下，簡單的從字面去曲解和批駁敏捷。我就從我的敏捷實踐出發談談我的感想。1 個體和互動勝過過程和工具 我認為這條主要是針對流程和管理上的觀念...
敏捷的原則和價值觀
敏捷宣言中列出的敏捷價值觀和原則，雖然不屬於scum框架的內容，但可以幫助我們更好地理解 scrum 的起源以及為什麼要採用 scrum 敏捷原則 01 我們最重要的目標，是持續不斷地盡早交付有價值的軟體以使客戶滿意。02 擁抱需求變化，即使是在開發的後期。為了客戶的競爭優勢，敏捷過程掌控變化。03...
我的價值觀
首先談談我對自己的認識，我是2013年大學畢業，本科專業數學與應用數學，安師大2009年數學專業招了240人，我就是其中之一，為什麼報數學系呢，只因為我高考數學考了138分，那時候的自己不知道什麼是喜歡和不喜歡，沒有興趣沒有愛好，用現在的話說就是很傻很天真，就知道學習，考試，得分。學習幹什麼，為什麼...