琼港计划 ———— Alpha阶段问题总结

[琼港计划团队账号]

这个作业属于哪个课程	2501_CS_SE_FZU社区-CSDN社区云
这个作业要求在哪里	团队作业——事后诸葛亮
团队名称	琼港工作室
这个作业的目标	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. 团队是否运用单元测试、测试驱动的开发、UML或其他工具来帮助设计和实现？
• 4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？
• 5. 代码复审是如何进行的，是否严格执行了代码规范？
• 6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
• 测试/发布
• 1. 团队是否有一个测试计划？为什么没有？
• 2. 是否进行了正式的验收测试？
• 3. 团队是否有测试工具来帮助测试？
• 4. 团队是如何测量并跟踪软件的效能的？
• 5. 在发布的过程中发现了哪些意外问题？
• 6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
• 总结
• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
• 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段？
• 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
• 你觉得目前最需要改进的一个方面是什么？

团队项目总结报告

设想和目标

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

我们的软件《汉堡主理人》旨在解决卡牌肉鸽游戏与模拟经营游戏融合的市场空缺问题。定义非常清楚：为既喜欢卡牌策略又喜欢经营模拟的玩家提供独特体验。在需求文档中，我们对典型用户（硬核策略玩家、休闲经营玩家）和典型场景（3分钟快节奏单局、多周目挑战）都有清晰描述。

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

有相对充足的时间进行计划。团队在项目启动阶段花费了约2周时间进行详细的需求分析和原型设计，为后续开发奠定了良好基础。

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

通过飞书文档协作和QQ群讨论，采用民主集中制原则。重要决策会组织专题会议，充分讨论后由项目经理综合各方意见做出最终决定。

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

通过Alpha测试反馈，用户对核心玩法（卡牌组合×经营自动化）接受度高于预期。我们成功实现了预设的"3分钟快节奏单局"目标，离最终产品目标更近了一步。

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

经验教训：初期对移动端性能优化预估不足。
改进方案：在原型设计阶段就加入更多性能考量，提前制定优化策略。

计划

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

90%的原计划工作都已完成。未完成部分主要是部分特效优化和极端设备适配，原因是时间限制和部分低端设备兼容性问题的复杂性超出预期。

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

初期在UI动画效果上投入了过多时间，部分复杂动画在移动端实际表现效果有限，后来进行了简化。

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

是的，采用敏捷开发模式，每个冲刺任务都有明确的验收标准和交付件定义。

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

大体按照计划进行，但在第4-5天遇到了性能优化瓶颈，通过调整任务优先级保证了核心功能的按时交付。

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

预留了15%的时间作为缓冲区，这个缓冲区在解决突发性能问题时发挥了关键作用。

6. 将来的计划会做什么修改？

• 增加更细粒度的任务分解
• 强化代码复审环节
• 提前进行跨平台测试

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

学到经验：详细的任务分解和及时的沟通能显著提升开发效率。
改进方案：建立更完善的风险预警机制，提前识别潜在问题。

资源

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

人力资源充足，但在特定领域（如Shader编程、移动端性能优化）存在技能短板，通过团队学习和外部资源补充解决了问题。

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

采用基于历史经验的类比估算和三点估算法，精度达到85%左右。图形资源制作时间预估相对不够准确。

3. 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源是否低估难度？

测试资源基本足够，但移动端真机测试设备种类不够全面。对于美术资源的工作量确实有所低估，像素画制作的精细程度要求比预期更高。

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

部分基础性的UI实现工作可以由经验较少的成员承担，让核心开发人员更专注于架构和关键技术难题。

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

经验教训：专业技能分布不均衡影响整体进度。
改进方案：提前进行技能培训和技术分享，建立更合理的任务分配机制。

变更管理

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

通过QQ群公告、飞书文档更新通知和每日站会，确保变更信息及时传达给所有相关人员。

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

采用MoSCoW法则（Must-have, Should-have, Could-have, Won't-have）进行优先级排序，结合影响分析和风险评估做出决策。

3. 项目的出口条件有清晰的定义么？

有明确的出口条件定义，包括功能完整性、性能指标、质量标准等具体可衡量的指标。

4. 对于可能的变更是否能制定应急计划？

对主要风险都制定了应急计划，如性能不达标时的优化方案、关键功能延迟的应对措施等。

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

团队展现出良好的适应性，能够快速响应和处理突发需求，这得益于前期的技术储备和灵活的开发流程。

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

学到经验：建立变更控制委员会能更有效地管理需求变更。
改进方案：制定更正式的变更管理流程，减少随意性变更。

设计/实现

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

设计工作主要在项目前期由UI设计师和架构师共同完成，时间安排合理，人员配置恰当。

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

在卡牌效果与经营系统的结合方式上存在模糊点，通过原型验证和团队讨论，最终确定了清晰的设计方案。

3. 团队是否运用单元测试、测试驱动的开发、UML或其他工具来帮助设计和实现？

使用了单元测试框架，部分模块采用TDD开发。使用UML图进行架构设计，这些工具在保证代码质量和设计清晰度方面发挥了重要作用。

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？

卡牌拖拽交互和状态管理相关的Bug最多，原因是移动端触摸事件的复杂性和状态同步的难度。发布后发现的主要是特定设备上的渲染问题。

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

采用Pull Request机制进行代码复审，严格执行预定的C#代码规范，确保了代码质量的一致性。

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

学到经验：前期更严格的设计评审能减少后期的修改成本。
改进方案：引入更多自动化代码检查工具，提高代码质量。

测试/发布

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

有详细的测试计划，包括功能测试、性能测试、兼容性测试等全方位测试策略。

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

进行了正式的Alpha测试，邀请目标用户群体参与，收集了大量有价值的反馈。

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

使用了Unity Test Framework、Appium等自动化测试工具，以及自研的AI辅助测试系统，显著提升了测试效率。

4. 团队是如何测量并跟踪软件的效能的？

使用Unity Profiler进行性能分析，建立性能基线，持续跟踪关键指标如帧率、内存占用、加载时间等。

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

主要意外问题是部分Android设备的GPU驱动兼容性问题，通过动态降级特效方案解决。

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

学到经验：更广泛的设备兼容性测试十分必要。
改进方案：建立设备测试矩阵，覆盖更多低端设备型号。

总结

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

团队目前处于CMMI三级（已定义级）向四级（量化管理级）过渡的阶段。过程已文档化、标准化，并能持续改进，但在量化管理方面还有提升空间。

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

团队已从磨合期进入规范期，正在向创造期迈进。建立了有效的工作流程和沟通机制，开始展现出创新能力和问题解决能力。

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

• 沟通协作更加顺畅高效
• 任务估算和进度控制更加准确
• 技术难题解决能力显著提升
• 质量意识普遍增强

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

最需要改进的方面：风险管理与预警机制。需要建立更系统化的风险识别、评估和应对体系，特别是在技术难点和外部依赖方面，做到提前预警、主动应对。

具体改进措施：

• 建立技术风险雷达图，定期评估各技术方向风险等级
• 制定更详细的应急预案
• 加强跨领域知识分享，减少单点故障风险
• 建立更完善的质量度量体系