8组-Beta冲刺-总结

https://www.cnblogs.com/xiao-qingjiang/p/15616868.html

一、基本情况

现场答辩总结：
根据老师的指导和建议，我们充分认识到了我们的不足。
一是工作量不足，在这次冲刺中我们仍然没有很好的完成这个项目，前端效果和UI设计还需要进一步改善；
二是产品的测试需要加强，还存在一些bug；
三是产品的展现，在答辩展示时，选取的例子需要具有代表性。
非常感谢老师和同学们的建议。

全组讨论的照片

评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，组长得分减 50%）

姓名	分工	预计贡献比例
肖清江	产品经理	8%
刘璐瑀	策划组	8%
赵威威	策划组	6%
黄慧卿	策划组	8%
刘凌斌	后端	11%
李忱轩	后端	11%
陈松庆	后端	13%
黄海涛	前端	10%
田剑心	前端	11%
杨潮湧	前端	14%

二、总结思考

2.2.1 设想和目标（4分）

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

  • 解决的问题及定义：为有强烈使用需求的外地务工人员及其子女，以及缺乏学习环境和学习指导的在外闽南青少年提供学习闽南语的辅助平台
  • 典型用户：有强烈使用需求的外地务工人员及其子女，以及缺乏学习环境和学习指导的在外闽南青少年
  • 典型场景：使用者打开软件便可看有关闽南语的推文了解闽南文化，也可以打开闽南乡音歌曲感受闽南风情，还可以读出自己不理解的闽南语进行查词学习其中文意思，闲暇之余还可模仿闽南歌曲等进行个人作品录制，录制之后可以得到其有关读音准确性的评分。

• 我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
  目标基本完成，接下来主要是进一步优化和debug。
  有按照原计划交付时间交付，原计划达到的用户数量尚未达到，因为还未上线，所以用户数量尚未达到原定目标。

• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  由于产品未上线，还未推广和产生用户，难以评估是否用户对重要功能的接受程度和我们事先的预想一致。
  离目标更近了，功能实现和预想的没有太大偏差，很快应该就能够上线。

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  UI设计较为手忙脚乱，如果历史重来一遍，会在一开始的时候先确定好界面设计的风格，再有所针对性地去寻找相关素材以便后续进行相关设计。

2.2.2 计划（5分）

• 是否有充足的时间来做计划?
  有，计划的时间还是比较充足的，可以进行相对细致的规划。

• 团队在计划阶段是如何解决组员对于计划的不同意见的？
  经过协商讨论，如果认为某计划不可行，欢迎提出理由和新的方案，其他成员共同思考，最终得到能让大家认可并愿意执行的计划。

• 原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  原计划的工作成功完成，没有未完成的，但完成质量不够高，接下来还需要进一步的优化。

• 有没有发现做了一些之后看来没必要或没多大价值的事?
  有些需要大家共同参与的博客都是让成员发文档给负责人，也许直接发聊天框可能更方便哈哈，就不需要打开文件了（懒人操作）。

• 是否每一项任务都有清楚定义和衡量的交付件?
  每一项任务都有清楚定义，并给了每项任务的审核指标，完成任务需要达到审核指标。

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  项目的一些子任务的交付时间和原计划有出入，主要是由于当时没有考虑到这两周考试很多（零零总总加起来有四门考试，大部分同学都有一到两门），因此考试的备考时间没有考虑到计划里，导致后期的进度比较赶。

• 在计划中有没有留下缓冲区，缓冲区有作用么?
  留下了一天的缓冲区用于debug，但这个缓冲区被考试备考时间占用了，似乎没有发挥原有的作用，但缓冲了考试备考时间。

• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  结合接下来时间的考试、其他课程的作业安排以及同学们的比赛或训练情况等进行进一步更细致化的规划，留出合适的缓冲区，在紧急时候可能会开展加班。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  配置云服务器的难度预估不足，导致预留的时间不足，出现了一些意外之外的配置问题，如果历史重来，会留出更多的缓冲时间以免出现意料之外的问题。

2.2.3 资源（3分）

• 我们有足够的资源来完成各项任务么?
  有，我们的任务所需的资源都是可获取且容易获取的，可能比较紧张的资源就是组员们的时间资源了，毕竟这学期课多考试也多，还有其他课程有大作业。

• 各项任务所需的时间和其他资源是如何估计的，精度如何?
  会根据每项任务先进行评估，评估的指标包括完成这项任务是否需要学习未掌握的技术、学习的时间成本、完成的时间成本、以及完成任务需要哪些资源（如框架、接口以及其他成员需要提供哪些资源（如接口）等）。

• 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  人力和软件/硬件资源是足够的，而测试时间比较紧张，测试并不是特别完善。
  不需要编程的资源 (美工设计/文案)都分配了比较充足的人员进行完成和审核，总体还是比较合理的。

• 你有没有感到你做的事情可以让别人来做（更有效率）?
  可能让其他人做效果会更好，毕竟我的文字功底挺一般的。

• 有什么经验教训? 如果历史重来一遍, 会做什么改进?
  一开始的云服务器没有先去处理，直到需要部署才开始去找，导致了进度有点紧张，再加上部署过程遇到了一点问题，如果历史重来，会在部署前做好前期准备工作，预留充足的时间进行部署。

2.2.4 变更管理（4分）

• 每个相关的员工都及时知道了变更的消息?
  有，每次都会通过qq群进行通知，对于没有看到的同学会私聊提醒。

• 我们采用了什么办法决定“推迟”和“必须实现”的功能?
  根据紧急程度和依赖关系进行决定，比如某个功能的实现必须在前一个功能实现的基础上开展（即该功能依赖前一个功能），那么该“前一个功能”就是必须实现的；
  如果某个功能与其他功能无关且并不紧急，便是可以“推迟”。

• 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  针对每个小功能做出了清晰的功能出口条件，但对整个项目的出口条件还未给出明确的定义。

• 对于可能的变更是否能制定应急计划?
  理论上是能的，但在执行过程中似乎这个应急计划并不是很有效，因为我们这次的工作便不是完成的很好，希望在接下来的工作里能够做好更合理更有效的应急计划。

• 组员是否能够有效地处理意料之外的工作请求？
  这取决于组员们的时间安排，如果最近有考试的话就有点难度，如果没有都是可以有效处理意料之外的工作请求的。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  做好应急备用计划，以免不时之需。

2.2.5 设计/实现（4分）

• 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  设计工作有产品经理，前端、后端、UI的负责人在充分吸取组内成员的意见后进行讨论完成的，在alpha冲刺的第一天完成总体规划，第二天完成较为细致的规划。
  是合适的时间，也是合适的人。

• 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  有，经过讨论后确定采纳一种确定的方案。

• 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  我们使用startUML来进行辅助设计，虽然因为后续添加功能，使得uml图做了太多修改导致进展缓慢，但是我们通过uml更好的理解了需求，懂得如何体现需求、业务逻辑设计与验证和测试，具体实现等不同角度的异同，良好的uml可以让我们从不同的角度去理解软件系统，对于学习软工实践卓有成效。

• 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  我们的uml进行了多次大幅整改，因为需求的扩展和某些功能在技术上无法实现，导致我们一直更新uml设计，同时还面临着结构冗余等设计问题，也导致了我们大幅修改uml，在最后的设计图里，我们得到了更好的后台响应速度。

• 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  语音识别和语音评分的功能出现bug最多。首先是因为调用接口时所需求的音频文件参数较为复杂，在调参时容易忽略部分，导致音频文件难以识别。其次是，前后端交接时，由于前端所发来的音频文件与之前所准备的样例文件有一定区别，需要再度调参后才得以使用。发布后，由于之前考虑的都是音频能识别出的情况，忘记考虑音频识别不出来，字段为空，会导致报错，返回评分出现问题。

• 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  代码格式及代码复审，代码格式由于在实现前有过一定协商，且实现时各成员之间采用分层实现。各成员在写好函数后会将实例备注在前面，方便上一层成员调用函数。以至于在各层交接过程中有充分的沟通，对于代码格式也有协调。最后复审时，走马灯地过一遍代码，没有太细致的审核。

• 学到了什么? 如果历史重来一遍, 我们会做什么改进?
  在本次团队作业中，我们学会了使用一些新的语言技术和新的工具。
  新的语言：pymysql、mysql、
  新的工具：navicat、亿图图示、InnoDB存储引擎、Dbeaver、gunicorn、
  新的技术：python爬虫、ffmpeg、gunicorn并发
  也遇到了很多的困难，或在代码面前思考人生。
  主要困难：（1）数据库设计结构不够清晰明了，在前期的搭建过程中，浪费了很多时间
  （2）前端同学对于微信小程序开发不够熟练，在获取录音数据和进行前后端音频交接过程中遇到了较大的困难。
  （3）前期对于产品定位不够清晰，UI设计人员对于产品架构没有完整设计，前后端开发人员只能摸着石头过河。
  如果历史能够重来，我们会：
  （1）对产品清晰定位，完整做好开发文档，整合出一个个的大任务和小任务
  （2）小组每个成员都制定合理的开发计划，在制定的开发周期内完成任务。
  （3）需要加强自学能力，多开展集中学习讨论。
  （4）开展小型团建活动，增加开发人员之间的联系和接触，以此提高开发效率。

2.2.6 测试/发布（3分）

• 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
  我们有一个粗略的测试计划，准备在终版前完成，目前由于部分逻辑功能还在实现，暂时未进行正式的验收测试。

• 团队是否有测试工具来帮助测试？
  我们通过postman进行接口测试，用httperf进行基本web性能测试，使用Siege进行压力测试

• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  我们使用httperf进行web容量测试，由于我们作为小团队不能承担高配置服务器，检查到后端服务器与数据库服务器在高并发时有明显卡顿

• 在发布的过程中发现了哪些意外问题？
  服务器后端配置与环境调试往往出现很大问题

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  学到了大量的团队配合相关知识，如果历史重来一遍，我会用这次的经验弥补不足，进行更完善的开发准备

2.2.7 团队的角色，管理，合作（3分）

• 团队的每个角色是如何确定的，是不是人尽其才？
  根据大家所拥有的技术栈和以往的实践经验，以及大家未来想要发展的岗位来进行确定角色，做到了人尽其才，也复合大家未来发展的需求。

• 团队成员之间有互相帮助么？
  有的，当有同学进度难以赶上时，空闲同学会主动伸出援手。在不同分工方面遇到问题，我们会互相帮助进行搜寻资料寻找解决方案、

• 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

肖清江：
我非常感谢刘凌斌同学对我的帮助，他在我遇到一些特殊情况时能够帮忙组织起大家推进任务，我们无论是之前合作的结对编程，还是这次的团队作业，合作都非常愉快，非常期待我们的下一次合作。

李忱轩：
我感谢陈松庆对我的帮助，在测试接口环节，他付出了大量的时间进行对接，使得前后端接口交互得到实现。

陈松庆：
我很感谢李忱轩同学对我的帮助，在Beta冲刺中，李忱轩同学作为后端组的绝对核心，不仅与前端有良好的交接，还在后端的工作中带头冲锋，为大家工作起了巨大作用。

刘凌斌：
我很感谢肖清江同学对我的帮助，在Beta冲刺中，肖清江同学作为产品经理，在前端和后端之间起到了很好的桥梁作用，前端和后端围绕产品经理对产品的设计进行开发。从结对作业到现在的团队工作，我们的team都是good。

杨潮湧：
我感谢田剑心对我的帮助，因为某个具体的事情：之前碰到过两个界面需要在跳转后进行数据传递的问题，一开始没什么思路，后面请教了剑心，推荐我直接使用全局变量来完成对应功能，还手把手教我怎么敲代码。

黄海涛：
我感谢杨潮涌对我的帮助，在beta冲刺的最后两天一起codeing交流方便，帮我解决了很多代码里的bug。之前没有完成的功能也在潮涌的指导下完成了。非常感谢。

田剑心：
我感谢陈松庆对我的帮助，因为某个具体的事情：在冲刺阶段，为了方便我调试接口，他和我一起找地方熬夜测试。

赵威威：
我感谢肖清江对我的帮助，因为在之前制作PPT的过程中，有一些部分不知道在怎么部署，他详细地为我解答，也提出了一些建议，十分感谢。

刘璐瑀：
我感谢黄慧卿对我的帮助，我们一起与前端的同学进行及时的沟通。

黄慧卿：
我感谢刘璐瑀对我的帮助，我们一起与前端的同学进行及时的沟通。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  时间和进度安排不够合理，如果历史重来，会更好地进行规划和推进进度。尽早与后端进行对接和接口测试，并合理分配相关接口测试工作，积极跟进各组员进度，做好监督。

2.2.8 总结（4分）

肖清江：
这次的beta冲刺中，进一步push了兄弟姐妹们，非常感谢大家的配合，beta冲刺取得了一定的成果。大家都很给力，每天都能看到新的工作进展。而组内互帮互助的氛围也很好，和大家一起工作非常愉快。

李忱轩：
我很感谢这次队友对我的支持，在最后几天的测试环节大家都心疲力尽，幸好队友给力，每天都能看到新的进展，我一开始以为对接工作相对简单，结果在使用和测试过程中，总是难免出现奇怪的意外，在这次的beta冲刺中，每天几乎都有人要参与考试，安排时间等，队友们能够腾出时间来进行逻辑测试等，每天都能看到新的成绩，不同的工作总是面临着不同的挑战，希望下一次面对相同或不同的工作能够以经验支撑，经得起更多的训练

陈松庆：
很感谢队友们的帮扶，最后几天都是修bug到两点，真是人都冲麻了。幸好有着队友一起麻，看一下就感觉大半夜的冷空气真是清新舒畅。缓解了坐电动从创咖到西三再到宿舍楼活动室被冷风敲打的痛苦（划重点）。最后一天从下午院楼写到西三，西三再回宿舍，到宿舍拿个充电器又去食堂，吃完饭去创咖，创咖关门去西三，西三被阿姨赶走去活动室。朴实无华的一天却给我的微信步数记录添上了浓墨重彩的一笔。这里也得感谢队友的电动车，换自行车的话，浓墨重彩就得变成罄竹难书了。最后，还是感谢队友的努力和付出。

刘凌斌：
很感谢队友们对我的帮助和支持，我们一起见证过凌晨的福大，一起抱怨过项目开发的难度，我们之中很多同学接触的都是新的东西，需要学习的内容也是非常的多，虽然我也很想吐槽我们小组的小程序界面实现的效果，但终究是自己小组的成果，还是自己的娃。在项目开发中，我的主要工作是数据库的搭建和维护，答辩大会上的数据库接下去计划，上面的“保证数据库增删改查”是个意外，制作ppt的同学的小失误。现在数据库的进度应该是进行数据维护，还有想法设法优化数据库代码。

杨潮湧：
作为前端负责人，在本次beta冲刺中，对于组员项目进度的监督力度不够，导致前端部分进度较慢，同时与组员交流不够多。除此之外，我对于前端与后端和UI的对接工作，有了更加清晰的认识和理解。在实际编程过程中，也通过查看官方文档、搜索网络资料和询问相关方面的资深大佬进行学习，对微信小程序中js的使用及相应api的应用也有了更深的领悟。

田剑心：
通过本次β冲刺，完成了前端我负责部分的全部内容，但是由于一些未知的问题，访问服务器的效率很低，总之就是很奇怪。通过本次项目经历，我学到了很多开发方面的知识，也学会了的团队协作。

黄海涛：
beta冲刺更有紧迫感，因为之前留下的问题较多，时间更少。这一周的工作因为之前没有和后端交流好，所以调用接口时磕磕绊绊的，浪费了很多时间。最后两天在 ddl的催促下进度明显加快许多，甚至最后一晚熬夜加工完成。首先承认自己态度的懒散和时间分配的不足，但是还是觉得这门课的一学分让我花远超一学分的时间先学新技术，再自己重新开始的模式非常的阴间。

赵威威：
BETA冲刺阶段的时间我找了很多PPT模板，又复习了很多剪视频的技巧，周五晚上剪得时候本来以为会花费特别久的时间，但自己做完算了时长发现比之前的速度快了不少，比较开心。百度和B站大学永远的神。以及在制作PPT过程中，不断地思考怎么做才能展示我们的亮点，但比较可惜的是，最终还是被老师评价看不到我们突出的亮点，希望在最终的答辩环节，能够让老师看到。

刘璐瑀：
在上次alpha冲刺中，我们以及完成了页面设计，此次冲刺，重点是与前端的同学交流，解决界面还原度不够高的问题。在沟通交流中，体会到了每个人对同一页面设计的不同理解，更加体会到沟通的重要性。经过这次软工大作业，我愈发坚定以后不做与前端、界面设计有关的工作，还是更喜欢编写、设计算法带来的感觉。

黄慧卿：
我们的主要工作在上一次冲刺中基本完成，这次冲刺主要是与前端同学进行交流，协助他们还原界面。原本以为设计好界面交给前端同学，我们设计界面的工作就算完成，但是后面发现页面的背景透明度，布局，逻辑等还需要与前端同学进一步沟通交流。经过此次冲刺，更深刻体会了ui设计这个角色，也更坚定了自己以后不做前端工作人员的想法。