這本書買了有一段時間了，可是最近才算真正過了一遍，書不算厚，300頁左右，但是看完後感覺收穫頗多。
這本書並沒有教給你具體的建模技術，比如uml，模式等的使用，或者手把手的教你乙個例子，而是首先提出敏捷建模的原則，實踐來解釋什麼是敏捷建模和其關鍵部分。然後展開說明敏捷建模中各製品，和統一過程，xp的結合等。
對於我自己來說讀這本書最大的收穫不是獲得了某些技術，而是明白了乙個道理，在軟體開發過程中，對「度」的掌握的重要，從傳統的重型軟體開發過程到現在的敏捷開發，最重要的不是測試驅動，不是結對程式設計，最最重要的是對軟體開發中的「度」的重新定義，在過多過少之間尋求平衡。我們常提的「過度設計」，「過多的文件」等等，無一不是對「度」的掌握出了問題，而這些東西本身並沒有過錯，相反它們的作用是無法替代的。
對「度」的掌握直接延伸到「合適」，「沒有最好，只有更好」，根據自己的專案規模，團隊組成，行政組織機構，找到適合自己的過程。否則即時你現在很「敏捷」了，但是仍然面臨專案失控的危險。
「過猶不及」，「物極必反」，要保持在平衡點上實在是一種理想，在軟體開發中只能時時的調整方向，雖然不是最正確的方向，但是保證我們不要偏離太遠。
敏捷開發讀後感
經過閱讀這些文章，我對於敏捷開發有了初步的了解。總的來說呢，敏捷開發 是一種以人為核心 迭代 循序漸進的開發方法。就是將乙個大專案進行分割，將其分割成為乙個乙個分別獨立而其中又存在聯絡的小專案，每乙個小專案由不同的小組分別完成。由於這種較為靈活的模式，使得敏捷開發與其他軟體開發型別相比在適應性上有了...
《SCRUM敏捷專案管理》 讀後感
學習實踐了一段時間scrum，遇到一些問題，最近在閱讀 scrum敏捷專案管理 一書。略有收穫。記錄下來，以供日後回顧與共勉。專案管理的核心原則 不同型別 背景的專案所採用的專案管理方法可能是截然不同的，沒有最好，只有更好，要靈活使用，管理方法也是工具而已 專案管理，應以成果為導向，而非過程為導向。...
關於敏捷開發的讀後感
完成一項工程時，我們常常會有這樣的感受 我們的解決方案要根據顧客的需求和現實情況的需要，不斷更改。採用傳統意義上的瀑布式開發，往往要花費更多的時間。最重要的原因就在於它相比於極限程式設計 敏捷開發，對於團隊合作的重視程度不夠，自由度也相對較低，導致效率偏低。在實際做專案時，我們應該清楚，我們做工程的...