本周再次打開《構建之法》，這次我閱讀時重點在於學習敏捷流程、項目經理和用戶場景等相對較為宏觀的內容。

第六章開篇即簡單地介紹了敏捷開發的流程：Product Backlog—>Sprint Backlog—>Sprint—>軟件的增量發布。同時提出了一些敏捷開發的特色之處：團隊成員自己主導任務的估計和分配，使其能動性得到較大的發揮；通過每日“例”會進行面對面的交流，報告工作進度、今日要工作的內容、遇見的問題；通過燃盡圖或看版圖展現項目進度。這是一種和我們之前接觸的瀑布模型或需求驅動方法截然不同的開發方式，給我眼前一亮的感覺，但我也許需要一段時間去好好消化理解。

緊接著，作者列出了幾個敏捷過程中常見的的問題，主要的有：解決無成員願意認領的任務和認領任務多寡不均的問題；解決每日例會可能越來越空洞的現象；沖刺可能被領導打斷的問題。並給出了部分問題的解決措施。

然後，作者提出了敏捷流程中的“第三步半”：即軟件項目中常常有一些比較艱難和底層的任務。但這些看上去最多占20%的工作往往要花費80%的時間。只有完成了這些工作（主要是一系列的驗證工作）後，才能真正進入增量發布階段。

將敏捷流程進一步推廣，作者告訴我們還存在著一個叫做“極限編程”的存在，即把一些認為有效的方法運用到極致。

最後，作者用非常大的篇幅來強調，敏捷宣言表明的是一些優先級，但千萬不能把他教條化。如果用敏捷編程去開發宇宙飛船的控制軟件，那麽前幾批宇航員都活不了了。

在第九章，作者告訴我們，一個典型的軟件團隊裏，除了能寫代碼、測試代碼和畫圖做設計的成員，還有一類角色，不做上面這些事情但也很重要，即項目經理PM。（Program Manager，有別於Product Manager和Project Manager），用於解決團隊成員之間的交流成本的問題，並承擔開發和測試搞不定的所有工作。作者還告訴我們了一系列PM的能力要求：觀察、理解和快速學習能力、分析管理能力（分析重要程度和緊急程度）、一定的專業能力、自省的能力。並告訴我們PM的具體任務：帶領團隊行程團隊的目標/遠景；管理軟件的具體功能的生命周期；創建並維護軟件的規格說明書；代表客戶和用戶利益，協調並決定各種需求的優先級；分析並帶領其他成員對缺陷/變更需求形成一致意見並確保實施/帶領其他成員確保功能/時間/資源的合理平衡，跟蹤項目進展；推動項目成員持續改進，提升士氣。

第十章中，作者列出了一些典型的用戶和場景。首先，作者用一個讓我笑到差點噴飯的笑話來告訴我們找到用戶語言或行動背後的動機才是最關鍵的：

如上，如果一味地按照用戶的表面語言或行動來實現，就可能得到笑話一樣的產品。因此，我們需要找到並定義典型的用戶和場景，通過規格說明書（功能說明書+技術說明書）展現出來，通過功能來驅動設計。

四瀆《構建之法》——計劃估計、敏捷流程、項目經理和用戶場景