經過閱讀這些文章，我對於敏捷開發有了初步的了解。總的來說呢，敏捷開發
是一種以人為核心、迭代、循序漸進的開發方法。
就是將乙個大專案進行分割，將其分割成為乙個乙個分別獨立而其中又存在聯絡的小專案，每乙個小專案由不同的小組分別完成。
由於這種較為靈活的模式，使得敏捷開發與其他軟體開發型別相比在適應性上有了較大的優勢。例如工程化方法對於開發專案有著詳細而又長遠的規劃，能夠有著良好的效率。但是一旦遭遇變化，工程化的方法往往需要改變很多東西來滿足新的需求。而敏捷性開發只需要將與之相關的專案稍加變動就可以實現新的需求。也就是說敏捷開發是一種歡迎變化，乃至擁抱變化的開發方法，通過迭代法改進和完善本身的專案。這種開發方式可以在很短的時間之內提供可以使用的軟體。
而敏捷開發另一大特色在於以人為核心。
為乙個共同的目標，將各人的能力融合在一起，協作創新。在乙個彼此熟悉的環境下，監控管理完全忽略不計，流動性也不復存在，能力與協作更不在話
下，每個人將自己的能力充分發揮，
得到乙個創新的專案。這就是它的另乙個優勢。
在我看來，雖然敏捷開發這種方式正在像潮水般的進軍，但其中還是有著不小的缺陷的。
首先，敏捷開發要求團隊之間有著高度的配合和默契。但是，每個人的水平都是不同的。在敏捷開發的條件下，每個人都需要匯報自己每天的工作情況。然而，在一起討論的過程中，難免會暴露某些人的能力的不足，而這則會對其造成不小的心理壓力。無論是團隊還是個人，都會受到不小的影響。
其次，敏捷開發需要極其強的溝通能力。而程式設計師往往是不擅長溝通的，這樣就使得大家之間的想法不能保持高度的一致。也就是說，某個人的想法難以百分之百的傳達給其他人，這就造成了關於專案需求上的誤解，從而導致進度的延遲。
鐵打的營盤流水的兵，只要是團隊就不可能沒有人員的流動。而敏捷開發的過程中，不可能每乙個開發人員都了解完全的客戶需求，每個人了解的就是自己專案的需求。也就是說一旦有人離開自己的崗位，如何讓他的繼任者在短時間內接替他的工作就成了另乙個難題了。
這就是我關於敏捷開發的一點自己的感悟。
關於敏捷開發的讀後感
完成一項工程時，我們常常會有這樣的感受 我們的解決方案要根據顧客的需求和現實情況的需要，不斷更改。採用傳統意義上的瀑布式開發，往往要花費更多的時間。最重要的原因就在於它相比於極限程式設計 敏捷開發，對於團隊合作的重視程度不夠，自由度也相對較低，導致效率偏低。在實際做專案時，我們應該清楚，我們做工程的...
《敏捷建模》讀後感
這本書買了有一段時間了，可是最近才算真正過了一遍，書不算厚，300頁左右，但是看完後感覺收穫頗多。這本書並沒有教給你具體的建模技術，比如uml，模式等的使用，或者手把手的教你乙個例子，而是首先提出敏捷建模的原則，實踐來解釋什麼是敏捷建模和其關鍵部分。然後展開說明敏捷建模中各製品，和統一過程，xp的結...
《SCRUM敏捷專案管理》 讀後感
學習實踐了一段時間scrum，遇到一些問題，最近在閱讀 scrum敏捷專案管理 一書。略有收穫。記錄下來，以供日後回顧與共勉。專案管理的核心原則 不同型別 背景的專案所採用的專案管理方法可能是截然不同的，沒有最好，只有更好，要靈活使用，管理方法也是工具而已 專案管理，應以成果為導向，而非過程為導向。...