再次读完《构建之法》第二版15.3之后思想上有了新的感悟。相较于第一次草草读完看看热闹，第二次我读时才发现竟遗漏了很多有趣和值得学习的地方。
“我们常说‘软件的生命周期’——这个软件开发的周期结束了，生命也结束了。”这句话直接表明了应该什么时候开时候诸葛亮会议，而有趣的是将软件的生命结束定义到了开发周期的结束。我想，只有在开发刚刚结束后开这样的会议，团队成员的切身感受才是最深的，总结出的需解决问题才是最直接有效的。
书中还说明了会议的几项原则。
“见机行事，根据会议的进展灵活地变动计划”。
“牢记会议的核心问题：‘如果可以重新来过’，什么方面可以做的更好？”。
“在问‘为什么’的时候，要多问几次，层层推进，找到问题的根源”。
掌握了这三个原则就可以把握好事后诸葛亮会议的深度和发展。
在模板中，我看到模板主要将问题分为几个大类：设想和目标；计划；资源；变更管理；设计/实现；测试/发布；总结。
“计划”的第五个问题“在计划中有没有留下缓冲区，缓冲区有用么？”。这个的问题好在提醒了开发团队要建立缓冲区，不管是多么完善的体系也一定避免不了一些“小插曲”，所以缓冲区设计的好坏直接影响着整个进程的发展。“资源”的第四个问题“你有没有感受到你做的事情可以让别人来做（更有效率）？”。这个问题是对每个成员自身的提出，每个成员在项目结束后总结自己的工作，每人不全都是为了钱而工作，其中自然离不开乐趣，而自身的价值就是这个为题的出发点。当然在另一个层面这考虑的是团队中人员的“术业有专攻”，可以更合理的分配团队中的资源。“变更管理”的第四、五问“对于可能的变更是否能指定应急计划？”、“员工是否能够有效地处理意料之外的工作请求”。这个两个问题在项目最初就应该考虑，回过头来总结当初的计划是否合理，工作请求是否得到了满足。“设计/实现”的问题中提到“为什么我们在设计/开发时没有想到这些情况”。像这样的问题应该在会议中刨根问底，要是只有笼统的回答，下次的结果也还会是这样。“测试/发布”的第三题“团队是否有测试工具来帮助测试？”这个问题只有两种可能，用了或者没有，从这作为分流点，通过其他问题就能比较出用与不用的差异，从而说服团队成员使用测试工具。
在这节后面提出了“怎么开好一个Postmortem”会议。其中第7、8问题是这个会议最直观的结果，用数据表现大家最想解决的问题，用行动面对出现的问题。
以上是个人观点，如有不对，请多指教。