组长博客：https://www.cnblogs.com/wuzzezeze/p/15615568.html

一、基本情况

1.(2.1) 基本情况：

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

• 现场答辩总结：

  • 增加拼音
  • 站在老师、使用者的角度把软件功能做到极致

• 全组讨论的照片
  

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

二、总结思考

• 2.2.1 设想和目标
  1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？
  我们的软件致力于帮助上课老师和督导队成员通过上传excel表格生成小程序内的点名表进行快速点名并且生成点名完的excel表格。该软件主要是针对教师点名方面，将教师点名的功能做到极致化，便捷化，使用最少的动作，完成教师对点名的需求。我们的典型用户是上课老师和督导队成员，典型场景是老师上课点名和督导队下课点名。
  2.我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
  原计划完成的功能：通过excel表格上传点名表、多人界面的快速点名表、点名结果的基础可视化、分成老师点名和督导队点名两种。完成了上传表格，多人页面的快速点名，单人页面点名等最重要的基础功能
  按照原计划时间交付了。我们的用户群体面向老师，目前仅有任课老师
  3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  小程序目前没有上线，没有用户。
  主要用户（老师）对重要功能接受程度与预期一致，与Alpha冲刺相比改进完善了许多
  根据客户的需求，我们会不断完善，离最终目标更进一步。
  4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  UI界面可以适量参考别人现成的，毕竟个人的审美和素养还是有限的；会更多的搜索资料

• 2.2.2 计划
  1.是否有充足的时间来做计划?
  相对Alpha冲刺时间少了很多，但有上次的经验教训，这次效率高了不少
  2.团队在计划阶段是如何解决组员对于计划的不同意见的？
  通过线下开会交流，线下开会完善制定计划明显比线上更有效率。
  3.原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  可视化和拼音显示未能完成。
  可视化时间不够
  拼音显示是因为npm的拼音库在下载安装后，会直接导致下载后的微信小程序软件崩溃，目前没查明原因。
  4.有没有发现做了一些之后看来没必要或没多大价值的事?
  自己做的原型最后都没用上
  5.是否每一项任务都有清楚定义和衡量的交付件?
  每一项任务都有很清楚的定义，但测试报告和前端做出来的成果难以有清晰的衡量标准，测试报告没有其他相似产品的对比，而且毕竟每个人对于前端的审美存在一定差异。
  6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  意外：拼音库崩了，前几天还在博客里展示拼音功能来着
  风险：第三方库的导入，在导入npm的拼音库的过程中，导入后的项目一编译就报废，庆幸有备份项目。确实没法想到导入第三方库能直接报废项目，之前做项目从没遇到这种情况。
  7.在计划中有没有留下缓冲区，缓冲区有作用么?
  Beta冲刺时大家对工具和语言都很熟悉了，仅留了很短的缓冲区
  8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  缓冲区仍会保留，但只会更短，组长会更加严厉的督促组员的进度完成情况，如果没有完成，会建议组员利用自己的多余时间进行加班，不要拖累组内其他同学。
  9.学到了什么? 如果历史重来一遍, 会做什么改进?
  应在缓冲区多多搜索资料，编码其实不难，重要的是要有一个好的正确的思路

• 2.2.3 资源
  1.我们有足够的资源来完成各项任务么?
  有，十人组人力资源丰富，时间资源上，一周说长不长说短不短，去掉组员准备考试的时间，相对比较紧迫
  2.各项任务所需的时间和其他资源是如何估计的，精度如何?
  根据Alpha冲刺的经验估计，这个没法量化，但是在Beta冲刺前完成了项目，应该还算精确
  3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  足够，十人小组不缺人力资源，硬件资源用安卓机进行测试，电脑进行代码编写以及云开发。
  并未低估难度，毕竟这是一个服务类的微信小程序，最基本的前端界面肯定不能满足客户的需求和审美。于是在制作前端的过程中运用了第三方库进行进一步美化，目前看起来没有问题。
  4.你有没有感到你做的事情可以让别人来做（更有效率）?
  组内来看的话，没有。大家都是第一次开发微信小程序，每个人都在自己最合适的位置上。
  5.有什么经验教训? 如果历史重来一遍, 会做什么改进?
  对UI界面可以更多的借鉴前人的经验，不要埋头苦干闭门造车

• 2.2.4 变更管理
  1.每个相关的员工都及时知道了变更的消息?
  我们会在交流群中通知，保证每个成员都能及时了解变更消息
  2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
  通过Alpha答辩时老师和同学的建议，以及后续的内部讨论，必须实现的功能是我们确定项目后定下的产品准备实现的功能，推迟的是我们在完成预定目标后仍有空余时间才会考虑的对产品细节进行优化的功能
  3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  出口条件是预定功能能够正常使用
  4.对于可能的变更是否能制定应急计划?
  若出现可能的变更我们会根据项目当前进度和剩余时间制定应急计划
  5.组员是否能够有效地处理意料之外的工作请求？
  具体到个人这种能力比较一般，从整体看，小组处理意外情况的能力较强
  6.学到了什么? 如果历史重来一遍, 会做什么改进?
  相比Alpha冲刺，我们的工作量没有变小，但是效率提升了，再来一遍会从一开始就用最高效的方式展开工作

• 2.2.5 设计/实现
  1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  在Alpha答辩后，由组员共同商议，合适的时间，考虑到我们小组的抢矿，民主决定当然是合理的
  2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  对于一些细枝末节又难以实现的功能，我们适当将其推后
  3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  我们使用的是微信开发工具对小程序进行设计。微信开发工具的各项功能，如模拟器，云开发等简化了小程序开发的过程，显著加快了我们的工作效率。
  4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  总体设计上并没有太大的区别。我们主要是在uml的基础上对相关的功能进行了拓展和延伸，因此没有必要更新uml文档。
  5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  对点名记录下载的BUFG最多。主要原因是对代码的理解和使用不够熟练。发布以后尚未发现更多重要的bug（我们主要实现了程序的基本功能实现和debug，功能开发还有相当的工作量）。
  6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  代码复审主要是在测试过程中遇到问题后再寻找相关的代码进行复审。因为本组内的代码开发者都是初学者，因此对于代码规范的实现并没有强求。
  7.学到了什么? 如果历史重来一遍, 我们会做什么改进?
  进行程序设计的过程中使用相应的工具能够加强对程序框架的认识，加快设计开发的进度，也方便与其他成员进行交流。如果历史重来一遍，我们会在项目初期就开始进行一部分设计的工作，以减少对实际开发工作时间的占用，留下更多的空间。

• 2.2.6 测试/发布
  1.团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
  因该项目还没有完工，还有部分功能没有实现，所以没有一个具体的测试计划，只有在完成一个小阶段之后会进行一次项目流程的实现，观察到此为止是否存在问题，验收测试就是观察小程序的运行结果是否符合预期
  2.团队是否有测试工具来帮助测试？
  微信小程序自带的程序就可以进行实机测试，观察测试结果。
  3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  因为软件的功能较为直接，可以通过直接观察查看软件的效能。测试功能与软件的实际运行结果基本一致，在云数据库查看方面还存在一些问题，没有按照ID顺序进行观测，需要改进。
  4.在发布的过程中发现了哪些意外问题？
  目前仍处于开发完善阶段，还未进行软件的正式发布。
  5.学到了什么? 如果历史重来一遍, 会做什么改进?
  测试可以分出一个人来做，快速发现和定位BUG的来源，前端还是后端

• 2.2.7 团队的角色，管理，合作
  1.团队的每个角色是如何确定的，是不是人尽其才？
  根据Alpha冲刺的表现决定，原来做什么，Beta冲刺还做什么，和人尽其才可能还是有不小差距的
  2.团队成员之间有互相帮助么？
  有，Beta冲刺BUG频出，也经常一起找BUG
  3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （汇总至组长博客）：
  出现问题会在QQ群及时沟通，重要的问题在站立会议时一起集中讨论
  吴子澳：我感谢 赖莘龙 对我的帮助，因为某个具体的事情:在我对单人界面一头雾水时帮我找到了参考资料，并帮我完善界面
  许茹婷：我感谢吴超凡对我的帮助，由于小程序工具自身原因，我变成管理员后仍不能正常使用小程序，感谢吴超凡同学借给我他的appid。
  夏明旻：我感谢 吴彬 对我的帮助，因为某个具体的事情:在实现数据可视化的时候，吴彬教我如何调用后端数据，虽然最后还是没有实现出来，但还是很感谢他教我。
  赖莘龙：我感谢 吴子澳 对我的帮助，因为某个具体的事情:我对单人界面一头雾水时，在他的帮助下我们才能成功完成新的点名界面。
  谢元：我感谢赖莘龙对我的帮助，帮我们做出了大部分的前端界面，并且完善了代码。
  吴超凡：我感谢 _谢元_对我的帮助， 因为某个具体的事情:在修改读取Excel时经常出现不同种类的bug，他总是能很快的找到bug所在，以及修改的思路，对于我的项目进度有很大的帮助。
  罗进：我感谢 赖莘龙 对我的帮助，因为某个具体的事情:在我对完善界面没有头绪时给了宝贵的建议。
  庄婉苹：我感谢 夏明旻 对我的帮助，因为某个具体的事情:分配到前后端交互的任务后，不知道从哪里下手，教会了我一些云函数的使用。
  吴彬：我感谢 谢元 对我的帮助，因为某个具体的事情:在我对哪里找相关学习资料一头雾水时帮我找到了参考资料，并帮我明确目标
  陈祉镪：我感谢谢元对我的帮助，因为他帮我把我头疼了很久的环境配置设置好了。
  4.学到了什么? 如果历史重来一遍, 会做什么改进?
  线下会议效率很高，可以尽量选择线下会议的形式讨论

• 2.2.8 总结（4分）

  • 吴子澳：
    以前上任何一门课，或者觉得简单或者觉得困难，但是这次的软工实践真的让我感觉是种折磨，以前不会了，看ppt，看书，看网课，现在不会了，完全不知道该怎么办，不知道从哪看起从哪学起，全方位的懵逼，不过还好，最后我们还是做出来了成品，可能不像其他组用到很多我都没听过的算法，但是这是我们自己的成果。最大的收获不是这一学分，是自己的充实

  • 许茹婷：
    这是第二次用微信小程序完成软工作业，但是这是第一次接触到调用数据库，上传文件等技术，虽然这些部分并不是我负责的，但是通过查看代码也有了一定了解，虽然过程艰难，但我学习到了许多制作美观界面的方法。

  • 夏明旻：
    这次软工实践让我真正意识到自学的重要性，但一直以来我的学习方式都是被老师追着学，但是软工实践并不是，所以这门课我上的非常吃力。虽然在alpha冲刺说要在beta冲刺里努力出一份力，但是我的表现还是没有达到我的期望，还是挺遗憾的吧，希望在以后的时间里可以慢慢充实自己，但是变化是不等人的。

  • 赖莘龙：
    我们小组这门课经历了不少波折，在更换了选题后，我根据小组需要去学习了前端知识，但发现网上的教学和相关博客基本没有对我们这个小程序的制作有帮助的。出现问题，寻找解决方法，学习后发现对我们的开发没用，重新寻找解决方案，不断重复这个过程。。我甚至一度觉得这种过程是种折磨想要放弃，但好在有了组长吴子澳的帮助，我才能顺利完成任务。这门课程虽然很辛苦，但我感觉我学习到了很多新的知识，看到我们的成果时，也感觉自己花的时间是有意义的。

  • 谢元：
    心得：从这次的项目学到了很多知识，不只有前端的基础相关语言，还有微信小程序特有的前端语言，以及微信小程序云开发相关知识，如何操作云数据库，编写云函数等等。虽然有点累，也因为其他课程而焦头烂额，但确实很充实，完善了自己。

  • 吴超凡：
    本次的软工实践属实是一次十分充实的学习经历，在这门课程开始的时候和结束的时候我没有想过会学习这么多的新东西，学习的过程可谓十分艰辛，又因为基础本来就不怎么好，在项目刚开始的时候也不了解老师的具体需求，走了很大的弯路，前几周时间完全浪费了，最后做出的产品也只能说能看，还有很多的细节都没有在规定时间做完，还要继续努力学习。

  • 罗进：
    这是门异常折磨的课程，学不完的知识、d不完的bug，赶不完的ddl，终于暂时过一段落。在学习的过程中也很迷茫，不知道要干什么，要怎么学，但总的来说这段时间过得很充实，学到了宝贵的开发知识，经历了难忘的团队合作经历，最后得到了功能较完善的产品，对自己的能力和不足也有了充分的认识。

  • 庄婉苹：
    通过这次的大作业，学习到了基础的微信小程序前端的搭建，一点点前后端交互的知识，虽然说不多，但是有进步总是好的。很遗憾在柯老师的班级也没能卷起来。

  • 吴彬：
    在软工实践之前，对于软件开发我一直了解不深，在软工实践的过程中，我恶补了软件开发的相关知识，了解了软件前端后端之间的区别和联系，虽然过程很艰难，不过还好，最终在我们团队共同努力下还是做出来了成品。虽然没有其他小组那样使用很多前沿的算法和技术，但是最大的收获还是对自己的充实和对目标的明确。

  • 陈祉镪：
    此次beta冲刺没能帮上什么忙，本来在帮忙做着拼音库的调用，然后连npm都没配置好，还是队友太给力了。通过此次软工实践，我发现要学习的东西还有很多，相比实际工作过程的项目要求，我们现在学习的还都是基础。

标签：总结,功能,点名,微信,程序,冲刺,Beta,我们
来源： https://www.cnblogs.com/wuzzezeze/p/15615568.html