团队作业第六次——事后诸葛亮

设想和目标

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

我们的软件要解决的是用户选择电脑困难的问题。
定义的很清楚了。
通过4个典型用户场景,引出了我们的四个主要功能,硬件知识,硬件匹配电脑,关键词匹配电脑,论坛交流。

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

我们离目标还有一定的距离,原计划的功能大都实现了,按照原计划时间交付了。

原计划的用户数量还没有达到,只在同学小范围内使用传播,而且数据库中的数据还没有录入完毕,一些页面的细节还没有实现好,缺少了论坛交流功能。

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

团队软件工程的质量只能说略有提高,我们主要完善了管理员角色的新增文章功能以及一些页面的初始化。

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

并没有,因为我们侧重在了功能实现,但是前端与用户的交互还不能够让人满意。但是我们确实离目标更近了。希望在今后的日子里,还可以为这个项目添砖加瓦。

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

不同成员们的代码风格略有差别,整合在一起时难免有些杂乱,还有不少冗余代码。如果历史重来一遍我们会提前商量好代码风格,还有命名规范也有待加强。

计划

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

没有,因为大部分都是因为运动会的几天大家都有共同的空余时间去活动室一起工作,在α冲刺之后,大家都有其他科目的大作业,使得能用于项目的时间大大减少。排除考试上课的的因素,时间有些紧张,但敲代码的时间是其次,主要是上网查找资料和学习还有不断地试错,耗费了团队成员大量时间。

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

开会讨论,畅所欲言,再由所有团队成员一起提出意见,判断具体的可行性和实现内容或是放弃当前的想法。

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

最大的未完成的就是论坛交流功能,因为过多的时间用于学习,导致只做了原型,并没有具体去实现。

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

没有。

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

因为任务安排较为明确,大家的完成度也还不错,所以每一项的任务都有清楚的定义和衡量的交付件

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

第一次冲刺阶段基本按照计划进行,没啥意外。但是因为技术视野受限,没有预估好任务的实现难度,且需要实现的内容较为模糊,所以完成度不是很高。

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

有,本来是用于测试和进行阶段的进度总结,但是后来还是都用于编码了。

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

如果还有机会,我们会依照原计划进行,因为目前已经掌握了许多功能的实现方法。

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

我们会在前端的交互上下功夫,让用户使用起来能够更加舒适。

资源

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

有的,前后端的团队成员都有各自的渠道获取学习资源并实现学习资源的共享。

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

各项任务需要的时间和资源一开始确实没有什么明确的概念,只能按任务大小笼统分配,但是因为大家是在一起开发的,所以在开发过程中可以灵活调整任务量共同克服困难。

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

是,因为对于测试工具的不熟悉,使得测试时压力特别大。而美工/文案确实比想象中难度要大很多,因为这是一整个项目的基调与基础,不是划划水就好了。

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

不会,因为团队里面每个人都有自己的任务,大家也都很好的相互配合,才有了这个项目现在的样子。

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

没有好好学习spring boot,如果重新来一次,就不会跳过很多细节的东西。

变更管理

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

是的,每个成员都关注团队群的情况,使得消息通知特别及时被大家接收到。

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

通过集体讨论,表决哪些功能暂不实现。

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

各个功能都做完成好,并且能让第一次上手的用户就方便的使用。

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

在论坛交流这一块,我们认为无法迅速实现,因此就果断选择了抛弃,转去实现两个核心的匹配功能。

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

能,一开始我们没有打算实现管理员功能,后来经过组长的坚持,成员们也接受了这个意见,并且认真完成了任务。

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

组员需要规范代码,以应变需求的变更或者是功能的新增,如果重来,我们会规范代码的命名和结构。

设计/实现

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

设计工作是在冲刺之前,由吴俊杰,阿说阿加,朱煜喆完成,因为这个项目本来就是由组长提出的,因此项目经理和美工负责将组长的想法细化。

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

有,一开始对功能的设计还是很模糊,但是后来经过成员们的协商,定下了具体要实现的内容。

3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?

用E-R图来帮助数据库的搭建。UML类图让后端的分工更加明确。

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

匹配功能,由于对于网页间的数据传输的方法不熟悉,导致了该bug。在我们开发时还没有发现,到最后展示的时候才发现。

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

没有严格代码规范是一个重大的失误,以至于出现了甚至中文命名的尬尴情况。

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

我们学到了代码需要规范,而且在设计时下一定功夫是由好处的,让实现人员更加明确目标,能够加快项目的速度

测试/发布

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

没有,因为时间较为紧张。

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

都还是停留在完成功能后人为测试。

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

没有,都是组员通过postman自行测试。

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

有,因为到最后发现还是有一些bug没有结果。比如匹配到信息还会出现查询错误的消息。

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

提前租赁的服务器过期了。

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

测试以及测试工具的使用真的很重要,如果重来,我们会专门安排一个人进行测试工作。

团队的角色,管理,合作

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

是一开始组队时都定下的,基本上每个组员都在做事,并且自己负责的部分都完成的很好。

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

有,前端之间相互协商界面功能的实现方法,以及后端之间一起学习spring boot。

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

没有出现特别大的合作方面的问题,成员们都很团结。

每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):

陈聪

我感谢黄杨龙对我的帮助,因某个具体的事:CSS应用中的继承、网页自适应

江海天

我感谢陈聪对我的帮助,因为某个具体的事情:在我们对前段框架一筹莫展的时候,发现了ibootstrap这个可视化的网站,让我们对于前段开发有了质的飞跃。

邱健强

我感谢吴俊杰同学对我的帮助,因为在项目遇到瓶颈的时候,也就是前后端如何交互的问题上,通过和吴俊杰同学的交流学习,才解决了这个问题。

李清宇

感谢吴俊杰,因为某个具体的事情:他利用阿贾克斯帮我实现前后端交互的难题并促进团队项目进度

朱煜喆

我感谢林志全对我的帮助,因为用mysql建立数据库时他告诉我用excel表格直接插入更方便,节省了大量时间

吴俊杰

我要感谢李清宇,因为当初若不是他鼓励我上台讲出这个项目,也就不会有hunter这个小组,更不会有如今这一项目。

黄杨龙

我感谢陈聪对我的帮助,因为某个具体的事情:在界面设计时意见的不统一,他提供了很多的很优秀的想法,很好的帮助我们最后页面的设计

沈溢煌

我感谢吴俊杰对我的帮助,因为某个具体的事情:虽然他主要在做前端,但当我后端上遇到难以解开的BUG时,他也积极帮我一起寻找和解决。

林志全

我感谢吴俊杰对我的帮助,因为在进行前后端交互时他教会了我很多,让我学会了很多ajax的知识

阿说阿加

我感谢吴俊杰对我的帮助,因为刚开始团队成员不熟悉是他带我们进入团队状态彼此了解,很多作业问题也是找他商量解决,组长优秀!

总结:

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

我认为团队属于可重复级(Repeatable)。管理制度化,建立了基本的管理制度和规程,管理工作有章可循。 初步实现标准化,开发工作比较好地按标准实施。 变更依法进行,做到基线化,稳定可跟踪,新项目的计划和管理基于过去的实践经验,具有重复以前成功项目的环境和条件。

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

我觉得我们属于磨合阶段,大家之间因为有这共同的目标才能团结,但是相互之间的配合还有不够默契的地方。

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

只是小小的前进了一步,多实现了一些项目上的功能。

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

前端还有登录状态的一些细节。

正如我们前面提到的, 软件的质量 = 程序的质量 + 软件工程的质量,那团队在下一阶段应该如何提高软件工程的质量呢?

首先要规范代码,其次养成写文档的习惯,使用一些管理软件来辅助团队的工作。

组长想说的话

这段时间大家真的都很辛苦,很多组员在运动会的那四天假期都特别配合,而且在项目进行期间,都非常团结,没有发生矛盾。我们的活动室在五区,去的路途都很遥远,但是组员们真的一个去的比一个早,而且一去都是一整天,有时候回来了还在宿舍加班,让我一个做组长的都有点不好意思了。一开始看后端的进度时,我特别的慌,甚至都有点想放弃了,但是我的组员们没让我失望,在学习了spring boot之后立马展开了功能的实现。感觉我们组的成员在α冲刺的时候真的是实现了从零开始的蜕变。
learning by doing 在我们组就是件常事,后端的学习,前后端的交互,前端页面之间的交互,都是通过上网找资料,自己写代码测试,然后应用到实际项目中的。尽管最后的项目有点不尽人意,但也是我们组最真实的努力体现。最后感谢大家对这个组的付出,也感谢大家信任且选择了我这么一个菜鸡组长,只能和大家一起学,不能够带飞大家。希望这次的组队,会成为你们每个人最难忘的记忆。

我们一起努力过的纪念

团队作业第六次——事后诸葛亮_第1张图片
团队作业第六次——事后诸葛亮_第2张图片

你可能感兴趣的:(团队作业第六次——事后诸葛亮)