「MOSS - 33」MOSS队：Beta阶段总结和反思

「MOSS - 33」MOSS队：Beta阶段总结和反思

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	Beta阶段总结和反思
我们在这个课程的目标是	熟悉敏捷开发的方法论，并通过实际开发产品进行实践。
这个作业在哪个具体方面帮助我实现目标	完成Beta阶段软件的总结和反思，对整门课程进行系统总结和反思。

Author: MOSS队

Date: 2023.06.16

Part 1 设想和目标

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

我们的软件要解决什么问题

从学生角度，要解决如下问题：

• 答疑信息集中在微信聊天记录中，高度序列化，并且答疑信息相对不公开的问题。
• 学生出于各种原因不愿意实名提问。

从辅导师角度，要解决如下问题：

• 微信答疑打扰辅导师，无法集中安排时间答疑。
• 辅导师激励机制较弱。活动组织者难以统计辅导师的工作量，不方便发布志愿时长。

从活动组织者角度，要解决如下问题：

• 整理的课程资料鲜为人知，需要有力的平台推广。
• 活动组织者对答疑活动情况没有合适的了解渠道。

是否定义得很清楚

是，我们从三类用户的视角，分点列举了软件需要解决的问题，问题彼此之间已相对比较独立。

是否对典型用户和典型场景有清晰的描述？

是，我们对典型用户和典型场景有清晰的描述。我们有三类典型用户，分别对应用户、辅导师、活动组织者三个角度，并且采用流程图的形式描述答疑的具体场景，定义十分明确

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

我们的目标基本达到。在规格功能说明书中提出的主要功能都已实现。

用户数量达到了预期，计划与实际的使用者都是22级士谔书院学生和士疑解惑的辅导师。

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

用户量、用户对重要功能的接受程度和我们事先的预想的较为一致。我们离我们当初希望解决的用户痛点更近了。

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

yjk: 主要的设计和架构比较清晰，但是对于用户的使用需求的把握仍有进步空间。如果可以重来的话，我们会进行更完善的用户调研，对各项工作的优先级进行更细致的划分；在用户使用方面，我们发现出现了明显的倾斜，如学生们对物理答疑的需求较大，但是物理的辅导师人数却相对较少，且回答热情不高，这是本软件之外的问题，但是也应作为现状和用户需求的一部分纳入考虑，如进行更广泛的宣传动员、实施更行之有效的奖励激励政策。

szy:经验教训包括明确需求、保持有效沟通、注重代码质量、确保测试全面。如果历史重来，我们将更早地进行需求分析与评估，加强团队间协作与沟通，遵循最佳编码实践，确保严格的测试及持续集成，有控制地处理变更以降低项目风险。

yyh:主要是针对后端框架的经验教训，在处理搜索引擎的时候，发现如果有更加合理的后端架构可能会事半功倍，因此最后也仅实现了分词模糊搜索功能。如果可以重来，希望能够设计出更加优美的后端架构，结合现成的开源搜索引擎，会使得搜索体验得到进一步提升。

ccy:经验教训主要在jwt鉴权码的部分，由于设计数据库以及后端架构时没有考虑jwt实现细节，导致到具体实现jwt刷新机制时，框架自带的大量接口无法使用。如果能够重来，希望能够花费更多时间在技术细节的调研上，实现更安全的认证机制。

wxz:前端的分工基本上是按照功能进行划分的，这导致UI设计上有一些不协调，但是这样分工其实很符合敏捷开发的需求，毕竟开发流程多一个环节，开发的效率就会相应降低一些。如果重来一次，如果考虑采用瀑布模型开发，那么我很乐意将UI设计单独作为前端开发的一环。

wxg:在Alpha阶段，我们已经预先设想了Beta需要扩展的大致功能，留了足够的接口。但同时，我们并没有设想对提问的流程进行更改，这导致在Beta阶段用户对我们的提问流程提出建议时，我们无法即使做出更改。这可能需要在后续进行一定的重构。

jyz:在项目最初前端采取了按模块分工的方式，这样的分工有一定优势但也有弊端，在我们项目中弊端可能主要体现在美工方面，不同人设计的界面不完全协调。如果重来，也许会让某一个人单独负责UI设计。

Part 2 计划

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

是的，我们深知磨刀不误砍柴工的道理，在Beta开始之前预留了足够的时间进行调研、讨论和计划，在课程组和甲方的帮助下完成了充分的计划。

在Beta阶段，我们基本采用Alpha阶段的时间线，并特别考虑了考期等因素，预留了更充沛的时间冗余，效果更佳。

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

我们的主要方式是相关成员讨论和表决。对于团队整体级别的计划的意见，一般进行线下会议或线上会议的方法讨论；对于单独涉及前端或后端的内容，如果不产生副作用影响，由前端或后端的成员分别讨论即可。

得益于充分的事前计划和分工，我们在Beta阶段只遇到了少量的不同意见需要协调，且不影响主要工作框架，效果较好。

得益于Alpha阶段的良好合作，我们在Beta阶段的计划和沟通更加自然、流畅、顺利。

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

在规格功能说明书中提出的主要功能都已在alpha阶段实现。issue的标签功能、数据统计功能、更丰富的管理功能等都已在beta阶段实现。

总的来说，本项目原计划的工作已全部保质保量完成，并通过了甲方的验收。

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

我们的多数工作都是很有价值的，部分工作可能看起来没有直接价值，但是也拓展了我们的视野，帮助我们选择了正确的道路进行开发。

站在Beta阶段结束的时间点回看，我们的工作富有价值且高效，既高规格完成了既定任务，又充分锻炼和提升了团队成员项目开发与合作的能力。

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

是的，对于主要的功能和任务，我们通过GitHub的issue和pull request进行管理，交付清晰，方便管理和回滚。

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

yjk：项目整体都是按计划进行的，只出现了少量意外，主要集中在Alpha阶段和甲方交付的过程中。具体地，当时由于书院的老师工作和排期繁忙，我们没有充分提前提交我们的软件，导致验收和公众号宣传等工作有所滞后，但是好在不影响项目的整体成果，最终也得到了甲方的充分认可。

szy:项目整体按计划进行，但出现部分意外，如需求变更、排期延误等。我们没估计到的风险包括技术实现难度、团队成员协作问题等。原因在于初期需求评估不足、团队经验欠缺，导致未能提前发现和应对这些风险。后续需加强风险管理。

yyh:项目整体按计划进行，但是网页备案方面出现意外情况。由于没有在网页上悬挂备案号导致备案审查没有通过，在两日之内紧急更新悬挂号。原因是之前没有备案过相关网页，缺少相关经验。

ccy:项目整体按计划进行，但是在展示活跃用户时，由于没有设置展示用户数目的上限，导致后台用户信息面临泄露的风险。原因是涉及接口时没有考虑周全，所幸最后及时修复。

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

是的，我们在任务管理、时间安排等方面都留有了缓冲区，增强了项目运行和管理的鲁棒性，保证了我们在遇到突发情况时可以不影响项目的整体安排和进度。

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

未来，我们会进一步明确设计缓冲区，尽可能以明确的项目管理和安排来避免加班等不稳定情况。

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

yjk：真正学习和实践了如何管理一个小规模的软件团队并向一个共同的目标前进。如果重来的话，我会学习更多关于项目管理和进度规划相关知识，更科学地分工和组织。

szy: 我们学到了合理分工、明确职责的重要性。若历史重来，我们会改进需求分析，提前明确任务，加强团队协作，确保成员承担相匹配的职责。

jyz: 学到了敏捷开发的流程，并且体会了团队开发和个人独立开发的不同。重来一遍也许在早期就更详细制定分工，比如专人单独负责美工，减少反复修改的过程。

yyh: 学到了敏捷开发的流程，以及认识到了软件功能性和安全性测试的重要性。如果历史重来，我会在早期制定更详细的计划以及设计更合理的框架。有了更合理的框架，则后端就可以更改成更好的搜索引擎，在核心功能方面更加完善。

ccy: 学到了如何在开发中和成员高效沟通，并认识到了软件安全性的重要性。如果历史能重来，我会花费更多时间调研技术的细节，并设计更自洽的后端框架。

wxz: 学到了网络安全的重要性。在以往的前端开发过程中，我往往只关注于界面是否美观、功能是否合乎逻辑，很少考虑安全相关的问题。如果能重来，会把安全性问题也作为一项重点在设计之初进行充分调研，而不是开发完后再修补漏洞。

wxg: 学到了软件可扩展性的重要性。如果历史能重来，我会在设计阶段考虑更多可能的用户需求变化，并留下更多冗余的空间。

Part 3 资源

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

是的，我们有优秀的团队成员、认真负责的甲方以及优秀的课程团队，因此有足够的服务器资源等完成各项任务。

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

我们根据往届惯例和现代化工具进行估计，精度大致符合现实需求。

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

后端单元测试：使用DRF的APITestCase框架进行测试，pycharm也有对此单元测试的集成，较为方便。同时beta阶段也对之前alpha阶段的单元测试进行了回归测试。因此测试的时间和人力资源较为充足。

后端压力测试：使用开源负载测试工具Jmeter，模拟多种负载类型如并发用户数、请求率进行测试，比较方便。在beta阶段也针对新引入的接口设计了单元测试用例。整体来说，人力与软硬件资源是充足的。

美工资源：在美工方面，Alpha阶段我们确实没有分配足够的人力去处理；而在beta阶段，我们向美工倾斜了更多的人力和资源，大幅提升了软件的页面效果和用户友好度。

文案：博客的文案部分，由于PM将任务分配到个人，并负责最后琐碎的整理工作，大家可以较为及时完成文案。

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

我们根据大家的能力、兴趣、个人时间等进行了合理的分工，多数工作都安排给了合适的人选，因此没有什么别人做更有效率的事。

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

yjk：如果可以重来的话，我们会更科学地评估任务的分工、所需人数以及耗时，来更完善的管理项目，进一步地，我们会学习和使用当前工业界流行的资源分配与评估方法，使得资源分配更加科学合理。

szy:我们学到了合理调配资源、充分利用现有资源的重要性。若历史重来，我们会根据任务需求分配人力与物力，提前考虑可能遇到的困难，确保资源利用最大化。

jyz：有些任务可能比起多个人共同讨论，专人负责更有效率，例如美工设计。在分工明确方面，我们BETA阶段相较ALPHA阶段有了明显改善。

yyh：资源分工需要对项目工作量有着更加合理的估计。因此，熟悉和了解使用的技术栈尤其关键。如果重来一遍，可能会让专人提前了解相关技术栈，进行集成测试。

ccy：在分配任务时，需要根据项目的需求和紧急程度来确定任务的优先级。如果重来一遍，可能会在核心功能上花费更多时间。

wxz：需要进一步对功能的优先级进行分工，优先保证核心功能的实现效果。如果重来，可能会对功能的分类更加详细，对不同类别的功能采取不同的验收标准。

wxg：对任务进行更细粒度的拆分，理清任务之间的前置后置关系。如果能重来一遍，我会对测试任务制定更详细的验收标准，并在进度管理时优先处理前置任务。

Part 4 变更管理

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

是的，我们及时地通知了所有相关成员。

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

我们主要通过线下会议和文档管理的方法来集中表决。

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

我们规定了明确的项目出口条件：

前端

要求	完成情况	下一步
实现学生端最小可用版本	覆盖了issue提问、同意，搜索issue，与辅导师一对一问答的功能。	继续完成功能更完善的平台。新增如通知，反馈，学年等功能。
实现辅导师端最小可用版本	覆盖了issue认领、复审、分类等功能。针对issue进行富文本回答。	继续完成功能更完善的平台。提供辅导师通知功能。进一步优化复审流程。
实现管理员端最小可用版本	覆盖了增加用户，批量增加用户，冻结用户等功能。	继续完成功能更完善的平台。提供管理员更加全面的权限控制。
UI简洁美观	UI简洁且美观	进一步美化UI，优化用户操作体验
前端的验证和提示	添加了大部分前端验证和提示。如用户登录验证码，确认弹窗等。	对新功能继续添加前端验证支持
兼容性	在mac、windows、ubuntu等环境的chrome、edge浏览器的最近大部分版本都有所兼容。	进一步扩展兼容支持

后端

要求	完成情况	下一步
数据库设计	前端能够正常访问，并支持正常的数据修改	针对新增功能或当前bug完善设计数据库
权限验证	针对学生、辅导师、管理员都有对应的权限控制	继续完善权限系统，并做好安全测试
批量注册	保证了注册账号只能由管理员权限账号创建，放置恶意用户创建账户	设计注册方式，让注册更加便捷
issue检索	支持对于issue的各种检索，如tag搜索，关键词搜索等	继续优化性能和检索体验

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

是的，我们可以指定应急计划。

得益于清晰的项目管理和任务分工，我们为项目设置了合适的安排和冗余，即使出现突发变更，我们也有足够的人手和时间来处理。

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

是的。

得益于团队的凝聚力，每一位团队成员都对项目怀有极大的热情；而且得益于事前合理的分工和安排，我们较少出现意料之外的工作安排，即使出现了，成员也都积极承担和解决。

Part 5 设计/实现

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

前端：设计工作在需求分析和原型设计阶段基本完成，由团队内熟悉项目需求的同学完成，我们认为是合适的时间和合适的人选，提前进行设计工作，由对需求比较清晰的同学进行初步设计是不错的选择。

后端：设计工作在需求分析结束立刻进行，由团队内有过数据库设计经历的同学完成。在需求确定后，数据库表、字段定义可以效率较高地确定，并且和前端原型设计并行执行，不会耽误进度；而由设计过数据库的同学完成，可以避免不少此前踩过的坑。

前端和后端设计工作，均由alpha阶段负责需求的同学进行确定，是合适的时间和人选。

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

没有碰到。

在Beta阶段，我们吸取了Alpha阶段的教训。对于统计图、工作量统计等较为复杂的功能，我们都通过详细的文档来避免模糊性。同时通过2-3人的小规模快速会议来确保该任务的参与者能达成共识理解。

issue状态及转移明细

issue的状态转移条件一开始设得不够严密，导致实现过程中反复更改。一开始没仔细考虑状态转移的权限判断是放到前端还是后端（还是both）。

在发现问题后，新增更详细的文档来明确上述摸棱两可的情况。

issue状态及转移明细

0：未认领(默认)，1：已认领，2：未认领复审 3: 已认领复审 4: 有效提问 5: 无效提问

写在前面：为了方便调试，默认管理员可以进行所有操作；或者后端可以创一个role=3，代表开发者身份

状态

前提：学生为提问者，辅导师为在当前状态认领/认领复审了该issue的辅导师

状态	学生是否能发布和修改comment，能否修改issue描述	辅导师是否能发布和修改comment，能否修改issue描述
0	能	否
1	能	能
2	否	否
3	否	否
4/5	否	否

allow_comment：0无，1有

状态转移

状态转移	对应api	前端操作视图	操作对象与条件
0→1	adopt_issue	搜索视图/issue详细视图	辅导师操作，具有该科目属性的辅导师可以操作
0→5	cancel_issue	issue详细视图	学生操作，提出该issue的学生可以操作
1→0	reject_issue	issue详细视图	学生操作，提出该issue的学生可以操作
1→2	agree_issue	issue详细视图	学生操作，提出该issue的学生可以操作
2→3	review_issue	搜索视图/issue详细视图	辅导师操作，具有该科目属性的辅导师且不是该issue最后一任回答者可以操作
3→1	readopt_issue	issue详细视图	辅导师操作，认领复审该issue的辅导师可以操作
3→4/5	classify_issue	issue详细视图	辅导师操作，认领复审该issue的辅导师可以操作

后端向前端传一个status_trans_permit字段，长为7的int数组，第i个int代表jwt的拥有者是否有权限对该issue进行上面第i个转移，若有权限则为1，没权限则为0

统一采用复杂的权限由后端来计算判断，通过接口向前端返回permit位；而简单的权限（例如根据role即可判断的）就由前端来判断，但后端也会鉴权。

0：未认领(默认)，1：已认领，2：未认领复审 3: 已认领复审 4: 有效提问 5: 无效提问

写在前面：为了方便调试，默认管理员可以进行所有操作；或者后端可以创一个role=3，代表开发者身份

状态

前提：学生为提问者，辅导师为在当前状态认领/认领复审了该issue的辅导师

状态	学生是否能发布和修改comment，能否修改issue描述	辅导师是否能发布和修改comment，能否修改issue描述
0	能	否
1	能	能
2	否	否
3	否	否
4/5	否	否

allow_comment：0无，1有

状态转移

状态转移	对应api	前端操作视图	操作对象与条件
0→1	adopt_issue	搜索视图/issue详细视图	辅导师操作，具有该科目属性的辅导师可以操作
0→5	cancel_issue	issue详细视图	学生操作，提出该issue的学生可以操作
1→0	reject_issue	issue详细视图	学生操作，提出该issue的学生可以操作
1→2	agree_issue	issue详细视图	学生操作，提出该issue的学生可以操作
2→3	review_issue	搜索视图/issue详细视图	辅导师操作，具有该科目属性的辅导师且不是该issue最后一任回答者可以操作
3→1	readopt_issue	issue详细视图	辅导师操作，认领复审该issue的辅导师可以操作
3→4/5	classify_issue	issue详细视图	辅导师操作，认领复审该issue的辅导师可以操作

后端向前端传一个status_trans_permit字段，长为7的int数组，第i个int代表jwt的拥有者是否有权限对该issue进行上面第i个转移，若有权限则为1，没权限则为0

统一采用复杂的权限由后端来计算判断，通过接口向前端返回permit位；而简单的权限（例如根据role即可判断的）就由前端来判断，但后端也会鉴权。

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

后端运用单元测试进行测试，大部分采用TDD测试驱动开发。

测试用例数目当前总共有64个。其分布与Alpha阶段区别如下：

• issues：16个
• users：20个
• admins：9个
• subjects：4个
• tags：4个
• chapters：4个
• years：5个
• mail：2个
• notifications：3个

同alpha阶段的计划，为了敏捷开发，我们不完全遵守TDD开发流程。几乎是测试用例和开发并行编写。

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

得益于Alpha阶段完善的测试，Beta阶段没有发生严重的Bug，用户提出的大多数反馈意见是对新功能的需求以及对原来功能的不了解造成的。

Beta阶段我们出现最多的Bug是因为开发服和生产服同步的时间结点不对导致有些新功能和原来的功能产生冲突，表现为markdown解析问题、部分组件的UI有问题等等。

我们在同步开发服和生产服之前应该进行更全面的测试，保证没有问题再同步。

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

我们主要利用GitHub的pull request对代码复审进行人员指派，并严格执行了代码规范。

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

yjk: 学习了如何进行CI/CD以及项目的运维管理等。

szy:我们学到了在设计/实现阶段，明确各成员角色、交流沟通的重要性。若历史重来，我们会制定详细的开发计划，加强协作，早发现问题并进行针对性优化。

jyz:熟悉了使用Vue2框架做前端开发。如果重来，UI设计应该会模仿一些现有的成功网站，在UI上反复做的修改比较多，但美观效果依旧一般。

yyh:熟悉了django后端开发以及DRF框架的运用。如果可以重来，希望能够设计出更加具有拓展性的后端架构。

ccy：我熟悉了jwt机制的实现方式与技术细节。如果可以重来，希望能够实现功能更齐全的的认证机制。

wxg：我熟悉了vue2框架下更工程化的api模式。如果能重来，希望能在设计时更加结合具体实现情况，给出更加明确可执行无二义的文档。

wxz：学习了使用Vue2框架进行前端开发。如果重来，应该会和其他前端统一使用一个框架，尽可能统一前端代码风格。

Part 6 测试/发布

6.1 团队是否有一个测试计划？

有测试计划，后端计划采用TDD测试驱动开发，并计划了以接口为单位的单元测试。

• 前端测试计划：由不同的同学在页面进行了多轮功能测试与场景测试，在每次提交和合并代码时也采用复审的方式。
• 后端测试计划：
  • 单元测试：对Alpha阶段的单元测试点进行回归测试，同时针对新增功能新增单元测试点测试。后端推送代码的时候均需在本地对所有测试点进行单元测试，只有测试通过后才可提交。

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

我们进行了验收测试。在开发结束后，我们分别按照Beta阶段开始时的功能规格说明书模拟用户进行各种业务行为操作，包括正确行为和各种错误行为。

在正式发布之前，我们还特别邀请了数十位真实的学生和辅导师进行内测，产生了大量的真实意见，更完善地进行了验收测试。

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

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

在测试网站在不同浏览器的兼容性时，使用了Sauce Labs。Sauce Labs是一个基于云的移动测试平台，可帮助企业进行自动化跨浏览器、移动测试和手动测试。该平台上所有的测试都在专用的、安全的、一次性的虚拟机中运行。该软件兼容任何编程语言的测试，并集成了CI系统，以实现自动化构建过程。

后端单元测试时，使用了python的APITest模块以及pycharm对单元测试的集成功能进行测试。单元测试用例都是手造数据测试，主要针对API的边界条件以及API的安全性等方面进行测试。

后端压力测试时，使用了开源负载测试工具Jmeter对部分调用次数频繁的接口进行测试，并涵盖了在beta阶段引入的部分新接口。

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

我们通过共享文档用户的反馈追踪软件的效能。此外我们也使用了JMeter开展压力测试，定量分析API的可用性和效能。

从软件实际运行结果来看，这些测试工作是有用的。它们可以帮助团队及时发现和解决软件性能问题，提高软件的质量和用户满意度。

我们的测试工作可以进一步改进，例如可以定期进行性能测试和压力测试，长期保证软件有效的稳定性。

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

前后端对接的过程中，有一个接口测试完之后又更改了参数名，但是前后端没有同步，导致接口调用出错。但是由于这个功能的使用场景很少，因此并没有对用户的使用造成影响就被修复了。

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

yjk：我们初期着重于进行敏捷开发，没有太注意到测试流程和框架，主要依赖于开发者自己的测试经验和能力。如果可以重来的话，我们会在初期同样调研测试的相关内容，形成完善的测试工作流，提升项目的质量。

szy:我们学到了测试/发布阶段需确保质量、团队协作的关键。若历史重来，我们会强化测试流程，集成持续集成/部署，提高问题解决效率和产品发布质量。

jyz:前端测试主要采用人工手动测试的方法。在alpha阶段内测中被志愿者提出了各种bug和建议。在beta阶段我们有所改善，团队内部首先进行更多更充分的测试。

yyh:如Alpha阶段，为了敏捷开发，我们不完全遵守TDD开发流程。大部分情况下测试用例和开发并行编写。如果重来一遍可能会着重编写测试用例，尽可能TDD开发，会使开发更加完善且鲁棒性更强。

ccy：在开发中我们没有充分调研jwt机制的实现细节，也没有预留充足的时间编写测试单元。如果重来一遍我可能会花费更多精力在架构的设计、以及技术栈的调研和学习上。

wxg：在测试时我们并没有给出详细的验收标准和指标，这导致许多测试者测试的重点仍留在alpha阶段的功能，分不清feature和bug，无法用便于开发者理解的方式来描述bug。如果能重来一遍，我会设计更加科学的测试文档。

wxz：对于不常用的功能的测试还需要加强，如果重来，还需要考虑定期进行回归测试。

Part 7 团队的角色，管理，合作

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

在确定角色分工时，我们首先收集和考虑大家的过往工作经验、兴趣和能力，然后根据往届优秀团队的分工确定我们的分工和比例（1PM，4前端，2后端）。幸运的是，团队成员的工作经验和本次项目的需求是吻合的，因此我们很自然地分为了1PM，4前端，2后端的组成，做到了人尽其才。

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

是的，我们的团队成员互帮互助。

尽管平时课业繁忙，我们仍能做到4h内一定回复和解决问题，遇到需要联动讨论的内容时，我们可以快速预约线上或线下会议，高效集中互帮互助解决。

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

当面临项目管理和合作问题时，我们采取以下策略，由前后端同学首先线上尝试问题解决，如果问题无法解决会召开线下的研讨。另外，我们会在每次ScrumMeeting时进行集中沟通，按照团队管理方案进行及时的解决和任务分配，发挥每位同学的长处。如果遇到非常棘手的问题，我们会进行线下集中讨论与敏捷开发。此外我们还开发了感谢信机制，对自己有帮助的同学发放感谢信，优化团队合作氛围，我们认为这是一个非常好的机制。

Part 8 总结

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

目前我们属于CMMI中的第三级，明确级。我们对项目的目标和要做的努力很清晰，项目目标可以实现，在项目实施上能够遵守既定规则和流程，对全流程进行监测和控制，同时，我们将实施的规则制度化，保证了我们迁移到其他项目开发上仍可成功。

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

我们目前处于创造阶段。我们拥有完善的开发、沟通和管理流程，团队成员知道自己的分工，具有自我驱动精神和能力。

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

yjk：在beta阶段，本团队的合作更加顺畅，在沟通方面已经不存在问题或困难了，因而可以更加专注于项目本身，效率进一步提高；另外，尽管有着考期等多重压力，但是团队成员彼此更加包容和理解，团队氛围极佳，大家都有充分的信心按时按质交付任务，也有信心一起面对困难和挑战。

szy：里程碑式的改进主要在于前端美工的改进与调整，主要对一些配色进行了调整以及布局进行了调整。其次是对更多功能做了改进和细化，例如忘记密码、标签等功能。

jyz: 根据alpha阶段收集的用户反馈，增加了更多有利于改善用户体验的细节，例如忘记密码功能、消息通知功能、前端使用的编辑器改善。并且针对alpha阶段用户所关心的美工问题，我们也做了较多的讨论和修改。

ccy：在安全性上，我们在用户登出时注销了验证码。在功能上，我们新增了通知模块，并且完善了管理端的功能。与Alpha阶段相比，团队对于合作的流程更加熟练，开发的效率有不小的提升。

yyh：在用户体验上进行了极大的改进，包括草稿、通知等功能的实现都方便了用户在issue提问和回答的流程中能够在平台上进行流畅的体验。同时，与Alpha阶段相比，合作流程和代码管理都更加熟练，开发效率有所提升。

wxg：在团队分工上有了较大的改进。相较于alpha阶段按照模块分工的粗粒度模式，beta阶段我们对开发任务进行了更细粒度的拆分，明确了每个任务所涉及的前后端人员。

wxz：由于已经有个Alpha阶段的框架，所以Beta阶段我们对需求的分析和每个人的分工都更加明确，减少了交流不充分引起的问题。

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

yjk：目前最需要进一步提升的是合规化与传承。一方面，本项目想要长久运行，需要迁回校内并同信息办办理一系列正规化手续；另一方面，本项目需要稳定的学生组织接手并长期运营维护。

szy：目前最需要改进的地方是一项目需要交付下一届的维护的同学，可能需要撰写一些帮助文档。

jyz: 欠缺使用说明和维护说明，交付下一届维护和使用时可能需要较多沟通。

ccy：代码的可读性与可重用性有待提高，如果需要交付给下一届同学，后端部分代码需要优化逻辑结构并添加注释。

yyh：代码规范性和可读性有待提高，如果为了对平台的可持续使用，则需要后端也需要提供并维护一个架构文档，供给下一任同学维护。

wxg：从可持性方面，缺乏一个完善的说明文档，不便于下一届同学上手。

wxz：代码的可读性需要提高，不同开发者的代码风格相差很大，需要更详细的注释和文档。

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

原则	具体事例
最优先要做的是尽早、持续地交付有价值的软件，让客户满意。	在项目开始阶段，我们就明确了应当先开发一个最小可用产品，将产品的最核心功能完善并交付甲方进行体验。在这个基础上，我们再进行周围功能的开发。
欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。	在项目开发中，我们收到了来自甲方的一些新需求，比如增加敏感词审核系统。尽管当时软件已经开发得比较完善，但是得益于项目架构的清晰性和鲁棒性，我们可以快速加入该机制。
频繁地交付可工作的软件，从数周到数月，交付周期越短越好。	在敏捷开发过程中，我们在10天左右即完成了最重要的核心功能并进行初步交付，后续持续进行热更新和热修复，持续部署和交付。
在团队内外，面对面交谈是最有效，也是最高效的沟通方式。	我们坚持以线下研讨室会议为我们的主要会议形式，增加大家的见面机会，降低团队的沟通成本。
简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。	我们尽可能将彼此的工作进行解耦，并且在工具链等的选用上尽可能地遵从多数成员的固有习惯，在可以不引入新机制的情况下就不引入。当然，对于一些必要的新机制如CI/CD，还是有必要增加的。

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

程序架构在设计时应有意识做到模块间高内聚低耦合。在开发过程中不要畏惧重构，当改变部分功能、发现重要bug、代码复审时发现更好的实现方法时都可能会进行代码重构，但代码质量也将得到提高。软件质量一般可以从功能性、可用性、可靠性、高效性、可维护性、可移植性来评价，在重构代码前后可以自审本次重构能够在哪方面提高软件质量，以判断重构的必要性。

后端通过采用现成的DRF框架减少代码的书写量，提高程序的架构。对于在多个函数中重复执行的部分，还可以用python的decorator属性进行统一的封装，这样在重构或修改时只需改动一处，减少因漏改而带来bug的风险。

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

eolink与postman

beta阶段中由于采用TDD开发，使用drf自带的测试框架即可进行接口正确性的测试，间接取代了postman的功能。

而在接口的定义方面，仍然使用了eolink工具进行信息共享，但在beta阶段中我们利用了接口状态栏目信息，区分【已发布】、【设计中】等状态的接口，提高了接口文档检索的效率。

notion与GitHub

notion是一个非常优秀的笔记和项目管理软件，有以下优点：

• All In One笔记
• 对GitHub等开发工具的良好支持
• 简洁、无广告、易于上手
• 独特的哲学：数据库&块

GitHub是优秀的开源代码托管软件，有以下优点：

• 大家对GitHub非常熟悉
• GitHub拥有社交平台的属性，可以帮助推广我们这一开源软件
• GitHub提供了Actions进行CI/CD的管理，便捷高效

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

我们计划增加更细粒度的log记录用户的使用情况和操作。

我们主要通过网站访问次数、issue提出/回答/复审等数据了解用户活跃数据，并实现了网站前端的显示。

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

开发过程中的项目文档已较为完善，消除了模糊性，有利于高效的开发。但从可持续性角度来说，我们的项目文档大多存在notion上，没有整理成一个便于新开发者从零开始上手的文档。这方面可能不便于新加入的成员上手。

接口管理的有序性有待改善。用Eolink管理api的一大问题是，接口更新后无法@相关人员告知变更；在对接口时发现了bug也只能在notion上反馈，关于接口的信息组织较为零碎。

改进可以考虑加入一个文档阅读指南，告诉新手应该按照什么顺序进行阅读。同时增加一些对文档之间关系的说明；权限管理模式需要更加明确；在设计接口时，应当指明该接口对于每一类输入应当有何响应，明确每个接口对于不同权限的jwt有何响应；从管理的角度，可以实现规定更完善的文档场景。

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

可以进一步提升大家的集体感、成就感和获得感，在团队中充分体现民主原则，允许不同的思想相互碰撞，但不逾越大家事先确定的规则和框架。

8.11 对于软件工程的理论，规律有什么心得体会或不同意见？

yjk：软件开发不只是写几行代码，用后即弃，它更是一个系统工程，一个被高强度复用的工具。因此，更科学地开发软件、管理软件开发的流程、更科学地评估开发质量至关重要。

szy:软件工程理论强调计划、分析、设计等阶段的重要性。实际应用时，需保持灵活，结合具体项目需求，进行迭代优化以确保高效和符合实际的解决方案。

jyz：对于敏捷开发有了直观体会。在敏捷开发中，通过尽早和不断交付有价值的软件，满足客户需要，是主要原则。敏捷过程中，开发团队几乎在整个项目期间朝夕在一起工作，面对面的交流是最有效率和效果的信息传达方式。并且每隔一定时间，团队做阶段总结并相应地调整行为。

yyh: 软件工程是一个不断发展和变化的领域，软件工程师需要不断学习和掌握最新的技术和工具。同时，软件工程师也需要保持开放的心态，接受不同的意见和建议，以便不断改进和提高自己的技能水平。同时，高质量代码胜过一切。在软件工程中，编写高质量、易于维护的代码比一切都重要。软件工程师还需要考虑代码的可扩展性、可复用性、性能、可靠性等因素。

ccy：在软件开发过程中，难免会遇到各种问题和挑战，软件工程师需要具备解决问题的能力，能够快速识别问题、分析问题并提出解决方案。此外，软件工程师需要注重细节，能够认真地完成每一个细节，并确保软件的质量和可靠性。

wxg：通过实践，对于敏捷开发有了更切身的体会。由于开发周期较短，前期设计时难免有不周全的地方，因此开发文档会频繁更新。如何规范管理开发文档，确保开发成员对文档的理解同步且一致，同时又尽可能避免频繁的更新打扰到并不相关开发者。