敏捷軟體開發是為了防止專案開發中的過程膨脹而提出的。為此，成立了敏捷軟體聯盟，並建立了《敏捷軟體開發宣言》。
我對敏捷開發的感覺有以下幾點：
一．在開發過程中強調人以及人與人之間關係的作用。不但要求開發團隊要有乙個積極向上的氛圍，同時強調成員與成員之間的合作和交流。例如：每兩名成員組成一對，共同開發乙個功能，並且這種結對要至少每天更換一次。這就保證了資訊在專案組內部的流通，同時知識也更容易傳播。
二．降低了工具的作用。作者強調在開發的過程中，應當優先使用簡單的工具，直到證明這些簡單的工具不再適用。在書後的附錄中，乙個開發團隊因為在專案中期引入了乙個**管理工具，而在工具的配置，培訓以及修改錯誤上耽誤了大量的時間。
三．在每次迭代中，要優先實現已確定的素材，其次再為下一次迭代的素材作打算。在每次迭代中，要以實現當前的素材為準則。「團隊最開始的工作是以盡可能最簡單的方式實現第一批使用者素材。只有當出現乙個使用者素材迫切需要改變基礎結構時，他們才會引入該基礎結構」。在這一點上我有一些疑惑：如果第一批素材與第二批素材在對資料庫的設計上要求並不統一，那麼在進行第二批素材的時候，就需要對資料庫進行更改。如果類似的事情出現在專案的中後期，是否會產生不好的影響？
四．推薦在編寫**之前，要先編寫單元測試和驗收測試。然後以通過測試為目的來編寫**。這樣「有目的的編寫**」，可以有效地降低**的冗餘。同時，單元測試可以降低**之間的耦合。
五．重構和隱喻很重要。我想這並不僅僅適用於敏捷開發。
敏捷開發筆記 評估進度
度量真實的進度 待辦事項 估計任務真正花費的時間，可能前幾次估計的不准，比如第一次估計是2天完成，而實際上是6甜完成，那麼下次估計的時候，就乘上這個3這個係數。前幾次這個係數會波動，越到後面，這個係數會穩定，最終趨近於1 不要用不恰當的進度來欺騙自己和團隊 sprint，評估任務和資源，如果任務超過...
《敏捷軟體開發》筆記1
引言 本書的核心思想是 任何技術都有侷限性 因此，不可能找出一種最好 最正確的軟體開發方法。在軟體開發專案中匯報情況的人們也會因為一些不是事實的 事實 犯了類似的觀察錯誤。需求編寫人員也不例外。他們觀察使用者群體並編寫自認為是需求的文件，其實其中包含不少觀察錯誤。我們對 這是什麼 的理解會隨我們如何...
前端開發筆記（一）
1 js判斷字串是否為空 var str if str str 2 判斷checkbox是否被選中 js判斷checkbox是否被選中 var c document.getelementbyid protocl if c.checked jquery判斷checkbox是否被選中 3 js定時器se...