-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是设计一个图书管理系统软件，解决整个图书馆的书籍管理和用户借阅书籍等问题。
我们软件的用户群体是学校的全体师生，数据是图书馆的书籍、用户和管理员的信息，对于软件的定位十分明确。 -
每个成员在beta 阶段的实践和alpha 阶段有何改进?
| 成员 | 改进|
| -- | -- |
| 赖国颢 |我在beta阶段之前，对于Qt的开发停留在几个小页面，小组件的开发，项目一大，就很混乱；现在我能充分布局好多个页面，还有页面于页面之间的通信框架，现在我感觉就算开发的项目再大，我也能做到在开发中对各个对象约束得井井有条 |
| 杨百友 |学到了如何整理文档和进行接口管理 |
| 刘立光 |提高了数据库的效率，减少了不必要的数据冗余。 |
| 李子聪 |对postman有了更深的理解和对markdown的使用更加熟练 |
| 李济远 |beta阶段相较于alpha阶段对数据库的认识更为深入，熟练度更高 |
| 李兆彬 |beta阶段在alpha的基础之上测试工具使用更加熟练，效率更高 |
| 黄永名 |Beta阶段更加深刻理解了项目的每个职位的职能，项目代码运行逻辑 | -
团队在beta 阶段吸取了那些alpha 阶段的经验教训?
在alpha阶段中，我们对用户需求的分析不够仔细完整，有些功能是不应该做的，而有些功能是必须品，缺遗漏了，所以我们总结出要尽量延迟开发，把前面的用户需求和框架做好了，再开始编码，这样开发会更少出错，也更加高效。 -
12 条敏捷开发的原则中, 团队做得最好和最不好的各列举 2 点。
最好的两点：
(1) 工作软件超过详尽的文档：
虽然文档很重要，但更重要的是交付能够工作的软件。我们在开发过程中，对工作软件是精益求精的。
(2) 自我组织超过等级制度：
在团队合作过程中，我们每个个体都充分主动地参与进来，对于一些没有在会议中谈到的点，我们也可以在私下把他们完成。
最不好的两点：
(1) 代码复用超过代码复写:
我们这次的开发中，很少考虑代码的复用性，代码几乎都是独立的个体。
(2) 最佳实践 超过最佳工具：
我们都是使用自己会的工具来开发的，没有考虑到什么样的工具更加适合这个项目。 -
对照 The Cathedral and the Bazaar (大教堂和集市), 你的团队开发模式是哪一种, 优势/劣势在哪里?
我们团队的开发模式更倾向于封闭的大教堂，这是因为我们可以更加集中尽力去解决当下的问题。
优势是：这种方法，交流成本更低，可以有更多的时间去进行代码的开发和测试；
劣势是：实际开发出来的功能可能和用户想要的不一样，又需要重新加工。
成员贡献表
| 成员 | 贡献事项 | 贡献占比 |
|---|---|---|
| 赖国颢 | 担任项目组长，负责统筹全局，开设会议，组织讨论，同时负责博客的制作和客户端的开发和测试 | 20% |
| 杨百友 | 主要负责后端服务器模块，主要工作内容包括设计HTTP协议和接口，登录授权，权限认证，接口拦截，以及为前端提供数据库数据获取服务 | 16% |
| 刘立光 | 负责数据库设计，通过进行需求分析设计图书管理系统的关系表 | 12% |
| 李子聪 | 负责团队的博客和计划表等文本工作，及部分测试的工作 | 13% |
| 李济远 | 负责数据库设计，通过进行需求分析设计图书管理系统的数据库结构，并根据团队成员需求及时修改数据库结构。 | 12% |
| 李兆彬 | 测试，使用postman进行接口功能测试，接口权限测试和接口拦截测试 | 14% |
| 黄永名 | 收集图书数据，数据库（部分）工作内容：主要负责，一是收集图书的相关信息和数据。二是数据库表结构的优化和改善，编写了部分sql语句和说明文档。 | 13% |