因为把dll看成ddl而急死——Alpha阶段问题总结

因为把dll看成ddl而急死 2025-11-10 21:41:09

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——事后诸葛亮
团队名称	因为把dll看成ddl而急死
这个作业的目标	Alpha阶段问题总结
其他参考文献	现代软件工程讲义 11 项目管理 - 事后诸葛亮会议

一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
2. 是否有充足的时间来做计划?
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
二、计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
3. 是否每一项任务都有清楚定义和衡量的交付件?
4. 是否项目的整个过程都按照计划进行?
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
三、资源
1. 我们有足够的资源来完成各项任务么?
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
四、变更管理
1. 每个相关的员工都及时知道了变更的消息？
2. 我们怎么决定“推迟”和“必须实现”的功能？
3. 项目的出口条件（什么叫“做好了”）是否清晰？
4. 对可能的变更有没有应急计划？
5. 员工能否有效处理意料之外的工作请求？
6. 我们学到了什么？如果重来一遍会怎么改进？
五、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
六、测试/发布
1. 团队是否有一个测试计划？为什么没有？
2. 是否进行了正式的验收测试？
3. 团队是否有测试工具来帮助测试？
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
5. 在发布的过程中发现了哪些意外问题？
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
七、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
2.你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
4.你觉得目前最需要改进的一个方面是什么?

一、设想和目标

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

在快速发展的在线教育和知识付费市场中，用户对“深度、垂直内容”的“系统化学习”和“深度社交”的需求日益增长，然而，现有主流平台内容虽然丰富，但普遍存在“娱乐化倾向”，内容碎片化、浅层化，无法为用户提供结构化、系统化的学习体验。除此之外，这些平台往往缺乏围绕深度知识构建的高质量创作者生态和深度社交圈子，用户难以找到同好并进行有价值的交流和互动。因此，我们推出“知音”App，旨在打造一个专注于IT领域的知识分享与社交平台，通过“视频+文档”的混合内容形态，为用户提供沉浸式、结构化的学习体验，并构建一个高质量的创作者生态和深度社交圈子，以此解决解决“学得不深、聊得不专、体验不好”这三个核心痛点。
在设想阶段，我们对要解决问题有了清楚的定义，对典型用户和典型场景也作出了清晰的描述。我们的主要用户为内容消费者与内容创作者，内容消费者以在校大学生、IT从业者居多，他们希望能高效获取高质量、结构化的知识，与同行交流、解决问题并跟踪前沿技术动态；而内容创作者以技术专家、资深开发者、培训讲师为主，他们则希望能便捷地创作深度内容，以此获得精准的流量分发和粉丝增长，从而实现知识变现。

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

在此次Alpha冲刺阶段，我们沿用此前的计划，并根据实际情况进行了相应调整，从而得出了实际执行的计划，因此可以说有相当充足的时间来做计划。

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

在计划阶段，团队成员对于计划本身持赞同态度，仅在部分方面持有不同意见。在该阶段，团队成员主动将意见讲出，并积极提出个人见解与解决方案，最终在根据具体情况进行相应的调整以保障计划合理性。

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

用户量相较于我们的预想偏多，用户对我们的“知音”APP感到新奇，并积极尝试体验APP的主要功能，表现出了较高的接受程度，同时也予与我们反馈和意见，极大地鼓舞了我们的士气，使我们感到朝着目标迈进了一大步。

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

在此次过程中，由于部分工作的实际工作量大于预期，因此在执行计划时遇到了困难，没能及时调整、平衡每个人的工作量，最终导致效率的下降和部分模块存在问题。
如果能在来一次，我们将会加强团队内部的沟通，及时反馈问题，平衡工作量以提高效率，并尽早完成任务以留出充足时间来进行测试和调整。

二、计划

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

主要功能几乎都完成了，部分优先级不高的功能还需要测试

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

前后端各自开发，没有进行有效沟通，导致返工此时较多

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

前期有些任务没有交代清楚，后面猜坑后才重视明确任务的重要性，清楚定义了需要交付什么

4. 是否项目的整个过程都按照计划进行?

是

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

有，比如每个任务都有预留一段时间来沟通和对接，避免因为时间太急，质量低

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

完善其他小功能，对并发进行优化

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

学会沟通和对接，会提前进行有效沟通

三、资源

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

在Alpha阶段，我们基本拥有完成核心任务所需的开发资源，包括人员、开发环境和基础工具。
后端使用Go语言，前端使用Flutter，技术栈统一且团队成员具备相应能力。
但在测试资源方面稍显不足，特别是在性能测试和兼容性测试方面缺乏专业的测试工具和设备。

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

我们主要采用基于任务拆解和经验的工作量估算法。整体来看，对于逻辑明确、功能独立的任务，时间预估相对准确；
但对于一些涉及复杂业务逻辑和新技术的模块（例如视频与文档的进度同步），其复杂度和依赖关系在初期难以被完全预见，导致实际耗时超过了最初的预估。

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

测试资源是相对紧张的环节，测试工作主要集中在开发周期后期，导致测试时间不够宽裕。
对于美工设计和文案等非编程资源，我们初期更关注功能实现，确实低估了其在确保用户体验一致性和界面美观度上的所需投入和迭代次数。

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

在部分任务中确实存在这种情况。
例如，一些复杂的性能调优或底层框架问题，如果由对该领域更有钻研的同学负责，可能会更快地定位并解决。

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

经验教训：
1.资源评估不应只关注开发，测试、设计和文档等支撑环节的资源同样需要被重视和提前规划。
2.对于技术不确定性高的任务，应预留更多的探索和缓冲时间。
3.任务分配可以更精细地考虑成员的技能优势，以提升整体效率。
改进措施：
如果重来一遍，我们会：
1.在项目计划阶段，就同步制定测试资源计划，并尽早搭建测试环境。
2.对核心及高风险任务进行技术预研，以便做出更准确的工作量评估。
3.在任务认领时，更明确地讨论和匹配成员的技术特长与任务要求。

四、变更管理

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

我们做了一个简单的变更通知模板，变更会在项目群和看板同时同步，重要的在站会上再提醒。

2. 我们怎么决定“推迟”和“必须实现”的功能？

用 MoSCoW 分级（Must/Should/Could/Won’t）。然后简单打分，影响大、风险高、与主流程相关的优先做。
比如Must 有弱网重试、视频文档切换一致、学习进度保存；Should 有并发优化、离线预加载；外观类功能可以推迟。

3. 项目的出口条件（什么叫“做好了”）是否清晰？

功能部分，Alpha 阶段的 Must 全部完成并通过验收，Should 完成大部分。
缺陷部分，发布前 P0/P1 为 0，其他问题写清规避方案。
质量部分，主学习页加载不超过 3 秒，视频与文档切换不丢进度，可一键回滚。
工程化部分，接口与数据变更说明、发布清单、监控和日志都到位。

4. 对可能的变更有没有应急计划？

灰度发布加功能开关，先小流量再扩大，保留上一稳定版本方便回滚。数据库变更尽量兼容，必要时做版本化接口。
设置错误率和崩溃率告警，弱网场景增加重试与提示。

5. 员工能否有效处理意料之外的工作请求？

临时请求必须进看板，口头的不接。进行分级处理，P0 立刻，P1 当天给方案，P2/P3 放到下个迭代评审。
这样整体来看处理更有序，沟通往返减少。

6. 我们学到了什么？如果重来一遍会怎么改进？

心得：不做统一通知和文档，最容易误解和返工，弱网等边界场景要前置。
改进：在需求冻结前加一次小型变更评审，固定每周变更窗口，紧急变更要备案。

五、设计/实现

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

设计工作于项目启动后第 1 周启动，第 3 周完成核心设计定稿，
第 4 周配合开发进度完成细节补充。设计工作按模块分工推进，由技术负责人统筹协调。
设计启动于需求规格说明书确认后，为后续 9 周开发预留了充足时间，是合适的时间。
从最终成果来看，执行者均具备对应设计任务的技术能力，均在限定时间内按预期完成了指定任务。

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

设计阶段存在多处模棱两可的场景，核心通过 “需求回溯 + 技术验证 + 集体评审” 的方式解决。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

团队综合运用了多种工具与方法辅助设计与实现：
设计阶段绘制了数据库 ER 图、类图及用况活动图；
接口文档工具规范了前后端交互的接口格式、参数类型与响应逻辑；
采用 Go 自带测试框架与 Flutter 测试工具进行模块化测试。

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

Bug 最多的功能是混合内容的 “视频与文档无缝切换” 与 “进度跟踪” 模块,原因是业务逻辑复杂，需要同步多组数据。
重要 Bug如，弱网环境下，文档加载失败会导致视频播放界面卡死。
未预见这种情况的原因一是设计 / 开发阶段的测试环境以稳定网络为主，对弱网场景的模拟不充分。

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

代码复审采用 “分支管理 + 交叉评审 + 核心模块集中评审” 的方式开展：
开发人员完成模块功能后，提交合并请求（MR），指定至少 2 名跨模块的开发人员进行交叉评审，
评审通过后才可合并至开发主分支；对于用户系统、推荐算法等 P0 级核心模块，组织全体技术成员进行集中评审；
关于代码规范执行，我们提前制定了统一的代码规范，并同步至团队共享文档。
评审过程中发现相关问题，均要求提交者修改后重新评审，整体严格执行了代码规范。

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

一是要充分考虑边界场景、异常场景的处理；
二是接口定义与数据格式的提前对齐至关重要;
三是代码规范与代码复审是保证项目可维护性的关键。
如果历史重来，我们会：
设计阶段针对每个核心功能，梳理全量使用场景（含正常场景、边界场景、异常场景），
并在设计方案中明确对应处理逻辑。
还会，提前开展技术预研，在设计前搭建原型验证核心技术方案的可行性，减少设计与实现之间的偏差。

六、测试/发布

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

团队未制定正式、完整的测试计划，仅在开发后期口头约定了 “核心功能跑通” 的测试目标。
核心原因有三点：一是项目初期资源规划偏向开发环节，对测试的重视度不足，默认 “开发自测 + 简单交叉测试” 即可满足 Alpha 阶段需求；
二是团队缺乏专业测试人员，成员均为开发岗，对测试计划的框架、内容拆解缺乏经验，难以系统性制定；
三是前期预估测试工作量较小，认为 “功能点不多，边测边改” 效率更高，无需单独落地成文档化计划。

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

未进行正式的验收测试，仅开展了非正式的 “内部体验式验收”。

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

仅使用了基础测试工具，未引入专业测试工具。

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

功能层面：通过 Excel 表格记录发现的 Bug，标注 “模块、描述、严重程度（P0/P1/P2）、发现人、修复状态”，每日站会同步 Bug 修复进度；
性能层面：无量化测量，仅通过主观感受判断 “加载是否卡顿”“切换是否流畅”，未记录响应时间、并发量等数据；
兼容性层面：仅在 2-3 款主流手机（安卓旗舰机、iPhone）上测试，未覆盖中低端机型、不同系统版本（如安卓 10 以下、iOS 14 以下）。
测试工作有一定作用，但效果有限。有用之处在于：通过内部交叉测试和外部体验，发现了核心功能的关键 Bug（如弱网下视频卡死、进度丢失），避免了 “无法使用” 的严重问题；验证了核心流程的可行性，确保用户能完成 “登录 - 选课 - 学习 - 切换内容” 的主路径。但局限性明显：一是遗漏了边缘场景 Bug（如断网后恢复网络的进度同步、多账号登录冲突），发布后才被反馈；二是未发现性能隐患（如同时加载多个视频时内存占用过高），影响部分用户体验；三是兼容性问题未暴露，导致少数中低端机型出现 UI 错乱。
建立量化的效能指标：明确核心指标（如主页面加载时间≤3 秒、视频播放卡顿率≤5%、接口响应时间≤500ms），并使用工具（如 JMeter）定期测试记录；
引入分层测试工具：后端增加接口自动化测试框架（如 Go 的 Ginkgo），前端引入 UI 自动化工具（如 Appium），减少重复手动测试工作量；
搭建专用测试环境：分离开发环境与测试环境，模拟真实服务器配置、网络带宽（含弱网、断网场景），确保测试结果贴近实际使用场景；
扩展兼容性测试范围：借助云测试平台（如 Testin），覆盖不同品牌、型号、系统版本的设备，避免机型适配问题。

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

发布过程中（采用 “内部小范围灰度发布”，覆盖约 50 名用户），发现了 3 类意外问题：
环境适配问题：部分安卓低端机型（运行内存≤4GB）安装后启动闪退，排查后发现是前端打包时未适配 32 位系统，默认打包为 64 位安装包；
数据同步问题：少数用户反馈 “切换设备登录后，学习进度未同步”，经排查是后端同步逻辑存在延迟，且未添加重试机制，导致数据未及时写入数据库；
服务器压力问题：当同时有 20 + 用户在线学习时，视频加载速度明显变慢，甚至出现加载失败，原因为服务器带宽预留不足，且未配置 CDN 加速，无法应对集中访问。

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

项目启动初期，同步制定测试计划：明确测试范围、测试阶段（单元测试、集成测试、系统测试）、测试责任分工、测试用例编写规范、Bug 分级标准，确保测试工作有章可循；
引入专业测试工具并搭建测试环境：后端使用接口自动化工具编写核心接口测试用例，前端使用 UI 自动化工具覆盖主流程，搭建含弱网模拟、性能监控的测试服务器，提前发现性能和兼容性问题；
开展正式的验收测试：基于需求文档编写详细验收用例（覆盖正常场景、边界场景、异常场景），组建 “开发 + 产品 + 外部用户” 的验收团队，严格按照用例执行测试，形成验收报告，未达标则不予发布；
发布前进行多轮预发布验证：先在测试环境进行压力测试（模拟 100 + 并发用户）、全机型适配测试，再进行小范围灰度发布（10-20 人），收集反馈并修复问题后，再扩大发布范围；
配置发布应急资源：提前预留 CDN 带宽、准备回滚方案（保留上一稳定版本安装包、数据库备份），若发布后出现严重问题，可快速回滚，减少影响。