一个完整的案例研究，给整本书里讲的理论知识来了一次实践。
个人比较好奇这一章，所以提到前面来先看了。
完整的案例：
1. 建议：项目的初始需求
2. 探究：对初始需求进行细致的研究，特别是对其中可能出现的关键技术问题，做全面的评估。确定团队分工。
3. 首次计划会议：将确定下来的需求传达到每一个团队成员手里，以任务卡片的形式将需求具体化，并借此评测项目开发所需的时间。
4. 增量一：灵活程序框架。目的是建立一个框架式的应用程序，该程序具备架构的主要特性以及一些核心功能。在该项目里，主要任务是建立一个对象模型和运行一个将场景模型投射到屏幕上的软件。
5. 任务综述：任务综述是水晶项目管理体系中对主办方要求的唯一一项工作产品。
6. 评审一：让团队成员了解产品开发状况，并发现一些问题。
7. 反思研讨会一：确认水晶管理体系在项目开发过程中发挥了作用的环节和需要改变的环节。
8. 增量二：CP输入与编辑。该任务的目标是使用户输入以及编辑“相对应”。
9. 评审二、反思研讨会二。
10. 增量三：校准。
11. 评审三、反思研讨会三。
12. 增量四：年末巩固。
13. 评审四、反思研讨会四。
14. 增量五：完成。
15. 评审五、反思研讨会五。
注意点和疑问：
# 该案例团队成员较少，且只有一名技术是全职投入，我认为项目的完成质量大部分取决于该技术人员的实力水平，而采用什么样的开发模式并不能起什么决定性作用。
# 案例中着重提到了水晶项目管理体系的可居性。团队乐意再次使用该方法体系。
这个可居性对于不同的团队成员意味着不同的东西：
1. 对于设计师(也是全职的技术)，他觉得自己总是很“专注”且“精力充沛”。
这种感觉是由以下因素得来：
参与每个增量计划；
熟悉需求以及用户的优先项(根据价值)；
完成增量以及在增量期内完成系统特性的添加时所获得的成就感；
在一定程度上感觉到从繁重的工作中解脱出来，实际上并未能放下多少工作，但确实使人有了好心情。
2.对于用户(也是初始项目需求的缔造人) ：
可以清晰地了解项目的进展状况；
定期的评审会创造了一条团队成员分享信息的途径；
这些都是以前做项目时从未经历过的事情。
3.对于项目经理：
团队成员的交流很好；
不能掌控项目进度，感觉有点失控。
# 最让人感兴趣的是首次计划会议，通过任务卡片的形式将需求具体化并传达到技术方，并借此制订了项目进度。
感兴趣的点一是任务卡片的形式，二是进度有策划方和技术方共同制订。
# 探究阶段所提到的360度全方位考察值得关注，在这个案例里并未展开，要等到以后看第三章才能详细了解。
# 由团队共同决定进度表就意味着主办方不能靠自己的意愿制订项目的deadline，除非删减需求或者增加团队的战斗力。
# 在第一次增量阶段，策划方对项目需求做了精简，目的是为了确保项目能按时交付。而策划方请求的一个新功能也被否决，原因是主办方主要关心项目能否按时交付，而不是能否交付一个最全面产品的问题。
# 该案例在用户角色方面与水晶项目管理体系有所背离，缺少一类实用户参与项目。
# 该案例符合水晶项目管理体系的基本特征，但一些扩展的特征未能很好的体现。具体指：个人安全，焦点，与专家用户建立方便的联系，拥有自动化测试、配置管理、经常集成的技术环境。
体会：
1. 对于任务综述的严格贯彻。
2. 团队成员的充分交流。
3. 任务卡片和进度表。
4. 定期的评审讨论会。
5. 让每一个参与项目的团队成员获得更多良好的感觉。
