团队任务五

05号团队-团队任务5：项目总结会

团队信息

  • 团队序号：05
  • 开发软件：飞机大战
  • 今日整理人：李姝雅
  • 学号：2017035107209
  • 团队职务：UI设计师

代码仓库

团队会议

  • 时间：2019.6.25
  • 地点：图书馆三楼
  • 成员：于子淇、李涛、许国玮、曹月、李媛媛、李姝雅。
  • 参与情况：全员出席

对设想与目标的回顾

  • 回顾：

  • 团队于4月17日第一次团队会议之后，经六人讨论（车功明、于子淇、许国玮、曹月、李姝雅、李涛）确定了本次团队项目的基本方向，并做出了相应的设想与目标。

    • 设想：从缓解年轻人压力、打发空闲时间、兼顾符合当代年轻人的休息取向上看，我们团队决定开发游戏类软件项目。在多种大众化游戏中，选择了相对兼顾游戏刺激与休闲度都较适合的飞机大作战游戏。本身这款游戏的普及度已经很广泛，所以决定采取一定措施让游戏更适合当下对口人群。
    • 目标：实现游戏的基本必备框架后，尽量与设想更加贴近，在实现游戏基本功能之上增加更多趣味性。

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

    • 我们的软件要解决当代年轻人压力，打法空闲的问题。
    • 从一开始的出发点就是针对于休闲的一款游戏，尽量做到不复杂但又不过于枯燥。
    • 典型用户适用于当代青年，场景为一般的空闲时间。

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

    • 在做冲刺前的准备时就已经明确的做好了需求分析以及整体计划。第一阶段冲刺的时候由于任务量过多，导致时间比较紧，相对第二阶段的计划有了第一次的经验就显得时间充裕很多。

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

    • 在计划阶段产生对规划的不同意见时，我们首先听取了每位成员的意见，通过归纳对每种意见进行投票，最终确定了整体计划。

  • 用户量、用户对重要功能的接受程度和我们事先预想一致么？我们离目标更近了么？有什么经验教训？如果历史重来一遍，我们会做什么改进？

    • 用户量和用户对重要功能的接受程度，一开始我们所想的过于乐观，实际上最终并没有足够的上传推广，也就是最开始的计划有问题，如果重新计划，应当逐天计划工作量，不再大范围计划。

对计划的回顾

  • 回顾：

    • 冲刺前准备（04.24---04.29）：完成软件的需求分析与原型设计并制作出UI效果图，制定详细具体的工作计划与任务进度安排，另外软件工程师和软件测试工程师可以开始进行准备工作。

    • 第一阶段冲刺（ 05.13---05.29）：在项目经理的带领下以见面会的形式找出
      Product Backlog并制定Sprint Backlog，同时开展每日立会，软件工程师，软件测试师，UI设计师，每日汇报当天工作量以及第二天的工作计划，同时每日向对应的仓库分支下提交工作内容。并于阶段冲刺结束之后进行了冲刺总结。

    • 第二阶段冲刺（06.03---06.14）：项目经理带领团队成员确定当前冲刺需要解决的事情Sprint Backlog，将这些事情添加到ISSUES中。通过见面沟通讨论会的形式完成。依旧开展每日立会，工程师，测试师，UI设计师每日提交自己的任务。测试师在工程结束时进行打包构建一遍发给客户。并在本次冲刺结束之后，进行第二次冲刺总结。

    • 事后诸葛：（06.19---06.26）：对设想与目标，计划，资源，变更管理，设计实现，测试发布进行回顾。

  • 计划的完成度：

    • 第一次冲刺中的预计任务已经全部完成，在第二次冲刺中的添加boss想法并未实现。
    • 由于没有做充分的准备，同时成员的能力不够，所以导致计划未实现。

  • 有没有你发现一些事情后，发现事后看来并没有必要

    • 有些成员开会的时候过于形式化，实际内容其实并没有讨论出什么结果。

  • 是否每项任务都有清楚的定义和交付件

    • 每项任务都有清楚的定义和交付件，在一二次冲刺的开始进行了任务确立并指派给固定成员，并于冲刺结束之后进行了任务交付的核对。

  • 是否整个项目都按照计划执行

    • 大体都在按照最初指定的甘特图进行计划，在每次阶段任务开会的时候会制定出每个时间段的小目标，同时也有每日立会进行写作管理监督整个计划，明确的知道每个人每天要做什么而不是盲目做事。

  • 计划中是否留下缓冲区，缓冲区作用是什么

    • 计划中有留下一定的缓冲区，一是在每个阶段的计划初考虑到任务可能超出预计时间而留下的剩余时间，二是考虑成员的工作过于集中于自己项目总体上进度产生分支，缓冲区可以帮助整理总体进度。

  • 将来的计划将会做怎么样的修改

    • 将来会主要在用户体验方面进行修改。

对资源的回顾

  • 回顾：

  • 我们有足够的资源来完成各项任务吗？

    • 有，首先飞机大战作为普及度很高的大众化游戏，我们有很多的同类游戏可供参考，同时相对于复杂度较高的工程项目，我们的UI设计也只集中在飞机子弹等素材上，相对比较简单，

  • 各项任务所需要的资源和时间是怎么样估计的，精度如何

    • 以上为资源的进度，精度基本贴合。

  • 测试时间人力和软件是否足够，对与那些不需要编程资源是否低估难度

    • 相对于其他组，我们组的测试人力和时间并不是很充足。我们组的工程师人数较多，同时只有一个测试师，所以工作量较大，同时水平有限，人力上也不充足。对于不需要变成资源的任务我们相对进行的比较顺畅，在项目初期就已经基本确定了所有美工以及UI素材。
    • UI测试分支：https://gitee.com/lishuya0330/team_project/tree/UI设计图/

  • 你有没有感到你做的事情 可以让别人来做更有效率

    • 在项目进行的后期个人觉得更适合于项目经理一职。我们组的项目经历在人员调动期间申请离组后，新晋的组员接手了项目经理一职。但由于项目初期并未在本组织，所以计划安排上有所出入导致整体方向混乱，相比较下一直在本组织的可能更了解项目走向以及初期的预期。

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

    • 测试职位人员太少，人员分配不平均。如果重新分配的话不会再出现工程师测试师三比一的情况了。

对于管理变更

  • 回顾：

  • 每个相关的员工都及时得到了变更的消息

    • 是共同商讨进行的变更。都有得知。其中具体变更如下：

    • 04.16 04.28 05.20
      曹月 产品经理 软件工程师 软件工程师
      李媛媛 未进组 未进组 项目兼产品经理
      车功明 项目经理 项目兼产品经理 已离组

    • 其他人员在04.16---06.14均无变动

  • 我们采用什么办法来推迟和必须实现变更的功能

    • 确定任务优先级。在项目初期确定任务的时候就已明确的制定优先级任务，最高级为必须实现的任务。

  • 项目出口有清晰的定义吗

    • 有定义。比如第一代阶段冲刺的buff功能虽然未在第一阶段实现，但在第二阶段冲中择优完成了buff功能。buff功能是我们集中讨论区别于其他飞机大战的一大特色点，增加游戏可玩性。

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

    • 首先我们在每次阶段中都留有一定的缓冲时间，一边即使调整项目分歧。同时也在每次项目的初期指定任务时都会简单商讨一个plan b，以备万一。

  • 员工是否能有效的处理意料之外的工作请求

    • 能。组员在两三个月的磨合中，包括可能测试师需要工程师帮助等等意外情况，大家都第一时间尽自己可能给予了帮助，没有吝啬刻薄种种，即使是在工作时间之外的时间内，接到任务也会组内商讨第一时间完成，没有懈怠或掉队等现象。

对于设计/实现的回顾

  • 回顾：

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

    • 我们最开始的设计是有项目经理进行的需求分析报告，对整体项目进行设计。后续设计由项目经理和UI设计师共同完成。前期主要围绕的是游戏的整体方向，从功能，难易程度，运行目标入手，后期以游戏的外观为主进行设计。

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

    • 工作进行中有模棱两可的情况，比如有飞机被敌机击中时无减分情况，需要测试很多次才察觉，平时运行也并不明显。我们的工程师在第一时间内仔细查找了问题并进行改进。偶尔还会有汇报时间不确定的时候，但是我们组的成员都在没有确定明确时间之前就开始做准备，以备不时之需。

  • 团队时候运用到单元测试 测试驱动的开发 或者其他工具来帮助设计和实现 这些工具有效吗

    • 我们所用的打包程序时pyinstaller。最开始的时候有用到UML确定整体游戏系统。我们认为这些时有效的，在整体规划和封装上都方便了很多。

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

    • buff功能产生的bug最多。发布之后暂无发现bug，我们在设计之初并未考虑到buff功能，是后在整体初步完成之后加入的功能，加入后导致游戏崩溃，卡顿等无法运行的情况。

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

    • 复审步骤：编译→软工自测→软工上传到码云→测试工程师测试→软工对测试工程师提出来的问题进行解答→发现Bug后列入修改计划
    • 有进行代码规范。程序单位首部有程序说明和修改备注，变量、过程、函数命令符合规则。

对测设/发布的回顾。

  • 回顾：

  • 团队没有测试计划？为什么没有？

    • 在最开始测试之前就已经确定了测试计划。

  • 有没有做过正式的验收测试

    • 在每阶段结束的时候都会进行验收测试。

  • 团队是否有测试工具来帮助测试

    • 有。我们的测试工具是pyinstaller。

  • 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看这些测试工作有用吗？应该有哪些改进？

    • 每日进行提交代码并测试当天提交的代码。
    • 从软件实际运行的结果看这些测试工作是有用的。通过每天的测试情况来辅助代码，及时检查出运行问题及时改正，以免一步错步步错。
    • 我们在第二次阶段冲刺的时候由于测试的疏忽，很多天没有进行测试，导致整体进程缓慢，应当互相进行监督，认真完成分内工作。

  • 在发布的过程中发现了那些意外问题？

    • 在发布过程中对于软件没有发现问题，但是遇到了打包问题，打包之后出现了运行后闪退的情况。后来工程师经过查找等方法最终完成打包。

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

  • 回顾：

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

    • 团队于4月16日建成，经讨论最后确定每个人的角色。每个人都讲述了自己所擅长，通过擅长来合理分配角色。虽然人均水平有限，但都在自己的工作中尽到了最大作用。

  • 团队成员之间有互相帮助吗？

    • 有。我们的软件工程师同时会辅助测试，项目经理的设计也多数与UI设计师合作完成。

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

    • 对于合作方面的问题，我们组的态度都很端正，每个人坦诚讲述自己的想法，各抒己见，进行探讨，在最后投票制选出大家认为合理的方案。

成员贡献分配

成员 分数
曹月 2
李涛 3
李姝雅 2
李媛媛 3
许国玮 2
于子淇 3
posted @ 2019-06-26 10:29  李姝雅  阅读(328)  评论(0)  编辑  收藏  举报