beta阶段的postmortem报告

1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?

2.团队在beta阶段吸取了那血alpha阶段的经验教训？

  在alpha阶段，我们对用户需求分析不够仔细，没有以小孩子的视角去仔细思考需求。在beta阶段我们对心理健康游戏加入了在每次打完怪后会和用户进行一定程度的互动，并根据此互动来生成在最后完成任务时的总结，还依据用户的回答来分析用户最近的情绪变化，对用户进行言语上的安慰。而在网络安全部分，因需要把每次用户提交的问题进行提交chatgpt并对此生成一个分析结果，所以会出现提交时间过长的问题，所以我们在这期间加入了一个动态的加载动画，是一个火箭升空的动画。以此来帮助孩子们度过等待的时间。

3.12条敏捷开发的原则中，团队做的最好和最不好的各列举2点。

最好的两点：

(1)   工作的任务量是首要进度度量标准。

我们非常认同这个衡量标准并在实际项目执行中很好地应用了这个标准。由于在beta阶段添加的代码耦合性没有第一阶段那么大，应用这个标准能够更加清晰地反映工作的进度。

(2)   在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

起初，我们打算通过应用MVVM模式进行开发，PM把设计文档都写好，然后让组员实现。然后在实际过程中发现这个方法并不是最适合我们的。因为我们对WPF技术并不是很熟悉，与其因为整体框架所需知识的学习而拖慢进度，不如采用成员之间互相交流互相学习的方法迭代式地开发。

最不好的两点：

（1）没有规划好具体进度，出现了因某个功能未实现或处理某个bug而导致了出现了加班加点的情况。

（2）还是没有特别彻底的以用户为小孩子的角度去分析需求，对于介绍和每个页面完成任务后的总结不够吸引孩子，出现了篇幅过多，趣味性不够的情况。

4.对照The Cathedral and the Bazaar（大教堂和集市），你的团队开发模式是哪一种，优势/劣势在哪里？

我们团队的开发模式更倾向于集市模式。

我们通过各抒己见，然后共同讨论的模式来进行项目需求分析和功能实现，这种模式的优势在于我们能够更好的去贴近用户需求并且做出一个能尽可能让大家都满意的项目方案。

劣势在于我们没有太多的时间思考关于项目骨架的问题，在“大教堂和集市”文中提到的以下两点上做得还不够好：

a) 健壮的结构远比精巧的设计来得重要。换句话说，结构是第一位的，功能是第二位的。

b) 保持项目的简单性。设计达到完美的时候，不是无法再增加东西了，而是无法再减少东西了。

在以后的项目中，还是需要尽早考虑一些关于结构的问题，应对敏捷开发中需求的变化。