二号团队-团队任务5:项目总结会

  • 说明团队信息。在文章开头给出团队序号、开发的软件名称、今日整理人姓名与学号以及在团队中的职务。

    • 团队序号：二
    • 开发的软件名称：贪吃蛇
    • 今日整理人姓名：张炜一
    • 学号：2017035107122
    • 团队中的职务：项目经理/产品经理

  • 给出团队项目的代码仓库地址。列出团队所有软件工程师的代码仓库地址并标注哪个是主仓库。

  • 给出团队会议的时间、地点、成员参与情况与照片。

    • 团队会议
      • 时间：2019年6月26日15：00
      • 地点：图书馆三楼东厅
      • 成员参与情况：张炜一、王琨、尹志成、铁驰、齐浩楠、马铭泽（全员参加）
      • 照片：

  • 对设想与目标的回顾。

    • 我们的软件要解決什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
      • 我们软件要解决的问题是对源代码进行完善，添加功能使游戏更有体验性，我们对每个添加的功能都做了非常详细的计划，定义的很清楚。对典型的用户目前还没有做清楚的描述。软件的问题还是不少的，最大的问题就是代码的书写，这是一个大量而且困难的工作。对游戏的定位我们还是准确的。对典型用户和场景进行了大量的调查与总结最终确定了方案。对于我们软件需要结局的问题定义的比较清楚，对于典型用户和典型场景有着比较清晰的描述。我们初期就要解决生活压力大的人群通过玩我们的游戏来得以相对的放松。
    • 是否有充足的时间来做计划?
      • 我们用了充足的时间来做整个项目的计划
    • 团队在计划阶段是如何解决同事们对于计划的不同意见的?
      • 我们通过开会商讨的方式来解决同事们对于计划的不同意见。
    • 用户量、用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?有什么经验教训?如果历史重来一遍，我们会做什么改进?
      • 用户量以及用户对重要功能的接受程度和我们事先预想的一致，我们离目标更近一步，得到的经验是每个人应在团队中各司其职，如果历史重来一遍，我们会将每个人的任务划分的更加细致。

  • 对计划的回顾。

    • 你原计划的工作是否最后都做完了?如果有没做完的，为什么?
      • 原计划基本都完成，但是还是觉得可以更进一步的完善整个过程，依然有很多的不足。
    • 有没有发现你做了一些事后看来没必要或没多大价值的事?
      • 有一些事情在回顾的过程中确实是浪费时间的，比如说在写软件测试报告中，因为格式、顺序都有很多的考虑，浪费了很多的时间。但也学到了很多。有一小部分的工作最后与实际项目来说没有太大价值。对于相同逻辑的代码重复编辑浪费了很多时间，通过请教其他成员的帮助来用新的思维解决一些问题。
    • 是否每一项任务都有清楚定义和衡量的交付件?
      • 我们的每一项任务都有清楚定义和衡量的交付件。游戏初期是在摸爬滚打的过程中，并不是很顺利，我们只是在研讨的同时一点点在进步并逐步建立完整的流程。在整个项目行进过程中，有两次没有清楚定义和衡量的交付件，降低了当天的效率。
    • 是否项目的整个过程都按照计划进行?
      • 项目整体大部分都在按照计划进行，偶尔出错但很快回归正轨。在游戏的设计过程一直到最终完成，是有很多意外的，包括技术的不行，成员内部意见的不统一等等等等，万幸我们都一一克服。
    • 在计划中有没有留下缓冲区，缓冲区有作用么?
      • 有缓冲区，我们留下了这段空档就是专门应对过程中出现的各种各样的问题。缓冲区可以有效缓解突发情况对于项目进展的影响。通过攻关克难我们解决了一些问题，使缓冲区发挥了最大作用。
    • 将来的计划会做什么修改?(例如:缓冲区的定义，加班。)
      • 会合理的调整时间，还有每个人的具体分工。对于缓冲期会加大它的力度，他为我们解决了很多问题。我们将会增加开会讨论的次数，加一些班。
    • 我们学到了什么?如果历史重来一遍，我们会做什么改进?
      • 我们学到了一个项目的完成不仅仅是一个人的力量，是靠团队中的每一个人共同努力的结果，如果历史重来我们会按照计划中的时间去开发软件。

  • 对资源的回顾。

    • 我们有足够的资源来完成各项任务么?
      • 我们有足够的资源来完成各项任务。
    • 各项任务所需的时间和其他资源是如何估计的，精度如何?
      • 各项任务所需的时间是根据任务的难易程度估计的，精度相对准确。我们各项任务所需的时间和其他资源通过我们实际完成的情况来评估的，较为准确。
    • 测试的时间、人力和软件/硬件资源是否足够?对于那些不需要编程的资源(美工设计/文案)是否低估难度？
      • 测试的各项需求都足够，对于不需要编程的资源（UI设计）需要不断更新，所以没有低估难度。首先对于测试、人力、等方面我们是很重视的、其次我们对这些进行了大量的研究所以还算满意，对于美工方面也进行了很多，并最终确定了方案。对任何的方面都会以最认真的一面来对待。
    • 你有没有感到你做的事情可以让别人来做(更有效率)?
      • 我们团队合作的力量更大一些，但是没有想过我的事情让别人做
    • 有什么经验教训?如果历史重来一遍，我们会做什么改进?
      • 如果历史重来，软件工程师会更努力地学习编程语言。

  • 对变更管理的回顾。

    • 每个相关的员工都及时知道了变更的消息吗?
      • 对于组内队员的变更我们进行了及时消息交流和工作交接。每次变更都是经过团队开会决定的。
    • 我们采用了什么办法決定“推迟”和“必须实现”的功能?
      • 我们项目根据项目计划和实际是否出现bug。来决定是“推迟”还是“必须实现”
    • 项目的出口条件( Exit Criteria-什么叫“做好了＂)有清晰的定义么?
      • 项目的出口条件是完成需求分析中的所有项，并无bug产生。我觉得项目做好了就是游戏经过了我们组内所有人的认可，并被其他人认可。实现预期的项目功能就为做好。
    • 对于可能的变更是否能制定应急计划?
      • 对于可能的变更，团队内及时开会制定应急计划
    • 员工是否能够有效地处理意料之外的工作请求?
      • 员工能够有效的处理意料之外的工作请求。

  • 对设计/实现的回顾。

    • 设计工作在什么时候，由谁来完成?是合适的时间，合适的人么?
      • 设计工作在每个阶段结束后，下一阶段开始前由产品经理完成，是设计工作合适的人选。我们在合适的时间选泽了合适的人选来完成设计工作，由UI设计师马铭泽来完成。
    • 设计工作有没有碰到模棱两可的情况，团队是如何解决的?
      • 全体成员通过集体开会讨论的方式来解决设计工作模棱两可的情况。
    • 团队是否运用单元测试( Unit Test)、测试驱动的开发(TDD)、UML或者其他工具来帮助设计和实现?这些工具有效么?
      • 团队运用单元测试来帮助设计和实现，很有效。
    • 什么功能产生的Bug最多，为什么?在发布之后发现了什么重要的BUg?为什么我们在设计/开发时没有想到这些情况？
      • 在添加障碍物的时候产生bug最多，在发布之后发现了障碍物大小的bug，在设计之初没考虑到分辨率的情况。蛇身移动以及障碍物的设定产生的bug最多，因为我们对代码掌握的不熟练。发布之后没有发现重要的bug。
    • 代码复审( Code Review)是如何进行的，是否严格执行了代码规范?
      • 代码复审是软件测试工程师进行的，严格执行了代码规范。

  • 对测试/发布的回顾。

    • 团队有没有测试计划?为什么没有?
      • 团队有测试计划。
    • 有没有做过正式的验收测试?
      • 在项目开发结束后，做过正事的验收测试。
    • 团队是否有测试工具来帮助测试？
      • 团队利用单元测试来帮助测试。
    • 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看，这些测试工作有用么?应该有哪些改进?
      • 从软件实际运行效果，软件测试工作有用。认为我们这些测试工作很有用，发现了诸多需要解决的问题。
    • 在发布的过程中发现了哪些意外问题?
      • 在发布过程中发现了障碍物大小的问题。

  • 对团队的角色、管理、合作的回顾。

    • 团队的每个角色是如何确定的，是不是人尽其オ?
      • 根据每个人所擅长，确定每个人的职务。
    • 团队成员之间有互相帮助么?
      • 团队之间有互相帮助。
    • 当出现项目管理、合作方面的问题时，团队成员如何解决问题?
      • 当出现项目管理，合作方面的问题时，团队及时开会纠正错误以及以后的工作目标。我们会促进加强沟通来解决相关问题。

  • 对团队成员贡献分的分配：

    • 张炜一：4
    • 王琨：4
    • 铁驰：2
    • 马铭泽：2
    • 齐浩楠：2
    • 尹志成：1
posted @ 2019-06-26 16:34  炜一  阅读(192)  评论(0)  编辑  收藏  举报