软工作业No.9 第六周 事后诸葛亮分析报告

甜美女孩项目2048结果

整理：邓画月、曾祎祺

设想和目标

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

  弄一个给用户消磨时间的游戏，定义的很清楚。该游戏玩法简单，典型用户大概是学生，主要是空闲时间比较多的大学生，空闲时间在宿舍或者其他地点进行游戏。

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

有时间，但是大部分人并不知道如何利用这一段时间来做计划。

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

团队一起讨论的时候，有不同意见的话当时就会提出，然后一起解决。一般来说，少数服从多数。

 

 

计划

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

原计划中的两个功能没做完，一是因为水平问题，自己学的知识还太少了。二是因为时间问题，做项目期间有两场较重要的期末考试，需要比较多的时间用来复习。

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

有一些，但是大家认为与其不断地争论某些事情有没有必要，不如做了再说。

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

大部分是有的，但可能各人理解会有偏差

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

基本按照计划进行。

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

好像没有留缓冲区。

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

将来的计划应该就是留缓冲区。

 

资源

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

有吧

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

大概估计的，精度不太高。后来随着项目任务的加重，大家只顾得上干活，没时间考虑精度问题。

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

    足够

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

我们分工还挺明确的，有美工有开发有测试。各自完成自己的任务就可以了，还挺有效率的。

 

变更管理

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

正常情况下都可以。

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

讨论。

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

不太清晰。

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

基本没有，到时候随意抓人顶上。

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

规定所有请求都转到PM那里处理，这样减轻了开发人员的压力，让他们有大部分时间花在自己那一亩三分地上。

 

设计/实现

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

项目一开始，由美工和负责界面的同学完成。是的。因为要定好界面大小，图片按钮之类的东西。

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

很多，就看具体执行的人是如何解决的。一般由美工和界面的直接解决。

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

没有

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

纸牌2048！大概是因为还没有实现游戏功能（哈哈哈哈哈）

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

专人复审。一开始定了代码规范，但后来并没有严格执行。

 

测试/发布

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

我们有测试计划。

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

否

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

否

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

直接运行点击“玩游戏”，在玩的过程中测试算法是否有问题等等。

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

基础2048的算法有一些不太对的地方。

讨论照片：

            团队成员在Alpha阶段的角色和具体贡献：设总分20*6=120

名字	角色	团队贡献分	可验证的贡献
邓画月	Dev	21	基础2048开发，督促工作，表格文件整理
何颖琪	Test	20.5	界面UI设计及测试
于可欣	Test	19	测试、复审与数据库算法
梁子君	Dev	17.5	纸牌2048算法与复审
梁沛诗	Dev	20	界面及音效开发
曾祎祺	PM	22	需求说明书，博客编写，纸牌2048小部分