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

  1. 文章标题格式

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

  1. 说明团队信息

团队序号:3

团队成员:产品经理\项目经理:许兴鑫

                 软件工程师:吴登峰、王炳文

                 软件测试工程师:郑文龙

                 UI设计师:杨蕃、李昊燃

整理人姓名:许兴鑫 学号:2017035107036 职务:产品经理\项目经理(队长)

  1. 给出团队项目的代码仓库地址

团队仓库地址:https://gitee.com/sanzudingli/snakey

软件工程师仓库地址:

吴登峰(主):https://gitee.com/sanzudingli/snakey/tree/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E5%B8%88%EF%BC%88%E5%90%B4%E7%99%BB%E5%B3%B0%EF%BC%89/

王炳文:

https://gitee.com/sanzudingli/snakey/tree/%E7%8E%8B%E7%82%B3%E6%96%87%EF%BC%88%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E5%B8%88%EF%BC%89/

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

会议时间:2019/6/25

会议地点:图书馆3楼休息厅

参与成员:许兴鑫、吴登峰、王炳文、郑文龙、杨蕃、李昊燃(全员参与)

会议照片:3号团队-团队任务5:项目总结会_第1张图片

  1. 对设想与目标的回顾

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

贪吃蛇游戏的开发,程序代码的连接要并行开发,需求的变动,软件及代码的变动,成员之间要多交流。要解决的问题定义的还是比较清楚地,典型用户和典型场景分析在开始时也都做了详细的调研,经过调研后确立了最终的目标。

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

有时间,因为准备的比较早,计划做的比较详细,并且都在组员的接受范围内

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

主要通过集体开会的形式进行讨论定出结果,PM也很注重一对一交流。

  1. 对计划的回顾

·原计划的工作是否最后都做完了?

原计划的工作基本都做完了,只有一个白边的问题没有解决,因为实在是找不到出现白边的原因。

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

我认为我做的每一件事都是会有一些价值的,因为即使对于项目来说没什么意义但也是对我自己的一种提升。

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

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

·是否项目的整个进程都按照计划进行?

项目进程整体来说都是按照计划来进行的,有一些细节上的意外也无伤大雅。

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

计划中留下了缓冲区。减少了实际的物理读写次数,并且减少了动态分配和回收内存的次数。

·将来的计划会做什么修改?(例如:缓冲区的修改,加班。)

不出意外的话不会对计划做什么修改了。

  1. 对资源的回顾

·资源:从开始做到现在也更改了一些资源的运用,到现在做出的程序资源算是有点欠缺,总体是做出来了,就是缺少能够做出闪光点的资源。

·所需的时间和其他资源及精度:各个成员所做的工作时间安排是环环相扣的,各司其职 ,在第一个开始做任务的时候,下一个人先开始做好资源,这样不会出现空缺的时候导致程序终止,总体精度较高。

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

测试时间来说的话 ,因为能力问题时间算是比较紧的,人力很充足,对于软件的掌握不够好,在UI中就出现png格式图片在Python中出现白色背景边的问题。因为UI之前所用的ps软件试用期结束了,换了一个ps软件,可能是新ps软件的版本与电脑系统有冲突的缘故,在内存充足的情况下老是有内存不够的问题,贪吃蛇大作战的所有素材基本都是经过改版的,因为之前对于游戏美化感的低估导致游戏缺少美感,经过改版算是有了一些美化感。

·是否有自己的事情让别来做更有效率:可能是因为学过ps的选修课的缘故,对于UI设计方面有一些喜爱吧,当时第一次做出来发现美感缺失的很严重,内心是有一点动摇,既然选择了就要做好,所以最后我选择了相信自己。

·改进:因为自己的学习不扎实,导致做出的素材有缺陷,如果能重来我会多去了解ps这个软件,做出更好的素材,配合团队做出更好的贪吃蛇大作战游戏。

  1. 对变更管理的回顾

·每个组员都能及时的知道变更消息

·推迟和必须实现:根据项目的进度进行衡量,若一个功能如果不能实现的话会导致整体效果的缺陷就决定为必须实现,反之为推迟

·项目出口:冲刺前定好的目标,大部分完成(一至两项未完成)且运行时一起正常,无影响正常使用的BUG

·能制定应急计划,组员会在微信群内进行实时沟通讨论情况,并做出相应的决定

·能有效的处理意料之外的工作请求,若有障碍项目经理会进行沟通并进行调整、监督、沟通

学到了临时有情况如何应对,不足:应对的速度不是特别的快,会有一些耽搁,但是实际效果影响不大

  1. 对设计/实现的回顾

·设计工作在5月20号,由项目经理和软件工程师来完成,是合适的时间合适的人

·设计工作碰到过模棱两可的情况,团队经过大家一起讨论,根据每个人不同的想法,最终确定出大家都认可结果。

· 团队运用单元测试,测试驱动的开发,优点:1.帮助开发人员编写代码,提升质量、减少bug。2.提升反馈速度,减少重复工作,提高开发效率。3.保证你最后的代码修改不会破坏之前代码的功能4.让代码维护更容易。5.有助于改进代码质量和设计。

· 刚开始实现倒计时功能的时候,产生Bug最多,因为函数运算有瑕疵,软件工程师代码逻辑能力有所欠缺。当发布之后点击退出游戏导致程序崩溃。这个Bug到目前也没解决。

·代码复审:复审者可以选择面对面的复审、独立复审或其他方式。在面对面的复审中,一般是由软件工程师控制流程,讲述修改的前因后果。但是复审者有权在任何时候打断叙述,提出自己的意见。复审者必须逐一提供反馈意见

代码审查清单

1.代码能够工作么?它有没有实现预期的功能,逻辑是否正确等。

2.所有的代码是否简单易懂?

3.代码符合你所遵循的编程规范么?这通常包括大括号的位置,变量名和函数名,行的长度,缩进,格式和注释。

4.是否存在多余的或是重复的代码?

5.代码是否尽可能的模块化了?

6.是否有可以被替换的全局变量?

7.是否有被注释掉的代码?

8.是否有可以被库函数替代的代码?

循环是否设置了长度和正确的终止条件?

  1. 对测试/发布的回顾

·团队有没有测试计划?为什么没有?

团队有测试计划,每日测试计划

·有没有做过正式的验收测试?

做过正式的验收测试,每周结束都会进行一次

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

团队有测试工具,python等工具来完成测试工作

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

团队通过每日例会进行任务的分配,通过每日测试工作的进行计划来进行软件功能的效能跟踪,从实际效果来看,这样的测试工作还是比较有作用的,可以对软工测试上花费更多精力,因为会存在bug测试以及产品更新测试,时间短任务多

·在发布过程中发现了哪些意外问题?

发布过程中发生过产品包装出现黑屏现象,以及运行卡顿现象等等,但最终经过努力都解决了

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

·团队角色的确定:经过讨论,自己确认的职务。都能发挥所在职务的职能

·互相帮助:有互相帮助的情况,令我印象最深刻的是,UI设计师的图有一些问题,软件工程师与UI设计师共同讨论解决了问题,当然了这只是列举其一。

·我觉得我们团队正在处于规范阶段,因为都能互相照应,都能各司其职,按时完成任务

·需要改进的部分:技术,因为进度大部分因技术原因所限制

  1. 对团队成员贡献分的分配

许兴鑫:3       吴登峰:3     杨蕃:3        郑文龙:2     李昊燃:2     王炳文:2

你可能感兴趣的:(3号团队-团队任务5:项目总结会)