Beta阶段事后分析
Beta阶段事后分析
| 项目 | |
|---|---|
| 这个作业属于哪个课程 | https://bbs.csdn.net/forums/buaa-ase2023?typeId=2469180 |
| 这个作业的要求在哪里 | https://bbs.csdn.net/topics/615769171 |
| 我们在这个课程的目标是 | 学习并实践软件工程开发的方法论。在把握整体流程和内容要素的基础上实践细节，培养开发技术、开发思维、团队协作等能力。 |
| 这个作业在哪个具体方面帮助我们实现目标 | Beta阶段事后的Postmortem，总结和反思整个软件开发中的优点和不足。 |
一、设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
BUAAMapForum致于为BUAA的同学们提供详细的、可视化的、可交互的、丰富的BUAA地图浏览功能，并且为同学们提供交流讨论学校的内容和设施的平台。主要功能点描述如下：
- BUAAMapForum提供登录注册全流程，并且支持邮箱验证
- 在地图上进行标记，以钉子（Pin）的形式展示北航学院路校区的各种不同的点位，并且对点位加入详细信息描述（如Tag、位置描述、图片等）。当然，展示的内容可以进一步扩展。
- 用户和管理员可以以不同的权限对钉子进行操作
- 普通用户可以创建并维护私人钉子，可以修改钉子信息、上传图片，可以将自己的钉子申请公开；对于公共钉子，若发现存在问题或者是信息丢失，用户可以进行反馈
- 管理员可以创建并维护公共钉子，同时能够审核用户的私人钉子公开申请
- 论坛全流程。用户在论坛中以Tag和Pin为维度进行讨论，并且能够举报破坏社区和谐的内容；管理员可以实现论坛的维护和管理。除此之外，我们也配置了自动审核功能，可以对图片、文本的敏感信息进行过滤
- 个人主页功能。查看自己的钉子，帖子，回复以及消息，并且提供一定的管理和跳转服务
- 移动端适配。除管理功能外，其他的功能均提供移动端的服务
详细的功能描述、典型用户和典型场景在功能规格说明书中进行了描述，并且在本阶段已经能够满足所有场景需求。
我们达到目标了么？
-
从结果的角度出发
在功能规格说明书V2.0中，我们定义了Beta阶段需要完成的任务，我们在Beta阶段发布声明中，详细描述了各个预先商定好的功能的出口情况，并且记录了一些额外完成的任务。除此之外，我们对软件进行软件具有一定的用户使用量，并且得到了用户的支持和反馈，做出了一个能够被用户接收、使用的产品
-
从实践的角度出发
我们在9周左右的时间内，对敏捷开发流程进行了初步的实践。我们对软件设计流程、代码管理流程、文档管理流程、自动化部署流程、前后端协作流程、软件测试流程、敏捷会议流程、敏捷开发流程、软件发布流程等多个软件工程流程进行了实践，对敏捷开发流程有了初步的认知和体会
-
从团队的角度来看
我们通过长期的沟通交流和合作，形成了一个能够共同完成挑战，克服困难的团队。尽管我们仍旧有许多需要提升的地方，但是我们有足够的自信确定我们并不是一群“乌合之众”，而是一个”团队“
用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
我们的软件在Beta阶段实现了多方面的突破，用户日活为Alpha阶段的两倍左右，这超出了我们的预期。不过用户的注册量距离预期有小小的距离，这是多方面原因导致了，我们在Beta阶段发布声明中对这一点进行了反思。从整体上来说我们达到了最初的目标，尤其是移动端的适配，对我们的用户活跃量起到了非常大的帮助和提升。
根据不少用户的使用反馈（有熟人，也有陌生人），我们的产品的确能够帮助用户解决问题。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
-
作为一个团队，沟通是非常重要的。尽管我们进行了更加详细的设计，但是对API的讨论可能依旧存在一些不足；另外，在进行前端页面搭建的时候，设计能力强的同学可以给设计能力相对较弱的同学更多的指导，这样可以减少修改的次数
-
安全性设计不足。在Beta阶段当中，我们遇到了一些安全性问题，包括删除、修改内容没有鉴权，出现XSS富文本注入风险等
-
我们可以更好地准备一些宣发的资料，包括海报、文档网站等等。在Alpha阶段的基础上，我们在B站上发布了视频进行宣发，并且为移动端准备了二维码。不过在听取了其他团队的汇报后，我们发现有不少值得借鉴的宣发方法
-
移动端开发。
尽管我们完成了BUAAMapForum对移动端的适配，但是我们认为我们并没有执行一个非常规范的移动端开发流程。在本次开发中，我们将一个模块的PC端和移动端开发，交给了不同的团队成员，并且有较高的代码复用率。这导致了以下几个问题：
- 代码同步难度提升。A使用了B的代码，但是B的代码出问题了，或者是B添加了新的功能，A需要学习B的代码逻辑，这带来的一定的上手难度
- 样式难以适配。有一些在PC端写好的样式并不适合在移动端使用，故而需要重新进行调整
- 网站性能较差。由于没有考虑到移动设备的性能与PC设备的差距，移动端的网页在性能测试中表现不佳
总的来说，如果有充足的时间，我们要在开发移动端网页前进行更加充分的调研，将这一内容加入在我们的前期目标当中。
二、计划
是否有充足的时间来做计划？
在进行Beta阶段的开发前，我们一共召开了两次设计会议，对Beta阶段的工作内容进行计划。
第一次设计会议讨论了项目Beta阶段主要功能的总体设计，我们明确了需要开发哪些模块，模块有怎么样的功能流程，模块的运行方法，模块之间的协作情况等，并且对上Alpha阶段的遗留问题进行了总结讨论。
第二次设计会议则主要讨论了每一个功能模块和功能流程的设计细节，如应当使用怎样的API、使用怎样的前端组件实现、组件之间的引用情况，同时，我们也讨论并确定了前后端任务的具体分发。
前端任务分发；后端任务分发
总的来讲，我们在Beta阶段开始前进行了相较于Alpha阶段更加充分的设计和计划。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
一般的分歧，只要不对多个功能模块产生大范围的影响，通常是由团队成员在实现过程中因地制宜地选择解决方案。
当团队成员在关键问题上产生分歧的时候，大家可以自由的发表意见。如果在潜移默化中出现了分歧场景，那么PM会维护秩序，保证每一位有想法的同学都能“说上话”。当想说话的同学都说完之后，我们会针对每一个方案进行讨论，并且表决哪一个方案到底是最好的。
但需要注意的是，我们没有时间充分讨论并解决每一个问题。在关键的讨论中，当某个问题花费了过长的讨论时间时，或者这个问题本身并不值得“激烈的讨论”，那么PM就会及时打住，选择一个可行（未必是最优）的方案，继续之后的讨论。
决定性的意见非常重要，有助于我们在紧急情况下保证进度的正常推进。
原计划的工作是否最后都做完了? 如果有没做完的，为什么？
我们Beta阶段计划的任务都完成了。详情可见我们的Beta阶段发布声明。
需要注意的是，我们在开发过程中，发现某些计划好的任务并不一定是最理想的，因此我们也对各项任务进行了灵活的调整。另外，我们发现当任务拆分的比较细的时候，一些“关键节点”对于开发整体进度的影响变小了。
有没有发现你做了一些事后看来没必要或没多大价值的事？
在Beta阶段中，我们优先实现最重要的部分，并在此基础上进行补充。因此，我们做的绝大部份工作都是有意义的。也许某些功能使用的用户不多（例如消息系统），但是它们对于软件的完整性来说是不可或缺的。用户当然软件工程的重要目的，但是对于我们来说，实践过程也是有意义的。
另外，我们也困惑与前端单元测试的意义。对前端进行单元测试是否真的有必要？我们最初是尝试对前端进行单元测试的，但工作量实在是太大了，并且测试的效果和场景测试相差甚远。经过和老师的讨论，我们认为前端的单元测试意义不大。
是否每一项任务都有清楚定义和衡量的交付件？
经过Alpha阶段，我们对于产品的验收有了更加详细的标准。一个合格的产品需要进行功能测试，单元测试，API测试、压力测试等。同时，对于整个软件，还需要进行整体的场景测试，确保用户在使用过程中不会产生疑惑，体验良好。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
核心功能的开发按照预期的进度顺利进行，没有产生拖延的现象。不过仍旧出现了一些问题：
- 我们的产品在样式的美观程度上出现了一些问题，并且团队成员花费了比较多的时间进行调整。这主要是前端设计经验不足导致的，没有什么特别好的解决办法，只能由经验更丰富的同学进行改进
- PC、移动端代码不同步的问题。这个问题在前面已经提到过了，主要的原因是我们对同时开发PC端和移动端的流程不熟悉导致的
这两个问题是比较突出的问题，值得我们在事后进行反思。
在计划中有没有留下缓冲区，缓冲区有作用么？
有。在敏捷开发的第二周，大家要参加计网实验考试，因此我们提前开始了敏捷流程，并且将一些困难的、但不处于关键路径上任务的截止时间延后1～2天。在测试、发布一周，我们则集中精力调整前端样式、修复系统Bug。
将来的计划会做什么修改？
如果还有一次迭代的过程，我们会强化我们的设计流程，尤其是要增强对移动端功能的设计。另外，我们也会采用更加合理的分工，将同一个模块的PC端和移动端交付给同一位开发人员进行开发，避免本阶段遇到的问题再次出现。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了什么：
- 计划一定要提前制定、详细制定、明确到人，不能模棱两可，否则大家容易产生推脱心理或是侥幸心理。试想一下，当你开发完一个模块，兴冲冲地去找另外一位开发人员对接时，他却说“有这回事吗？”
- 计划的严格执行和制定良好的计划同样重要。团队成员要明确哪些计划处于团队项目的关键路径之上，并且要强化责任感
- 执行计划的过程中，要在坚持核心任务的基础上进行灵活的调整。不论是对于学生组成的团队来说，还是企业的团队来说，灵活性都是非常重要的。哪些是火烧眉毛的任务？哪些是不要紧的任务？团队需要有一个清晰的研判
我们会做的改进：主要的改进描述在在“将来的计划会做什么修改？”这一小节。
三、资源
我们有足够的资源来完成各项任务么？
经过Alpha阶段的开发和总结，前端和后端同学的技术都有所提升。
前端：在经过一段时间的开发后，前端成员对于Vue框架、Element-Plus、各种API的使用更加熟练，能够在更短的时间内完成更多的任务。
后端：后端环境逐渐稳定，需要完成的任务也变得固定，能够更快地响应前端的对接需求。
虽然团队的成员没有变化，但是我们对于技术、流程的掌握更加深刻，因此拥有了更多的“资源”来完成任务。当然，金钱、时间等更可衡量的资源也是很重要的，从结果来看，我们的资源还算充足。
各项任务所需的时间和其他资源是如何估计的，精度如何？
在开始冲刺之前，我们对时间的估计有限的开发经验（相信在流程完善的企业当中，基于市场统计和分析和丰富的开发经验，对于时间的评估会更加准确）；除此之外，我们也评估了一些其他资源可能产生的开销，包括金钱（在网络上查看价格）、场地（校内场地）等等。
对于任务耗时的估计，颗粒度在小时级。不过在开发的过程中，我们对任务也有灵活的划分。
测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
按照指定的测试方案，我们顺利的完成了Beta阶段的测试，没有出现“资源短缺”的情况。
不过事实上，美工的难度确实比想象的更大，我们花费了不少时间用于调整网页的样式。设计、文案的难度在可控范围内。
团队成员分配到的工作是否都是合适的？
吸取了Alpha阶段的经验教训，Beta阶段采用4前端+2后端的配置。每个人分配的任务量也较合理。
有什么经验教训？如果历史重来一遍，我们会做什么改进？
PM尝试做前端单元测试，但是jest实在太离谱了，最终放弃了。如果历史能够重来，PM应该尽早去帮助前端调整网页样式。
另外，关于同时开发移动端和PC端任务的可能的更好的调整，在前文也提到过了。
四、变更管理
每个相关的员工都及时知道了变更的消息？
Scrum Meeting和现代社交软件确保我们能够进行及时的沟通；集中线下协作开确保了沟通的质量。
在Beta阶段开发过程中，我们的变更次数不多，并且我们线下碰面的次数非常频繁，团队成员能够及时获得变更消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们的任务分配当中，每一项任务都有设置了前置任务。我们判断任务是否有推迟的可能性时，是通过观察该任务是否处于关键路径之上的。这是在设计会议上分析、讨论的结果。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，详见我们的功能规格说明书或者是Beta阶段发布声明。
对于可能的变更是否能制定应急计划？
总体来讲，在Beta阶段我们并没有遇到需要制定“应急计划”的变更。大部分的变更都是细节上的变更，没有撼动项目的整体逻辑。
员工是否能够有效地处理意料之外的工作请求？
由于我们进行了多次线下集中敏捷，大家都能通过冲刺完成额外的工作请求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在进行原型设计、需求分析和计划制定的时候，一定要确保团队成员对于功能、任务的理解到位且没有歧义，这样就不会因为开发出了“不符合预期”的产品而导致发生变更。实际上，埃杰团队成员的沟通还是相当到位的，成员遇到问题的时候都比较积极主动，因此没有遇到大的变更。
在Beta阶段中，涉及到更多流程化的设计，我们通过两次会议充分地商讨了设计的细节，希望能够尽可能减少重大变更的发生。
五、设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
Beta阶段的工作在Alpha阶段制定开发计划时已基本确定。
在Beta阶段开始前，我们举办了两次线下设计会议，分别讨论了整体设计和细节设计。我们针对每一个功能点进行了讨论，包括其前端界面设计、功能设计、后端数据模型设计、API设计等，并记录下来，最后汇总形成功能规格说明书V2.0。
当然，设计是会发生变更的。如果发生了设计上的变更，我们会在线下Coding的时候或者是Scrum Meeting上通告全体成员，保证大家都知晓变更的内容。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
存在。
对于影响很小的模糊功能点（如某一个字段在数据库中的类型、API要多传或者少传什么数据），前端或者后端内部可以私下讨论并给出解决方案，并通告其他成员。
对于影响较大的模糊功能点（如涉及流程，或者是一个大的功能模块），我们会在Scrum Meeting上或者是线下Coding时集中讨论。PM会给出处理的建议，并在无法达成一致的时候拍板一个解决方案。
在本阶段中，我们还参考了某一些知名网站在实践中采用的网页设计方案（如知乎、百度贴吧等），以达成一个较好的解决方案。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们使用Balsamiq Wireframes实现了产品的原型设计；通过绘制流程图实现了流程的设计；我们使用ApiFox设计和管理数据模型和API；使用Github进行代码管理和CICD；使用Notion进行文档管理；使用iDea的插件TestMe测试，选用JUnit5 + Mockito进行后端单元测试。
我们尝试了Jest对前端进行单元测试，但意义不大且环境频繁出错。
遇到了什么功能的什么Bug？
- 在加入富文本编辑器的时候出现了字符串存储问题导致的富文本编辑器无法使用的bug
- 若干用户权限导致的钉子，帖子，消息等不能正常删除、修改的bug
- 若干路由跳转相关的bug
- 某些关键操作缺少权鉴（偷懒了）
- 华为手机无法响应长按事件的bug（未修复）
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们通过Github PR实现代码复审，并且遵循了课程组给出的Github规范（包括分支维护规范）。
当然，我们的工作也有需要改进的地方，包括：
- 可以尝试使用JSLint实现更严格、更自动化的代码风格规范
- 在进行代码复审的时候，可以关联其他的成员，明确复审人
- 团队成员还要多写注释和文档，便于其他的成员快速上手
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计前需要详细讨论，尤其是要注重流程的讨论，因为流程通常要涉及多个功能点，并且链条比较长，容易产生模棱两可的地方
- 开发的时候需要多沟通，并且要明确什么问题是可以自己解决的，什么问题是需要一起讨论的
- 仍旧是那个问题，PC端和移动端的开发，怎样做才是更加规范和高效的，这是我们需要加强调研的地方
六、测试/发布
团队是否有一个测试计划？为什么没有？
Beta阶段的测试计划与Alpha阶段大致相同，分为单元测试（新增）、功能测试、用户体验测试、API测试、安全性测试、网页性能和压力测试等，因为测试的流程和工具已经确定，所以Beta阶段的测试的效率更高。
是否进行了正式的验收测试？
我们对功能点进行了单元测试、功能测试、用户体验测试、API测试、安全性测试、网页性能和压力测试。
当然，我们的测试仍旧存在着一些不足，并且被助教发现了（如富文本编辑器被XSS攻击等）。
团队是否有测试工具来帮助测试？
我们使用了非常多的工具协助测试，包括ApiFox、Vue单元测试、JMeter等工具。测试的方法见我们的Beta阶段测试。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们主要通过JMeter进行API的压力测试，使用谷歌的插件LightHouse进行网页性能测试。
使用JMeter进行测试后，我们使用GoAccess评估了网站的访问量，得到的结论是我们服务器能够承受的压力完全可以满足网站的流量。
我们使用LightHouse分析了PC端网页性能后，将Element-Plus的引入方式由自动引入改为按需引入，提升了网页的性能，并且使用了更高级、简洁的JS代码。在分析了移动端的性能后，我们也明确了一些努力的方向，包括图片使用Webg格式、打包chunk等、使用.gz文件提供服务等。
在发布的过程中发现了哪些意外问题？
- Redis服务器的问题，在上文已经提到过了；除此之外，我们还发现向教育网邮箱发送验证码邮件的时候容易丢失
- vue3组件库突然更新导致项目出现了不可描述的bug
- 安全性问题，如XSS攻击等
- 华为手机无法响应长按事件
- 自动部署因为网络问题失败了，导致评审前的最后一次release版本没有部署成功
我们学到了什么? 如果重来一遍, 我们会做什么改进?
- 提前调研移动端开发的相关知识，采取更加符合规范的开发流程
- 了解更多安全性测试的相关内容，进行全面的安全性测试（不过事实上，这有点困难，因为我们不清楚有什么渠道可以系统地了解相关的问题）
- 采用更多元的方式进行发布。当然，发布周也和考试撞上了，因此大家的时间也有一些紧张。
七、团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
我们根据上学期数据库大家在数据库小组作业团队中的分工和大家之前的开发经验进行角色的确认；PM是自荐产生的。后端的两位同学都贡献了非常稳定、高效的表现，PM也顺利地组织了各类任务、文档，前端的完成质量也可圈可点。
总的来说，大家的努力都确保了Beta阶段任务的完成。
团队成员之间有互相帮助么？
我们在线下、线上进行了非常多的讨论，并且团队成员之间互相提供了技术、方法、思路上的支持。技术上的支持尤其重要，可以大大减少团队成员在开发过程中“钻牛角尖”的情况。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们认为项目管理主要指的是进度管理问题。如果出现了“任务细分”的问题，我们通过线下敏捷开发实现快速跟进；如果出现了额外需要考虑的任务，那么我们的组员会共同商议解决方案。
另外，在Beta阶段中，我们对开发流程更加熟悉，并且形成了一套规范。按照流程和规范进行开发，效率会得到很大的提高。
整体来讲，我们没有遇到重大的项目管理和合作问题，埃杰团队的合作过程是比较愉快的。
八、总结
团队目前的状态属于 CMM/CMMI 中的哪个档次？
CMM等级：我们团队进入了已定义级，我们拥有标准化、文档化的技术工作和管理工作，并且有健全的评审制度和灵活的流程控制。
CMMI明确级：我们的开发逐渐进入流程化的管理，并且启发了Beta阶段的全涉及流程。当然，我们在Alpha阶段中还存在一些项目实施上的波动，未能进入下一等级。我们将在下一阶段尽可能实现更加量化的管理流程。
团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队目前处于“创造”阶段，在Postmortem会议上，我们回忆了Alpha阶段我们的开发由不成熟到成熟的过程。我们对于任务管理、任务验收等都建立了约定，这使得我们的团队处于“规范”阶段。在Alpha阶段后期，团队成员甚至完成了一些额外、有创新性的工作，这表明我们的团队已经处于“创造”阶段了。
你觉得目前最需要改进的一个方面是什么？
任务的分配。前面提到过，我们进行了一次人员结构的调整，在调整之后我们并没有做针对性强的任务重分配，只是进行了一些简单的调整。事实上，在下一阶段我们可以更细致地分配任务，保证每一位成员的贡献度。
对照敏捷开发的原则，小组做得最好的是哪几个原则？请列出具体的事例。
| 原则 | 完成质量 |
|---|---|
| 尽早和持续地交付有价值的软件来满足客户 | ⭐⭐⭐⭐ |
| 欢迎对需求提出变更 | ⭐⭐⭐⭐ |
| 不断交付可用的软件 | ⭐⭐⭐ |
| 项目过程中，业务人员与开发人员必须在一起 | ⭐⭐⭐⭐⭐ |
| 要善于激励项目人员 | ⭐⭐⭐⭐ |
| 最有效的沟通方法是面对面的交谈 | ⭐⭐⭐⭐⭐ |
| 可用的软件是衡量进度的主要指标 | ⭐⭐⭐⭐ |
| 提倡可持续的开发 | ⭐⭐⭐ |
| 对技术的精益求精以及对设计的不断完善将提升敏捷性 | ⭐⭐⭐⭐ |
| 要做到简洁，尽可能减少不必要的工作 | ⭐⭐⭐⭐ |
| 最佳的架构，需求和设计出自于自组织的团队 | ⭐⭐⭐⭐ |
| 团队要定期反省如何能够做到更有效，并相应调整团队的行为 | ⭐⭐⭐⭐ |