【第八周】beta阶段事后诸葛亮会议

本文由宫成荣，武志远共同编写

组名： 新蜂

组长： 武志远

组员： 宫成荣 谢孝淼 杨柳 李峤

项目名称： java俄罗斯方块NEO

会议时间：2016.11.15 18：00~18：40

会议地点：冬华一楼会客区

 

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

我们的项目是一款小游戏，所以项目的目的在于满足用户玩小游戏的需求，不同类型的用户可以从中获得不一样的体会；定义的也很清楚；关于典型用户和典型场景在spec中都有清晰的描述。

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

构建α版本的时候确实没有充足的时间做计划，或者说第一次接触这样的项目，甚至不知道如何去计划。但是在β版本中，因为在α版本已经完成了游戏的主体框架，所以在此基础上对新添加的各个功能还是做了充足的计划的。

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

主要是靠事实说话，有不同意见互相摆事实讲道理，实在解决不了的就举手表决了。

 

 

计划

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

并没有都做完，比如现在暂停功能还只能用键盘空格实现，主要还是因为大家事比较多不能很好的集中力量，所以只能推到final版本冲刺。

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

很多，比如讨论俄罗斯方块实现方法，这已经是很成熟的游戏了，网上有很好的例子，我们要做的只是在此基础上改进。

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

大部分都没有，只能是与预期的结果相近或者基本实现预期的功能。

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

基本上是按计划的，因为站立会议可以不断的计划不断的调整。

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

开始的时候没有留缓冲区，所以任务衔接的不好，后来加了缓冲区，因为任务不能按时完成导致的不利后果减小了。

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

适量加大工作量，追赶进度。

 

资源

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

基本上是足够的，主要还是人员协调不太方便。

2.       各项任务所需的时间和其他资源是如何估计的，精度如何?

都是刚开始自己瞎估计，当然差得很远，但是一遍一遍的估计到后面也就比较准了。

3.       用户测试的时间，人力和软件/硬件资源是否足够?

   用户测试时间不够，还没拿出去给太多的人用，大都是自己组里的组员以及室友试玩一下。

4.       你有没有感到你做的事情可以让别人来做（更有效率）?

没有，大家都是第一次接触，所以都算是新手。

 

变更管理

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

是的，有了新进展都会在微信群里通知。

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

对于一般的功能，对比提交时间和预计工作时长，如果提交时间马上到，而预计工作时长不够，那只能推迟；但是如果是核心功能，那就加班加点也得必须实现。

3.       项目的出口条件（Exit Criteria）是否得到清晰的定义?

对于我们的项目，用户可以流畅的游戏，从中获得乐趣就算是出口条件了把。

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

没有，实在不行都是齐上手。

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

基本可以合理分配。

 

设计/实现

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

设计工作主要是在初期，当然后期也会在做的过程中调整设计。由全组成员讨论分工设计的。

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

很多，主要还是靠大家开会商讨。

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

游戏是比较特殊的软件，我们没有使用测试驱动开发（TDD）和UML，但是在开发过程中，我们使用了XML文档来保存各种数字参数，比如布局各窗口的大小，坐标等。其实不用XML也能实现，事实上我们开始没有使用XML，是才开始的硬编码后来改写成XML的，为的就是防止硬编码，有利于后期更改，代码复用。

1. 什么功能产生的Bug最多，为什么？

开始设计游戏控制，添加键盘监听的时候，游戏采用了MVC架构，分view，control，model层，每层的模块就更多了，开发的时候都是写一点测试一点的，控制方块移动的时候，我们肯定不能把所有的代码都写好再测试，而是先测试游戏能不能读到键盘的输入，想让屏幕显示一个数，设定读到键盘输入该数就加1，结果开始总是报空指针异常的错误，看了整个程序也没有飘红，不知道怎么回事。修改了好长时间才能正确显示。

另一个就是硬盘存储用户分数信息，存到.dat文件里，方法都是借鉴网上的，.dat文件内容很难修改，错一点点就读不出来。

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

由我进行代码评审，之前开发的时候简单制定了下代码规范，比如大括号必须单独一行，尽量加注释等。我看代码的时候先把代码签入程序，然后跑一遍一般没问题，然后简单看一下代码，算是白盒测试。 

 

测试/发布

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

测试是随时都可能发生的，比如写一两行或几行关键的代码都要进行测试，马上观察代码效果。测试计划很少制定，因为测试比较频繁，一言不和就把游戏运行一下。

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

验收测试前面也说了，主要是我验收，签入代码后，先运行程序看看效果，算是黑盒测试，然后我在看注释和代码，算是白盒测试。

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

有。也是没有，比较简单，有的时候为了节约时间，更有针对性，我会写一个临时的main方法，单独跑某一模块的代码，为其添加输出，观察结果是否正常。

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

效能是我们关注的最少的，游戏算是运行流畅。也不会产生严重的后果，因为不论是现在的java和win10对于内存管理机制已经很成熟了，不会担心这方面的问题。另外，我为了观察内存泄露的风险，把游戏开了几个小时，发现没有任何异常，内存基本和原来保持一样，于是就停止测试了，当然几个小时的测试不能完全证明已经杜绝内存泄露的风险，因为内存泄露可能是缓慢的，服务器上的程序需要严格测试，再小的内存泄露如果在长时间开启的情境下也会产生严重的后果。不过我们不用测试这么严格，毕竟一般几个小时的游戏时间也是接近用户使用的真实场景了。

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

我们软件是发布在window平台上单，同时需要用户有java，jdk，64位32位均可。我将软件打包成.jar文件，点击运行即可，但是有些用户我发现他点击之后不能打开，而是像打开一个压缩包一样。幸好此人有些java功底，使用cmd执行了程序，顺利的进行了游戏，我从中吸取教训，最终发布一定要是打包成.exe文件的。

总结：

大家普遍认为在这个过程中自己的进步都很明显，学习到了很多软件工程里的工程知识，在工程控制方面都有了较大的进步，数据方面并不好展示，可能需要做下一个项目的时候与现在这个项目作对比就能清晰的看到水平的进步。

我们认为还是处在CMMI二级，团队应该处于规范阶段，因为团队人员调整了一次，还是花费了不少的时间重新适应。

在这个里程碑里大家的牢骚少了很多，更多的是领任务做任务交任务。

转载于:https://www.cnblogs.com/Boxer1994/p/6069941.html