团队作业9——事后分析(Beta版本)

事后诸葛亮分析


设想和目标

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

  软件要满足的是低年级学生练习四则运算的需求。需求定义得不太清楚,中途还经历了一次变更,仍然需要在这方面进行改进。

2. 我们达到目标了么(原计划的功能做到了几个?  按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)

  原计划功能并未完全实现(排行榜),此次任务,花了较多时间磨合,所以进度较慢,故交付时间有延误。

3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?

  经过这次的项目,团队成员对软件工程的理解又进了一步,主要是在团队协作以及测试方面有进步,从完全不了解到入门水平。

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

  在用户量上我们并未取得较大进步。但是我们希望下一个版本的四则运算能够取得较大进步,新版本将整合新模式以及新注册方式,项目也将转入闭源。

 

有什么经验教训? 如果历史重来一遍我们会做什么改进?

 

计划

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

  并没有,花了太少时间来进行计划,导致后期很多问题的发生。

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

  投票,少数服从多数

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

  还没有,主要是因为时间不够。

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

  没有,仍需改进。

6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

  项目途中组员认为软件需求定义不清晰,中途讨论修改了软件需求,并对软件进行了较大改动。

 

资源

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

  我们最缺的资源就是时间以及注意力。

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

  资源的分配主要是靠空想来决定的,精度极其不准确。

 

变更管理

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

  是的,通知非常及时。

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

  不影响基本功能的运行的功能皆可推迟。

3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

  没有考虑到。

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

  有,加班

 

测试/发布

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

  有,流程清晰。

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

  是的。

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

  有,使用mocha来进行测试。

 

 

团队的角色,管理,合作

    1. 团队的每个角色是如何确定的,是不是人尽其才?

  根据各自擅长方向来决定的,人尽其才。

    2. 团队成员之间有互相帮助么? 

  有的,沟通效率较高。

    3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

  通过小型会议来解决管理问题。

名字

角色

贡献分

可验证的贡献

塗家瑜

组长

20

后端代码

陈宏辉

队员

40

前端代码、文档

张新磊

队员

20

数据库

姚燕彬

队员

20

测试

 

   

 

posted @ 2017-12-24 20:32  坎大哈的白衣天使  阅读(163)  评论(1编辑  收藏  举报