考前自救题库——Beta阶段反思

问题	内容
这个作业属于哪个课程	2021春季计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	团队项目-Beta阶段反思
团队在这个课程的目标是	完整地开发完一个项目且能达到预期目标
这个作业在哪个具体方面帮助我实现目标	在开发过程中开展各种会议，完成多次报告且分阶段展示成果，最后通过事后总结反思问题

数据补充

自救题库beta阶段累计用户量：1940

自救题库beta阶段累计活跃用户数：2423

自救题库beta阶段接口最高访问量：186683

自救题库访问最高并发数：2651

设想和目标

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

我们的软件定义就是一款帮助同学考前复习的小程序，具体来说就是让用户可以通过手机软件练习航空航天概论和军事理论两门课程的选择题，进而帮助用户利用零碎时间复习，既可以充分利用时间，也可以通过多种复习模式提高复习效率。

定义较为清晰，对于典型用户和典型场景也有比较清晰的描述，详情见发布博客和展示博客。

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

目标达到了。

原计划的功能虽然在开发阶段有一定的修改，但是截至发布时所有的预期功能都达到了，也按照袁家骅交付时间交付了。截至本篇博客发布前，由于航概和军理考试将至，本小程序用户量已经一千多了，日活量也达到了两三百，达到了预期的用户数量。

3、和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

之前的APP由于使用http传输导致了一些安全性问题，后来改成了https传输，之后觉得APP可能不够方便又换成了小程序，总之安全性有了很大的提升。

关于单元测试和Eslint由于后期时间规划不够充分没有完整运行，这也是之后开发软件时需要注意的地方。

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

用户量与我们事先预想的一致，甚至部分超出了我们的预期。

我们团队认为比赛功能是比较重要的功能，后来用户反馈也较好，但是用户认为最重要的可能是添加了军理课程，题目比较丰富而且都是出自于历年的复习和考试题，大大方便了对于军理的复习。

离目标更近了。

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

我们在开发之前会对用户进行更加详尽的调研，多方面了解用户需求，进而开发出更加值得用户信赖的产品。

计划

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

做计划的时间还是比较充足的，从ISSUE划分来看也比Alpha阶段更加合理，开发过程中只因为一些意外情况调整了ISSUE而没有出现大幅度改动的情况。

2、团队在计划阶段是如何解决同事们对于计划的不同意见的？

全组首先会进行开会讨论，赞同或者反对的同学都要给出自己的理由，如果都无法说服对方且这个问题不是很重要的话就先往后延迟，如果问题很重要且需要当场解决则通过投票决定。

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

都做完了。但是任务分配最后有一些调整，因为有的同学最后由于考试较多，时间比较紧张，没有办法花很多时间开发，最后把就把任务分配给了别的同学，但是最终所有功能还是全部完成了。

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

没有。

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

Beta阶段的ISSUE划分比较细致，前端每次merge请求时需要附上开发后的界面结果，后端直接提交代码，在开会时也会进行代码展示。

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

项目出现了2个意外：一是某位同学因为实验没有参加一次会议，而这次会议正好大家讨论修改了这位同学所负责的开发内容，因为会议记录没有记录完全，同学之间的交接也出现了疏漏，导致这位同学仍然按照原来的记录进行开发，最终在发布前三天才发现并进行紧急修改；二是有的同学因为时间比较紧张导致任务没有按时完成，但是与其他组员也没有及时对接，最终导致其他同学熬夜赶完了某些页面。

为什么没有估计到这样的风险？一是会议记录没有记录完全，文档也没有及时更新；二是同学之间的交流不及时，比较紧张的开发阶段有的同学较长时间联系不上导致了进度的延误。

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

留了缓冲区，为了防止意外情况的发生。事实证明，缓冲区的设置是很有意义的。

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

要求开发阶段每名组员都能按时联系上；

会议记录要更加详尽，一些重大修改可以直接发到群里方便没来的同学及时了解；

对于计划要更加严格地执行，减少拖沓现象的发生。

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

如上述计划修改。

资源

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

后期时间资源可能有些缺乏，特别是前端工作量较大。

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

本团队前后端分别设置了一个负责人，每位负责人在开发前划分好ISSUE并为每个ISSUE预估一定的时间，之后同学可以自己领取ISSUE也可以由负责人进行安排，精度划分还是较为细致的。

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

测试的时间和人力在后期都不太充足，对于文案可能不算太困难，但是美工的确低估了难度，由于本组没有专门负责设计美工的同学，所以所有界面的实现都是由大家合作讨论或者前端同学按照一切从简的方案进行开发，如果有设计的同学可能我们的界面也会更加美观。

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

本小组在最开始已经划分了两名比较熟悉技术栈的同学分别作为前后端的负责人，所以效率基本上已经达到最大化了。当然虽然有的同学对于技术栈比较熟悉，但也不可能把所有开发任务都堆到个别同学的头上，所以只要能按时完成分配的任务就已经是达到目标了。

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

任务划分可以更加灵活一些，对于提前完成个人任务的同学可以及时分配一些其他的任务，贡献分也相应提升，从多方面提升小组同学的积极性。

变更管理

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

一般会通过开会的方式变更管理，然后在群里进行通知。

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

我们在开发前进行了一次预备会议，将任务按照重要以及紧急的程度进行划分，对于重要且紧急的任务提前进行开发，也就是“必须实现”的功能。然后依次是紧急、重要的任务，最后是不重要且不紧急以及一些大家暂时没有决定好的任务进行延后。

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

见测试文档。

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

可以制定。在PM调度时后端的任务分配也进行了一定的调整。

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

能。比如之前所说有的同学因为时间原因自己的任务没有完成，最后分配给了其他同学，当然这是建立在其他同学已经完成了自己分内的任务并且能够较快上手之前同学的代码的情况下才能成立的，所以这样的情况最好还是不要发生。

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

每位同学对于自己在开发阶段的可用时间先进行预估，然后再匹配对应的工作量，如果有意外情况或者发现自己的时间比较紧张要提前与PM沟通。

设计/实现

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

设计工作分为两个阶段，第一阶段是在开发的开始阶段首先对整个功能有个大致的设计，是由全组同学共同讨论决定的，由于时间的原因我们会进行开发；第二阶段是在开发的过程中，征求用户意见以及组内同学经过更长时间的思考之后对于之前的设计可能进行一定的修改。

是合适的时间，合适的人，也是在当前阶段最有利于开发的做法。

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

有。

主要是比赛系统的设计，有同学在开会时提出将比赛改成快问快答设计，团队也进行了激烈的讨论，最后经过开发难易度分析以及实际场景的设想，最终采纳了该同学的建议。由上可知，主要是通过在会议中讨论的方式解决。

3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

在Alpha阶段使用了UML帮助设计和实现，在设计过程中由于部分功能的修改需要更新UML文档。单元测试由于时间的原因没有完整运行。

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

在前端科目切换时出现了一些bug，发布之后发现了如果把表情包当作微信名不能正常使用的bug，主要是由于团队内测时所有的成员微信名都是字母或数字，而且大家对utf-8编码都缺少了解。

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

由于Beta阶段每人主要负责一个模块的内容，后期也没有时间专门安排代码复审，主要是在功能交互或者出现冲突的时候会重复审查一下他人的代码。

关于前后端的代码规范都是遵守了各自开发工具上指定的代码插件规范。

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

我们会从一开始部署单元测试，然后在开发的过程中适当安排时间进行测试而不是到最后时间比较紧张导致测试出现bug。

测试/发布

1、团队是否有一个测试计划？为什么没有？

没有，后期开发过程中出现了一些意外情况，没有时间做完整的测试。

2、是否进行了正式的验收测试？

进行了，详情见测试报告。

3、团队是否有测试工具来帮助测试？

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

主要通过postman进行测试，通过Apache自带的ab测试进行压力测试。

改进计划：使用junit进行单元测试，并使用CI进行自动单元测试。

4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

主要采用压力测试衡量软件效能，测试结果还是较好的，具体见测试报告。

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

见计划部分的意外情况。

6、我们学到了什么? 如果重来一遍, 我们会做什么改进?

在开发阶段更加高效，预留完整的时间做测试。

最后我们是将所有的bug分别放进了单独的ISSUE里，可以考虑将bug与之前的ISSUE关联起来，便于更方面地定位bug以及对应地开发人员。

团队的角色，管理，合作

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

团队的前后端分工是在Alpha阶段接确定好的，一些会议记录等大家基本轮流进行，在角色选择的时候也是充分考虑了个人意愿，也算是人尽其才吧。

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

团队成员之间除了会上进行讨论外，其余的开发时间有任何问题都会在群里进行交流，一些除了开发外的问题比如文档等如果有同学有事或者抽不出时间也会有其他成员帮忙一起写。

3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？

一般进行开会讨论，没有结果就征求一些用户意见或者投票表决。

总结

1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

处在已定义级和已管理级之间，软件的质量有一定的保证，同时项目管理也有一定的标准。

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

目前团队处于规范阶段到创造阶段之间，当然规范阶段还有一些不足之处，大家在本次开发中也都得到了很多收获。

3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?

Beta阶段的会议上会检查开发进度，整体的开发效率较Alpha阶段大家还不熟悉技术栈的情况下提高了很多。

ISSUE修改的频次比Alpha阶段少了很多，在开发的初始阶段对任务的划分较为细致。

4、你觉得目前最需要改进的一个方面是什么?

就规范性来说，首先需要分成两个仓库分开开发，而不是一锅端；其次对于开发文档要进行更加规范的归类，比如接口定义等最好实时更新，并且大家在开发前也要养成勤看文档的习惯；

就开发来说，测试需要更完善，更规范，包括单元测试，CICD的使用等，同时ISSUE和commit的使用也需要尽量关联起来，milestone和分配任务要细致。在团队开发的后期大家可能只注重功能的实现而忽略了这些工具的使用，也导致在追踪bug时比较困难，所以这些辅助工具的使用也很重要。

5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

尽早并持续地交付有价值的软件以满足客户需求。开始时开发出来一个最小可用版本，同时重要的功能放在比较早的时期实现，不断进行更新迭代。

需求变化。在最开始我们希望让用户自定义上传题目到中期的比赛再到后期的快问快答，组员始终保持开放和学习以及为用户提供最好使用体验的心态面对需求的变化，最终不仅提高了用户满意度，组员的技能和学习能力也有了一定的提升。

6、正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

代码复审方面，可以在工作性质相同的组员之间进行复审；对于代码规范最后能前后端自己参照一份完整的代码规范，并严格执行。

其它软件工具的应用，应该如何提高？

充分利用CICD的自动化特性，对于milestone、issue和commit关联等都需要更加规范。

项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

我们开发的是微信小程序，可以直接通过微信公众平台得知用户数据。

项目文档的质量如何提高？

首先需要对文档进行归类，其次对于一些接口文档等尽量进行迭代而不是重新开设。

对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

• 要更加积极地调动组员的积极性，如果出现进度滞后的现象要积极寻找原因并落实奖惩机制
• 例如组织会议等工作可以让大家轮流进行，既增加了团队归属感也锻炼了大家的能力

对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

本软件工程课程的同学在这学期与其他同学任务量区分最大的可能就是本课程有很多阅读写作的作业，但是后来发现写作也会锻炼许多对于编程十分有益的技能。无论是写作还是写代码，最核心的共同之处都在于它们需要清晰思考的能力，所以对于我们来说，写作是十分必要的，对于现在的开发协作来说也变得越来越重要。在本次工程实践中出现了一些效地差错，如果当时我们能把更改的部分写入文档中，可能就不会出现这样的问题。

讨论照片（zwh同学因事请假）

大家的一些开发感悟