最近為了完成java設計模式和uml的大作業算是花了不少時間來動腦理解和動手編寫代碼，也開始發現代碼的神奇和美妙，java竟然可以開發簡單的小遊戲，而且代碼並不向想象中那樣難以理解，其中的規律似乎很神奇。帶著這種愉悅美好的心情讀《構建之法》，或許會比以前收獲更多。

繼瀑布模型之後又前輩們提出了“敏捷”，1.敏捷這個詞聽起來就是反應靈敏迅速而有效，而在軟件按工程裏，敏捷不同於現有做法之處在於：敏捷的價值觀和流程是個人和交流、可用的軟件、與客戶合作、響應變化，而現有做法的則是流程和工具、完備的文檔、為合同談判、執行原定計劃。

2.敏捷的開發原則是盡早並持續交付有價值的軟件以滿足顧客需求；只有不斷關註技術和設計

3.敏捷的流程可以分為以下四步：第一步－找出完成產品需要做的事情；第二步－決定當前的沖刺需要解決的事情，整個產品被劃分成幾個互相聯系的沖刺，產品訂單上任務被進一步細化，被分解為以小時為單位，訂單上的任務是團隊人員根據自己的情況來認領；第三步－沖刺，在沖刺階段，外部人士不能直接打擾團隊成員，一切交流只能通過scrum大師來完成，這一措施較好地平衡了“交流”和“集中註意力”的矛盾，沖刺期間，每日都開個例會，每日例會強迫大家向同伴報告進度，迫使大家把問題擺在明面上，同時啟動每日構建，用建民的圖表來展現整個項目的進度，圖表可以是燃盡圖，想象我們把一堆待完成的事完成了，沖刺階段是時間驅動的，時間一到就結束，這個特點看似不起眼，其實有效地斷了各種延期的想法，很棒啊；第四步

4.但理論遇上現實或多或少都會出現問題，比如在第一步中我們應該怎樣體現各個需求和任務間復雜的依賴關系呢，第二步中成員認領任務不均怎麽辦呢，第三步中每日例會都是流水賬怎麽辦呢，以及燃盡圖只列出任務的數目，無法展示項目的拖延情況；這時就可以有更好的改進了，應該明確定義好一個任務，還應記載完成這個任務還需要多長時間，已經花了多少時間雖然重要，但那不是管家（已經是沈沒成本了），關鍵是我們離目標還有多遠。還有燃盡圖，書中作者提出了以時間來度量，比如實際剩余時間，預估剩余時間，實際花費時間等。

5.敏捷適用於產品可靠性不高，容忍經常出錯，需求經常變化，團隊人員數量不多，有資深的程序員帶隊，公司鼓勵變化等情況，而不是必須有較高可靠性、不容許出錯的商業情況，也不是要有極高可靠性、精益求精的科學計算、復雜系統的核心組件，這兩種應該用計劃驅動和形式化的開發方法。

最後，我覺得敏捷是一個有自己應用場景的好方法，能提高團隊成員開發的積極性和團隊凝聚力，思維也非常明確簡介，簡單粗暴，直奔主題，強調可用的軟件、可度量的進度、每日例會、面對面的交流等直接有效的流程和方法，不僅在軟件開發方法中占據一席之地，在生活中應用也能有很好的效果，短學期的開發實踐很期待用這個方法。

構建之法－－－敏捷流程