第8章叫做“白板上的及时贴”。在本章的开头，有一句话“吃自己的狗食”。这是微软和许多态度严谨的软件公司的一种规定，即开发者必须使用自己正在做的产品。在OSAF，“吃狗食”感觉很对路。吃狗食可以用来在服务器发布版中找出最后一些产品缺陷。在这些前人的经验中，我们可以看到“吃狗食”有助于发现和修正缺陷。在学习中，我学习到了WebDAV（Web-based Distributed Authoring and Versioning）。WebDAV的工作机制是扩展HTTP，增加了让用户在远端服务器上编辑文件的新命令。“kibble计划会议”而提出的“白板上的及时贴”很好地解决了会议上如何知道新版本的大小和无法比较特性的问题。“白板上的及时贴”通过略去已经取消或推后的特性，还有没必要包括的特性，让工作简单化。通过“白板上的及时贴”能很好地监控工作进度，就和我们在团队项目第一次冲刺周期制定的任务看板类似，能很好地显示工作进度，让大家知道目前实现的状态。
第9章叫“方法”。首先提到质量三角——时间、金钱和特性（或质量）。通过Chandler1.0版的引用，很好地告诉我们，OSAF需要有可行的方法论。作者通过各种案例告诉我们，方法论形成经历了很多失败，通过各个成功人士的修改和添加，出现了各种各样的方法，例如CMM、TSP、PSP、瀑布模型、螺旋模型，最终出现了敏捷软件开发。《敏捷宣言》简明扼要，敏捷方法论层出不穷，有争球式开发（Scrum），最流行的变种是极限编程。我们在团队项目的软件开发过程中，采用的就是敏捷软件开发方法，通过敏捷开发方法来实现我们的项目，给我们带来了方便。
第10章讲述的是工程师和艺术家。这一章中，作者通过引入一次软件工程大会上的专家小组会，来说明“软件”和“工程”两词已经密不可分。术语“软件工程”几乎是在一夜之间变成了既定事实。通过在软件发展历史上的名人实例，简单明了的讲述了什么是软件工程。我们常视艺术活动和科学工作为不相干之事，但两者实有雷同。科学与艺术以不同比例占据了创造和洞见的多数工作。工程师当然要在艺术与科学的深渊上搭起桥梁。是工程还是文学？是科学还是艺术？如何解决编程的双重身份问题？这根本不是难题，而只是编程作为人类活动的一种唯一性表现。在字面编程中，良好的注释是优秀编程实践的特点，他说明你关注自己在做的事，而且也照顾那些跟进修正代码缺陷的人。注释也是程序员之间沟通的渠道，偶尔甚至会成为竞技场或派遣无聊的出口。也许他们在注释中发泄的怒气不叫艺术，但是对于他们的工作性质而言，他们的自由发挥就是艺术。
以前，我们在编程时，并不懂得什么叫“白板上的及时贴”，都是在编程过程中想到什么就写什么，不注重方法。同时，在编写代码的过程中只注重个人设计，忽略注释的重要性，给自己和团队以及其他人带来了不便。对于自己编写出来的代码，并没有什么实用性，别人无法理解。
在这学期的学习中，我学会了如何团队合作，学会了敏捷开发方法，通过在对这几章的学习，加深了我们任务看板、敏捷开发方法的认识，让我明白了当初的做法所带来的不便，加深了自己在软件项目开发方面的认知。
在以后的学习过程中，我们在软件项目开发时应有明确的目标，通过“白板上的及时贴”来优化项目特性，优化工作量。同时通过敏捷开发方法正确地开发软件项目，让自己的项目不仅仅是一个工程，也是艺术。同时，我们也要学会“吃自己的狗食”，来保证自己项目的质量。