再次讀完《構建之法》第二版15.3之後思想上有了新的感悟。相較於第一次草草讀完看看熱鬧，第二次我讀時才發現竟遺漏了很多有趣和值得學習的地方。
“我們常說‘軟體的生命週期’——這個軟體開發的週期結束了，生命也結束了。”這句話直接表明了應該什麼時候開時候諸葛亮會議，而有趣的是將軟體的生命結束定義到了開發週期的結束。我想，只有在開發剛剛結束後開這樣的會議，團隊成員的切身感受才是最深的，總結出的需解決問題才是最直接有效的。
書中還說明了會議的幾項原則。
“見機行事，根據會議的進展靈活地變動計劃”。
“牢記會議的核心問題：‘如果可以重新來過’，什麼方面可以做的更好？”。
“在問‘為什麼’的時候，要多問幾次，層層推進，找到問題的根源”。
掌握了這三個原則就可以把握好事後諸葛亮會議的深度和發展。
在模板中，我看到模板主要將問題分為幾個大類：設想和目標；計劃；資源；變更管理；設計/實現；測試/釋出；總結。
“計劃”的第五個問題“在計劃中有沒有留下緩衝區，緩衝區有用麼？”。這個的問題好在提醒了開發團隊要建立緩衝區，不管是多麼完善的體系也一定避免不了一些“小插曲”，所以緩衝區設計的好壞直接影響著整個程式的發展。“資源”的第四個問題“你有沒有感受到你做的事情可以讓別人來做（更有效率）？”。這個問題是對每個成員自身的提出，每個成員在專案結束後總結自己的工作，每人不全都是為了錢而工作，其中自然離不開樂趣，而自身的價值就是這個為題的出發點。當然在另一個層面這考慮的是團隊中人員的“術業有專攻”，可以更合理的分配團隊中的資源。“變更管理”的第四、五問“對於可能的變更是否能指定應急計劃？”、“員工是否能夠有效地處理意料之外的工作請求”。這個兩個問題在專案最初就應該考慮，回過頭來總結當初的計劃是否合理，工作請求是否得到了滿足。“設計/實現”的問題中提到“為什麼我們在設計/開發時沒有想到這些情況”。像這樣的問題應該在會議中刨根問底，要是隻有籠統的回答，下次的結果也還會是這樣。“測試/釋出”的第三題“團隊是否有測試工具來幫助測試？”這個問題只有兩種可能，用了或者沒有，從這作為分流點，通過其他問題就能比較出用與不用的差異，從而說服團隊成員使用測試工具。
在這節後面提出了“怎麼開好一個Postmortem”會議。其中第7、8問題是這個會議最直觀的結果，用資料表現大家最想解決的問題，用行動面對出現的問題。
以上是個人觀點，如有不對，請多指教。