团队作业6-项目Postmortem

设想和目标

1. 设想

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

• 制作一款界面简洁、功能完善、带有局内聊天且可联网游戏的五子棋软件。
• 定义清晰，功能拆分完善
• 五子棋是一种简单的休闲游戏，主要面向不需要高强度消耗、高耗时的网络用户。

2. 我们达到目标了么

• 原计划功能-完成情况
  • 基本的五子棋游戏功能-完成
  • 游戏简洁的图形化界面-完成
  • 游戏的联网功能-完成
  • 游戏内用户间文字交流-完成
  • 游戏多开-未完成
• 交付情况
  • 按原计划时间交付
  • 交付前按计划完成初步测试

3. 与初始阶段对比

团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

• 对比
  • 上阶段完成了游戏本体，包括以下功能
    • 棋盘界面初始化
    • 判断落子
    • 判断输赢
    • 交换下棋者
• 质量明显提高
  • 界面更完善，功能更完全
• 提高点
  • 界面增加初始界面，导向单机、联机功能
  • 游戏内增加悔棋、和棋功能
  • 用户交互体验提高，如增加了落子前执棋提示

4. 用户体验

• 下棋功能
  • 界面简洁
  • 下棋反应迅速
  • 判断输赢无误
• 重点功能-文本交互
  • 文本传输无误
  • 方便快捷，不影响游戏体验
  • 交互体验优秀

5经验教训

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

• 项目计划阶段
  • 提前了解项目需求的功能，使用何种方式进行实现更加合理。
    • 如未实现的多游戏功能，使用Java的多线程处理会更理想
  • 合理评估小组能力，计划相应功能
    • 项目过程中是否有充足时间完成功能
• 项目实施阶段
  • 小组成员间交流要更明确
  • 代码管理需要更规范

计划

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

是，项目开始前，各成员提前对功能进行了解，且额外预留时间进行组内讨论

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

由于团队规模不大，五名成员都对计划提出建议，整理后重新进行讨论

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

设置团队飞书

• 实际上，由于以下原因，设置飞书意义不大
  • 团队规模不大
  • 已采用Github进行增量式管理
  • 成员更加适应微信及线下交流

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

每一项任务都有清楚定义和衡量的交付件。

• 项目是分模块进行的，两个模块的负责人每日订立并交付计划后，在统一集中交付件。

5. 意外情况

暂无

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

在计划中设置了基础功能以及拓展需求，拓展需求视作缓冲区。
事实上，本次缓冲区确实起到了作用，团队召开每日会议时，实时根据项目完成情况，考虑是否完成需要完成拓展功能。
通过这种方式，我们小组成功的完成了所有基本功能，并按时交付

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

在计划阶段额外增加一日的缓冲时间，避免因意外情况导致的无法按时交付。

资源

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

有

• 主要需要的资源为时间资源
• 其他资源，如软件，各成员都已准备

2. 时间估算

• 估算方式
  • 根据功能复杂程度估算
  • 根据功能分配人员估算
  • 根据功能优先级估算
  • 根据功能间衔接估算
• 估算精度
  • 偏差不超过一日，基本都按照计划时间进行交付

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

人力资源稍微欠缺，因为项目成员较少，要依赖每位成员扮演多个角色。

变更管理

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

及时
通过每日站立会议、微信交流，及时更新信息

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

• 在项目的一开始，规定好了所有必须实现的功能
• 通过每日会议时的交流，推断出必须功能的完成情况、完成难度
• 根据完成情况和组员体验，将拓展功能推迟，优先完成必须功能

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

• 无导致游戏崩溃的bug
• 用户游玩时，避免
• 软件能在预期的平台上运行

设计/实现

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

• 团队通过分模块并选择负责人，保证各部分负责人与成员交流道为，以匹配合适的人。
  • 实现过程中，这种方式得到了很好的效果，每个功能都匹配到了最适合的成员
    • 适合：掌握相关技术/对该功能及其相关技术感兴趣，愿意学习
• 时间根据Deadline、项目结构、完成难度进行分配
  • 如游戏本体功能需要最先完成，模块提交时间要求较早
  • 网络通信功能较难，所以先学习，并在本体功能完成过半时，开始进行实现

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

• 存在游戏本体功能和网络功能有交叉
• 通过统一接口，分配任务解决

3. 什么功能产生的Bug最多

• 网络功能
  • 通信、落子、胜负判断等功能都需要重新调整结构

测试/发布

1.测试计划

需求改进与系统设计 - 云下成伞 - 博客园 (cnblogs.com)

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

进行了，主要通过各成员一同进行测试

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

本次项目基本都通过手动测试，这种测试方式效率低下且容易产生错误
 在后续学习中，希望通过使用自动化测试工具来进行测试，例如Java的Maven

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

成员并不了解项目应该如何进行发布，如何撰写说明

总结:

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

目前属于CMM-initial级
主要问题是：

• 工作无序
• 管理无章法，缺乏健全的管理制度
• 开发项目成效不稳定

2.团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

我们团队主要还处在磨合阶段
以下是当前团队中的状态：
（1）团队公开地讨论流程和工作的方式。
（2）经过多次会议，团队定下了更现实的目标和决心。
（3）通过聆听、讨论，成员互相之间更加了解，认识到并欣赏各自的能力和经验。
（4）成员之间的讨论更加友好，大家意识到并尊重各人的个性。
（5）集体意识更强，有共同的目标。

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

• 团队目标更明确
• 任务分配更加合理

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

团队的增量式管理有待加强

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

响应变化高于遵循计划

• 每日站立式会议，团队成员都能积极提出完成任务过程中出现的问题和难点
• 负责人根据问题和难点，实时调整计划，保证项目的完整性

6.下一阶段

正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

• 将当前完成的项目代码格式化存入团队Git仓库
• 要求成员之后的更改通过Fork到个人仓库后机型更改
• 更改完成并提交的时候，要附带简洁明了的commit

7.对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。

首先，个人项目强调独立思考和解决问题的能力。没有团队成员的支持和协助，需要自己分析需求、设计架构，并编写代码。这个过程中，应当熟悉各种开发工具和技术，培养自己解决问题的毅力和耐心。

其次，在结对项目中，与队友合作对于项目的成功至关重要。与队友相互协作，分享想法和解决方案，使得项目的开发进程更加高效和有趣。同时，结对编程也是一个提高自己的沟通和团队合作能力的机会。

最后，在alpha团队项目中，我们学习到，一个好的项目管理和组织结构对于项目成功的重要性。团队成员之间的任务划分和协调，有效地提高了项目开发的效率和质量。同时，了解和尊重团队成员的专业背景和能力，能够更好地发挥每个人的优势，推动项目的进展。

讨论照片

成员贡献

姓名	学号	得分	贡献
崔海源	3122004779	22	团队组长、网络功能负责人
陈炜烽	3122004776	20	游戏本体功能负责人
麦润泽	3122004785	19	游戏本体功能成员
肖德栋	3122004792	19	游戏本体功能成员
陈耀安	3122004777	20	网络成员、PM

成员的绩效 =团队获得的分数 +个人的团队贡献分所有人贡献分的总和为20N=20x5=100，平均每人可得20分，100分的分配如下:
1.团队基础分(80分):每人按时按量完成自己所选的任务，全部按要求完成即可获得16分。
2.团队贡献分(12分):为团队整体做出贡献的，例如为团队写博客、上传团队项目、为团队项目寻找解决方案、帮助整个团队项目完成任务等等。
3.团队改进分(8分):在完成基础框架的同时，对自己的内容进行进一步完善改进甚至超额完成任务的。