Beta冲刺——答辩博客

这个作业属于哪个课程	2020春软工实践|W班
这个作业要求在哪里	作业的要求
这个作业的目标	团队及项目简介
作业正文	作业正文
其他参考文献	无

一、设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

解决问题

• 由于疫情的影响，处在非常时期中的人们都不得不面临一个问题:远程教学/办公。体验了一周网络授课后我们的直观感受就是：APP和网页太多，来回切换复杂繁琐，没有办法一次性获取所有学科相关信息。这导致学生有些时候会忘记一些待办事项，比如某科作业没法及时完成，又或是某一个项目变更相应要求后没有及时看到变更的通知。如果没有一个APP能够兼顾所有功能，那么就必定会导致学习和工作效率下降，对于使用者来说体验也非常不友好。既然没有，那么就应该有，也必须得有一个能够直观显示所有信息并且加以提醒的软件，既能改善用户体验，又能拯救拖延症，于是便有了这个项目——Done。我们的想法就是把安排融入到日历当中，最直观的显示对应日期的计划以及各种事项。

定义是否清楚

• 我们对软件的定义比较清楚，明确是一款计划发布的软件应用

是否对典型用户和典型场景有清晰的描述

• 有一个核心案例，最能反映我们开发此项目的原因
• 某大学生 陈某
  学校正式开展线上教学，但是由于是第一次进行此类型的教学方式，导致每门课程没有统一的教学和作业发布平台，许多科目的事情混杂在一起会很容易忘记某科作业，于是陈某便开始使用日历来记事，但发现日历上能写的事情不够多并且显示不够直观，在经过他人的推荐下开始使用Done来管理学习相关计划...

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

原计划的功能

• 计划、小组和用户功能基本完成

是否按照原计划交付时间交付

• 除了部分数据交互时间在缓冲时间完成之外基本上按时交付

原计划达到的用户数量达成情况

• 本阶段有几十人参与试用体验，总体符合预期

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

质量是否提高

• 吸收了上次冲刺的经验，质量有所提高

具体提高的秒数

• 有关任务量化更准确了，与当初最开始学习框架还很陌生的状况完全不同，不会因为一些很基础的问题讨论半天，基本上现在问题解决都很迅速
• 有关代码部分，前后端代码都进行了一定的重构，保证代码质量有一定程度的提升，比如后端就修改了接口的一些格式和效率复杂度等

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

• 用户的试用反馈来看基本符合我们当初预想，不出彩但是功能够用，用户量可以说也是差不多符合预期，但通过beta冲刺我们的确在不断向目标前进

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 经验教训
  有关后端部分，接口定义一定要十分准确，并且后端接口完成后要及时补全相关文档，与前端联调，保证效率
  前端部分则是一定要留足时间以保证应对网页架构临时需要变动的情况
• 改进
  组小组的最开始就要找好各有所长的人，而不是像我们组一开始全是只会后端，搞得最后前端部分比较狼狈

二、计划

1. 是否有充足的时间来做计划?

事前准备计划

• 我们预留了较多来准备此阶段计划，文档部分也完成的还可以

进行计划

• 整个阶段对每天的计划分布是经过组员讨论合理后得出来的安排，所以每个计划对于每天是否能够完成的指标来说都是有足够时间的

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

• 通过组内讨论，交流然后进行表决，最后少数服从多数，最方便的解决办法

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

• Beta阶段在计划内没有完成的工作就是登陆部分的数据对接，因为和预期设想的使用方式有区别，加上服务器不知道为什么一直会挂载错误，导致功能还在维护中

4. 是否每一项任务都有清楚定义和衡量的交付件?

• 每一项任务都在文档上有清晰的要求，比如上传接口测试完成的图片，并附上文字说明等最基本的衡量要求

5. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

• 整个项目出的意外就是时间分配不断推迟，导致原本的一些任务工期都普遍延后了1-2天，带来的影响就是未完成的部分
• 当时并未设想到前端人手不足的情况下会带来这么大的压力，一度面临前端可能部分功能搁置的风险，主要原因还是组内没有拥有相关前端开发经验的人

6. 在计划中有没有留下缓冲区，缓冲区有作用么?

• 本次预留缓冲区时间较上次少，事实证明，缓冲区还是越多越好，计划赶不上变化

7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 有关前后端交接真的是很难预估的一个环节，要是再重来可能希望在对接的时候提高交流的有效性，比如通过每天写总结文档总结当天交接情况等

三、资源

1. 我们有足够的资源来完成各项任务么?

时间

• 上阶段彻底熟悉框架后，本次分离开发的部分可以说时间比较充裕，交接联调部分勉勉强强

技术相关

• 技术感觉还是有所欠缺，特别是前端开发过程中遇到的问题比较多

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

• 通过小组内讨论与网上搜索相关项目开发经验分享，从而确定出具体的时间和其他资源所需量，并且在任务中不断完善，总体来看精度尚可

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

• 测试部分可以说时间部分勉强够用，人力资源由于向其他组进行交流，共享了一些技术心得方面等资源，所以比较丰厚，但有关编程外的部分比如文案UI等没有专门人员负责，导致有些部分反而耗费大量资源并且没有实现预期效果，落差较大

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

• 参考了下其他组的情况，可能还是要看个人能力，有些工作确实要让更适合的人来做效率会提高

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 对于资源方面，宁愿多算也不要少算，永远留下一个所谓的“提前量”
• 改进的部分就是对于任务资源分配方面要确定好难易度来更恰当分配资源，这样才能提高整体效率，而不是将资源平均分配

四、设计/实现

1. 项目是否经历重构？为什么需要重构？

• 有部分前端页面的vue组件以及计划功能模块小幅度重构，其实只是将原本混杂的代码进一步细分，并且在此基础上继续开发

2. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 单元测试：十分有效，能很直观表现出开发最终成果是否正确，并且定义起来也比较方便
• UML部分：由于在开发过程中有一些比较难实现的，或者有冲突的功能模块部分，所以需求时不断在变化的，我们的UML文档相比最初也有一定的变化，但并没有非常多

3. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

• 在小组功能模块部分Bug最多，因为小组部分进行的跨模块交互是最多的
• 由于我们的服务器一直配置不好，其实并没有很正式的一个发布，一直遇到的bug就是出现登录失败的情况，当初确实没有很好的考虑到这方面的情况

4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

• 代码复审是由一个负责人进行复审的，基本上大家编程习惯都逐渐适应了，所以执行的比较好

5. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 设计与实现都是开发过程中十分重要的环节，要整个小组一起不断学习，共同探讨存在问题才能更好的完成任务
• 对于一些欠缺的功能，可能还是需要更多的组内讨论来重新定需求之类的设计方面问题

五、测试/发布

1. 和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？

• 提高的部分可能就是实际参与测试的人数，毕竟是直接发放给其他人进行实际使用体验软件功能

2. 团队是否有一个测试计划？为什么没有？

• Beta阶段计划的测试就是通过给其他用户进行实际使用来反馈测试

3. 团队是否有测试工具来帮助测试？

• 前端：一些chrome的插件以及其他原生浏览器
• 后端：Junit，POSTMAN

4. 团队是如何测量并跟踪软件的效能？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

• 实际上有关我们软件的效能部分并没有很有效测试，但是在运行的实际结果来看，我们小型的使用规模基本上软件效能能够有效支持运行

5. 在发布的过程中发现了哪些意外问题？

• 服务器部署问题，在博客中基本上从开始部署那天就每天都有反馈

6. 我们学到了什么? 如果重来一遍, 我们会做什么改进?

• 测试部分是软件开发必不可少的一环，并且测试并不是出现问题就一定是坏事
• 服务器方面可能会考虑重新寻找一个而不是用之前的服务器，并且有关方面要提前请教

六、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

• 通过组内每个人自己意愿并且结合实际人员掌握技术进行角色确定，基本上每个人都能够较好的适应角色

2. 团队成员之间有互相帮助么？

• 由于我们开发项目经验较少，所以组内在开发时交流很多，经常互帮互助，解决一些问题，共同进步

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

• 我们小组经典投票，少数服从多数

七、总结

1.组员们自我总结

• 221701127(李昊天)

• beta冲刺重温了后端整体部分，之后主要负责了服务器配置和项目部署方面，重新熟悉了linux系统的相关操作和阿里云服务器的使用，深刻的认识到就算只过了几天不用，知识还是会忘的，以后要多做点备忘录

• 221701138(林亿祥)

• 有关vue的知识部分以及以前掌握的前端内容对于项目开发来说还是不够用，在经历此次项目开发后我会继续学习前端相关知识框架等，并且争取在beta冲刺结束后继续维护与优化我们的项目，希望能够长久的使用下去

• 081700308(付其佳)

• 在这次beta冲刺中我学到了很多也收获了很多，我感受到在实际编码前的各种工作对后续的冲刺非常重要，运用好框架编程事半功倍

• 221701425(黄杰辉)

• beta阶段学习了有关session方面的知识，并且编写了相关接口来完善用户登录部分，虽然也学习了token相关内容但发现碍于时间限制还是选比较方便的进行开发，经过这次项目经验后个人觉得收获颇丰，后端技术有所提升

• 221701434(曾峻祺)

• beta阶段冲刺进一步学习了ssm框架以及与前端的数据交互，在冲刺阶段不会的问题大家都会一起商讨，同时也体验到了SSM框架给我带来的便利以及分而治之，是一次很不错的团队配合以及难忘的经历

• 221701438(黄懋贤)

• beta阶段冲刺进一步学习了vue前端以及前后端交互，在冲刺阶段遇到困难大家都很互帮互助，从中认识到团队协作的重要性，总之这是一次难忘的经历

2.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

• 目前团队的状态应该属于可重复级(Repeatable)

3.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

• 经历两个阶段后应该属于磨合与规范中间的状态

八、提高软件工程的质量

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

代码管理

• 尽可能用较少的人数来进行管理，保证代码管理标准的统一性

代码复审和代码规范

• 复审则是需要尽可能多的人对不同的部分进行复审，规范制定方面则是要全部人员参与，各抒己见，交流得出最优的代码规范，并且有选择性的接纳他人的编码习惯

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

• 整体程序架构应该通过相关资料查询，修改一些内部类的结构与使用，从而提高其架构
• 衡量通过代码总量，运行时占用内存与速度等指标来进行判别

3. 其它软件工具的应用，应该如何提高？

• 通过不断使用，在熟悉中熟练

4. 项目管理有哪些具体的提高？

• 时间部分与任务具体贡献比部分需要再多考虑，特别是任务量化部分需要再三考虑再下最终定论

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

追踪

用户设置部分提供较合适的问卷，并且在使用中定时发送请求让用户反馈使用体验

用户数据相关

通过用户状态更新等数据库方面的数据变化来了解用户相关数据

6. 项目文档的质量如何提高？

• 多写，并且多学习其他组的文档是如何撰写的，结合自身不断撰写的经验与其他组的成品来提高质量

7. 对于人的领导和管理， 有什么具体可以改进的地方？

• 有关任务完不成的部分应该要有严格的惩罚机制，保证项目进行中能够有序高效

8. 对于软件工程的理论，规律有什么心得体会或不同意见？

• 文档方面格式要确定下来，避免不同组员的文档撰写习惯不同导致文档最终样式不堪入目
• 代码方面要有选择性的参考与借鉴，而不是盲目的ctrl+c，v来使用他人的代码