3组Alpha冲刺总结

一、基本情况

1.1组长博客链接

组长博客链接

 

1.2现场答辩总结

• PPT部分页面排版不是非常美观，但内容比较充实，逻辑比较清晰。
• PPT讲解到前端原型部分时略显仓促，但整体讲解得体到位，对于六轮Alpha冲刺的工作分配以及Alpha冲刺的任务完成度都有较好的评价体现。
• 演示视频功能齐全，逻辑清晰，但是BGM由于本身片段长度不足，因此在视频中间位置会进行第一遍与第二遍的切换，导致声音忽低忽高，需要改进。
• 对于测试组对本组的提问/其他组或老师的提问都回答的比较合理，没有出现答不上来或者回答不令人满意的情况。
• 对于Alpha冲刺时整体的安排规划没有做的很好，希望在Beta冲刺中可以合理安排分工，圆满完成前后端的任务。

 

1.3全组讨论的照片

 

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

工作	姓名	团队分工	贡献比例
前端	韦宏麟	原型设计，素材收集	10.5%
	林雨欣	主界面，素材整理	10.5%
	方静怡	数据统计界面，登录界面	10.5%
	汪鸿宇	原型设计，素材收集	9.5%
	江舒颖	视频播放界面，素材整理	10.5%
后端+算法	黄新成	关键点检测算法，脱把骑行检测，答辩	10%
	林志锋	目标检测算法，车流量检测，视频摘要	10%
	邹其清	后端api，博客编写	9.5%
	李晓芳	后端api，ppt制作	9.5%
	张妍	后端api，ppt制作	9.5%

 

二、总结思考

2.1设想和目标

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

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

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

• 目标目前尚未全部完成。
• 经历alpha冲刺我们小组完成了多个场景及晴雨昼夜情境下的数据收集及手动标注工作，学习使用yolov5训练数据，实现了流量统计、脱把骑行、改装监查、头盔检测、视频摘要、闯红灯检测等功能。大部分功能的算法都已经做到基本实现，能够在多场景和晴雨昼夜条件下有较好的效果。
• 我们的项目未能按照原计划交付时间交付，我们对数据收集标注和训练的时间估计有很大的失误，加之其余课程大作业、考试的压力项目没能按照原计划交付，前后端的完成度不是太好，API尚未编写，也未能完成前后端对接。
• 原计划是我们的产品面向交管人员，用户群体比较难接触推广，因此暂时没有做到推广使用。
  
   

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

• 由于我们的项目针对的用户群体是交管人员，且我们的项目因为一些意外完成度不是那么好，尚未对项目进行推广。
• 我们认为现今非机动车数量急剧增加，就本校而言已是如此，监管困难是一个显而易见的难题。我们的项目能够在一定程度上解放部分人力，对交通监管方式的优化有所帮助，相信能有较好的接受度。接下来的冲刺，我们将完成项目，达成我们的预期目标。
  
   

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

• 经历了alpha冲刺我们小组总结了以下几个经验教训：
  • 团队的分工需要精确且细化，做到每个成员都明确自己的目标，并为完成目标制定完成期限，否则参差不齐的完成度可能会影响后续的进度。
  • 对于团队项目需要定义合理的缓冲区，避免时间估计失误和“突发状况”的出现导致延误项目。
  • 团队内部成员需要多进行互相交流，如果各做各的很容易导致出现无效的工作，沟通是团队工作的做好的一个重要因素。
  • 需要制定符合实际的计划，过于理想化的目标容易打压信心，产生挫败感。
    
     

2.2计划

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

• 有。团队项目发布的时间比较早，对于整个项目的规划有充足的时间来完成，做计划的时间是很充足的。在开始开发前的选题、需求分析、还有对UML图的绘制都是我们对项目有了更加清晰的认识。
  
   

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

• 在计划阶段，其实大家的分歧并不多，当面对组员之间的不同意见时，我们都是开会讨论，当面解决、达成共识的，会讨论出一个大家都满意的方案。
  
   

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

• 原计划的工作并没有100%完成，只实现了60%左右。
• 原计划是希望在Alpha冲刺阶段实现前端和后端还有前后端的对接，但是现实是后端只实现了算法部署，前端的界面中动态图表也没有解决，前后端对接部分还没有实现。
• 原因：
  • 一是因为这段时间大家都太忙了，忙着对付各种考试，而且还有别的大作业，没有100%的时间和精力能够投入在项目上。
  • 二是这个项目开始的计划预想比较复杂，实现起来也不太容易，对于前后端的考验都很大，而大家又都是初学者，实现起来比较困难。
    
     

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

• 暂时没有，感觉做的每一个工作都是有必要的、有用处的，每一个任务的完成都是一种经验的积累，为后续进展做铺垫的。
  
   

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

• 在项目真正开始前的计划阶段，我们对项目的各项任务分工做了大致的分配，但是对进行过程中将会遇到的各项任务不能够做到完全的估计和衡量，随着项目的进行和每次任务的发布，我们对于每个部分要做什么更加清晰明确，基本上对每一项的任务都做出了清楚的定义并制定了衡量的交付件。
  
   

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

• 项目总体的推进不太符合预期，起先刚开始alpha冲刺第一次开会做了个大致的规划，计划能在alpha冲刺将前后端都基本实现并能够成功对接，但事实上直到alpha冲刺结束前后端也未能完成好，对接更是没有完成，这是我们项目进度估计上的失误。
• 问题大概是在于过于理想化地估计工作进度且分工未能做到精确细致，因此有时会出现对自身工作目标不是太明确的情况。
• alpha冲刺的过程本身具有较大的工作量，项目的意外是和大家图形学和数学建模的考试撞上了，时间管理成为我们的一大难题，我们需要花大把时间应对考试。
• 起初对数据收集和标注工作量的估计不准确导致后续才发现需要大把时间放在这方面。
• 当时未能估计到的风险即考试的来临和数据收集标注的时间消耗，原因就在于从0开始收集、学习标注，还没有给足我们的项目足够的缓冲时间。
  
   

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

• 在计划中预留的缓冲区比较短，是针对学习数据标注、训练，前后端开发学习、API的编写学习预留的一些时间，冲刺的过程中由于有图形学和数学建模考试的插入，缓冲区的时间显得少之又少，加上对数据收集、标注、训练所用时间的错误估计，我们在前期的这些工作上花费了大量时间，本组成员光是收集和标数据就冲了alph冲刺的大半个阶段。
• 预留的缓冲区还是有一定的作用，但由于估计失误和没将备考放在规划的考虑范围内，缓冲区的作用显得不是很大，还是需要切实有效的规划。
  
   

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

• 由于alpha冲刺大部分时间处于项目的“数据准备”阶段，真正的前端、后端编写搭建还没能全部完成。接下来的阶段本组将把其他课的大作业、备考等事宜纳入项目计划的考虑因素内，切实合理安排时间，在冲刺前先召开小组会议，细化分工。
• 由于有部分成员对前端或后端不太熟悉，将再给出1~2天时间进行缓冲学习，前后端并行工作，争取预留2天时间完成前后端的对接。
• 工作量较大，预计需要小组成员共同“熬夜加班”努力完成。为使项目顺利完成，尽可能在下一轮冲刺前尽早开始其他课的大作业，以便在截止期限时能够在短时间内收尾。
  
   

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

• alpha冲刺时本组成员学习了怎么收集数据、使用labelimg标注数据、使用yolov5训练数据集，学习如何实现流量统计、目标识别、跟踪、视频摘要算法实现、关键点检测算法实现脱把骑行检测等。总体来说学习了“数据准备“的过程以及完成项目功能的各种算法，并应用到项目当中。
• 由于对数据收集标注工作的错误估计和其他学科的考试安排，我们对任务的限定时间规划不合理，换句话说”理想很美好，现实很残酷“，还是对软工作业有太理想化的幻想。
• 如果历史再来重来一遍，我们会对项目有更切合实际的估计，虽然无法在alpha冲刺完成项目，但我们认为更加有条理的规划更能推动项目有条不紊的进行。
  
   

2.3资源

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

• 没有。
• 我们团队最需要的是人力和时间资源，但由于面临考试时间紧张，这些资源都处于比较缺乏的状态。
• 大部分成员缺乏项目开发经验，需要一边摸索学习一边推进项目进度，花费时间精力学习个人分工的所需技能等，从学习成果来观察，网络上的学习资源是比较充足的。
  
   

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对于可能的变更是否能制定应急计划?

• 若出现变更，我们能够制定应急计划并进行沟通讨论，确定完整的方案来应对计划变更。
  
   

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

• 能有效地处理意料之外的工作请求，我们是将工作请求分配给合适的组员，确保能够完成请求。
  
   

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

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

2.5设计/实现

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

• 设计工作是在Alpha阶段冲刺的时候开始的。由我们的组长领导，团队成员一起讨论来完成。是大多数设计人都有空并能进行当面讨论的时间，是合适的人选。
  
   

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

• 有，当遇到模棱两可的情况时，我们将在团队内进行投票表决，得票高的方案将会通过。
  
   

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

• 有运用单元测试，UML测试，等测试工具。
• 这些工具很有效，大大的提高了测试的效率，降低了手工测试的工作量。同时有的测试工具还有提供一些小问题的解决办法，为我们减轻了很多负担。
• 测试出现的大多问题都会记录下来然后团队讨论解决方案。
  
   

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

• 在页面、功能方面的站台有所变动，由于所实现的功能有小小变更，以及界面布局页变得更清晰。原则上是要更新UML文档的，但由于时间问题，在基本确定并实现变更后再进行UML的改动。
  
   

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

• 后端提供接口以及前端实现数据大屏时调用接口并提供实时数据改变的部分bug最多。发现了数据的改动不能及时获取
  
   

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

• 由组长进行人工查看。对大多代码都严格执行，有起到一定的代码规范作用。
  
   

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

• 学到了在完成工作的过程中一定要做好沟通，一定要了解互相之间的进度，组长要调动起所有组员，知道所有人的进，有人进度拉下的话要及时去催和了解情况。
• 历史重来一遍的话，我们会往后端部分及时催促下进度，并向前端部分提前做些页面上布局的改变，并且组内多进行一些技术上的沟通交流，不要一个人蛮干。
  
   

2.6测试/发布

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

• 团队目前没有特别具体明确的测试计划，因为项目的完成度还没到需要测试的那个阶段。暂未进行正式的验收测试。
  
   

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

• 目前暂时没有，后续开始测试的时候可能会借助部分测试工具。
  
   

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

• 由于暂未到测试阶段，测量和跟踪软件的效能的方法还未确定，所有无法得知测试工作是否有用，以及该进行何种改进。
  
   

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

• 由于项目目前进度只完成了60％左右，暂未到发布的阶段，所有发布的过程中会发现哪些意外问题暂时无法得知。
  
   

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

• 由于测试和发布这两个阶段目前都还没有进行到，所以可以从中学到什么暂未知晓。如果历史重来一遍，会尽量让完成度尽可以到达可以进行这两个阶段的程度。
  
   

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

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

• 根据每个人的特长和兴趣来确定。比如有的成员对于美工比较擅长，在团队中就是来制作原型；有的成员有学习过前端，并且对前端比较感兴趣，在团队中就担任前端制作的角色；有的成员对算法比较感兴趣，并且比较擅长编程，负责的工作就是项目后端和接口的部分。
• 通过这样的方式每个人都充分发挥着自己的特长，并且做着自己感兴趣的事，有助于工作效率更高。
  
   

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

• 由于本组人员充足，在每个部分都有大于等于两个以上的成员负责。
• 成员间对于代码上的bug有进行互相探讨，并且合理分工，互相分享学习资源，提高实现项目的效率。
• 对于原型上的设计，两人分工收集素材，避免在素材收集上花费太多的时间，并且互相结合队友的意见，设计出更加合理美观的界面。
  
   

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

• 黄新成：我感谢韦宏麟对我的帮助，因为某个具体的事情：在我特别忙的时候帮我做ppt，陪我一起熬夜，挺过一段艰难的时光。
   
• 江舒颖：我感谢李晓芳对我的帮助，因为某个具体的事情：帮助我查看前端界面在不同分辨率是否能正常显示。
   
• 李晓芳：我感谢江舒颖对我的帮助，因为某个具体的事情：她在项目初期就开始做准备工作，推动了ddl驱动型的我尽快开展工作，减缓了ddl带来的压力。
   
• 林雨欣：我感谢方静怡对我的帮助，因为某个具体的事情：在重新绘制原型时起初存在差异较大的想法，在一番沟通和共同商讨共享素材后求同存异。
   
• 方静怡：我感谢林雨欣对我的帮助，因为某个具体的事情：在优化界面时提供了很多很不错的idea，在界面构图中也提供了不错的方案。
   
• 张妍：我感谢方静怡对我的帮助，因为某个具体的事情：她给出了前端大概需要的数据内容，使得我对于接口的学习方向更为明确。
   
• 林志锋：我感谢林雨欣对我的帮助，因为某个具体的事情：在进行红绿灯训练集进行标注时，替我分担了部分的标注工作，为我减轻了压力。
   
• 汪鸿宇：我感谢韦宏麟对我的帮助，因为某个具体的事情：我在调试环境的时候遇到了很严重的问题，无论怎么调试都无法正常运行，后来我请教了韦宏麟，他不仅帮我解决了问题，还细心地告诉我报错原因。
   
• 韦宏麟：我感谢黄新成对我的帮助，因为某个具体的事情：在我熬夜写代码一直找不出bug时他鼓励我早点休息不要再找bug了第二天和我一起找，太温暖了。
   
• 邹其清：我感谢黄新成对我的帮助，因为某个具体的事情: 合理分配任务，在我不知道要做什么时，能够给我指明所需要完成的任务。
  
   

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

• 学到了在团队中分工必须要明确，一开始就需要分工，任务需要早点指派，每个人各尽其职，在每个部分成员应该增强沟通并且互相配合。
• 如果历史重来一遍,将会把每个部分实现的时间控制好。有些部分可能需要某个部分完成之后才可以开始进行，这样会使某一组停滞不前很被动。例如B组实现功能需要依赖A组完成某个部分，则可以A组完成某个小部分时B组就可以开始进行，提高效率，保证进度。
  
   

2.8总结

• 黄新成：
  • 很高兴在每次会议大家都很积极地讨论，有困难也一起解决，让我感受到了团队的凝聚力。
     
• 李晓芳：
  • 本次Alpha冲刺中，我们遇到了许多困难，尤其体现在时间管理上，考试压力、学生活动等等事情无一不阻扰项目的推进。但让我感动的是，团队成员都很努力地完成自己的工作，团队沟通做得也比较好。
     
• 林雨欣：
  • 前期经过开会安排后分配大家收集和标注数据，说实话标数据这个工作不算太难，主要是太苦力了，alpha冲刺就是全组人的爆肝标数据。另外让我觉得alpha冲刺非常痛苦的地方在于冲刺时间和数学建模考试的冲突，时间管理也太难了（甚至幻想如果老师们可以交流一下轮流布置大作业和安排考试就好了，但这只可能是幻想），我没有想到大三竟如此忙碌。由于团队对新原型的需求加之考试压力，感觉非常无奈，毕竟没有原型前端也会因此耽误进度，可以说太难受了。开会讨论工作事宜，安排工作量和工作进度在考试的施压下也是没有全部完成，希望在Beta冲刺能够把我们的项目做出来吧，虽然工作量比较大的，难怪说选柯老板的学生都能造火箭了。
     
• 方静怡：
  • 在这段时间中我收集了数据、标注了数据，还优化了原型界面，学习绘制了前端。标注数据的工作是相当繁琐的，因为数据很多；在优化原型界面时也遇到了困难，对于 这个项目不太好想前端应该放哪些功能，整个网页的构图是怎么样的，好在最后终于能画出来。然后开始加入前端的研究，但是在实现动态统计图的时候遇到了困难，还没找到解决办法。总的来说，这段时间，有很多事情堆在一起，使本就少的时间变得更少，拖慢了项目的进展，但还是能完成部分任务的。
     
• 江舒颖：
  • 关于前端页面构建的过程中，由于vue框架的版本问题有很多bug网上都没有很好的解决方法，只能尝试几种方法，找到对应的文件夹进性配置和修改。关于组件的相对位置与绝对位置和网页的自适应问题对我而言算是前端工作中的两个很重要的问题了，所以在写代码时应当先解决这两个问题。
     
• 林志锋：
  • 在经历了个人编程和结对编程之后，我以为团队编程可以让自己过的轻松一点，没想到工作量还是那么大，加上还要数学建模考试，天天复习，导致自己对于自己理想的目标的完成度搞得很低，因此感到十分惭愧，惭愧不仅在于对于算法和功能没有进行太大的优化，还在于前几次团队任务中，没有帮助好组长，多多建言献策，组长一个人可能力有不逮，于是我们Alpha冲刺的规划就比较散乱，最后也没有完成我们理想的目标，希望在Beta冲刺中能够改变这个现象，大家精诚合作，最后做出一个令人满意的项目出来。
     
• 张妍：
  • 本次Alpha冲刺并没有能很好的完成分配的任务，接口编写的学习程度仍然还不够编写出我们软件需要的接口，还需要继续学习。但还是有很多收获的，比如学会了如何使用labelimg标注数据集，对于接口有了更多的认识，对于接口编写了也有了一定的了解，尝试写了几个接口，可以实现文本的传输。我们软件需要的接口需要带有的功能是传输视频，目前暂未编写成功。
     
• 汪鸿宇：
  • 这次Alpha冲刺，我深深的感受到了学习的时间规划非常关键，只有时间规划好，才能更好的完成任务。更好的时间规划意味着更好的时间利用率，也就意味着我能学到更多的知识，完成更多的任务。
     
• 韦宏麟：
  • 在编代码前要做好设计、理清思路，如果没有进行全局的思考就直接打代码，速度一定不会快并且还会乱。遇到不会的地方要及时向队友寻求合作，自己一个人干时遇到的错误可能队友早就遇到过并且可以解决了，有队友的帮助的话效率会高很多。
     
• 邹其清：
  • 这次的alpha冲刺的阶段收获了很多，如能够熟练使用labelimg工具对数据集进行标注，了解接口基本内容，学习了前后端整合的基本知识等等，但是由于以前没有接触过相关内容，并且时间不够充足，因此重新开始学习花费的时间比较长，有的内容不能很好的理解，需要请教组内其他成员或上网查找。对于接下来的beta冲刺，需要合理分配时间，和组员共同实现剩余任务，完成项目内容。