一、基本情况

1.1组长博客链接

组长博客链接

 

1.2现场答辩总结

• 对于测试组对本组的提问/其他组或老师的提问都回答的比较合理，没有出现答不上来或者回答不令人满意的情况。

• 由于Alpha冲刺进度较慢，项目难度又大，导致大部分难的任务都堆积到Beta冲刺，所以这一周大家任务都很重，在Beta冲刺中完成了多个难度较高的任务如服务器搭建、数据库部署、接口调用等。在服务器部署上，我们要在华为云上配置好yolov5、alphapose、mysql、nginx+flask等；还要将后端核心算法封装调用接口传到前端，传输图片检测已经研究了好久了，实现视频传输更是难上加难。

• 组内沟通不够，应该学习别的组，每天把大家聚在一起完成任务。

• 分工也不够细致，所以一开始会有点不知所措。

 

1.3全组讨论的照片

 

1.4评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例

工作	姓名	团队分工	贡献比例
前端	韦宏麟	上传下载功能，数据同步，前端界面	12%
	林雨欣	ppt制作，素材收集	10.5%
	方静怡	ppt制作，素材收集	9%
	汪鸿宇	视频摘要界面，素材收集	9.5%
	江舒颖	接口测试，登录注册接口整合，界面整合	12%
后端+算法	黄新成	服务器部署，接口测试	10%
	林志锋	目标检测接口编写	10%
	邹其请	博客编写，接口测试	8.5%
	李晓芳	登录注册接口编写，数据库连接	10%
	张妍	接口测试，界面测试	8.5%

 

二、总结思考

2.1设想和目标

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

• 随着非机动车数量的急剧增长，危险驾驶行为屡见不鲜，交通监管压力日益沉重。《交通强国建设纲要》要求大力发展智慧交通，目前的非机动车监管过于依赖人力监管，在效能方面略显逊色，需要智能化>监管模式。现有摄像头注重于监管机动车，而忽略了大量非机动车的数据，处于“存而不用”状态。
• 我们的软件可以为交管部门提供科技辅助执法的创新方式，一定程度上缓解过于依赖”人力监管“的难题，智能化的数据统计分析、违规的筛查都是非机动车交通监管的有力武器。整体上说软件要解决的问>题和功能定义得比较清晰。
• “云视界——基于深度学习的道路信息检测”能够适用于公园、红绿灯路口、高校、公司、社区、停车场、公园、景点等场景，应用广泛。本软件面向交管部门的人员，为他们提供更加方便、智能的监管模式。
  
   

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

• 目标未完全达到。原计划的功能包括流量统计、头盔检测、脱把骑行检测、改装监查、视频摘要、行人检测、闯红灯检测等，这些功能在分离的情况下已全部实现，但在接口算法之间有冲突，所以不得已摒弃了脱把骑行功能，视频摘要的画线函数需要手动画线，此处的局限性使得无法适应多变的红绿灯路口。另外，在答辩前才发现换个设备打开前端页面，前端的页面元素有错位现象，该部分还需修复。功能的不完善使得我们的项目无法完全交付，更没法谈用户数量。
  
   

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

• 由于我们的项目针对的用户群体是交管人员，且我们的项目因为最终的完成度不太好，尚未对项目进行推广，也无法对用户对重要功能的接受程度进行说明。
• 在beta冲刺后我们完成了接口的编写、服务器及数据库部署、前端页面搭建等任务，我们离项目完成是更近的，但由于时间和能力都有限，即使花了大量时间我们也没有将项目完整地完成，这一点比较遗憾。
  
   

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

• 经历了beta冲刺我们小组总结了以下几个经验教训：
  • 对于团队工作，能够面对面交流的尽量不在线上交流，能够语音说明的尽量不用文字，有效的交流沟通真的能够大幅度提高效率。
  • 团队工作最好能够集合成员一起完成，不仅能加快项目推进进度，还能加深团队感情，有利于合作。
  • 项目开始时不应该画太大的“饼”，要合理估计工作量和时间，否则结果就会像现在一样项目的完成度不太好。
    
     

2.2计划

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

• 团队的总体计划是有充足时间做的，由于团队任务发布得早，所以有比较充足的时间做计划。这次Beta冲刺时间紧迫，我们花了二个小时讨论Beta冲刺具体要做什么。
  
   

2.2.2团队在计划阶段是如何解决组员对于计划的不同意见的？

• 大家都可以提出自己对项目的建议，有分歧的时候会面对面开会讨论，或者直接在群里发表意见解决。
  
   

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

• 原计划是准备在Beta冲刺中能实现前后端对接、服务器搭建、数据库部署、接口调用的，虽然基本每项都完成了，但是完成的不够好。
• 原因：
  • 一是alpha冲刺阶段大家都在忙着考试和其他大作业，进度推进较慢。
  • 二是项目难度定的太高，大家都是新手，每一步都要现学，实现起来不容易。
  • 三是前期大家的沟通不够。
    
     

2.2.4有没有发现做了一些之后看来没必要或没多大价值的事?

• 有。因为一开始没有沟通好，所以导致前端不知道后端可以提供什么，后端也不知道前端需要什么数据，所以在做界面的时候就没有考虑到后端能提供哪些，导致后期要不断修改界面。
  
   

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

• 是的。在项目计划阶段我们就做了做了详细的需求分析和框架的搭建，讨论了各种功能的具体实现计划，分析出大概需要几个页面、后端接口、数据库、服务器、具体的原型设计，作为了我们每一项任务衡量的交付件，并将任务详尽分配给每个组员。
  
   

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

• 经历了beta冲刺我们认为我们的项目最后的成果还是没有做到符合我们原先的预期，beta冲刺前做过一个大致规划且分工比上一阶段更加细致精确，但我们还是低估了项目的难度和工作量因此项目整个过程并非按照计划进行。我们在做项目时发现alphapose算法做接口与其他算法产生了冲突，使得我们的项目不得不摒弃部分功能，这是我们当时没有估计到的。另外，由于视频摘要算法的划线函数需要手动进行，无法对多边的道路进行闯红灯检测，因此感觉非常苦恼。当时估计不到这些是因为组内成员未接触过编写接口，本身难度对我们来说就比较大，产生冲突也没有处理的经验，因此项目的进行不是很好。
  
   

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

• 项目在beta冲刺开始前已预留了少许缓冲区，主要用于接口编写、vue框架等知识的学习和上手，由于beta阶段本身时间就比较短，我们小组对这些知识又不太熟悉，更没有应用过，所以缓冲区对于我们来说还是很短的。缓冲区作用是一定有的，缺陷在于太短。
  
   

2.2.8将来的计划会做什么修改？（例如：缓冲区的定义，加班）

• 由于我们组的项目完成度不太好，前端页面换到另一个设备会出现元素错位的问题，发现问题较晚，答辩时尚未做好改动，因此下一步将把先前未完善的部分完善好，修复前端页面元素错位问题，另外，我们将进一步测试功能、修复bug并做细节优化。最后，反思总结项目完成度不好的原因、未来做何改进。
  
   

2.2.9学到了什么? 如果历史重来一遍, 会做什么改进?

• 我们学习到了接口的编写、如何将视频、图片放到服务器上检测、数据库的部署、前端vue框架和后端的知识和上手应用，学习了如何处理团队内部冲突，学到沟通是做好团队工作的关键，在冲刺过程中我们聚集写代码、做ppt，各司其职能够更深刻地让我们体会到团队的氛围感。如果历史重来一遍.......我们应该不会画大饼了吧，不然应该也不至于别的组都冲完了，我们还在前后端和接口。最该改进的就是对项目工作量的较合理估计和计划，否则大量的工作容易丧失信心，也容易感到迷茫。
  
   

2.3资源

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

• 没有。
• 我们团队最需要的是人力和时间资源，但由于面临考试时间紧张，这些资源都处于比较缺乏的状态。
• beta冲刺阶段中，前端和后端的实现比较顺利，但在前后端对接时出现许多问题，由于经验不足，需要一边摸索学习一边实现对接，并且花费大量时间精力进行测试，从学习成果来观察，网络上的学习资源是比较充足的。
  
   

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

• 各项任务所需时间和其他资源由团队成员讨论得出，具有较高的精度。
  
   

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

• 测试的时间、人力资源，软件/硬件资源稍有不足，前后端的对接和测试耗费不少时间。对于那些不需要编程的资源在一定程度上没有低估难度，美工设计和文案能够顺利完成。
  
   

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

• 没有。团队任务分配合理，每个人都有自己的任务需要完成，大家都能够各扬所长，尽最大能力交付自己分配到的工作，因此，团队做的事都很有效率。
  
   

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

• 经验教训：对项目整体开发的时间管控做的不好，没有正确预估每个阶段任务所需要花费的时间，如果更好地掌握时间进度来分配任务，将更有利于项目的开发。
  改进：在开发项目时，应该尽早了解前后端的需求，合理分配时间和任务，更好地完成前后端的对接。
  
   

2.4变更管理

2.4.1每个相关的员工都及时知道了变更的消息?

• 当项目任务发生变更时，团队会及时地将变更的消息通过Q群，或者以开会的方式通知给每个相关的组员，确保所有相关组员都能知道并正确理解，以便后续项目顺利进行。
  
   

2.4.2我们采用了什么办法决定“推迟”和“必须实现”的功能?

• 我们针对产品的核心定义进行筛选，对各功能实现的难易程度进行讨论，将项目核心基础功能作为“必须实现”的功能，将附加的额外功能或者实现难度较大的功能作为“推迟”的功能。
  
   

2.4.3项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

• 针对项目的出口条件做了清晰的定义：功能上达到预期效果，能够正常运作，并能够提供给他人使用；外观上具有一定的美观性，操作界面的用户体验良好。
  
   

2.4.4对于可能的变更是否能制定应急计划?

• 如果出现变更，团队能够紧急召开线上or线下会议，确保大部分成员都能及时参与，在会议中制定应急计划并展开沟通讨论，以确定完整的方案来应对计划变更。
  
   

2.4.5组员是否能够有效地处理意料之外的工作请求？

• 组员能够有效地处理意料之外的工作请求。首先，在工作分配上，团队优先将工作请求分配给有空闲的能胜任的组员，确保其能够完成请求；其次，对于分配到该请求的组员，他们都会尽心尽力地完成该请求。
  
   

2.4.6学到了什么? 如果历史重来一遍, 会做什么改进?

• 学到了在最初的计划中预留一定的变更应对时间，根据组员能力和具体情况合理分配任务，以及对可能的变更制定应急计划和解决办法。
• 如果历史重来一遍，会在项目初期需求分析阶段，将产品的功能以及需求进行明确的考虑和分析，对意料之外的情况进行防范，减少后续项目的完成中产生变更。
  
   

2.5设计/实现

2.5.1设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

• 设计工作是在alpha冲刺就已经设计好的，由设计组的人来完成。是在合适的时间，由合适的人来完成的。
  
   

2.5.2设计工作有没有碰到模棱两可的情况，团队是如何解决的？

• 会遇到模棱两可的情况，例如页面布局问题。我们首先会讨论哪种效果更好，如果实在会有分歧，我们会使用投票表决的方法。
  
   

2.5.3团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 我们在beta测试中有运用单元测试。但是效果不算是很好。
  
   

2.5.4比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• 区别不大，只有在具体功能上有一定区别。由于前端功能的改变，导致UML功能的改变。需要更新UML文档。
  
   

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

• 还是端口和前端的连接bug以及前端的整合最多。接口无法连接，和不同电脑适配问题。在设计开发时没有考虑不同人员电脑环境不同，导致问题。在设计/开发的时候的没有及时进行沟通。
  
   

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

• 由专人进行代码复审，严格地执行了代码规范。
  
   

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

• 在beta冲刺中，我们我们学到了合作的重要性。
• 如果能重来，我们会更加紧密的合作。
  
   

2.6测试/发布

2.6.1.团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？

• 团队目前有一个大致但并不是特别具体的测试计划。测试计划中的测试包括了注册和登录接口测试、视频传送接口的测试、检测后的数据返回前端的接口的测试、返回数据能否正常绑定的测试等等。部分测试在Beta冲刺阶段完成了。暂未进行正式的验收测试。
  
   

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

• 测试前后端的各种接口是否能正常调用，以及接口返回的数据是否正常这一块采用了软件postman以及网页自带的检查插件来帮助测试。
  
   

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

• 测量软件的效能会参考接口调用的准确性、视频进行检测时间和准确性等。由于软件目前只是初版，暂未开始跟踪软件的效能。从软件实际运行的结果来看，这些测试工作还是很有用的，有效的解决了一些出现的异常。会针对测试过程中出现的异常和一些特殊状况，对软件进行改进，使得软件效能更好。
  
   

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

• 目前项目完成了前后端整合，初版大致成型，但还未到发布的阶段，所有发布的过程中会发现哪些意外问题暂时无法得知。
  
   

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

• 学到了如何测试软件的接口以及如何使用测试工具postman等等。如果历史重来一遍，会更合理的安排时间，尽可能做更多的测试工作，尽量减少软件会出现的异常。
  
   

2.7团队的角色，管理，合作

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

• 团队的角色是根据大家擅长的技术和方面进行分配的。本组男女比例平均，擅长使用ps和画图的担任原型设计、优化、界面逻辑梳理和ppt制作工作，擅长算法的用算法实现各个功能，学习能力较强的共同交流、编写接口并进行测试以及学习过vue架构的三位同学做前端的页面搭建。可以说整体上讲，我们组的工作还是比较人尽其才的。
  
   

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

• 有。团队项目的进行少不了互相帮助，有写前端的同学与原型设计的组员共同交流功能呈现方式的修改、删除或添加，有接口编写的同学和前端接口调用的双向交流、测试，有各个方面工作的同学共同交流ppt的内容，还有其他成员帮助服务器测试使用等，团队成员之间的相互帮助是有并且比较有效的。
  
   

2.7.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢

    项目有时会出现团队成员想法有差异的问题，此时成员各自将自己的想法表达出来，共同交流沟通，能够各取所长。项目有时也有分工不太平均的情况，工作较少、较轻松的成员能够主动为工作较多的组员分担，如写好接口的同学帮助服务器的测试、优化好原型的同学主动承担ppt制作工作等。如有偶尔有同学想偷个懒，互相提醒催促一下也好了很多。

• 黄新成：我感谢韦宏麟对我的帮助，因为某个具体的事情：beta冲刺时我没有分配清楚成员的任务，到答辩当天才临时分配，但韦宏麟还是接受了这项重任，非常感谢他完美地完成了答辩的工作。
   
• 江舒颖：我感谢李晓芳对我的帮助，因为某个具体的事情：她耐心跟我讲述接口知识（代码编写、参数类型），以及关于后端接口的一些工具的使用，使我能更好地完成前后端接口连接的工作。
   
• 李晓芳：我感谢江舒颖对我的帮助，因为某个具体的事情：她尽早尽快地完成了前端工作，积极与我进行接口和后端功能设计的探讨，帮助我清晰地了解项目的需求，最终减缓了ddl带给我的压力。
   
• 林雨欣：我感谢林志锋对我的帮助，因为某个具体的事情：在我对项目没信心时对我进行开导，并在后期ppt制作过程中提供合理建议。
   
• 方静怡：我感谢林雨欣对我的帮助，因为某个具体的事情：她总是催促我完成任务，在我想偷懒的时候督促我。
   
• 张妍：我感谢林志锋对我的帮助，因为某个具体的事情：他在我修改测试接口的时候，提供了快速安装插件和库的方法，节省了耗费在配置环境上的时间。
   
• 林志锋：我感谢林雨欣对我的帮助，因为某个具体的事情：她在前后端整合工作中，帮助我收集并梳理了需求，使得后端工作更加有条理。
   
• 汪鸿宇：我感谢韦宏麟对我的帮助，因为某个具体的事情：beta冲刺时时间非常少，有些事情弄不明白，自己弄明白要费的时间会很长，就找韦宏麟询问，他事无巨细的教我怎么做。
   
• 韦宏麟：我感谢黄新成对我的帮助，因为某个具体的事情：在我熬夜写代码一直找不出bug时他鼓励我早点休息不要再找bug了第二天和我一起找，太温暖了。
   
• 邹其清：我感谢黄新成对我的帮助，因为某个具体的事情：后端接口问题有些不懂的地方请教他，都能很好的帮助我解决问题。
  
   

2.7.4学到了什么? 如果历史重来一遍, 会做什么改进?

• 我们学习到了接口的编写、如何将视频、图片放到服务器上检测、数据库的部署、前端vue框架和后端的知识和上手应用，学习了如何处理团队内部冲突，学会了成员之间的有效沟通。
• 如果历史重来一遍，我们会在项目选题时就对小组的水平、时间消耗、项目难度做切实际的估计，也会在这两轮的冲刺过程更加认真且拼。
  
   

2.8总结

• 黄新成：
  • 这次beta冲刺每个人都非常忙，我们alpha冲刺做的工作太少了，导致beta冲刺特别赶。前后端的整合和服务器的部署也是很麻烦的工作，刚开始也没想我们做的项目能上线，作为组长的我之前考虑的也不周到。答辩前一天晚上我们大家聚在一起做项目，做到了很晚。但下载功能和页面的整合还是没有做完，我本以为只能这样了，没想到江舒颖和韦宏麟熬到了很晚(也许还有其他组员我不知道)，把功能做出来了。很感动大家能为团队付出这么多。
     
• 李晓芳：
  • 本次Beta冲刺中，我们遇到了时间管理的难题。尤其体现在未完善的功能与迫近的ddl之间，一是时间紧张，需要对未能及时完善的功能做出取舍；二是ddl将近，已实现的功能还不是那么尽善尽美，还需要团队挤压出时间来进行改进。同时，在这个项目的推进过程中，每个团队成员都很努力地完成自己的工作，对他人都持着比较包容的态度，整个团队进行的沟通较为有效，这是让我有感触的地方。
     
• 林雨欣：
  • 本轮的beta冲刺，给我最深体会的就是大家聚集在一起做写代码、搭建页面、测试接口等工作的时候，这样的氛围下我深深地感觉到一个团队的样子和氛围，聚在一起时，面对面的讨论问题、各司其职不仅能提升我们的效率，也让我们的团队内部感情更加深厚。虽然我们的项目完成的不是很好，这是前期工作的估计失误和规划失误，但是吧，软工实践带给我们的痛苦还真是一样没少，身处柯老板的班，我觉得我们的团队也是学到了很多东西，如果当初没画这么大的饼就好了。另外，某班的软工课是真的让我羡慕，每周六我们背着电脑去上软工去答辩时我的舍友躺在床上睡觉，害，我只能用我在软工课活下来了来安慰自己。求评测组和柯老板“酌情”给点分，球球了。
     
• 方静怡：
  • 在本次Beta冲刺中，我深深地感受到了团队成员之间面对面沟通的重要性，在alpha冲刺时大家都是各做各的，交流大部分都是在qq，所以就积攒了很多问题，Beta冲刺阶段，大家聚在一起打代码，大大提高了效率，解决了分歧，所以我认为团队沟通非常重要。通过冲刺，我也学到了很多知识，有压力才有动力。
     
• 江舒颖：
  • 在ddl的时候大家坐在一起打代码的时候遇到了什么问题都互相帮忙查资料，这使代码完成效率大大提高。对于接口连接遇到了比较大的困难，但是一遇到什么问题，都可以及时地向后端同学反馈，减少了很多沟通上的障碍。感觉在前后端连接的时候最好能大家坐在一起打代码，真的能使效率大大提高，不然在宿舍自己打，很多问题还得通过qq来沟通，挺麻烦的。前端页面最好是用统一的布局单位以及相同的版本，这样会避免在页面整合上的很多困难。还是得安排好每个部分的完成时间，不然到最后很慌张会影响成品。
     
• 林志锋：
  • beta冲刺的前期真的感觉极其痛苦，我从没接触过后端，也没写过接口，摸索的过程感觉就是头脑风暴，前期编写接口出一大堆问题也在百度翻看了大量的资料才一点点地排错，一点点上手再到把接口写出来，我很感谢队友的帮助，在编写接口过程中我和队友进行了多次的交流，常有交流产生了灵感。最让我印象深刻的是beta冲刺答辩的前一晚，我们组在活动室共同奋斗，各种测试接口、服务器、前端和第二天答辩的ppt制作，这样的场面非常触动我，每个人都在为团队的项目作出努力的样子让我觉得很感动，不得不说，软工实践作业真的很折磨人，但也因此，团队的合作和努力就更显得珍贵。
     
• 张妍：
  • 本次Beta冲刺，对于安排到的任务基本上都完成了。这个阶段主要是在编写测试接口和整合算法，这是我第一次编写和测试接口，在这个过程中，我对于接口有了更清晰的理解，也掌握了基本的接口编写办法。测试接口的阶段，对于接口可能出现的各种异常也有了一定的了解，异常的解决办法也掌握了一些。这一次的冲刺，尽管过程比较辛苦，但是收获了很多新知识和新技能。
     
• 汪鸿宇：
  • 这次beta冲刺，我和组员的代码整合出了很大的问题，在积极沟通以后才得以解决，有时候自己一个人单干确实不行，还是得和其他人一起去学习，钻研。
     
• 韦宏麟：
  • 这次冲刺时间较短、任务较重，我个人经验也不是够充足，对项目的实现需要花时间学习不少新的知识。在页面布局与接口传送数据方面遇到了比较多的麻烦，但也积累了一些对应方面的经验，比如不同页面编写成员的页面布局最好用统一的适配方式、接口返回的数据应有较方便提取的格式等。最重要的是团队要有积极合作，多当面沟通，仅仅是线上沟通是不足以完整地取得有效的交流的。
     
• 邹其清：
  • 本次Beta冲刺阶段时间短，再加上课余时间不够充足，因此团队项目并能实现的很完美，尤其是在前后端对接时耗费了大量的时间和精力。但是，在Beta冲刺阶段还是有收获的，比如学会了使用flask框架编写接口，以及对接口进行测试等等，并且团队成员在这个过程中都能够互帮互助，并且多次讨论交流，共同学习进步，完成自己的任务。