敏捷開發最注重的是人，或者說個體。目標是提高個體的主動性，提高產出效率。敏捷開發要求團隊一起工作，甚至還有客戶。結對程式設計。迭代交付，三周為乙個週期，每個週期都發布可用地、經過測試的**。2到5個週期後進行一次發布。敏捷開發積極擁抱變化，主要依靠**重構來配合變化。
敏捷開發的優點在於發布時間短和響應需求變化，敏捷開發的缺點是可操作性差。實踐者們常常走入各種各樣的誤區。根本原因還是人，人的主動性還有在軟體開發中的行為受各種各樣因素的影響。
在需求分析階段準備兩份文件。乙份使用客戶的術語表達客戶的故事，另乙份是使用軟體術語表達軟體實現的故事。需求分析人員是客戶和專案組之間的橋梁，是客戶和軟體開發人員之間的橋梁，
十分類似於科手術過程，軟體開發團隊需要乙個主刀醫師，即軟體架構師。軟體架構師保證了整個軟體的思想和架構是乙個主體。而不是零散的，拼湊的。這有利於開發和維護。軟體架構師在乙個團隊裡一般只有乙個，或者乙個架構師團隊由其中乙個人作為領導。這樣保證了整個軟體系統的一致性。軟體架構師工作的主要依據是經驗。在軟體開發過程中，人是最重要的因素，而責任、權利和利益是保證這個因素發揮作用的關鍵。負責文化是人類社會活動中必須具備的一種文化。團隊往往成為不負責任的推辭。建立負責制度的目的不是為了懲罰，而是通過利益損失的形式，表明乙個事實：沒有金剛鑽，別攬瓷器活。也是質量保證的乙個重要推動力。關於第3章 關於需求的思考
需求就像一束光的源點，失之毫釐，謬以千里。沒有人不重視需求問題，可是，有多少人能講清楚解決需求問題的思路呢？捫心自問，需求跟蹤矩陣和需求變更委員會提公升了我們多少信心呢？
本章嘗試給出解決需求問題的方法。這個方法的邏輯很簡單，首先，我們需要準確表達需求，術語和講故事是兩種好的輔助手段；其次，我們要和客戶一起，推動需求的變化，需求變化不是成本的代名詞，被動接受需求變化才是吞噬成本的罪魁禍首。
簡單之美 軟體開發實踐者的思考
簡單之美 軟體開發實踐者的思考 基本資訊 這是一次軟體開發者的心靈溝通之旅 10大社群一致鼎力推薦 內容簡介 本書不是一本關於方 的理論性書籍 儘管已經嘗試在大量的思考上進行一些理論歸納 也不是一本 關於具體技術的操作手冊。本書為讀者呈現的是作者在軟體 開發實踐中的思考和體驗，目的在於 實 踐中的問...
敏捷開發實踐（2） 敏捷軟體開發者的習慣
敏捷開發實踐 2 敏捷軟體開發者的習慣 敏捷開發的最小單位就是參與敏捷開發的個人。將這些敏捷開發者聚集起來，就形成了敏捷開發團隊。正如上回介紹的，敏捷開發是一種以人為核心 迭代 循序漸進的開發方法，它以最大可能地發揮團隊的作用為目的。根據需要，隨時改善，以降低軟體開發中的風險。敏捷開發者的態度 敏捷...
精益軟體度量 實踐者的觀察與思考讀書筆記一
風險源於不確定性，然而軟體之所以為 軟 就是由其生命週期中所面對的變化和不確定所決定的，從另乙個角度講，不確定性又是與創新如影隨形。精益軟體開發的度量體系 度量本身不是目的，是手段。在很多情況下，資料的生產者不是資料的使用者 資料的生產者沒什麼動力去分辨資訊的價值，也不關心資訊準確與否 資料的生產者...