? 用了3天，充分擠完了海綿里的時間，看了《輕松Scrum之旅：敏捷開發故事》這本書，覺得寫得很好，有意思，找到了當時看大話設計模式時候的感覺。
? ? 從書的題目可以看出，這本書主要是講敏捷開發的，我也是第一次接觸，理解的不好還請讀者見諒。
? ? 一、從技術角度看：傳統的瀑布模型由于在前期花費了大量時間去分析需求和準備文檔，導致在產品模型在時間上的每一次迭代都會很漫長。而這其中很可能會發生需求的不斷變化，甚至產品完成后早已和時代脫節，失去了其本應產生的作用。造成的后果很明了：用戶不滿意，而且耗資很大。
? ? 而敏捷開發顯得更為輕靈多變一些。首先，輕量級的文檔使我們不再需要準備一些多年無人問津的復雜分析和記錄；另外，對變化的充足準備使得需求的頻繁變動不再成為程序員的噩夢。
? ? 二、從組織管理角度來看，1、我們傳統的團隊開發很可能存在以下現象。如：部門之間不協調，缺乏充分的溝通，人際交流成為一紙空談；小組內各成員也常常是各自開發自己的部分，對項目整體或與自己相關的部分也不很了解；溝通渠道缺乏導致上傳下達和團隊交流出現一些不必要的問題，甚至引發矛盾。
? ? ?這些問題的根源就來自于缺乏相應的機制進行組織和交流，把大家的意見和想法充分表達出來是敏捷開發中以人為本、團隊合作的宗旨。
? ? ?2、在項目把控上，傳統的開發都是定義好的，根據計劃把整體的任務都一次性定好，缺乏靈活性，難以應對內外部環境的變化。但敏捷開發中的Backlog—Story—Task任務劃分機制很好的解決了這個問題，使得在項目需求有較大變化時通過先急后緩的方式充分應對。
? ? ?3、在部門劃分上，敏捷開發提倡按產品劃分，而不是部門。把編碼和測試人員綁定在一起，使整個開發的過程成為一個流暢的整體，避免了出現相互爭資源；把單元測試放到每一個Sprint階段之后進行，減輕了集成測試的壓力，緩和了測試人員由于不理解需求，測試不徹底或描述不準確與程序員產生分歧。
? ? 三、從學習角度看，我們可以借鑒敏捷開發中的一些優秀經驗和思想。平時兼顧整體規劃和細節規劃，在應對變化上要做到靈活，給自己預留足夠的緩沖時間。
? ? ?做好人際交流，了解集體狀況、優秀的或與自己緊密相關的個人的狀況，這是自我調整的強有力參考。
? ? ?最后，要做好選擇，找到適合自己的環境和方法。踩在如此多的“關毅”的肩膀上，我們已經有足夠的知識水平和認知能力去適應這個世界的節奏了。

總結

以上是生活随笔為你收集整理的敏捷开发的一点感受的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。