2组-Alpha冲刺-总结

组长博客链接：https://www.cnblogs.com/wuzzezeze/p/15583137.html

一、基本情况

1.(2.1) 基本情况（10分）：

• 组长博客链接：已在博客开头给出

• 现场答辩总结

  • 点名界面最好可以做成单人单页，上滑签到，下滑未到，越方便越好，增加姓名拼音
  • 多人界面可以考虑改成对答到的不操作，未到的点击，减少使用者点击次数
  • 增加随机点名，增加点名数据可视化模块

• 全组讨论的照片
  

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

姓名	完成任务	工作量比例
吴子澳	前端设计，前后端对接，分配任务，博客编写	10%
谢元	后端数据库搭建，云函数编写，答辩回答别组提问	15%
吴超凡	后端数据库搭建，云函数编写，督促任务进度	15%
赖莘龙	前端页面搭建，前端优化，前后端对接	13%
吴彬	后端数据库搭建，云函数编写	13%
陈祉镪	后端数据库的实现	5%
夏明旻	前端原型设计，前端页面搭建，ppt制作	8%
许茹婷	前端页面搭建，ppt制作	7%
庄婉苹	前端页面搭建，ppt制作	7%
罗进	前端页面搭建，ppt制作，ppt演讲	7%

二、总结思考

• 2.2.1 设想和目标
  1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？
  我们的软件致力于帮助上课老师和督导队成员通过上传excel表格生成小程序内的点名表进行快速点名并且生成点名完的excel表格。该软件主要是针对教师点名方面，将教师点名的功能做到极致化，便捷化，使用最少的动作，完成教师对点名的需求。我们的典型用户是上课老师和督导队成员，典型场景是老师上课点名和督导队下课点名。
  2.我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
  原计划完成的功能：通过excel表格上传点名表、多人界面的快速点名表、点名结果的基础可视化、分成老师点名和督导队点名两种。
  按照原计划时间交付了。小程序还未完善完全，没有上线，目前没有用户。
  3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  小程序目前没有上线，没有用户。
  用户对于我们多人点名界面有觉得比单人界面更方便的，也有觉得单人更直观更美观的。确实没有预想到部分用户对于excel表格上传的功能不满意，想要通过直接爬取教务处数据生成点名表，也有部分用户觉得生成点名表不如二维码签到。
  根据客户的需求，我们会不断完善，离最终目标更进一步。
  4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  在合作的过程中，没有定下每次alpha冲刺的总任务和个人任务，对于ddl没有明显的紧迫感，以至于在最后几天特别忙。
  会重新协调好组内分工，落实每个人的任务和进度，对未完成任务的组员进行督促和帮助。

• 2.2.2 计划
  1.是否有充足的时间来做计划?
  有做计划，但时间不算充足，前两次冲刺大部分时间用于学习这次项目所需的新知识。
  2.团队在计划阶段是如何解决组员对于计划的不同意见的？
  通过线下开会交流，线下开会完善制定计划明显比线上更有效率。
  3.原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  个人签到页面和拼音显示未能完成。
  计划时打算做多人和单人两种签到界面，因为多人签到更难，想要先完成多人再做单人，结果没想到最后时间不够，没能完成单人签到界面。
  拼音显示是因为npm的拼音库在下载安装后，会直接导致下载后的微信小程序软件崩溃，目前没查明原因。
  4.有没有发现做了一些之后看来没必要或没多大价值的事?
  在做这次项目之前先用墨刀做了个原型设计，发现完全没用……
  5.是否每一项任务都有清楚定义和衡量的交付件?
  每一项任务都有很清楚的定义，但测试报告和前端做出来的成果难以有清晰的衡量标准，测试报告没有其他相似产品的对比，而且毕竟每个人对于前端的审美存在一定差异。
  6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  意外：没有想到前端对于微信小程序的学习占了太多时间，以至于后面几次alpha冲刺疯狂赶工。
  风险：第三方库的导入，在导入npm的拼音库的过程中，导入后的项目一编译就报废，庆幸有备份项目。确实没法想到导入第三方库能直接报废项目，之前做项目从没遇到这种情况。
  7.在计划中有没有留下缓冲区，缓冲区有作用么?
  最开始的几次alpha冲刺有留下缓冲区，因为不清楚对于这次项目，需要学习多久的微信小程序相关知识。
  8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  缓冲区仍会保留，但是不应设置太久的缓冲区，过长的缓冲区只会导致组员的松懈和推迟计划。组长会更加严厉的督促组员的进度完成情况，如果没有完成，会建议组员利用自己的多余时间进行加班，不要拖累组内其他同学。
  9.学到了什么? 如果历史重来一遍, 会做什么改进?
  缓冲区不宜设置太久，应该定下清晰且严厉的目标计划，只有落实到每次的具体计划ddl才能让组员有紧迫感，有为了完成计划而加班的自愿。

• 2.2.3 资源
  1.我们有足够的资源来完成各项任务么?
  有。人力资源分为前端六人，后端六人。云端资源是购买了微信小程序的付费服务器套餐。硬件资源主要依靠组员自己的电脑。
  2.各项任务所需的时间和其他资源是如何估计的，精度如何?
  有在网上查询相关类似项目的时间和资源，也询问了网上做过类似项目的前辈，可惜都没有明确的答案，于是靠自己以往做项目的经验预估了，可惜精度不尽人意，对于后期任务所需时间估计太少。
  3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  足够，十人小组不缺人力资源，硬件资源用安卓机进行测试，电脑进行代码编写以及云开发。
  并未低估难度，毕竟这是一个服务类的微信小程序，最基本的前端界面肯定不能满足客户的需求和审美。于是在制作前端的过程中运用了第三方库进行进一步美化，目前看起来没有问题。
  4.你有没有感到你做的事情可以让别人来做（更有效率）?
  组内来看的话，没有。大家都是第一次开发微信小程序，每个人都在自己最合适的位置上。
  5.有什么经验教训? 如果历史重来一遍, 会做什么改进?
  对于前期学习微信小程序开发的时间资源安排过多，以至于后期具体开发太紧迫。
  会要求组员花费更少的天数去学习相关知识，否则拖累其它部分的同学。

• 2.2.4 变更管理
  1.每个相关的员工都及时知道了变更的消息?
  我们会在交流群中通知，保证每个成员都能及时了解变更消息
  2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
  必须实现的功能是我们确定项目后定下的产品准备实现的功能，推迟的是我们在完成预定目标后仍有空余时间才会考虑的对产品细节进行优化的功能
  3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  出口条件是预定功能能够正常使用
  4.对于可能的变更是否能制定应急计划?
  若出现可能的变更我们会根据项目当前进度和剩余时间制定应急计划
  5.组员是否能够有效地处理意料之外的工作请求？
  部分组员处理意外情况的能力一般，但通过组内其他人员的帮助仍能有效处理意料外的工作请求
  6.学到了什么? 如果历史重来一遍, 会做什么改进?
  我们在中途更换过整个项目的立意，全部推倒重做了一遍，但在工作过程中因为项目的变更小组内工作的分配做的不是很好，导致了工作效率的不足。如果重来一遍，在项目变动后应该立刻重新进行具体的工作分配来提高工作效率

• 2.2.5 设计/实现
  1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  设计工作大概是在alpha冲刺阶段二，对微信开发工具有了基础以后由后端组讨论完成的。由于组员需要时间学习相关工具的使用，所以最开始并无法完成相关的设计，仅仅只是对要实现的功能进行了讨论和汇总，并做出相应的原型以作为程序开发的模板。因此不可避免地导致实际开发的时间被压缩。
  2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  在程序功能设计部分遇到过。我们通过团队协商，在考虑了时间成本和操作难度后，对功能进行了一定的优化和舍弃。
  3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  我们使用的是微信开发工具对小程序进行设计。微信开发工具的各项功能，如模拟器，云开发等简化了小程序开发的过程，显著加快了我们的工作效率。
  4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  总体设计上并没有太大的区别。我们主要是在uml的基础上对相关的功能进行了拓展和延伸，因此没有必要更新uml文档。
  5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  对excel文件的数据进行上传和导入数据库出现的bug最多。主要原因是对代码的理解和使用不够熟练。发布以后尚未发现更多重要的bug（我们主要实现了程序的基本功能实现和debug，功能开发还有相当的工作量）。
  6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  代码复审主要是在测试过程中遇到问题后再寻找相关的代码进行复审。因为本组内的代码开发者都是初学者，因此对于代码规范的实现并没有强求。
  7.学到了什么? 如果历史重来一遍, 我们会做什么改进?
  进行程序设计的过程中使用相应的工具能够加强对程序框架的认识，加快设计开发的进度，也方便与其他成员进行交流。如果历史重来一遍，我们会在项目初期就开始进行一部分设计的工作，以减少对实际开发工作时间的占用，留下更多的空间。

• 2.2.6 测试/发布
  1.团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
  因该项目还没有完工，还有部分功能没有实现，所以没有一个具体的测试计划，只有在完成一个小阶段之后会进行一次项目流程的实现，观察到此为止是否存在问题。
  2.团队是否有测试工具来帮助测试？
  微信小程序自带的程序就可以进行实机测试，观察测试结果。
  3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  因为软件的功能较为直接，可以通过直接观察查看软件的效能。测试功能与软件的实际运行结果基本一致，在云数据库查看方面还存在一些问题，没有按照ID顺序进行观测，需要改进。
  4.在发布的过程中发现了哪些意外问题？
  目前仍处于开发完善阶段，还未进行软件的正式发布。
  5.学到了什么? 如果历史重来一遍, 会做什么改进?
  在进行项目的测试时，正常应该分出人员对软件进行专门的测试分析，但是在进行分工时，怕考虑到测试人员的工作量只有在软件完成基础开发之后才能够进行，害怕浪费劳动力，就没有分配人员这个专门对这个方向进行处理，而是后端人员在完成部分之后就进行单独测试，效率较低，有没有系统规划。重来一遍的话，会分出单独的人员进行软件的测试，如果前期工作量不够可以安排文章的撰写部分增加工作量。

• 2.2.7 团队的角色，管理，合作
  1.团队的每个角色是如何确定的，是不是人尽其才？
  团队首先进行了大致的分工，一开始除了部分组员有比较明确做后端或前端，大部分组员都是按兴趣选，不管前端还是后端都有大量的知识和技术需要学习。然后前端和后端组都需要选出一位代理人，进行及时沟通，进行前后端内容的交接；
  和人尽其才可能还是有不小差距的
  2.团队成员之间有互相帮助么？
  有的，对于前端页面的搭建互相询问技巧，前后端一起寻找接口处的BUG......
  3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：
  出现问题会在QQ群及时沟通，在站立会议时一起再集中讨论

感谢汇总：

• 吴彬：我感谢谢元对我的帮助， 因为某个具体的事情:为学习开发过程提供了学习和借鉴资料。

• 吴子澳：我感谢赖莘龙对我的帮助， 因为某个具体的事情:帮我实现前端界面，一起改BUG找资料

• 谢元：我感谢吴超凡对我的帮助，在我对报错毫无头绪时帮助我一起debug；

• 赖莘龙：我感谢吴子澳对我的帮助，因为某个具体的事情：前端点名页面无法正常点名的时候是他花了大量时间帮助我解决了这个问题，在前端界面设计方面他也给了我很多建议。

• 夏明旻：我感谢许茹婷对我的帮助， 因为某个具体的事情: 我负责写点名记录的前端界面，其中要使用到block循环，在编译运行的时候页面直接变成空白了，让本来就崩溃的我更崩溃了，我和许茹婷说明了这个原因，她安慰我说不要急我们一起debug，让我得到了许多安慰。学到了遇到问题要保持冷静，慢慢找错误，而不是逃避。如果历史重来一遍，我会尽快完成其他课程的课设，将更多时间投入到软工上。

• 陈祉镪：我感谢吴超凡、谢元对我的帮助，在我因为个人原因导致进度落后时，是他们主动、仔细地向我讲解了他们的最新进度，让我有机会赶上进度。我感谢组长吴子澳对我的帮助，不停地督促我们赶进度，让我们不至于又DDL工作。

• 许茹婷：我感谢夏明旻对我的帮助，由于我不知道怎么进一步美化界面，带我了解colorui，设计出更好看的界面。学到了colorui的使用，如果再来一遍，我会用所学的将界面设计得更美观流畅。

• 罗进：我感谢吴子澳的帮助，因为某个具体的事情:在我苦于如何优化界面时为我提供了建议和帮助。

• 吴超凡：我感谢赖莘龙对我的帮助， 因为某个具体的事情: 前端和后端之间进行的沟通都是不断沟通了解的，沟通之中明确了具体的问题和需求。在面对不了解的领域时候，先明确自己为了完成这个目标需要做什么，需要学什么，具体要用什么工具能做出来。在开始行动，而不是学一半才发现这个工具没有用。

• 庄婉苹：我感谢组长吴子澳对我们组的奉献，因为某个具体的事情：在整个过程中非常有耐心地统筹我组的工作。学到了小组分工细致的重要性。如果重来一遍，会缩短一点学习的时间，通过实践更有针对性地去学知识。
  4.学到了什么? 如果历史重来一遍, 会做什么改进?
  团队分工不够合理，交流不够，没有合理利用人力资源，后面的Beta冲刺要更好的发挥十人组的优势

• 2.2.8 总结（4分）

  • 吴子澳：
    前期的分工不够明确，中期督促组员工作，促进前后端的交流交互做的不好，另外Alpha冲刺前期花了大量的时间看视频学习，但是后面上手做，查资料，明显学的更快，看视频学习不太适合这种冲刺任务的情景
  • 谢元：
    从这次的项目学到了很多知识，不只有前端的基础相关语言，还有微信小程序特有的前端语言，以及微信小程序云开发相关知识，如何操作云数据库，编写云函数等等。虽然有点不愉快的经历，但确实很充实，完善了自己。
  • 赖莘龙：
    在alpha冲刺的过程中，我学到了关于构建一个框架完善的前端界面应该具备的各种知识，也对如何调用后端的数据有了基本的了解，最让我感触良多的是光看视频是学不到太多东西的，还是要自己动手一步步做下去对知识的印象才会深刻
  • 吴彬：
    在项目开始前我对软件开发的流程，微信小程序的开发并没有了解。因此才在项目的初始阶段花费了大量的时间去了解和学习。通过这次项目，我学习了微信开发工具的使用，加强了对前后端的理解和认识，对软件开发中各部分成员的任务有了了解，对今后的就业选择有了一定认识。
  • 夏明旻：
    这次alpha冲刺里有其他课程的考试、课设，说实话非常紧张；我们小组也因为沟通问题出了很多差错，进度也比较慢，也没有达到老师的预期，毕竟是第一次集体做一个项目，希望自己在beta冲刺里可以在组里再多出一些力。
  • 陈祉镪：
    本次Alpha冲刺总体感觉不好，刚好其他项目冲突，又有考试，时间安排杂乱，而且团队内的分工还是没有明确，感觉又是各做各的，庆幸组内有些人很积极地完成了许多部分的任务，不至于成果都没做出来，希望在接下来的beta冲刺中组员们能更好地协调沟通，更有效率地完成这个项目。
  • 许茹婷：
    本次Alpha冲刺由于正好碰上我的考试，所以把事情堆到了后期“冲刺”，由于时间不够充分，导致设计出的界面不够美观，还要小组其他成员来善后，感觉非常抱歉，希望beta冲刺中可以做完做好所有的工作。
  • 罗进：
    本轮冲刺让我充分的认识到自己所学知识的不足，也让我学到了很多前端和小程序开发的知识，让我对一个项目的开发有了更深的认识。
  • 吴超凡：
    本轮冲刺总感觉一直在忙，但是没有效率，也没有好的成果，要学的东西太多了，要实现一个软件的开发各个方面都要有所了解，小组内的成员在之前都没有接触过这方面的内容，导致在发过程中没有一个人对小组进行带领，都是自己摸索着前进，也没有什么统筹规划，到最后只知道做了，但具体哪一步做的什么作用在哪都不了解，要是有个大佬带着走可能就会轻松许多吧。
  • 庄婉苹：
    学会了微信小程序前端界面的实现，丰富了小组合作的经验。