测试矩阵：
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件要解决的就是老师和课代表没有时间一个一个检查博客园作业；并且对典型用户和典型场景有清晰的描述。
2．是否有充足的时间来做计划？
我们有充足时间来做计划
3.团队在计划阶段是如何解决团队成员对于计划的不同意见的？
我们大家坐在一起，通过开团队会议的方式，来处理对计划的不同意见。
用户量，用户对重要功能的接收程度和我们事先预想的一致吗？我们离目标更近了，吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？
不一致，但的确离目标更近了。如果重来一次，我们将做更加详细的计划。
计划
- 你原计划的工作是否最后都完成了？如果没做完的，为什么？
完成。
2.有没有发现你做了一些事后看来没必要或没多大价值的事？
有。
- 是否每一项任务都清楚的定义和衡量的交付件？
否。
- 是否项目的整个过程都按计划进行？
没有。有时任务没能完成。
- 在计划中有没有留下缓冲区，缓冲区的作用是什么？
- 将来的计划会做什么修改？
任务分配更加明确，对团队成员要求更加严格。
3. 12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。
最好的两点：
(1) 工作的软件是首要进度度量标准。
我们非常认同这个衡量标准并在实际项目执行中很好地应用了这个标准。由于在beta阶段添加的代码耦合性没有第一阶段那么大，应用这个标准能够更加清晰地反映工作的进度。
(2) 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
起初，我们打算通过应用MVVM模式进行开发，PM把设计文档都写好，然后让组员实现。然后在实际过程中发现这个方法并不是最适合我们的。因为我们对WPF技术并不是很熟悉，与其因为整体框架所需知识的学习而拖慢进度，不如采用成员之间互相交流互相学习的方法迭代式地开发。
最不好的两点：
(1) 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
Beta阶段由于客观原因没能做到按照恒定速度开发，出现过加班加点的现象。
(2) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
面对在beta发布后反馈的安装不方便的问题，我们得到了一个教训：应该尽早地让客户使用我们的软件，从而了解最需要改善的地方。软件工程不仅仅是写代码，其中还涉及很多为人处事的道理需要我们去领悟。