甜美女孩项目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的算法有一些不太对的地方。
讨论照片:![](https://i-blog.csdnimg.cn/blog_migrate/763429304c133cc7239c6880842109e4.jpeg)
团队成员在Alpha阶段的角色和具体贡献:设总分20*6=120
名字 | 角色 | 团队贡献分 | 可验证的贡献 |
邓画月 | Dev | 21 | 基础2048开发,督促工作,表格文件整理 |
何颖琪 | Test | 20.5 | 界面UI设计及测试 |
于可欣 | Test | 19 | 测试、复审与数据库算法 |
梁子君 | Dev | 17.5 | 纸牌2048算法与复审 |
梁沛诗 | Dev | 20 | 界面及音效开发 |
曾祎祺 | PM | 22 | 需求说明书,博客编写,纸牌2048小部分 |