字节乱动--团队作业六:alpha阶段问题总结
字节乱动--团队作业六:alpha阶段问题总结
| 这个作业属于哪个课程 | 2021春软件工程实践|S班 |
|---|---|
| 这个作业要求在哪里 | 团队作业六——beta冲刺+事后诸葛亮 |
| 团队名称 | 字节乱动 |
| 这个作业的目标 | 记录alpha阶段存在的问题并总结 |
| 其他参考文献 | 无 |
| 汇总博客 | beta冲刺+事后诸葛亮博客汇总 |
一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
-
我们的软件旨在根据软件工程实践这门课程的过程，订制一套从寒假的预习作业、结对作业到后来的个人作业、团队作业的评分系统，帮助老师、助教批改学生的博客作业、管理学生成绩，并为学生提供答辩互评的平台。解决《软件工程实践》的助教们在每次评分过程中繁琐的统分计算，同时方便老师、同学们能有一个统一的评分方案，开发此评分系统。既能让助教从繁琐的任务中解放出来，又能更加系统、公平地进行组内、组间打分。
-
定义很清楚，且对典型用户（《软件工程实践》助教，老师，学生），典型场景（各次个人作业，结对作业，团队作业）有清晰的描述。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ )
我们计划，完成登录模块，细则管理-新增细则， 细则管理-所有细则，学生管理-新增学生，学生管理-所有学生，团队管理-新增团队，学生模块-作业提交，成绩管理-博客评分， 成绩管理-成绩查询。实际上已经全部完成且按时间交付，但是还存在许多问题，体验不够。
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?如果历史重来一遍, 我们会做什么改进
-
安卓端：大体一致，离目标更近。如果重来，一方面会把前后端接口规划得更具体、更清晰，参数、属性命名更优雅、更规范，数据类型更得体。另一方面会更加重视测试的编写。
-
web端：大体上一致，但是很多方面还需要改进，比如新建班级，成功与否，没有给出判断，在作业细则发布时，没有明确的限制输入的该作业占总分比，导致计算得到的成绩为几百分。没有我们离目标已经很近了（
虽然剩下的路很艰辛），如果历史重来，我们会选择重新把更多的精力放在测试上，宁愿，把一个个功能完成好，能够在处理各种情况，也不要完成了许多功能，但是也制造了许多bug。
二、计划
1. 是否有充足的时间来做计划?
得益于从团队成立初，需求分析开始，我们进行了许多次的规划，实际上我们有充分的时间来做计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
组长：积极沟通、讨论，互相理解、让步，尽量寻求能让各方都可以接受的解决方案。
一开始，我们通过会议讨论的细节，拟定初步计划，然后在充分讨论的基础上,通过投票等方式来决定最后的计划。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
- 组员1：原定的计划，完成90%，在完成某些预期的功能时，出现了许多未知的bug,某些功能的完成比想象的复杂如成绩统计与显示，还存在一些细节部分没有处理好。
- 组员2: 没有都做完。首先前期一直在划水，没有提前准备好，一方面是项目进度的问题，来不及做，另一方面是写测试用例文档花的时间太多了。
- 组员3：工作没能完全做完，前端代码仍有些许bug，但更关键的是与后端对接口的过程中发生错误，导致最后的进度没能完成。
- 组员4：计划都完成了，主要是自己负责的部分功能挺少的，如果现在再打类似部分的话应该挺快的。
- 组员5：原计划的工作还有一部分没有完成，因为导入依赖的时候遇到了一些错误，导致还没有完成，只能留到下一次完成。
- 组员6：做完了。
4. 是否每一项任务都有清楚定义和衡量的交付件?
- 每一项任务的衡量都依照原型设计和项目系统设计与数据库设计中验收标准。
5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
一开始前后端独立开发时时按照整个计划进行的，但是当前后端进行联合测试时，却出现了很多独立编程时未出现的问题，这算是前后端分离的风险，没有估计到的原因是团队的开发经验不足，错误估计了联合测试会出现的种种问题。
6. 在计划中有没有留下缓冲区，缓冲区有作用么?
- 成员1：有留下缓冲区，虽然只有十天的博客，但是团队成员常常需要熬夜加班，修复bug。
- 成员2：高级词汇，没听说过。只知道代码里有BufferedInputStream、BufferedOutputStream、BufferedReader、BufferedWriter。
7. 有没有发现你做了一些事后看来没必要或没多大价值的事?
-
组长：为了更方便地收集和统一处理网络请求成功的返回数据或异常情况，花费1天时间，封装了一个Result密封类，并为其写了调度适配器CallAdapter和转换JSON数据的Converter转换器，但使用起来并没有想象中的那么方便，反而为查看原始json数据、处理空字段等添加了麻烦。
-
组员1：测试用例文档写的太啰嗦了，费时费力，感觉还不如用markdown简单写一写，感觉有bug及时反馈才比较重要。
-
组员2： 开始时对界面的导航栏进行手写代码，后来同为前端的达明把他自己写好的框架直接发过来，就使得自己本来的框架没有意义（因为不统一且自身做得不够美观）
-
组员3：Debug过程中自己将本不需要改为json格式的数据改成json格式，导致一个晚上都在找错误（后来是后端的曹鑫一眼看出毛病）
-
组员4：手动写了一次分页查询，没有用插件，感觉麻烦还不好用。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
- 组员1：增加测试在项目编写中占比，每一个功能需能够处理各种情况。
- 组员2：由于期末各方面压力都比较大，因此考虑增加缓冲区比例。
- 组长：动手前把前后端接口先商量好，什么数据类型什么字段名称，不要在对接口的时候发现两人的想法完全不一致，然后重改一大堆。
9. 我们学到了什么?如果历史重来一遍, 我们会做什么改进?
刚开始冲刺的时候，对前端还不是很熟悉，导致开始前几天效率很低，大多数时间都花在学习知识上，边看边做了几天后，通过和团队内成员的沟通和学习，逐渐有了一些起色，慢慢的完成了一部分，但是还是遇到了一些暂时没有解决的bug，于是也开始有一些灰心，但是总体这次alpha冲刺还是很好，让自己有了很多学习的动力，也不想在团队里拖大家的后腿。从第一次软件工程的作业到现在，我仔细回顾了一下我的学习历程，发现自己对前端并没有一个系统化的学习，只是做到哪里学到哪里，遇到不会的就去单独处理，学起来不是很理想，但是让我对前端开发这一块有一个大概的认识，也让我对前端开发产生了兴趣，在这之前我并没有一个明确的方向，是软件工程这门课让我找到了自己今后的大致方向所以我之后会计划系统性的去学习前端开发。本次软工实践让我接触到了vue和layui的应用，在团队中有人开发能力强，有人开发能力弱，在尽可能的情况下像我这样能力偏弱的要多请教能力强的人，这样对开发中遇到的问题能够加深理解，并且让团队有一个更好的凝聚力，一个合作无间的团队才能够更高效的完成任务。
三、资源
1. 我们有足够的资源来完成各项任务么?
- 分开看，我们拥有的人力资源是足够完成各项任务的，当时合起来，人与人之间的交互也是一种资源的消耗，因此实际上，我们还是需要充分的利用有限的时间，才能完成各项任务。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
- 组员1：与完成相应任务的负责人商讨估计
- 组员2：经验主义居多，虽然大部分情况下精度适中，但是在某些情况下精度还是有一定的差距。
- 组长：主要靠负责人的个人经验和个人感觉来预测，至于精度，可能会存在一到两天的误差。
3. 测试的时间，人力和软件/硬件资源是否足够?
-
组员1：测试的时间，人力资源不够，考虑将开发人员也纳入测试人员中，可以功能间交叉测试。
-
组员2：测试时间、软件资源在Alpha阶段应该是不够的，人力和硬件资源还得进一步分析一下。
-
组员3：测试的时间感觉不是很够，因为在alpha阶段完成整个初步阶段就花了不少时间。
对于美工设计低估了难度，要使人机交互界面变得友好确实比只完成基础功能要难得多，并不是找一个框架套上去就能行的
-
组长：人力、硬件资源足够。测试时间还可以多一些。对不需要编程的美工等资源并没有多大的需求，前端能够搞定。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
-
组员1：我感觉让谁做都比我有效率。(捂脸)
-
组员2：很有感觉，自己刚开始做前端经常感到迷茫，有很多不熟悉的例如数据的传输ajax的使用，，自己第一次编写的时候就用了几个小时在改代码，让身为前端的达明同学帮我改只需要讨论一下（描述问题，看代码），几分钟就解决了。
-
组员3：如果让后端的组长来做应该会更快，我的那部分编程量不是很多，自己花的主要时间是在清楚项目结构和数据库类和数据关联理解上。
-
组长：没有
四、变更管理
1. 每个相关的员工都及时知道了变更的消息?
- 组员1：在例如数据库字段发生更改时，直接相关人员，都能第一时间知道变更的消息，但是某些后面编程涉及相关内容的人员可能知道变更的消息可能就没有那么及时。
- 组员2：并没有，比如代码有做改动的话代码没有及时地提交到github上或通过其他手段公布。
- 组员3：还算及时，我没碰到什么问题
- 组员4：如果有变更的话确实会比较麻烦点，主要是前后端负责同一个模块的人自己交流。由于部署的环境和自己电脑上的有出入，加上自己不能马上将修改的东西重新部署，容易出现接口对接问题。
- 组长：及时，延迟通常不会超过1小时。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 组长：我们采用功能相关负责人会议商讨，投票决定”推迟“和”必须实现“的功能。
- 组员1：根据任务难道。最简单基本、强烈要求的功能必须优先实现，困难的、可能导致任务延期的、可有可无的会延迟。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
- 组长：目前项目可以在正常的输入数据中，完整进行操作，但是离完全做好，还有所距离，对一些数据处理不合理。
- 组员1：通过自己写的单元测试、交接时没有出现别的错误就算做好了。
4. 我们学到了什么?如果历史重来一遍, 我们会做什么改进?
变更管理随着项目的进行而越加重要，我们还是需要更好利用github等来管理项目，多进行小而具体的commit,这样能够对项目的变更做到更好的管理。
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是按照软工实践课程的安排进行的，包含字节乱动——团队作业三需求分析和 字节乱动-团队作业四项目系统设计与数据库设计这些部分，是由团队所有成员共同实现的（当然工作被拆分成不同的模块分配给组员）。总的来说，是合适的时间，合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
-
组员1：在设计工作中肯定会碰到模棱两可的情况，我们团队一般会互相讨论一下，争取能有一个皆大欢喜的解决方法，到目前为止还没有出现争执不休没法解决的情况
-
组员2：这个记得不太清楚了，大概是讨论决定的吧。
-
组员3：主要是一个人给出建议解决方案，大家感觉行的话就按照这个样式去做。
-
组长：有，没必要的先搁置，必要时讨论出最终结果。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
设计阶段使用了uml帮助设计（字节乱动——团队作业三需求分析和 字节乱动-团队作业四项目系统设计与数据库设计博客中就有放一部分uml图）
单元测试在实际开发阶段有使用，虽然我们开发采用的是敏捷开发，但是并没有使用到测试驱动开发（TDD）。
这些工具对设计和开发还是很有效的
项目开始的 UML 文档和现在的状态相比，活动图的活动描述做了一些微调，主要原因是设计时一部分内容没有进行清晰的定义与描述，所以后面进行了修正。需要更新UML文档
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
-
组员1：个人博客评分这一块Bug比较多，因为这一块原本的实现想法是获取博客园文章的内容（后来发现博客园有反爬取机制），计划被打乱造成手忙脚乱，这一部分的工期也比较赶。
-
组员2：测试阶段，我感觉助教细则管理模块的Bug是最多的，主要是增加细则和修改细则那部分的表单内容比较多，编码的时候如果没有全面考虑的话，修改或增加如果没有正确填写都容易出错。发布之后没有发现新的。
-
组员3：
针对自己写的用户列表部分，最坑的是在自己的助教管理列表中的删除功能，不是bug多，而是在点击删除后会直接把数据库里关于这个学生信息全部删除，包括另一位前端的那部分信息，当时自己把他删了之后害的队友出大错，最后还要让后端人员恢复数据库信息，导致了进度的延缓。
开发过程中自己不注意交互友好度，直接把信息删了是件十分愚蠢的事情，如果重新安排的话，应该要在删除功能上先要求获得用户是否有权限进行删除，并提醒他是否删除。
-
组员4：
我负责的模块是对接口的时候出的bug最多，因为当时接口文档没有太明确，加上没有讨论出现了类名冲突大忌，平白无故多了好多麻烦。发布后出的bug有的还待解决。
-
组长：
组间答辩评分的那个Fragment bug较多。一方面，这一块不能全部适用能有效减少bug的MVVM架构，如用来保存各项分数的数据结构需要自己在Fragment内管理，在出现配置变更需要重启Activity的时候很有可能出现数据不一致的情况，导致用户体验下降；另一方面，用来输入分数的滑动条Slider控件与外层的回收滚动视图RecyclerView存在滑动冲突，导致Slider的使用有时会卡顿，这个问题涉及到View的底层触摸事件机制，需要覆写原生的控件，解决起来较为棘手，且可能会引入新的问题。没有想到这些情况是因为之前没遇到过这样的问题，也没有更好的解决方案。
发布后没有出现重大bug。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审这一方面，首先提交自己的代码前每个人要再回顾一些自己的代码，具体的复审一般是由组内的技术比较强的成员组织的，写代码的人员会解释说明一下模块的功能、参数、实现思路，技术比较强的成员会读一下跑一下代码看看有没有问题。在测试过程中，测试人员也会对代码进行二次复审（由于时间比较紧没有进行完全）。代码规范基本上做的了严格执行。
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
测试计划的话，算起来是有的，但是比较粗略，在alpha冲刺结束前还没能很好的完成计划。
2. 是否进行了正式的验收测试？
有非正式的，正式的还没有，打算Beta阶段再搞。
3. 团队是否有测试工具来帮助测试？
-
Web端有Selenium(不知道拼对没)，Android端有Mockito、Espresso。
- Alpha冲刺阶段，原先的测试计划是用Selenium IDE来录制一些操作，比如简单的场景测试，用Jmeter做并发请求的压力测试，但是功能测试这边发现了许多bug，并且很多功能没有及时完善，就没来得及用这两个测试工具。
- 在Beta冲刺阶段，计划用Selenium IDE将一些已经完善的功能录制起来，比如细则查询、成绩查询等，用Jmeter做一些并发请求的压力测试，后者可以根据Aggregate Report、View Result in Table等工具查看结果，并生成测试报告。
5. 在发布的过程中发现了哪些意外问题？
没有什么意外，真要算的话，服务器500？
6. 我们学到了什么?如果历史重来一遍, 我们会做什么改进?
测试时间、测试计划在Alpha阶段应该都是远远不够满足要求的，beta阶段还需要增加人手。
七、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
- 组长：根据自己擅长的领域和学习兴趣。
- 组员：由每个人依照自己擅长或者喜欢的领域去分配位置，具体工作由某个人依照具体实际情况分配。
2. 团队成员之间有互相帮助么？
具体工作中肯定是有的，冲刺的时候我们经常聚在一起开发，有不懂的就可以及时请教
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
- 组长：沟通、理解、让步。
4. 我们学到了什么?如果历史重来一遍, 我们会做什么改进?
我学到的是接口文档一定要定义清楚，然后编写的代码尽量早点提交到github进行整合。具体功能模块的任务
一定得细分到个人身上。一个良好的团队编程环境也十分重要。
