赛博厨神队——Alpha阶段问题总结

赛博厨神队 2025-11-10 20:01:20

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

1. 设想和目标
1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
1.2 是否有充足的时间来做计划?
1.3 团队在计划阶段是如何解决同事们对于计划的不同意见的？
1.4 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
1.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
2. 计划
2.1 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
2.2 有没有发现你做了一些事后看来没必要或没多大价值的事?
2.3 是否每一项任务都有清楚定义和衡量的交付件?
2.4 是否项目的整个过程都按照计划进行?
2.5 在计划中有没有留下缓冲区，缓冲区有作用么?
2.6 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
2.7 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
3. 资源
3.1 我们有足够的资源来完成各项任务么?
3.2 各项任务所需的时间和其他资源是如何估计的，精度如何?
3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
3.4 你有没有感到你做的事情可以让别人来做（更有效率）?
3.5 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
4. 团队的角色，管理，合作
5. 变更管理
5.1 每个相关的员工都及时知道了变更的消息?
5.2 我们采用了什么办法决定"推迟"和"必须实现"的功能?
5.3 项目的出口条件（Exit Criteria – 什么叫"做好了"）有清晰的定义么?
5.4 对于可能的变更是否能制定应急计划?
5.5 员工是否能够有效地处理意料之外的工作请求？
5.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
6. 设计/实现
6.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
6.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
6.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 工具或其他方法来辅助设计和实现？
6.4 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
6.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
6.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
7. 测试/发布
7.1 团队是否有一个测试计划？为什么没有？
7.2 是否进行了正式的验收测试？
7.3 团队是否有测试工具来帮助测试？
7.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
7.5 在发布的过程中发现了哪些意外问题？
7.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
8. 关于对AI技术员工作的实例分析
8.1 代码自动补全与生成：根据注释或函数名自动生成代码片段。
8.2 代码解释与调试：快速理解复杂代码、定位错误并提供修复建议。
9. 总结
9.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
9.2 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
9.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
9.4 你觉得目前最需要改进的一个方面是什么?

1. 设想和目标

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

我们的软件旨在为烹饪新手提供一个集菜谱寻找与跟练烹饪于一体的解决方案，该目标定位清晰明确。团队对典型用户（即厨艺入门者）及其核心场景（从寻找想做的菜品到跟着步骤完成烹饪）有着共同且清晰的认知。这一从用户真实需求出发的准确定义，为后续开发奠定了坚实的基础，确保了产品方向没有发生偏离。

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

尽管项目在形式上安排了计划时间，但团队普遍认为计划时间并不充足。其根本原因在于大部分成员对所需技术栈不熟悉，这在项目前期导致了严重的规划困难，甚至无法有效制定计划。随着后期技术能力的提升，进度才得以逐步追赶。因此，表面上的时间充足被实质性的技术准备不足所抵消，最终使得计划阶段非常紧张且效果未达预期。

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

在计划阶段，当团队成员对计划产生不同意见时，我们采取了一种直接且务实的协作流程来解决问题。具体而言，其核心模式是：首先共同识别和明确存在的问题，随后通过开放的讨论进行协商，直至达成共识，最终基于共识对原计划做出相应的修改和调整。这一"发现问题-协商一致-执行改动"的机制有效地维护了团队的协作效率。

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

关于软件的实际用户量和功能接受度，目前尚未进行组外测试，因此无法与预期进行有效对比。尽管无法量化成果，但团队在开发过程中已深刻认识到，详尽的需求分析和科学的任务规划是项目成功的基石。

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

必须将需求分析作为集体任务而非个人工作，并将宏大目标细致拆解为可执行的每日任务，同时为技术学习预留时间。如果重来，团队将致力于加强协作分析，并采用更精细化、循序渐进的迭代开发模式。

2. 计划

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

原计划的工作并未全部完成，各端均存在不同程度的遗留问题。移动端因对前后端对接流程不熟悉及未修复的Bug而滞后；Web端则因初期规划不足和团队整体编程能力偏弱，导致进度落后并存在缺陷；后端虽核心功能基本完成，但仍需通过沟通继续完善。究其根源，大量本应在设计阶段解决的接口与协作问题，被延后到了开发阶段，严重消耗了项目进度与团队精力。

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

回顾项目过程，团队确实投入了精力在一些事后看来价值不高的事务上。主要体现在两方面：一是后端在需求沟通尚未明确时就过早地进行了数据结构与核心方法的定义，导致后续因不符合实际需求而大量返工；二是前端在Figma视觉设计上耗费了过多时间，追求高保真原型，但受限于实际技术实现能力，最终产品难以高度还原设计稿，造成了设计资源的投入与产出不匹配。

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

团队在任务管理方面存在显著不足，绝大多数任务都缺乏清晰的定义和可衡量的交付件标准。这直接导致了功能验收环节的失效，许多接口与逻辑问题在开发阶段未被发现，直至交付给前端进行联调时才暴露出来，造成了大量的返工和沟通成本的浪费。

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

尽管在具体功能和细节实现上遇到了诸多挑战和延迟，但项目的整体推进进程与最初规划的进度表基本吻合，大体上符合团队的预期。

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

团队在制定计划时确实设立了缓冲区，其实际效用在后端开发中得到了显著体现。后端通过将核心功能（如触发器和存储）在项目早期提前完成，为后续阶段构建了稳固的基础。这一策略使得团队在Alpha冲刺期间能够专注于接口的增补与修改，而无需对底层核心逻辑进行重大调整，从而极大地缩短了后端对需求变化的响应时间。尽管与前端的前瞻性沟通启动稍晚，但缓冲区的存在依然为后续的协作调整争取了宝贵的时间。相对而言，Web前端虽也尝试进行部分预先开发工作，但其缓冲措施在实际项目推进中所发挥的作用较为有限。

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

基于当前阶段的经验，团队对未来的工作计划提出了两项关键调整。在流程上，将建立更主动的沟通机制，例如后端组将在每日开发前优先了解前端的对接需求，并对关键接口进行自动化测试，以确保协作的顺畅与稳定。在进度管理上，团队决定以Beta冲刺的每日计划为最低基准要求，并准备在此基础上通过加班加点的方式全力追赶进度，力求达成项目目标。

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

跨职能的事前沟通与精细化的过程管理是项目成功的关键。如果历史重来，我们将进行以下根本性改进：首先，强制要求前后端在编写任何代码之前，必须就需求细节和接口规范进行充分对齐，从源头上减少返工。其次，将落实每日计划、及时复盘和确保所有成员对任务理解一致作为不可妥协的团队纪律，以提升整体执行效率。尽管个别成员对工作习惯有不同看法，但团队共识将致力于推动更为规范和前瞻的工作模式。

3. 资源

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

团队普遍面临资源短缺的困境，其中最核心的问题是时间不足，导致任务分配捉襟见肘。此外，后端还面临着明确的硬件资源瓶颈，现有的服务器性能可能无法支撑Beta阶段规划的并发设计。

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

后端方面，例如不涉及复杂逻辑的单接口改动/增加理想的要求时间为半小时内完成编程与部署，但实际上组员需要上课和做别的事情，不可能这么理想，所以只能尽可能做到及时反馈，最迟当天必须完成。前端方面，开始时根据单个页面制作时间估计总时间，但是由于难度和接口数量不同，以及对新任务缺乏预期，导致时间估算不准。

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

团队在测试资源上面临着明显的不足，不仅时间和人力紧张，硬件条件也受到限制，例如后端因服务器性能问题不得不依赖本地测试，但这又引入了测试环境与生产环境差异的新风险。此外，团队普遍低估了非编程任务的复杂度，前端发现精美的界面设计实际实现起来远比想象中困难，而环境配置等看似辅助性的工作也消耗了远超预期的时间。这反映出团队在资源规划时未能充分认识到全链路开发的复杂性，对编程之外环节的难度预估不足。

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

部分成员反思时感到，由于自身技术熟练度不足或偶尔的粗心，某些任务若交由他人完成或许效率更高。

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

除了个人需要提升能力外，更关键的是在项目层面进行改进。必须制定详尽合理的计划，并基于成员的实际能力进行更科学的人力资源分配。同时，一个深刻的体会是，不能依赖理想化的时间预估，必须为所有任务预留充足的缓冲，因为实际耗费的时间往往远超最初的乐观预期。

4. 团队的角色，管理，合作

明确的分工与责任是高效协作的基石。每位成员都需要清晰理解并担当起自己的角色职责。同时，技术上的协同规范也至关重要，这要求我们从项目启动之初就引入代码管理工具，建立统一的开发框架与编码规范，为团队编程打下坚实基础。此外，持续而积极的沟通是维系团队理解的纽带，能有效破除协作壁垒，确保项目在共识中稳步推进。

5. 变更管理

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

团队在变更通知上做到了基本传达，但缺乏关键的确认识环节。既无法保证所有人及时收到信息，也难以确认任务最终是否被正确完成。

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

团队通过全组文档作为基准参考，结合组内讨论和私下沟通的方式，来决定功能的优先级。决策主要依据两个关键因素：一是成员对自身技术能力的评估，二是项目最终展示的核心要求，以此区分"必须实现"的功能和可以"推迟"的任务。

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

团队对项目"完成"的定义尚未达成明确共识。目前一个概括性的标准是：软件需能在不同设备上稳定运行，并满足课程作业博客的基本要求。但这一定义仍缺乏具体、可衡量的细化指标。

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

大致可以，有一定的应急处理能力。当出现需要修改或增加的情况时，我们能够通过即时沟通快速传达变动并执行修改。这表明我们对可能的变更能做出响应，但更多是依赖即时反应而非事先制定的系统化预案。

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

团队目前应对意外工作请求的能力较弱，大部分成员难以有效处理额外任务。

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

确保信息同步至关重要。如果重来，我们会建立多重确认机制：通过邮件/群公告/私信确保每个成员都收到变更消息，并要求对消息接收和任务完成进行双重确认，从而提升团队响应能力。

6. 设计/实现

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

设计工作在项目启动初期便已展开。界面设计则由林琬茗、侯晴宇、郭晶晶、陈茜蕾、黄子妍共同完成，人力充足且能集思广益。需求设计在大家的讨论中也有了雏形，后面也由王成桢和季致涵总结和补充，也在后面的前后端讨论进行时完善。总体而言，设计启动时机和主要人选是合适的。

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

当设计工作出现模棱两可的情况时，团队主要通过沟通协商来解决。通常的做法是将疑问发布到团队群中进行集体讨论以达成共识。对于那些在开发前期未能及时发现的理解偏差，团队则在后续实现过程中，由相关人员直接找对应成员进行点对点的沟通和修正。

6.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 工具或其他方法来辅助设计和实现？

团队有选择地运用了部分工具来辅助开发。在设计阶段，前端使用Figma进行界面设计，并利用UML流程图厘清逻辑，这有效提升了设计的可视化程度。后端则发现类图和ER图极大地提升了团队在数据结构上的沟通效率。然而，在开发实践中，团队未能采用单元测试或测试驱动开发等严谨的工程方法。同时，技术负责人也反思，由于有时过于关注技术拆分而忽略了用户用例图，导致与其他成员的对接效率受到影响。

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

项目中产生Bug最多的功能集中在文件资源管理和静态资源访问上。后端由于对服务器端文件处理缺乏实战经验，过度依赖理想化设想，导致出现了图片无法显示等静态资源管理问题。前端则因为低估了实现复杂度，且多个版本未及时整合，引发了大量静态资源路径错误。这些在发布后暴露的重要缺陷，根源在于团队在设计和开发阶段对技术细节的认知盲区，以及前期缺乏对资源管理流程的充分论证和统一规划。

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

团队的代码复审机制执行得并不严格。后端虽然进行了人工复审，但重点仅停留在验证业务逻辑是否实现，对于代码规范、冗余逻辑等代码质量问题则计划推迟到后续beta冲刺阶段处理。而Web前端则完全没有进行人工代码复审，基本上只要功能实现就会被采纳，代码规范也未能得到严格执行。

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

我们认识到，对不熟悉的技术栈必须提前进行充分的技术调研和原型测试，为方案选型提供依据，避免在开发中期陷入被动。同时，需要优化开发策略：对简单功能采用快速实现、快速验证的方式，从而将主要精力投入到复杂模块和易出错的细节上。最重要的是，如果重来一遍，我们会从根本上加强设计阶段的跨职能沟通，并对实现所需的技术、时间和人力资源进行更务实的评估，从源头上减少因前期准备不足导致的各种问题。