福大周润发队——alpha阶段问题总结随笔
| 这个作业属于哪个课程 | 2021春软件工程实践S班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 团队作业六——beta冲刺+事后诸葛亮 |
| 团队名称 | 福大周润发队 |
| 团队成员 | 柯少彬、陈皓宇、梁扬新、陈杉（原alpha冲刺团队成员，不参与beta冲刺）、林明昊（新加入）、池毓地、李家成、黄凯荣、黄钰栋、陈力涵 |
| 这个作业的目标 | alpha阶段问题总结 |
| 其他参考文献 | 构建之法 |
每个成员在alpha阶段的实践内容
| 成员 | 实践内容 |
|---|---|
| 柯少彬 | 服务器的搭建、游戏主体的实现、测试 |
| 陈杉 | 辅助服务器的搭建、游戏主体的实现，GUI设计 |
| 李家成 | GUI设计、GUI美化、测试 |
| 黄钰栋 | 收集数据库信息、辅助GUI设计、测试 |
| 陈皓宇 | 收集数据库信息、辅助GUI设计、测试 |
| 黄凯荣 | 测试、编写测试随笔、修复部分bug |
| 池毓地 | 编写PPT、测试、演示 |
| 梁扬新 | 辅助聊天室、游戏胜负判定逻辑、编写博客 |
| 陈力涵 | 编写文裆、系统邮件实现、测试 |
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件要解决现有的“你画我猜”游戏的单调内容，因为大部分游戏只有简单的胜负规则，而且模式较为单一，没有更进一步的内容。
- 定义得比较清楚，目的就是，在软件雏形做出来之后，能够实现自选游玩主题，在每一轮游戏后，公布答案的同时，还会提供关于答案的知识，起到寓教于乐的作用；在玩家游玩一定时间后，根据玩家的表现，将解锁对应的成就，可以提高玩家的获得感。
- 典型用户及场景即，一群人线上一起玩游戏（可以是都在一个较小空间内，也可以是远程），进入游戏之后，可以创建房间或者寻找房间。开始游戏之前可以自选主题，游戏结束后提供关于答案的知识。
2. 我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？)
原计划的功能差不多完成一半多一点，剩下的功能计划在beta冲刺阶段完成。软件alpha版按照原计划交付时间交付了。
3. 我们离目标更近了么？有什么经验教训？
- 那肯定离目标更近了，因为我们在alpha冲刺阶段完成这个软件的一部分功能。
- 经验教训主要有：
- alpha冲刺的时候，对成员分工不够明确。beta冲刺需要对成员分工进一步的明确，优化框架，使成员配合得更好。
- alpha冲刺的时候，时间安排不够合理。beta冲刺需要进行更加详细的开发计划，以实现应有的功能。
计划
1. 是否有充足的时间来做计划?
有充足的时间计划。实际上alpha冲刺是编码环节，alpha冲刺之前已经完成了需求分析与设计，这些都可以算计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
关于对计划的意见，我们主要是在站立式会议的时候，结合项目的完成情况和个人每天的总结，进行讨论的。按照“谁愿意谁完成”的原则进行分配任务，如果没有人愿意就让当时需求分析提出的人完成。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
是，最后都做完了。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有发现。
5. 是否每一项任务都有清楚定义和衡量的交付件?
是，从需求分析到alpha冲刺都有相应的代码和文档交付。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程基本都按照计划进行，因为当时考虑到上课等方面的因素。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
alpha冲刺是基本没有留下缓冲区。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
beta冲刺肯定要有缓冲区，因为beta冲刺开始之后至少有两场考试，可能会因为复习考试科目影响进度。
资源
1. 我们有足够的资源来完成各项任务么?
暂时是有足够的资源完成任务的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
在alpha冲刺开始前就进行了10天alpha冲刺的安排，精度一般，因为只是大体估计了十天要做什么。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源（美工设计/文案）是否低估难度?
人力和软件/硬件资源是足够的，不需要编程的资源（美工设计/文案）难度估计合理。
4. 你有没有感到你做的事情可以让别人来做（更有效率）？
肯定是有的，自己完成，时间一长很难坚持下去。但是让别人做可能会出现其他问题，比如还要花时间熟悉已完成的部分代码，或者还要学习新技术要花时间。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
线上沟通，保证每个人都能及时知道。此外还有站立式会议的讨论时间。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
核心功能是“必须实现”的功能，比如画图功能，进入游戏功能等。“推迟”的功能主要是依赖于核心功能运行的，并且对于核心功能是没有影响的功能，比如主题功能、寓教于乐功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
对已经完成的功能，能正确运行。
4. 对于可能的变更是否能制定应急计划？
是，可以制定应急计划。应急计划主要是，遇到急事没能继续参与开发的话，应该另找一人（一般是任务比较少的）把他的任务补充完整。
5. 员工是否能够有效地处理意料之外的工作请求？
能处理，一般通过线上沟通或者站立式会议讨论。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作在alpha冲刺之前完成，由小组所有成员共同完成。具体可以见设计的博客：设计
- 是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
根据大家不同的观点，尽量求同存异，大家互相讨论，得出解决方案。实在不行，由组长决定。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
- 有用单元测试，但只用在编码阶段。工具有效。
- 暂时还没发现UML文档和现在的状态的区别。暂时不需要更新UML文档。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况？
- 涉及到网络连接的功能产生的bug最多，因为这一部分的编程感觉不好实现。
- 发布之后暂时还没有发现重要的bug。
- 不是没想到，是可能由于技术问题，怕做不到。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
通过阅读其他人的代码进行复审的。严格执行了代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，编写代码的时候同步进行单元测试，待一个功能实现后进行集成测试。
2. 是否进行了正式的验收测试？
目前只是内部测试版，还没有进行正式的验收测试。
3. 团队是否有测试工具来帮助测试？
有，主要利用Junit和JProfier测试工具。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 利用JProfier测试，观察内存使用情况。其他的还没有开始进行测试。
- 这些测试工作有用，至少让我们知道这个程序运行起来需要占用多少内存。
- 改进的话，应加强团队测试程序的能力，不仅仅局限在单元测试和运行程序。
5. 在发布的过程中发现了哪些意外问题？
暂时没有。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
- 角色的确定主要看写代码的能力和之前的学习情况，会写代码的成员领导不太会写代码的成员学习。
- 项目是由组长和部分成员发起的，成员分工主要是前端、后端、测试。
2. 团队成员之间有互相帮助么？
有，比如当程序运行不起来时，或者编程方面遇到困难时，小组互相讨论解决问题。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
利用站立式会议的机会，讨论解决。
总结:
1. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
虽然团队也有线上的交流，但是大家都更倾向于线下的面对面交流，这样可以带来更高的开发效率。 - 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
利用站立式会议的机会，每个人进行总结反思，思考接下来该做什么、怎么做。
2. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
利用github，在每次push之前均应先pull别人修改的代码，而且github在push之前检测得到别人是否有提交记录。
3. 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
- 架构提高方面，写成接口和包的形式方便复用部分代码。
- 重构提高质量：只要有代码修改或者嵌入，都需要进行重构。
- 衡量质量的提高：修复找到的bug，寻找新的bug。
4. 其它软件工具的应用，应该如何提高？
一是互相学习，二是上CSDN、bilibili等网站寻找教程。
5. 项目管理有哪些具体的提高？
利用了github进行项目管理，取代发文件的形式。
6. 项目文档的质量如何提高？
写完后全员共同检查文档，保证正确无误。
7. 对于人的领导和管理， 有什么具体可以改进的地方？
计划可以再细致一些，时间安排方面，其实可以再留出些时间以备不时之需。然后组长要以身作则，不仅要让别人写代码，自己还要写比别人多一点的代码，这样大家才有动力。
8. 对于软件工程的理论，规律有什么心得体会或不同意见？
虽然敏捷开发强调程序比文档重要，但是软件开发过程中的文档编写也很重要，因为大家都是先读文档才去用软件的。
