团队项目总结

主要内容:

一、设想和目标

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

我们的软件解决的是有考研意向的人太孤独没有陪伴而有考研意向的人找不道考研基础知识的问题,定义的很清楚,对典型用户和用户场景没有清晰的描述

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

第一阶段冲刺没有充足的时间做计划,第二阶段冲刺有充足的时间做计划

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

一起商量

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

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

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

就是前期对于用户名标记没有重视,数据库名和表名没有协商一致,调用数据库的方法类中方法命名没有规范,我们会对调用数据库的方法类中方法命名要增加规范

二、   计划

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

对原计划的工作没有做完,原因是第一阶段团队磨合也需要时间,而且时间有一点少,不够用来学习和应用,而我们三个人水平有限

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

事后没有发现做没价值的事情

 

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

        每一项任务有明确的定义但没有衡量交付件

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

         大部分按照计划进行,但是也有点不同的地方

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

有设置缓冲区,缓冲区有作用

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

将来计划没有做什么修改

7、我们学到了什么? 如果历史重来一遍,我们会做什么改进?

我们学到了如何进行团队配合,整合代码时间要充足,整合代码前要提前与组员沟通好,如果历史重来一遍,在进行项目开发前应进行接口,数据表,某些类和方法调用以及命名的提前定下

三、   资源

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

有,可以通过百度、b站来学习

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

各项任务所需时间根据任务量以及困难程度,以及团队成员个人开发水平,精度比较差

3、测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试时,人力资源不足够,对于不需要编程资源低估了难度

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

是有这种感受

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

如果历史重来一遍,我会加强对任务评估的细化程

四、   变更管理

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

每个团队成员都及时的知道了变更的消息

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

我们采用对任务的难易程度决定推迟和必须实现的功能

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

没有清晰的定义

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

对于可能的变更不能制定应急计划

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

团队成员能有效的处理意料之外的工作请求

6、我们学到了什么? 如果历史重来一遍,我们会做什么改进?

如果历史重来一遍,我们会对出口条件做清晰的定义,对于可能的变更要制定应急计划

五、   计划/实现

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

设计工作由团队成员宋泊然完成,在合适的时间,是合适的人

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

设计工作碰到或模棱两可的情况,协商解决

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

没有运用单元测试,测试驱动的开发、UML等工具

4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

点击按钮进行显示数据或者跳转bug最多,软件会时不时闪退,因为我们设计开发室经验和储备知识不足

5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

没有进行代码复审,没有严格执行代码规范

6、我们学到了什么? 如果历史重来一遍,我们会做什么改进?

如果重来一遍,我们会运用单元测试工具,会进行代码复审,会严格执行代码规范

六、测试/发布

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

团队没有测试计划,因为前期没有想到

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

团队有正式的验收测试

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

团队没有测试工具来帮助测试

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

通过团队成员的下载和使用,这些测试工作有用,界面需要进行改进

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

在发布的过程中没有出现意外的问题

6、我们学到了什么? 如果历史重来一遍,我们会做什么改进?

如果重来一遍,团队要有测试计划,要使用一定的测试工具来帮助测试

七、总结

1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

目前的状态比较模糊

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

团队处于磨合阶段

3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?

团队协作更加默契

4、你觉得目前最需要改进的一个方面是什么?

团队成员应加强相互交流

八、确定本次项目需要改进的三个主要方面

1、团队成员应该加强交流,没有在开发前应提前决定应进行接口,数据表,某些类和方法调用以及命名,以及没有给重组代码留下充足的时间

2、团队成员开发任务量虽然相同,但是开发难度不同,没有根据开发难度进行分配,并且没有在分配时注意公用功能和交叉功能单独开发

3、团队成员没有进行相互监督开发,而是每一个人自由掌管开发进度;也没有对出口条件做清晰的定义和对于可能的变更要制定应急计划

原文地址:https://www.cnblogs.com/xianyu1805/p/13060626.html