「MOSS - 20」MOSS队：Alpha阶段总结和反思

「MOSS - 20」MOSS队：Alpha阶段总结和反思

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

Author: MOSS队

Date: 2023.05.03

Part 1 设想和目标

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

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

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

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

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

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

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

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

是否定义得很清楚

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

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

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

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

我们的目标基本达到。在规格功能说明书中提出的主要功能都已在alpha阶段实现。考虑到实际开发情况，issue的标签功能挪到beta阶段实现。这部分功能较为独立和边缘，不影响用户的使用体验。alpha阶段计划的管理端功能已全部实现，但考虑到部分权限较为敏感，用户误操作带来的后果较为严重，因此管理端功能alpha阶段并没有开放给用户使用。

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

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

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

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

yjk: 主要的设计和架构比较清晰，但是对于用户的使用需求的把握仍有进步空间。如果可以重来的话，我们会进行更完善的用户调研，明确工作。

yyh: 由于之前没有使用过django以及django rest framework做后端开发，因此花费了些时间了解学习，写出来的代码的质量比较差。如果能够重来希望能够学得更好点，写出质量高的代码。

wxg：

教训1：

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

改进方案：Eolink开会员，使用通知功能；或者notion上也开一个表格，维护每个接口的update情况

教训2：

issue的状态转移条件一开始设得不够严密，导致实现过程中反复更改。一开始没仔细考虑状态转移的权限判断是放到前端还是后端（还是both），最后想清楚后统一采用复杂的权限由后端来计算判断，通过接口向前端返回permit位；而简单的权限（例如根据role即可判断的）就由前端来判断，但后端也会鉴权。

szy:有一个经验教训就是git一定要熟练使用，用好git能给自己的项目管理带来极大的方便，而git用不好会导致极大的麻烦，所以一定一定要重视git！

jyz:前端样式实现地十分不鲁棒，并不适配移动端，beta阶段还需要做些改动。但如果从一开始就把解决此问题纳入考虑作为目标，会省去一些删改工作。

ccy：由于在敲定接口前对jwt机制没有充分了解，并没有引入刷新机制。而alpha阶段后期新加入jwt刷新机制时发现需要修改几乎所有的接口定义，导致这一特性只能在beta阶段进行添加。

wxz：

教训：在前后端api对接是一个持续的过程，前后端分别会根据具体实现中遇到的问题进行修改和妥协，这就需要在每次接口变动的时候同步所有开发人员。我们目前的api管理工具并不能做到记录接口变化、自动通知相关开发人员等功能，还需要依靠开发人员之间交流来完成。

改进方案：寻找功能更强大的api管理工具，或者制定一个api更新与同步的流程。

Part 2 计划

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

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

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

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

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

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

在规格功能说明书中提出的主要功能都已在alpha阶段实现。考虑到实际开发情况，issue的标签功能挪到beta阶段实现。这部分功能较为独立和边缘，不影响用户的使用体验。alpha阶段计划的管理端功能已全部实现，但考虑到部分权限较为敏感，用户误操作带来的后果较为严重，因此管理端功能alpha阶段并没有开放给用户使用。

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

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

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

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

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

前端：整个过程都基本上按照计划进行，一个没有计划的事是前端事先没有分配一个前端对需求比较了解的同学与后端进行接口的商讨，意识到这个问题后我们迅速给专门的同学分配该任务，项目得已顺利的进行。没有估计到的原因是缺乏对稍大型的项目没有前后端联动开发的经验。

后端敏感词功能：在项目交付的时候，书院验收需要进行敏感词审核。在意识形态上做检查。但是由于前期没有考虑到这个功能，后期交付时紧急开发，功能和代码质量上都需要再完善和改进。

后端数据库：在将数据从开发数据库迁移到实际使用的数据库时，产生了清空数据库的误操作(虽然最后通过MySQL的binlog恢复了)。由于前期没有考虑到使用DataGrip远程操作服务器MySQL数据库，所以没有估计到使用图形化界面操纵数据库时，危险操作带来的风险。

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

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

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

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

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

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

szy：学到了如何在一个稍大型的项目学会团队合作与团队分工，如果重来一遍我希望在项目启动之前做更详细的规划和分工，当然由于软工课程的实践需求，可能有些不切实际。

yyh：在开发前期，我们计划进行TDD开发。但是由于django较不熟悉，因此为了敏捷开发，我们不完全遵守TDD开发流程。本人是测试用例和开发并行编写。如果重来一遍可能会着重编写测试用例，尽可能TDD开发，会使开发更加迅速且功能完善。

jyz：在团段合作中体会到博采众长的好处，每名组员各有所了解的内容，发现和解决问题往往更快。重来一遍也许在早期就更详细制定分工，或者在分工模糊时和队友多交流，避免出现互相等待的情况。

ccy：学到了细粒度分工的重要性，初版任务分工粒度过大、不明确，没有很好地发挥github的issue功能，有时一个issue对应十几个commit。如果重来一遍，我会在花费更多精力在任务分工上。

wxg：我对如何分工有了更深刻的理解。前端一开始的分工是按照页面模块来分的，这就导致不同模块间风格不统一（甚至组件库都不统一），不同成员之间有一定overlap的重复工作。beta阶段想试试按照任务阶段来划分，初步设想可以划分为新组件库探索、前端静态页面和UI美工、接口对接和js逻辑、测试四个大的分支。

wxz：深刻意识到细粒度分工的重要性。将任务拆解成不同层次的多个子模块，一方面能够更加合理地分配任务，平衡开发人员的任务量；另一方面能够在最初就明确我们要做什么、怎么做，避免了“突然冒出来的新需求”这种情况。

Part 3 资源

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

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

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

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

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

后端压力测试：软件有现成的jmeter组件，硬件无需太多要求，测试可以较完善地完成。

后端单元测试：使用DRF的APITestCase框架进行测试，pycharm也有对此单元测试的集成，较为方便。

美工资源：在美工方面我们确实没有分配足够的人力去处理，后期beta阶段需要优化分工结构。

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

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

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

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

yjk：如果可以重来的话，我们会更科学地评估任务的分工、所需人数以及耗时，来更完善的管理项目。

szy:资源分工时，对于事件的的估计不够精准，重来的话做好细致的规划和方案是必要的。

yyh：资源分工需要对项目工作量有着更加合理的估计。因此，熟悉和了解使用的技术栈尤其关键。

jyz：我们对于各项任务所需时间并不完全准确，应该也有经验不足的原因，相信之后会做得更好。

ccy：第一次实践软件工程开发的确很难估计准确实际的任务时间，如果历史重来一遍，可能会更注重对各任务花费时间的记录，为以后资源分工作参考。

wxg：未严格记录每项任务的耗时，未正确估计任务的耗时。

wxz：没有统一使用软件来管理预期工作量和实际工作量，在项目开始阶段由于技术上不熟悉，难以正确估计工作量。

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 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

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

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

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

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

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

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 文档？

项目后端有进行单元测试。测试分布在django的各个apps中。

测试用例数目当前总共有53个。其分布如下：

• issues：16个
• users：15个
• admins： 6个
• subjects：4个
• tags：4个
• chapters：4个
• years：4个

代码覆盖率如图所示。

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

目前Bug最多的地方在于网络安全方面。

具体来说，在我们的产品发布后，发现的bug有：

• 前端代码中的v-html标签会被xss攻击
• markdown编辑器中使用html标签可以实现js注入
• 前后端api接口使用明文传递密码

在设计/开发的时候，由于团队缺少网络安全相关知识和经验，对这方面的准备不足。

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

我们主要利用GitHub的pull request对代码复审进行人员指派。

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

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

szy:学到了前后端如何实现分离设计，相互联动。如果可以重来，希望熟悉美工从而进行设计。

yyh：在实现工程中，学习并较为熟悉了django后端开发以及DRF框架的运用。如果可以重来，希望能够设计出更加优美的后端架构。

jyz：熟悉了使用Vue2框架做前端开发。如果重来，UI设计应该会模仿一些现有的成功网站，实在缺乏审美能力。

ccy：熟悉了DRF框架的运用。如果能够重来，会花更多时间提前学习DRF框架。

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

wxz：熟悉了vue2框架下的前端开发。如果重来，不会再混用两个vue组件库，同时更注重代码的工程化和鲁棒性，更多考虑响应式布局和安全问题。

Part 6 测试/发布

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

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

前端的测试主要采用代码复审以及实际场景测试，此外我们还进行了小范围内测，三板斧确保bug得到复现与解决。

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

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

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

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

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

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

在针对接口进行压力测试时，使用了Jmeter。Jmeter是使用Java语言编写的开源负载测试工具，可以模拟多种负载类型，例如并发用户数、请求率，进而测试Web应用程序的性能和可靠性，找出系统瓶颈和性能瓶颈，并了解应用程序在高负载情况下的行为。

单元测试用例暂时都是手造数据测试，主要针对API的边界条件等进行测试。

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

我们在nginx+uwsgi部署到服务器前后，均采用JMeter针对接口进行了压力测试，测试时利用了后端全部资源。

我们针对数据库查询效率、并发用户数、服务器端内存开销等指标设计了压力测试，并根据测试结果定位性能瓶颈，并作出一定的优化措施，详见alpha阶段测试报告。

对于alpha阶段无法短期解决的性能问题，我们将其加入beta阶段的计划中进行实施。

我们召集了数十名志愿者对目前发布的alpha进行测试，在用户正常使用的情形下，并未出现由于压力产生的问题。说明alpha阶段的压力测试是有作用的。

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

1. 小部分路由跳转出现问题，会跳转到空白页或默认的404界面。
2. 部分调试信息没有及时删除，包括：
   • 登录界面的默认id
   • 控制台输出的log信息
   • 测试时前端写死的部分信息
3. 修改密码未加限制，导致存在空密码
4. markdown编辑器中使用html标签可以实现js注入
5. 部分前端页面出现乱码

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

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

yyh：（如上几条所写）在开发前期，我们计划进行TDD开发。但是由于django较不熟悉，因此为了敏捷开发，我们不完全遵守TDD开发流程。本人是测试用例和开发并行编写。如果重来一遍可能会着重编写测试用例，尽可能TDD开发，会使开发更加迅速且功能完善。

jyz：前端测试主要采用人工手动测试的方法。在alpha阶段内测中被志愿者提出了各种bug和建议。如果重来，我们应该会自己进行更多更充分的测试。

ccy：同yyh，我开发时也没有完全遵守TDD开发。如果重来一次，我会先进行测试用例的编写。

wxg：在内测阶段未给出bug反馈的模板，导致一些神奇的bug无法复现。如果重来，会给测试者提供更详细的bug反馈模板，包括复现条件、测试环境等。

wxz：团队内部测试阶段是分功能进行测试，可能会缺乏一些整体测试视角（如功能A和功能B都没有问题，但是先进行功能A再进行功能B就出现问题）。开发人员对网络安全的hack技巧不够了解。

szy:学到了测试和对接的流程与技巧，重新来一遍的话会更加注重安全方面测试和学习。

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：需要进行更完善的项目管理

szy:提前进行更加详细的计划

yyh：用户体验方面可能较为欠缺，需要相应的设计

jyz：改善美工设计

ccy：提高meeting效率。对于两三个人之间的问题，在确定负责的同学后，可以考虑放在会议之后私下具体处理？

wxg：接口管理方式；

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

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

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

在代码管理中应当更好地利用git：保持每一次commit尽可能小，提交清晰、符合格式的commit，以便在发现问题时进行准确的版本回退。每一次pr合并前均应有改动代码相关的其它人员review并approve，github提供的推荐reviewer比较准确，reviewer应该真正过目所有改动文件，不应只走过场直接点击approve。当锁定代码某模块某次提交出现bug时，修改者和复审者都应对修复bug负责。

设计代码规范时，可以具体细化到代码格式、命名规范、注释规范、异常处理规范等分支，保证规范是清晰明确定义的，从而提高代码规范的质量。

8.6 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

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

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

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

eolink与postman

alpha阶段开发时没有充分发挥eolink的批量测试功能(它的杀手功能)，目前只是它只是充当一个类似“共享文档”的作用，后端发送请求采用的还是使用的postman工具，接口设计和测试较为割裂。

postman优势是界面操作比较方便，支持发送带文件的请求，并且保存接口操作起来也比较eolink方便。eolink优势是它支持变更提醒，但是要开会员(与写作人数有关，但人均9元/月)，还支持**、**Mock、API 自动化等高级功能。

后期可以考虑将接口文档和请求发送集成到一个软件中，这样效率会有所提高，但具体使用哪个软件有待调研和讨论。

notion与GitHub

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

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

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

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

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

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

我们主要通过网站访问次数、issue提出/回答/复审等数据了解用户活跃数据。

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

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

改进方案：Eolink开会员，使用通知功能；或者notion上也开一个表格，维护每个接口的update情况

权限管理模式需要更加明确；在设计接口时，应当指明该接口对于每一类输入应当有何响应，明确每个接口对于不同权限的jwt有何响应；

从管理的角度，可以实现规定更完善的文档场景。

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

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

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

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

szy:软件开发是一个迭代的过程。软件开发是一个复杂的过程，需要不断地进行迭代和改进，确保软件的质量和功能的完整性。开发人员需要关注软件的需求分析、设计、开发、测试和维护等不同阶段，并在每个阶段进行有效的控制和管理。在alpha阶段我切身体会到了整个流程。

yyh：在敏捷开发中，设计通常需要在编码之前进行。尽早开始设计可以帮助确保软件系统的架构和功能的合理性，并减少后期更改的成本。同时，代码质量的优先级可能更高。通过使用适当的编程规范、测试驱动开发和持续集成工具，可以帮助确保代码的质量和可靠性。

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

ccy：软件工程的理论强调在每个阶段中应该采取适当方法和工具，并且需要进行适当的文档化和记录，以便于团队协作和项目管理。我在开发过程中体会到了先写文档再写代码的好处，可以减少很多因成员间信息不统一带来的bug。

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