最近讀完敏捷著作中的經典《敏捷式軟體開發 (Agile Software Development)》，原名是Agile Software Development，感覺和以前看的有關軟體工程的書都有些不同。這本書充分體現作者真正將軟體開發過程管理視為一種可工程化的技術，書中的嚴謹與幽默，與國內要麼千篇一律沒有個人思考，要麼完全是個人感悟無法形成理論依據，有質的區別。作者的認真嚴謹確實給我留下挺深的印象。這已不僅僅是思考，而是不斷的完善，是一種希望最終形成體系的努力。
這裡摘出整本書中個人感覺有道理的段落，也做些個人感悟，留待以後觀用。
第0章 溝通的成功依賴於寄件者和接受者有可以引用的共用體驗（shared experience）項目的任務不是努力達到完全的溝通，而是管理我們溝通的不完全性三個層次——following，detaching，fluent：書中最有趣的部分就是：那麼，明天我做什麼
第1章 創造和溝通的合作博弈1.1 軟體與詩歌：很貼切的比喻想象一下，把50個人聚在一起，在有限的成本與時間內編寫2萬行的敘事詩1.2軟體是創造和溝通的合作博弈。溝通的效果比溝通的形式更重要模型就像任何一種溝通一樣，只要它能使下一個人繼續他的工作，這個模型就足夠了。應當對團隊的工作產品進行度量的是它們在向目標組傳達資訊方面的充足性。1.3合作博弈的原則軟體開發是一個（有資源限制的）創造和溝通的合作博弈。博弈的首要目標是交付有用的，可工作的軟體。次要目標，即博弈的沉澱，是為下一輪博弈做好準備。下一輪博弈可能更改或替換系統，也可能是建立一個相關的系統。1.3.1程式員只喜歡交流那些他們喜歡交流的事情。在軟體開發的課程表中，大學應該增加一些包含溝通密集（communication-intensive）課程。1.3.3標誌物與道具中間工作產品成為我們用於反思的提醒物。他們提供了共用體驗，以此來指向或者作為新想法的支援結構。1.3.5對於中間工作產品，需要進行的度量只有充分度（sufficiency）：它是否足以提醒相關的小組或足以激發相關小組的靈感。1.4這對我意味著什麼觀察：
- 設計團隊的人如何構建他們的理論
- 進行最後調試或程式維護的人如何構建他們的理論
- 與前者相比較，後者的可用資訊的不同
- 他們不同的理論如何在產生的程式中導致不同
- 你如何理解你的問題隨著時間的變化而發生的變化，這些變化又是如何改變你對於所要構建的解決方案的理解的
察看你的項目，然後提問：
- 參與這一博弈的都有誰？
- 哪些人在進行有限的，追求目標的團隊博弈
- 哪些人反而在進行他們自己的無限博弈
- 你的團隊夥伴在什麼時候一起創造，以及他們在什麼時候留下一些蹤跡好讓其他人知道他們進行到了哪一步？連續五個工作日仔細觀察這些事，注意他們如何一步一步進行。
把項目決策看作是博弈中的步驟。把它想象成一種不同的博弈，穿越沼澤：
- 回憶一下項目的準備活動，它們就像一個對沼澤發起進攻的初始計劃一樣。當出現了關於這片沼澤的特點和團隊的能力的新資訊時，計劃就要改變。
- 觀察每個人的貢獻：探查更深或更安全的點，為了讓其他人能穿越沼澤而製作地圖或開闢道路。
