【CodingNoBorder - 15】无际软工队 - 求职岛：BETA 阶段事后分析
无际软工队 - 求职岛：BETA 阶段事后分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 团队项目-Beta阶段反思 |
| 我们在这个课程的目标是 | 熟悉敏捷开发的方法论，并通过实际开发产品进行实践。 |
| 这个作业在哪个具体方面帮助我实现目标 | 熟悉敏捷开发的方法论：按照给定的模板了解产品总结所应涉及并反思的各个方面。 通过实际开发产品进行实践：对照产品 BETA 阶段的实际开发，分析实践带给我们的宝贵经验。 |
Author: 无际软工队
Date: 2022.06.22
我们如何完成这篇事后分析？
依然按照本团队的优良传统，例会讨论后共同完成文档的撰写，再由协调员 PM 进行总结。
以下各部分会注明各部分的初稿编写成员。
设想和目标
By JJLeo & roife.
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本项目将开发一款聚焦校内科研实习和内推信息聚合的中和求职平台，主要解决问题有以下几点：
- 方便本科生寻找合适的实验室实习，了解更多校内前沿实验室和研究方向，为未来的学业规划打下基础。
- 方便学生寻找校内的内推信息，快速加入企业实习，与学长学姐进一步交流经验，为未来的职业生涯打下基础。
- 方便教师发布招收实习生需求信息，招收到更多合适的本科实习生，为相关领域注入新鲜血液。
- 方便已就业的学长学姐发布内推信息，快速招收本校高质量实习生，促进企业与学生之间的交流，帮助树立良好的企业形象。
我们的需求定义明确清晰（选题和需求分析），进行了充分的调研，对使用者的需求有较好的把握。
我们对典型用户和典型场景有清晰的描述（功能规格说明书），我们的典型用户主要有四类，与前文需求中的四个角度相对应，分别是寻找校内实习的本科生、寻找企业实习的学生、招收实习生的教师、有发布内推需求的往届生。典型使用场景著有为校内实习生招收和企业内推两部分，思路清晰，定义明确。
我们达到目标了么？
在 Beta 阶段，我们的目标为完善求职者小程序端和实现招聘者网页端。
求职者小程序端方面，在 Alpha 版本的基础上，求职者可以编写多份简历并对其进行版本管理，投递时也可以选择相应的简历进行投递。此外，求职者可以添加自己的技术栈标签，并通过标签查看推荐招聘岗位和高效搜索相关招聘岗位。
招聘者网页端方面，招聘者可以通过平台提供的一体化管理系统实现发布招聘需求、发布分工需求、修改团队介绍、查看投递相关分工的求职者列表、为分工自定义添加标签、向招聘者发布审核信息等一系列相关操作，通过一个一体化网页平台实现高效招聘人才的全部流程。
我们成功完成了上述功能，达到了预定的目标。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
相比起ALPHA版本的开发，BETA版本开发中我们团队的软工质量有了一定的提高，可以从以下两个方面体现：
- 本阶段我们仍然维持了ALPHA阶段的的代码管理、分支合并等方面等规范。同时，我们的团队依然遵守了pylint等工具的自动代码风格检查，通过自动化测试简化代码管理流程。
- 本阶段的代码质量也有一定提高。我们充分利用了django rest framework框架的优势，简化了代码量，同时让代码架构更加清晰。此外，我们还吸取了ALPHA阶段的教学，根据模型设计重构了项目的URL路由，重构后的路由更加合理，且更加符合restful规范。
用户量、用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
尽管因为疫情的缘故生产实习取消了，Beta 阶段相比 Alpha 阶段我们的用户量仍然增加了 20%，这是符合预期的。
求职者方面，有不少同学通过我们的软件真正找到了自己喜爱的实验室实习岗位，并在该岗位上真正开始了实习，在 Beta 阶段项目展示 中我们对其进行了详细阐述。
招聘者方面，Alpha 阶段中不少老师并没有非常迫切的实习生招聘需求。随着 Beta 版本的上线，一些老师也通过联系我们发布了相应的实习生招聘需求，并对我们的平台表示了好评。
由此可见，用户对重要功能的接受程度和我们事先的预想一致，我们距离我们的目标——高效解决校内科研实习和内推，也更近了一步。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
我们积极反思，发现我们的问题主要集中在以下两个方面：
- 因为疫情居家、考期来临等一系列不利因素，团队成员的工作效率有所下降，进度管理出现了小小的问题，使得总体工期相比预期略微延长。
- 在基于 Alpha 版本完成相关功能时，因为新功能和旧功能的设计理念产生冲突，导致需要对包括数据库在内的多处内容进行大幅度更改，一定程度上增加了工作量。
综合上述问题，我们深入思考，总结经验，在以下两个做出改进：
- 尽可能地放眼未来，预留更加充足的缓冲期，寻找合适的方式尽可能地提升团队成员的工作效率，在特殊时期克服困难完成任务。
- 一方面，在设计未来有可能变更的内容时，尽可能采用更加通用的架构，以备不时之需。另一方面，尽可能避免不合理的设计，如果能提早设计出适合的方案，就可以避免修改。
计划
By Selia & neumy & TakiVotoid.
是否有充足的时间来做计划？
在本阶段，我们拥有足够的时间来做计划。在项目进行初期，我们对整个项目的调研、开发、测试等相关工作做了详细的长期计划。在各项阶段进行的过程中，我们坚持周例会、Scrum Meeting 制度，规划短期任务。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
无际软工队由七名成员组成，大家性格各异、技能及对产品的理解亦各不相同。
——在项目开发的每一个阶段，都希望能发挥每个人的技能和才智。
基于这个朴素的愿望，项目开始时团队成员一致同意：我们更进一步，在产品成型的各个流程都打破传统意义上的层级关系，扁平化组织结构，在重视每一个人参与和思考的前提下，完成不只限于开发，更包括调研策划、文档完成、宣发推广等在内的各项任务。
在团队决策上，由于上述原则和特点，团队避免采用 PM 拍板方式，也不采用简单的多数决方式来完成开发过程中涉及的各项决策。每次团队讨论依照：提出方案——寻找问题——解决问题——确立共识的方式来进行。
当遇到意见分歧时，我们会先请具有不同观点的团队成员简明扼要、重点突出地阐述理由。然后其他同学加入，进行一段时间的自由讨论。对于每一个策划提案，大家需要从各个角度提出潜在问题和疑虑。我们从疑虑少的方案入手，一项项讨论解决方案，直到取舍和平衡被所有人接受为止。
原计划的工作是否最后都做完了？如果有没做完的，为什么？
前端的原工作计划中的大部分需求都已经实现，尚未完成的需求包括实时通讯功能，其原因在于经过Alpha阶段的用户反馈发现实时通讯功能的作用不大，且经过团队研判后认为该功能将向项目内引入过多的非核心功能。本着奥卡姆剃刀原理，团队决定取消该功能的开发任务，转而将精力投入到核心功能的开发。
本阶段中后端计划进行的工作绝大部分均已完成，已完成的工作包括Tag系统、多份简历维护、搜索系统、招聘者系统、简历审核系统、网页端登录系统等。未完成的工作有简历打印格式的优化，我们前期计划提供latex排版，优化简历排版，该功能的定位为惊喜功能。由于该功能属于非核心业务，且实现难度较大，团队决定延后其开发任务，在beta阶段专心完成前文提到的更重要的功能。
有没有发现你做了一些事后看来没必要或没多大价值的事？
前端的工作有效性很高，大部分开发任务都围绕核心功能展开。团队整体的开发理念都围绕用户需求开展，严格遵守了“用户需求推动功能设计、功能设计推动开发”的基本逻辑，因此只要用户需求的研判能够保持精准，实际开发中也不会产出过多的无意义工作。
后端的开发过程中，由于本团队的开发流程较为完善，很少出现没有必要的事。但是，由于alpha阶段的一项设计欠缺考虑，在beta阶段我们对其进行了一定的重构。该问题主要为，alpha阶段时，我们认为每位求职者只有一份简历，但在beta阶段，我们了解了用户需求后，决定支持多份简历的维护工作。因而，原先很多判断简历与求职者唯一对应的条件被修改或取消了，也就是说alpha阶段中的一小部分工作在后来被取消或修改了，这是由于用户需求的升级和项目初期对于用户未来需求的预判不够丰富而导致的。
是否每一项任务都有清楚定义和衡量的交付件？
对于前端来说，整体开发任务分为view model与view开发。对于view model型任务，其交付件就是一个能够正常运行各项功能的无样式的网站；对于view型任务，其交付件就是一个在view model上添加了设计样式的正常运行各项功能的网站。因此前端开发任务的交付与验收逻辑清晰，前端开发与衡量标准能够实现统一，无论哪种任务都可以采用相同的功能测试来衡量。
后端跟随前端的任务进行开发，前端每一个API需求都会在需求文档中写明所需内容和要求，并通知相应人员完成，后端收到任务后会严格按照要求完成任务，因而对于后端而言，每一项任务的定义都是清楚的。对于每一个任务，后端都将交付一个已经完成部署的API的链接，作为交付件，并且在API说明文档中给出API的输入、输出和异常情况定义，并给出使用说明，因而后端的交付件的定义和衡量都是清楚的。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
最主要问题在于北京突发疫情与学校取消实习要求导致的线下实习量的锐减，团队对用户需求的研判从寻找暑期实习转向了寻找与联络研究生导师，这使得前端团队对现有工作进行了一次重新梳理，来分析哪些原来不是核心功能的功能再次成为了核心功能，以及是否需要减少某些不再是核心功能的功能上的开发投入。对于疫情的估计失误的原因主要在于团队对北京市防疫政策与能力的错误估计。
在计划中有没有留下缓冲区，缓冲区有作用么？
在计划中，我们预留了缓冲区，用来应对意外，例如：
- 小程序审核出现问题；
- 服务端部署出现问题；
- 服务器、域名的购买、申请出现问题；
- 需求临时更改带来的功能设计的重新规划和重构问题；
- 在实现中发现原本设计方案中存在的问题。
BETA 阶段，我们主要遇到了第四点和第五点，应对基于团队结构和分工的鲁棒性。
将来的计划会做什么修改？
团队应当为需求设计留好足够的横向扩展空间，以应对环境的变化。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
在本学期的团队项目中，我们学到了很多：
完整的开发流程
在本学期的团队项目中，我们了解了一个软件的开发流程，亲身体验了包括调研、分析、设计、开发、测试、部署、维护等一系列工作，对于整体流程和任务有了更好的把握。
调研策略和技巧
在调研的过程中，为了征求到更多老师和同学们的想法和意见，我们首先设身处地思考了用户对于产品的需求性，然后尝试从用户的角度来向老师和同学们进行询问和交流。同时，我们还考虑到了用户类型的全面性，尽可能地收集不同专业、不同年龄、不同职业规划的人群的意见。
用户分析
在用户分析的过程中，我们采用点面结合的方式，既从大量统计数据中观察普遍现象，也从一些个体情况中提取小众的需求和建议。
后端的敏捷开发与部署
在本次团队项目中，同学们第一次完整地体验了后端项目由开发到部署流程。在开发前，我们就设计了一系列开发守则和自动检查机制，帮助我们在后续工作中紧密配合。开发过程中，我们使用了高效的开发框架，并仔细研究了其相关原理和使用方法，尽最大可能地减少冗余或不安全的代码。我们使用单元测试对后端的每一个API进行测试，这些测试在每次提交时自动运行，帮助我们快速发现问题。开发过程中，我们还采用了腾讯云提供的对象存储服务，结合第三方平台更好地发挥效益。仓库管理和部署过程都有严格的审查和控制，这些是后端服务的保障性措施，得益于这些措施，我们的服务没有过出现服务暂停等现象。
前端的跨平台开发
在前端平台中，我们根据用户需求和使用场景的不同，为求职者和招聘者设计了不同的平台。求职者以浏览为主，使用微信小程序更方便；招聘者以刊登和审核为主，使用Web端更方便，二者既有共通之处，又有不同。我们为两个使用群体，提供了符合自身需求的使用方式。
收集用户反馈信息与反思总结
在项目的进行过程中，我们联系了多位老师和同学，请他们在使用后，提出意见和建议。我们还建立用户微信群，方便用户及时提出问题。我们对收集到的信息进行分析和总结，并及时修改一些任务和规划。
团队合作技巧
在团队合作过程中，我们的交流一直很顺利，这得益于我们设定的一套看板流程，从分配任务到接收任务，均有明确的说明和反馈，节约了很多交流的时间和精力。
如果历史重来一遍，我们会在以下几个方面做出改进：
- 前期评估时考虑更多问题，比如用户需求的更多可能和时事变化的更多方向
- 模型设计过程中赋予模型更多的灵活性，以减少后续的大规模数据库冲突处理
- 前端设计考虑跨平台开发，更早地将不同平台和使用场景的前端开发任务加入计划中
资源
By TakiVotoid.
我们有足够的资源来完成各项任务么？
团队共有七人，工作量分配合理。在物质资源上，由于有合作方和大学生创业支持，不存在经济上的问题。在宣发资源上，团队采取针对性投放、争取合作方展示资源等方式，实现了较好的宣发效果，可以说资源足够。
各项任务所需的时间和其他资源是如何估计的，精度如何？
每周例会，我们都回顾了上一阶段的工作、进行下一阶段的工作量评估，团队始终处在磨合、再认识的动态调整过程中，因而对时间和资源分配具有较合理的把握。任务的粒度管理上，我们压缩到两日内完成的粒度，加以基于 Scrum Meeting 的周期性动态管理的方式，没有出现太大的、可避免的问题。
测试的时间，人力和软件／硬件资源是否足够？对于那些不需要编程的资源 (美工设计／文案)是否低估难度？
从测试报告来看，团队的系统在 BETA 阶段依然保持了较高的完成度和测试覆盖率，没有出现严重的 BUG。
美工设计工作交由团队的原型设计来完成，从两阶段的经验上来看，原型设计的分工只是将将覆盖了工作量，应当进一步调整分工留足预备量。
你有没有感到你做的事情可以让别人来做（更有效率）？
后文介绍了团队分工的具体方式和实践，总体来说团队的任务分配是合理的。
在 BETA 阶段，进一步细致化分工，并没有出现分工导致的效率折损。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
在人员构成更具多样化的环境下，团队可以考虑在设计方面加大人员投入。
变更管理
By TakiVotoid.
每个相关的员工都及时知道了变更的消息？
团队采用 Notion 进行项目文档管理，并通过任务看板、Github Issues 方式来展示任务；团队组织了有效的会议，并实行会议纪要轮值制，确保每一位成员对项目进度的把控和了解。在变更管理上没有产生明显的问题。
我们采用了什么办法决定“推迟”和“必须实现”的功能？
团队优先考虑合作方的需求，决定首先冲击上线的平台。
对于用户的两种角色，团队优先处理只能采用 to C 模式解决的部分：求职者；对招聘者则优先采用 to B 模式，以团队沟通、定制化对接工作来减少开发工作量，缓解开发压力。
对于功能组，我们优先完成基本功能，其次完成惊喜功能，最后进行体验的打磨。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
有。项目的出口条件可见 BETA 阶段测试报告。
对于可能的变更是否能制定应急计划？
前文已经指出了团队所预见的风险和预案，团队在 BETA 阶段进行的重构并没有损伤项目的整体架构。
员工是否能够有效地处理意料之外的工作请求？
BETA 阶段的变更主要在于上述需求的扩充带来的重构需要，团队成功地完成了任务。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
团队管理和分工建构的鲁棒性，决定了团队面对挑战和变更的能力。团队应当进一步健全管理机制，保证各尽其能，宏观调控每个人的工作量和投入，帮助团队更好地面对挑战。
设计／实现
By 春日野くさ & roife & TakiVotoid.
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在编码之前进行，由团队共同讨论完成。
- 首先，由 PM 根据项目的规划提出项目需求，并将需求划分为 Alpha 阶段需求和 Beta 阶段需求两部分；
- 然后在 Scrum Meeting 上由PM与团队进行讨论，根据开发难度对需求进行重新规划；
- 规划完成后，在实现过程中仍然可能发生部分需求上的变化，由开发者反馈至 PM，汇总后在 Scrum Meeting 上讨论决定。
从 Alpha 阶段开发结果来看，目前顺利完成了 Alpha 阶段预期的功能。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在设计中存在一些模棱两可的分歧，主要在架构设计与 UI 设计等方面上。
当发生这种情况时，有不同想法的成员首先会在私下交流解决。如果交流后仍然有不同意见，则会在 Scrum Meeting 上进行讨论。目前在开发过程中遇到的设计上的分歧都能够在当次 Scrum Meeting 上解决，保证了开发的推进。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
后端在第一次Commit时就定下了一个测试框架一个测试规范和一些测试Demo，这是因为我们相信单元测试是需要时刻伴随着开发流程的，及时有效全面的单元测试可以大幅减少我们调试成本。我们要求撰写后端API的成员为每一个API都需要编写一个单元测试正例，调试通过后才可以Merge进dev分支，我们还通过CI/CD来在服务器上进行自动化测试。其结果是它的确发挥了很重要的作用，我们几乎没有在代码发布后遇到恶性bug，系统的安全性也有一定保障。
我们没有采取测试驱动的开发，而是在一个要求Commit内同时上交代码和测试的形式，允许成员自行选择先写测试还是先写代码。
我们在项目开发初期定义数据模型之后，便采用在Notion上共享查看模型定义文档，这个文档详细的描述了模型的字段，关系，含义和约束，起到了UML的作用，并且相对于UML这个表会更加省时省力、表意更加清晰、更方便实时修改和共享。在开发过程中，我们会在实现功能的时候发现数据模型可能有冗余或不足，将会直接对其修改。从Alpha到Beta阶段的迭代中，我们发现简历的版本管理功能是现有的数据结构不能解决的，因此也修改了UML文档来表现新的功能。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计／开发的时候没有想到这些情况？
在前端上主要是在显示上没有做到完美，某些提示不能以一种完美的形势展现给用户，这是因为前端在绘制页面上非常注重美观度，但是因为种种原因延误了工期使项目不能尽善尽美。
微信端出的主要bug是渲染异常，这是因为微信开发框架自身的不完备性使得代码无法按照程序员的想法正常工作，不过我们在开发过程中会同时进行测试并修正。
后端出现的bug主要在于前后端接口商议过程中有一些偏差，导致后端开发出来的API不完全符合前端的需要，这时候我们会直接沟通并立刻将其解决，除此之外后端自身出现的bug是比较少的。
因为我们的测试较为完备，在程序发布后几乎没有出现恶性bug，唯一的bug是微信下滑加载更多列表有时候不能启动，但这是微信框架的问题，我们无从修复。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们在项目开始之前就制定了一套严格的规范，包括 commit message 格式、分支合并流程等，借助 pylint 等工具，将这一套规范其融入了 CI 的流程。
项目开发的前期，项目组成员对于Django框架不够熟悉，因此由对Django比较熟悉的成员负责代码复审工作。当后端的某位成员提交代码后，由复审的组员进行审核，并且为代码提供架构和编写上的建议，并反馈给开发者。
经过几次的改进，后端成员基本能够在代码质量、风格等方面进行统一。此时我们主要使用 CI 来规范各个成员的开发行为，保证合并到分支中的代码都是符合代码规范的。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
磨刀不误砍柴功，明确的、引入自动化的代码规范及质量管理机制，为团队带来了很大的帮助。Code Review 工作弥合了大家的经验差异，为团队的总体开发质量带来了较大的提升。
测试／发布
By 春日野くさ & TakiVotoid.
团队是否有一个测试计划？为什么没有？
有。
团队针对各 API 功能组、用户端模块和操作流程，完成了单元测试、场景测试、压力测试等多维度、全方位的测试。对后端稳定性和预期功能、安全性，前端交互体验、视图逻辑等方面做了尽可能全面的测试。
同时，团队提供了一套 BUG 收集及反馈机制，并通过直接访谈、或用户群的方式触达用户，虽然时间紧迫，但仍收获了不少宝贵意见。
是否进行了正式的验收测试？
在验收阶段，团队组织全体团队成员进行了功能性测试，从用户的视角出发，补全用户故事的各个方面，以平台提供的功能序列为主干，测试边界问题。
BETA 阶段遗留的视图 BUG 较少，主要原因在于从一开始构建前端视图时，就采用了响应式设计，并由于前端架构的模块化，每个模块在开发阶段就已经过了细致的交互测试和场景测试。
团队是否有测试工具来帮助测试？
是的，利用Django框架的基于unittest集成而来的测试框架，再加上若干特别编写的辅助函数，可以轻松开发单元测试，并可以在CI/CD中自动运行。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们使用JMeter来测试API的可用性和效能。因为软件在部署时各个方面都会造成性能的低下，我们需要诊断是否存在某些错误的设置导致不能完全发挥服务器的能力。我们在JMeter测试时观察服务器的CPU，内存，带宽等参数寻找瓶颈以试图取得更好的性能。
做性能测试让我们对服务器承载能力有一个大致的了解，在应对真实使用场景时不用提心吊胆。可以改进的地方是可以在单元测试中额外增加性能测试部分，对优化代码起到积极作用。
在发布的过程中发现了哪些意外问题？
BETA 阶段的分发主要遇到了疫情的影响，生产实习被取消，预想的推广策略被打乱。考虑到 BETA 阶段的主要发布对象为招聘者端，团队因而转大规模宣发为有针对性的对接用户，在产品的发布上做了相当多的努力。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
与 ALPHA 阶段的体验相同，团队仍需更早引入内测用户，帮助进行系统的整体测试。
BETA 阶段，系统已上线运营，可以考虑引入灰度测试机制，向一部分用户预先上线测试版。
团队的角色，管理，合作
By BUAA_Wander & neumy & TakiVotoid.
团队的每个角色是如何确定的，是不是人尽其才？
本团队成员共七人，三名前端开发人员，三名后端开发人员，一名机动开发队员。PM 由前端开发人员担任，团队整体以前端需求为驱动，前端与后端的交流与沟通贯穿了整个并行开发流程。
团队成员的角色主要由成员们各自所掌握的技能和工作经验决定。
PM 具有充足的前端开发设计经验，有一套稳定成熟的UI设计风格，且对产品交互设计有独到见解。
机动开发人员具有丰富的全栈开发经验，作为PM的补充，在技术问题上辅助PM进行决策，并在实际开发过程中辅助观察督促前后端进度。
后端开发人员均能够熟练使用Django框架，且在接口安全性设计、后端服务架构与性能调优方面也有丰富经验。
前端开发人员能够熟练使用Vue（及其衍生的Nuxt和uni-app）框架，在用户界面设计与提高交互体验方面表现出色。
团队成员之间有互相帮助么？
本团队成员之间通过互相的协作与学习构建强关系纽带，因此互相帮助是本团队精神中不可或缺的一部分。不可否认的是，团队中确实存在着技术层面的个人能力差异，使得即使是均衡的任务分配也会对不同的成员造成不同的工作压力。因此为了更好地促进团队整体技术能力的提升与保持团队进度有序推进，团队通过定期的Scrum Meeting及时交流技术难点，讨论工作中遇到的技术难题，让高技术力的成员承担顾问的角色，来一起解决实际工作中遇到的问题，从而能够在不增加高技术力成员工作负担的情况下最大程度地利用团队成员的工作能力。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
有赖于定期的Scrum Meeting，项目进度管理能够以一个较短的周期进行定期检查，从而使得项目进度方面一直以来都没有出现较大的延期危机。团队采取了扁平化的管理结构，任何一位成员如果出现突发情况导致工作无法按时完成，其情况都将及时反馈到所有成员手上，此时将进行团队内的负载均衡，将该成员尚未完成的工作分摊至目前工作进度较为乐观的成员手中，在满足工期的要求下尽可能不增加其他成员的工作负担。同时，也有赖于团队的扁平化结构，当涉及团队协作时，主要合作成员通常可以采取直接联调的方式，通过线下或在线通讯工具保持实时的沟通，大幅提高解决问题的效率，同时也注重文档的记录，时刻保持共享文档的实时性更新。
团队成员间的感谢
团队成员都很腼腆，但他们 给出的奖励分 是真实的。
如果需要的话，请课程组来现场 （但是现场已经没有了那就随时欢迎线上！）听听大家的心声。
总结
By TakiVotoid.
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
团队完成了本阶段的所有功能需求，进入完善阶段；同时，团队正在进一步丰富产品功能。处于 CMM 的已管理级（Managed）阶段和 CMMl 三级，明确级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队的产品开发已步入正轨，各方面已形成完善的工作流，正处于创造阶段。
你觉得目前最需要改进的一个方面是什么?
团队应当改进风险管理能力，并在需求挖掘上进一步投入精力。
对照敏捷开发的原则，你觉得你们小组做得最好的是哪几个原则？
示例已经在以上的各个分项、项目展示中提到过了，以下针对各条给出一个自评。
| 原则 | 完成质量 |
|---|---|
| 尽早和持续地交付有价值的软件来满足客户 | ⭐⭐⭐⭐ |
| 欢迎对需求提出变更 | ⭐⭐ |
| 要不断交付可用的软件 | ⭐⭐⭐ |
| 项目过程中，业务人员与开发人员必须在一起 | ⭐⭐⭐⭐⭐ |
| 要善于激励项目人员 | ⭐⭐⭐⭐ |
| 最有效的沟通方法是面对面的交谈 | ⭐⭐⭐⭐ |
| 可用的软件是衡量进度的主要指标 | ⭐⭐⭐ |
| 提倡可持续的开发 | ⭐⭐⭐⭐ |
| 对技术的精益求精以及对设计的不断完善将提升敏捷性 | ⭐⭐⭐⭐ |
| 要做到简洁，尽可能减少不必要的工作 | ⭐⭐⭐ |
| 最佳的架构，需求和设计出自于自组织的团队 | ⭐⭐⭐⭐⭐ |
| 团队要定期反省如何能够做到更有效，并相应调整团队的行为 | ⭐⭐⭐⭐ |
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
应当完善代码注释。代码规范团队做得已经较为完善，应当进一步扩大 Code Review 的范围和团队交流的代码质量层次和方面。
整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
前端可以考虑剥离部分逻辑和服务离线运行。后端仍应进一步完善 API 版本机制、设计和实现迭代更新的具体步骤和流程，保证平台接口的鲁棒性，提高平台对新需求的适应能力。
其它软件工具的应用，应该如何提高？
尝试引入 Slack 等团队沟通工具，现有基于 QQ 的团队线上通讯手段存在局限性。
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
对于活跃用户分析，在后端运行了团队编写的数据统计与分析模块，但收集的数据仍不够全面。仍可以考虑引入第三方数据记录与分析平台，分析用户热点。
代码层面以外，团队还应进行更密切、长期化的用户调研和跟踪，了解用户的反馈意见。
项目文档的质量如何提高？
除了已有的 API 文档等项目文档，可以考虑引入自动化工具，规范代码注释并自动生成文档。
对于人的领导和管理，有什么具体可以改进的地方？
在疫情期间线上合作的新情景下，可以考虑将线下团队建设模式延伸扩展至线上或寻求新的活动方式。
对于软件工程的理论，规律有什么心得体会或不同意见？
课堂学习时体会不深，实际实践下来的体验让我们意识到：软件工程的方法论是软件开发的生命之源。
其他感想和体会
By TakiVotoid & Selia.
感想
在本次项目开发中，我们经历了Alpha、Beta两轮迭代，小组成员分工合作完成了调研与评估、设计与实践、测试与运维等环节，在实践能力、设计能力、分析能力等方面都有提升。下面，我们来展开谈一谈小组在本轮开发中收获的经验与教训。
工欲善其事，必先利其器。 先静下心来深入了解所需要的工具，再进行编码实践，往往要比直接上手实现要更快更好。项目初期，小组成员对RESTful框架了解不足，因而走了很多弯路，后来随着学习的深入，逐渐发现更好的实现方法，轻松解决此前困扰的诸多问题。在敏捷开发中，我们要注重学习和深入了解开发框架的实现细节，仔细研读指导文档，先行熟悉框架特点。
留得五湖明月在,不愁无处下金钩。 再精心的设计也常常有所疏漏，我们总要为可能出现的问题做出准备。再本项目设计的过程中，Alpha阶段后期我们逐渐意识到了小程序很难为招聘者提供良好的用户体验，所以增加web端的设计。而在开发web端时，我们不得不重新设计了一些模块。这一次经验告诉我们，在开发过程中尽可能地为更多可能的拓展留出余地，做出充分的准备。
人有冲天之志，非运不能自通。 努力和谋划固然是重要的，但是有时候我们也需要一点点运气。我们最初的选题主要有两个方向：校内外卖代取和校内求职平台，最终在调研和决策后选择了后者。进入五月，随着疫情形势变化，校园开始了封闭管理，外卖停止入校，那时我们还在庆幸没有选择代取项目，否则要面临破产风险。然而，几周后，外卖逐渐恢复了，但暑期实习却取消了，这对我们后续的推广十分不利。在项目的完成过程中，我们看到了时势对一个项目发展的巨大影响，我们需要有更长远的目光和更敏锐的嗅觉。
展望
站在软件工程课程的终点，回顾两个多月充实而收获颇丰的开发流程，我们相信无论是对于成员自身、还是刚刚萌芽看见阳光的产品，都还刚刚来到漫长旅程的起点。
第一篇团队博客里我们满怀着信心写下：
希望不受拘束地用编程实现想法，完成蕴含无限可能的产品。
今天，我们站在终点——
再出发。