大玩家队——alpha阶段问题总结随笔

big_players 2024-05-21 23:55:06

这个作业属于哪个课程	2302软件工程
这个作业要求在哪里	团队作业—bate冲刺+事后诸葛亮
这个作业的目标	alpha阶段问题总结
团队名称	大玩家队
团队置顶集合随笔链接	大玩家队——Beta冲刺置顶集合随笔
其他参考文献	《构建之法》、CSDN

一、设想与目标
1.1我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
1.2我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？）
1.3和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
1.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
二、计划
2.1是否有充足的时间来做计划?
2.2团队在计划阶段是如何解决同事们对于计划的不同意见的？
2.3你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
2.4有没有发现你做了一些事后看来没必要或没多大价值的事?
2.5是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
2.6在计划中有没有留下缓冲区，缓冲区有作用么?
2.7将来的计划会做什么修改？（例如：缓冲区的定义，加班）
三、变更管理
3.1每个相关的员工都及时知道了变更的消息?
3.2我们采用了什么办法决定“推迟”和“必须实现”的功能?
3.3项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
3.4对于可能的变更是否能制定应急计划?
3.5员工是否能够有效地处理意料之外的工作请求？
四、团队的角色，管理，合作
4.1团队的每个角色是如何确定的，是不是人尽其才？
4.2团队成员之间有互相帮助么？
4.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？
五、设计/实现
5.1设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
5.2设计工作有没有碰到模棱两可的情况，团队是如何解决的？
5.3团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
5.4什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug? 为什么我们在设计/开发的时候没有想到这些情况?
5.5代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
六、测试/发布
6.1团队是否有一个测试计划？为什么没有？
6.2是否进行了正式的验收测试？
6.3团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
七、总结
7.1你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
7.2你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
7.3你觉得目前最需要改进的一个方面是什么?

一、设想与目标

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

解决问题：

同质化严重：市面上的卡牌游戏往往只是对数值设计、卡牌和关键词进行修改，缺乏质的区别。
静态构建卡组：传统集换式卡牌游戏的卡组构建过程是静态的，玩家构建出强力套牌后参与对战，缺乏动态性。
玩法单一：许多卡牌游戏因为固定的卡组或极端强力的卡组，导致大量卡牌设计和卡组构建失去意义，玩家很快失去兴趣。

典型用户：寻求新颖游戏体验的玩家（特别是那些对传统卡牌游戏感到厌倦、希望体验更丰富、更动态的游戏的玩家）、策略游戏爱好者、Roguelike游戏粉丝、游戏收藏家、寻求故事性的玩家等。

典型场景：

场景一（寻求新体验的玩家）：在周末或下班后的闲暇时光，寻求新体验的玩家可能会在家中的客厅或卧室寻找一款能够带来新鲜感的游戏。他们厌倦了市场上相似的卡牌游戏，渴望尝试一款具有创新元素和独特玩法的游戏，如《遗忘之海》所提供的动态卡组构建和丰富的随机事件，以满足他们对新颖游戏体验的追求。
场景二（策略游戏爱好者）：晚上或周末，当策略游戏爱好者有更多的时间沉浸在深度游戏策略中时，他们可能会选择在安静的书房或专门的游戏室进行游戏。这些玩家喜欢深度策略和决策制定，他们寻求一款能够提供策略深度和复杂性的卡牌游戏，而《遗忘之海》中卡牌与Roguelike元素的结合，提供了丰富的策略选择和决策空间。
场景三（Roguelike游戏粉丝）：对于Roguelike游戏的粉丝来说，他们享受游戏的高随机性和每次游戏体验的独特性。无论是在咖啡馆、公共交通工具上，还是工作间隙，只要他们有空闲时间，都可以方便地拿起设备，享受《遗忘之海》带来的新鲜和刺激，体验每一次不同的冒险旅程。
场景四（游戏收藏家）：游戏收藏家可能会花费数周甚至数月的时间，在自己的游戏空间内，专注于《遗忘之海》中的卡牌、遗物收集等。他们享受收集游戏内独特元素的过程，并乐于展示自己的收藏，与同好分享自己的游戏成果。
场景五（寻求故事性的玩家）：晚上或任何他们可以沉浸于故事情节的时间，寻求故事性的玩家可能会选择在一个可以让他们不受打扰的环境中，体验《遗忘之海》中深度的剧情和角色发展。他们喜欢在游戏中探索故事，而《遗忘之海》提供的丰富故事线和碎片化叙事，能够满足他们对深度故事体验的需求。

1.2我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？）

原计划功能列表已全部实现

alpha冲刺按照计划和规定时间如期完成，并已顺利通过答辩汇报

1.3和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

团队软件工程的质量在当前阶段有了显著提高。这种提高主要体现在任务细化、团队协作效率、技术实施规范性、沟通顺畅性以及开发效率和质量上。

提高主要体现在以下几个方面：

任务细化与规划：通过详细规划每个人的任务，团队能够更快地推进项目进展。
团队协作与交流：通过小组长的指挥和小团队间的交流协调，提高了团队的整体协作效率。
技术能力提升：团队成员的技术能力逐渐熟练，技术实施变得更加规范和高效。
站立式会议：定期举行站立式会议，及时检查和评估团队的进展情况，快速发现和解决问题。

具体提高的幅度约为20%。这一数据是通过综合评估团队的工作量、任务完成情况和团队成员的满意度等指标得出的。

我们团队衡量软件工程质量提升的方法包括：

工作量和任务完成情况：评估团队在一定时间内完成的工作量和任务数量。
团队成员满意度：通过调查或反馈收集团队成员对当前开发流程和协作效率的满意程度。
技术实施规范性：评估技术实施的规范性和遵循最佳实践的程度。
沟通顺畅性：通过团队成员之间的沟通频率和质量来衡量。
站立式会议的效果：通过会议中发现问题和解决问题的效率来评估。

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

经验教训：

需求分析和规划：项目初期对需求的深入分析和细致规划至关重要，这有助于确保项目目标的清晰和实现路径的明确。
持续回顾和评估：通过定期的项目回顾和评估，团队能够识别问题和改进机会，从而采取行动以优化流程和提升效率。

改进：

提前进行需求分析：在项目启动之初，投入更多时间和资源进行需求收集和分析，确保所有利益相关者的需求得到理解和满足。
强化规划阶段：在项目规划阶段，更加注重细节和可行性，制定更为周密的计划，以减少在项目执行过程中的不确定性和风险。
建立持续改进机制：在团队中建立持续改进的文化和机制，确保每个成员都能够参与到改进过程中，不断寻找提升工作流程和产品质量的机会。
促进学习和知识共享：鼓励团队成员之间的学习和知识共享，定期组织技术分享会和研讨会，以促进团队整体的技术进步。
加强团队建设：通过团队建设活动和增强交流，提高团队凝聚力和协作效率，确保团队成员能够在一个支持和信任的环境中工作。
风险管理：提前进行风险评估和管理规划，制定应对策略，减少潜在风险对项目进度和质量的影响。

二、计划

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

因为之前团队成员都有选修过C#这门课，团队中有部分同学学习Unity的时间较久，并且确定了合理的分工，所以我们团队在alpha阶段时间较为充足。

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

直接管理：在大多数情况下，如果团队成员的意见基本一致，组长会根据团队共识直接下发命令，以确保计划的快速制定和执行。
集体商讨：当团队成员的意见不太统一时，组长会组织会议，让所有成员都有机会表达自己的观点和理由，通过开放的讨论来探索不同的方案。
少数服从多数：在集体商讨后，如果仍有分歧，团队会采取投票的方式来做出决策，遵循“少数服从多数”的原则，确保决策过程的公平性和民主性。

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

原计划功能列表已全部实现

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

无，我们团队讨论和规划得比较充分，没走什么弯路。

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

团队正在按照既定计划稳步前进，每个阶段的工作都与整体目标紧密相连，确保了项目的连续性和效率，所以并没有遇到什么意外和风险。

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

我们在计划中有留下缓冲区，针对游戏bug的修复和一些细节的修改。

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

增加缓冲日，以提升容错率。

三、变更管理

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

每个成员都有及时知道，一方面组长在团队群里@全体成员，要求每位成员回复；另一方面通过线上线下会议讨论。

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

经过线上线下会议讨论决定。

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

满足用户需求：项目被视为“做好了”当它实现了所有规定的功能，这些功能满足了用户的具体需求，并且达到了预期的使用效果。
质量验证：项目出口条件还包括通过一系列测试和验证，确保软件的质量符合既定的标准。这包括但不限于功能测试、性能测试、安全性测试等，以验证软件的可靠性和稳定性。
文档完整性：项目交付时，所有相关的文档都应该是完整和最新的，包括需求文档、设计文档、用户手册和操作说明等。

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

能，我们经过周密的团队讨论和默契的配合，总能解决问题。

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

我们拥有周密的团队讨论和默契的配合，大家的工作意愿很高，都愿意互帮互助，没人会因为多做一些工作而抱怨。

四、团队的角色，管理，合作

4.1团队的每个角色是如何确定的，是不是人尽其才？

谁擅长什么就做什么，也可以进行合作。我们事先发布群投票收集分工意愿，然后通过线上会议讨论和调剂，尽可能地做到了人尽其才。

4.2团队成员之间有互相帮助么？

有互相帮助。当有成员无法及时或无能力完成任务时，大家都积极参与进来，互帮互助，解决问题。

4.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当团队成员之间出现合作问题时，我们会采取分层次的处理方法：对于小范围的分歧，涉及的成员会被召集进行一对一或小组会议，通过开放和诚实的沟通来解决分歧。如果问题较为严重，影响到整个团队或项目进展，我们将组织全体会议，确保所有成员都参与到问题的讨论和解决过程中。

五、设计/实现

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

1.设计工作主要在项目的前期阶段完成，具体包括需求分析、概要设计和系统设计阶段。这些阶段是在项目冲刺之前进行的，以确保项目在开发之前有一个坚实的设计基础。

2.设计工作是由团队中的所有成员共同完成的。每个成员都有机会发表自己的意见和建议，共同参与产品细节的讨论和决策。到了原型阶段，设计工作则交给了组内的两名成员，他们分别负责软件的前台和后台设计。

3.是。设计工作在项目的时间线上安排得当。在冲刺之前进行充分的讨论和合作，确保了设计阶段有充足的时间来吸收团队的集体智慧，并形成清晰的设计蓝图。

4.是。设计工作是由合适的人完成的。在初始阶段，所有团队成员共同参与设计，这有助于汇集多元化的视角和专业知识。在原型阶段，工作分配给了擅长前台和后台设计的两名成员，这样的分工确保了每个设计任务都能由具备相应技能和专长的成员来执行。

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

在设计后台功能初期，我们团队面临了功能确定和实用性评估的挑战，但通过持续的会议讨论、深入的需求分析、用户研究、原型测试以及利益相关者的积极参与，我们成功地解决了这些问题，并最终确定了一套既符合用户需求又实用的后台功能。

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

Unity Test Framework：我们使用了Unity内置的测试框架来编写和执行单元测试。这个框架使我们能够针对游戏对象的行为、组件的交互以及功能的验证等编写各种类型的单元测试，有助于确保代码的质量和可靠性。
Unity Performance Testing：为了确保游戏的性能达到标准，我们利用了Unity Performance Testing工具进行性能测试。这个工具让我们能够测量游戏在不同情况下的性能表现，包括帧率、内存使用和CPU使用等关键指标。通过设置测试条件和使用Unity Profiler分析结果，我们能够识别性能瓶颈并进行相应的优化。
有效性：

提高代码质量：通过单元测试，我们能够在早期发现并修复错误，减少后期调试的难度和成本。

确保性能标准：性能测试工具帮助我们监控和优化游戏性能，保证玩家获得流畅的游戏体验。

效率和生产力：自动化测试减少了手动测试的需要，让我们的开发团队能够更高效地工作。

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

未发现什么重要bug，平时开发的过程中就有不断测试，遇到小的bug都会及时修复。

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

各个开发人员都有阅读并严格按照代码规范进行编写，组长会审查代码是否符合规范。

六、测试/发布

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

有测试计划，详见大玩家队——测试随笔。

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

除了平时各个成员的测试外，团队里有成员专门负责系统性的测试，最后通过正式的验收测试，团队开会讨论确定测试通过。

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

Unity Test Framework：我们使用了Unity内置的测试框架来编写和执行单元测试。这个框架使我们能够针对游戏对象的行为、组件的交互以及功能的验证等编写各种类型的单元测试，有助于确保代码的质量和可靠性。
Unity Performance Testing：为了确保游戏的性能达到标准，我们利用了Unity Performance Testing工具进行性能测试。这个工具让我们能够测量游戏在不同情况下的性能表现，包括帧率、内存使用和CPU使用等关键指标。通过设置测试条件和使用Unity Profiler分析结果，我们能够识别性能瓶颈并进行相应的优化。