王者荣耀交流协会PSP Daily项目Postmortem结果

整理:高远博

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

PSP Daily 要解决用户(主要是软件工程课上学生)记录例行报告、写每周PSP表格和统计的需求。该群体小而精,需求比较明确。对典型用户和典型场景在我们的软件功能说明书中有清晰的描述。

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

有时间,于是我们在项目进行的过程中总是先作计划/划分任务,再编码。

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

有时是组长负责决定安排,有时是大家共同讨论决定。一般,以实际编写功能代码的人的意见为准。

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

大部分计划基本完成。事后发现没有完成点击一个格子修改格子,因为该功能的实现难度被低估了。

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

重构代码。后来发现没有时间重构。

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

有。把功能做出原型,然后再合并到整个项目中。如果原型没做对,就无法合并到项目中。

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

是的,因为每天开会,大家都会积极参与,组长的命令也都得到了执行。

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

最后一天设为缓冲区,编码完成没完成的功能。

6、将来的计划会做什么修改?(例如:缓冲区的定义,加班)

对于功能的说明和设计要更加具体、细致,及时review和修改。

功能快速原型的手段很不错,要继续使用。

分工要细致、加强测试环节的配合。

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

有时间和设备来完成各项任务,时间是最宝贵的资源。有时候大家比较忙,任务就会被拖后。完成任务都能完成。

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

凭借程序员的经验。相对误差不是很大。

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

用户测试的时间不够,没进行什么测试。人力和软件、硬件资源是足够的。

4、你有没有感到你做的事情可以让别人来做(更有效率)?

有。交给更为出色的程序猿编写代码,会写得更快。

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

成员有时会在群里说明更新情况。

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

软件功能说明书的定义,基本功能/核心功能必须实现;

功能的思路如果清楚了,快速原型基本做好,则必须实现;

难度必须满足可以实现;否则,推迟。

3、项目的出口条件(Exit Criteria)是否得到清晰的定义?

完成软件功能说明书中承诺的所有的功能。

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

能。开会讨论决定、群里讨论。

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

是。队员之间配合得都不错。很尊重组长的意见。

设计/实现
1、设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

由提出项目主题的人完成。在开会时,也可能在开会之前讨论/思考。是经验丰富的人。

2、设计工作有没有碰到模棱两可的情况,团队是如何解决的?

没有。由于来了经验丰富的程序猿,定义/划分需求的时候很明确。

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

没有运用单元测试(unit test),测试驱动的开发(TDD)、UML工具。运用了 leangoo看板、燃尽图、todolist控制项目进度。保证了成员按时完成任务。

4、什么功能产生的Bug最多,为什么?

保存/导出excel的功能产生的bug最多。
excel操作不熟悉,学习的难度稍微大一点,网上的可学习使用的代码错误或者版本都不太一致,需要调试很久。
耦合严重。
5、代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

没有进行代码规范要求。开发迭代周期短,没有最终的代码复审。没有代码规范。

测试/发布
1、 团队是否有一个测试计划?为什么没有?

有测试计划。

2、 是否进行了正式的验收测试?

没有。

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

没有使用测试工具。

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

本地运行程序,测试各种功能。有用。改进:应该在final发布解决大部分bug。

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

Excel的操作需要Office的引入,涉及到运行环境问题。安装包解决了这一问题。

posted @ 2017-11-28 13:38  Gaoyb348  阅读(233)  评论(2编辑  收藏  举报