Beta版本总结

beta 阶段的 postmortem 报告

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

 

成员	Beta阶段的实践和alpha 阶段有何改进
黄山成	beta阶段较alpha阶段对相关的界面优化实现的更加完好，界面更加友好，并且数据库的创建及其导入都更加的灵活。
顾鹏	beta阶段较alpha阶段对结构和算法的理解更为深刻，相关技术更加熟练，底曾的架构更加完善。
吕兰兰	数据库从excel表中导入得更加顺利，服务器研究得更加深刻，用户的需求也更加了解，虽然最终约自习没有实现，但是学习到了很多。

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

    2.1在alpha阶段中，对功能的需求分析不够仔细，没有很好的了解真实用户的需求。因此在Beta版本中增加了更为迫切而实在的需求功能，增加了考试周自习的功能，也了解到约自习这一功能的作用。

2.2敏捷开发更加顺利，交流比一开始要多，因为Alpha版本发布后功能存在很多缺陷，连基本的查询都存在问题，所以Beta版本阶段，交流更多，实现得功能越来越完善。

3. 12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。

最好的两点：

(1)    敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。

这一点我们做得好是因为我们将考试周上自习进行的增加和完善，满足了客户的迫切需求。

(2)    保持简明——尽可能简化工作量的技艺——极为重要。

代码简明扼要，工作量也是简单分明，界面也比较灵活有趣。

最不好的两点：

(1)       无论团队内外，面对面的交流始终是最有效的沟通方式。

这一点我们首先没有对外寻求一些帮助，或者说没有没有虚心请教他人，

这使得我们服务器约自习那一块有问题。其次团队内部交流不多，所以开发效率一开始并没有得到提高。

(2)  尽早的、持续的交付有价值的软件来使客户满意

这一点我们做的不好，因为我们没有尽早发布自己的产品，也没有及时更新，这会使得软件生命周期阶段，软件生命力会降低。

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

我们团队的开发模式在alpha初始阶段更倾向于做成封闭的教堂，因为没有过多的了解用户，但在实际开发过程中慢慢向集市方式转变，开展出更加实用的功能，更加满足客户需求，所以我们认为更倾向于集市模式。

采用这样的模式，我们的优势在于能够更加贴近用户的需求，使得软件的实用性更加有所体现，用户的人数更多，有市场。而且功能和整体软件使用感受等方面也加强。

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

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

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

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