本周再次打开《构建之法》，这次我阅读时重点在于学习敏捷流程、项目经理和用户场景等相对较为宏观的内容。

第六章开篇即简单地介绍了敏捷开发的流程：Product Backlog—>Sprint Backlog—>Sprint—>软件的增量发布。同时提出了一些敏捷开发的特色之处：团队成员自己主导任务的估计和分配，使其能动性得到较大的发挥；通过每日“例”会进行面对面的交流，报告工作进度、今日要工作的内容、遇见的问题；通过燃尽图或看版图展现项目进度。这是一种和我们之前接触的瀑布模型或需求驱动方法截然不同的开发方式，给我眼前一亮的感觉，但我也许需要一段时间去好好消化理解。

紧接着，作者列出了几个敏捷过程中常见的的问题，主要的有：解决无成员愿意认领的任务和认领任务多寡不均的问题；解决每日例会可能越来越空洞的现象；冲刺可能被领导打断的问题。并给出了部分问题的解决措施。

然后，作者提出了敏捷流程中的“第三步半”：即软件项目中常常有一些比较艰难和底层的任务。但这些看上去最多占20%的工作往往要花费80%的时间。只有完成了这些工作（主要是一系列的验证工作）后，才能真正进入增量发布阶段。

将敏捷流程进一步推广，作者告诉我们还存在着一个叫做“极限编程”的存在，即把一些认为有效的方法运用到极致。

最后，作者用非常大的篇幅来强调，敏捷宣言表明的是一些优先级，但千万不能把他教条化。如果用敏捷编程去开发宇宙飞船的控制软件，那么前几批宇航员都活不了了。

在第九章，作者告诉我们，一个典型的软件团队里，除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，即项目经理PM。（Program Manager，有别于Product Manager和Project Manager），用于解决团队成员之间的交流成本的问题，并承担开发和测试搞不定的所有工作。作者还告诉我们了一系列PM的能力要求：观察、理解和快速学习能力、分析管理能力（分析重要程度和紧急程度）、一定的专业能力、自省的能力。并告诉我们PM的具体任务：带领团队行程团队的目标/远景；管理软件的具体功能的生命周期；创建并维护软件的规格说明书；代表客户和用户利益，协调并决定各种需求的优先级；分析并带领其他成员对缺陷/变更需求形成一致意见并确保实施/带领其他成员确保功能/时间/资源的合理平衡，跟踪项目进展；推动项目成员持续改进，提升士气。

第十章中，作者列出了一些典型的用户和场景。首先，作者用一个让我笑到差点喷饭的笑话来告诉我们找到用户语言或行动背后的动机才是最关键的：

如上，如果一味地按照用户的表面语言或行动来实现，就可能得到笑话一样的产品。因此，我们需要找到并定义典型的用户和场景，通过规格说明书（功能说明书+技术说明书）展现出来，通过功能来驱动设计。

四渎《构建之法》——计划估计、敏捷流程、项目经理和用户场景