good
勝過normal
個體和互動
過程和工具
可以工作的軟體
面面俱到的文件
客戶合作
合同談判
響應變化
遵循計畫
個體和互動勝過過程和工具
人是獲得成功的最為重要的因素。團隊的構建要比環境的構建重要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。
可以工作的軟體勝過面面俱到的文件
文件固然是有用的，但過多的文件可能會比過少的文件更糟。因為編制眾多的文件需要大量的時間，同步這些文件同樣需要大量的時間，一旦文件與**失步，那麼文件就會出現誤導。最好的培訓方式就緊挨著他們坐下來幫助他們，把知識傳授給他們。所以最好的兩份文件就是**和團隊。
客戶合作勝過合同談判
成功的專案需要有序、頻繁和客戶反饋。不是依賴於合同或者關於工作的陳述，而是讓軟體的客戶和開發團隊密切地在一起工作，並盡量經常地提供反饋。
響應變化勝過遵循計畫
響應變化的能力常常決定著乙個軟體專案的成敗。計畫不能考慮得過遠，因為商務環境隨時可能變化，而且一旦客戶看到系統的運作，需求可能會被修改。即使一切都確信不會改變，我們仍然不能很好地估算出開發需要的時間。最好的策略是：為下兩周做詳細的計畫，為下三個月做粗略的計畫，再以後就做極為粗糙的計畫。
我們最優先要做的是通過盡早的、持續的交付有價值的軟體來使客戶滿意
即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢
經常性地交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好
在整個專案開發期間，業務人員和開發人員必須天天在一起工作
圍繞被激勵起來的個人來構建專案。給他們提供所需要的環境和支援，並且信任他們能夠完成工作
在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談
工作的軟體是首要的進度度量標準
敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持乙個長期的、恆定的開發速度
不斷地關注優秀的技能和好的設計會增強敏捷能力
簡單－使未完成的工作最大化的藝術－是根本的
最好的構架、需求和設計出自於自組織的團隊
每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自已的行為進行調整
敏捷軟體開發 原則 模式與實踐 之敏捷實踐
參與公司的敏捷開發也有一段時間了，還沒有系統的學習過敏捷開發。比如早上的站會，每個月的迭代會，還有自己領取任務去開發故事，這些都是敏捷開發的流程之一。敏捷開發需要不斷的學習，不斷的實踐。現在開始寫一些關於敏捷開發的部落格。一 敏捷聯盟 1 個體和互動勝過過程和工具 乙個優秀的團隊成員未必是乙個一流的...
敏捷軟體開發實踐 概括
應朋友之邀，我準備寫一組文章關於敏捷軟體開發的實踐，也幫助廣大沒有用過agile的或者只停留在書本內容上的朋友親臨敏捷軟體開發這個驚心動魄的歷程。所謂敏捷，書本上有很多的介紹，我也不想重 明輪子了，反正就我的理解，敏捷的精髓就是面向變化，敏捷這個詞語，我最早遇到是出現在玩各種遊戲中，所謂的 力量型 ...
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...