• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

逐梦校友圈——alpha冲刺阶段问题总结

开发技术 开发技术 6小时前 6次浏览
这个作业属于哪个课程 <福州大学2021春软件工程实践S班>
这个作业要求在哪里 团队作业六——beta冲刺+事后诸葛亮
团队名称 逐梦校友圈
这个作业的目标 alpha阶段问题总结
其他参考文献 项目管理之事后诸葛亮会议
目录
  • 1. 设想和目标
    • 1.1 预期功能标准
    • 1.2 现实进展
  • 2. 计划
  • 3. 资源
    • 3.1 人力资源分配
    • 3.2 各项任务所需时间和其他资源是如何估计的,精度如何?
  • 4. 设计/实现
    • 4.1 设计工作在什么时候,由谁来完成?是合适的时间,合适的人吗?
    • 4.2 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
    • 4.3 代码复审是如何进行的,是否严格执行了代码规范
    • 4.4 我们学到了什么?如果历史重来一遍,我们会怎样改进
  • 5. 测试/发布
    • 5.1 团队是否有一个测试计划?为什么没有
    • 5.2 是否进行了正式的验收测试
    • 5.3 团队是否有测试工具来帮助测试?
    • 5.4 在发布过程中发现了哪些意外问题
  • 6. 团队的角色,管理,合作
    • 6.1 团队的每个角色是如何确定的,是不是人尽其才
    • 6.2 团队成员之间有相互帮助吗?
    • 6.3 当初出现项目管理,合作方面问题,团队成员如何解决?
  • 7. 总结
    • 7.1 团队改进计划
    • 7.2 代码管理质量具体应该如何提高,代码复审,代码规范质量应该如何提高
    • 7.3 整个程序的架构如何提高?如何通过重构等方法提高质量,如何衡量质量的提高?
    • 7.4 其他软件工具的使用,应该如何提高?
    • 7.5 项目管理有哪些具体的提高?
    • 7.6 项目文档的质量如何提高?
    • 7.7 对于人的领导和管理,有什么具体可以改进的地方?
    • 7.8 对于软件工程理论,规律有什么心得体会或不同意见?

1. 设想和目标

希望开发一款能让大学生有认同感的“校友圈”微信小程序,通过组队自习、拼车、拼单等搅局项目让同学之间快速融入,拉近彼此的距离,增加对学校的归属感。

1.1 预期功能标准

  • 前端
    • 展示校友圈内容,将帖文展示,可以实现发帖功能
    • 展示组局信息,可以加入组局
    • 展示个人信息界面,可以对个人信息,个人认证信息上传
  • 后端
    • 对五个不同的部分的数据库操作,并给与

1.2 现实进展

可以做到页面的展示,但是校友圈内容,组局内容bug还比较多,但是由于内容实在是过多,导致对接之后暴露的bug更多,修改起来很花费时间。

2. 计划

α阶段计划如下

逐梦校友圈——alpha冲刺阶段问题总结

3. 资源

3.1 人力资源分配

人力资源在分配时,由于是半随机组队,所以仅仅只是对PM工作进行了划分,划分给了大家认为的工作能够胜任者。当时决定采取前后端分离的方式进行开发,让组员自行选择自己想去的部分,并按照了解情况划分了小组组长,便于后续任务的开发对接。后续进行了github实战之后对小组的组员进行了更适合自己的微调互换。

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

采用弹性时间制度,所有的任务都有了一定的弹性时间,使得群成员可以通过自己的时间安排安排出更为合适的弹性时间。由于每日发布的都是根据前一日的安排,所以对于第二天的任务所需时间,各个组员都有不同的理解,同时当任务较少时,交接人员会了解情况,并做到任务合理分析。

4. 设计/实现

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

设计工作在α冲刺之前有专门的软件工程实践用来做实践,由前端同学后端同学分开探讨,前端同学探讨数据库接口问题,后端同学探讨数据库设计问题,之后再由前后端负责人将内容进行对接,探讨是否需要有更改的地方。

更详细的设计由整个组员一同执行,对功能合理性进行探讨,讨论数据库表结构等是否需要变更。

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

当时为了防止出现模糊情况,将所有的记录都记录在了石墨文档上,便于团队成员阅读。当有问题时,成员会跟PM或者团队负责人进行沟通,将问题更详细化之后,将更详细的描述发布在原来的石墨文档当中,并在q群当中及时对内容进行更新

4.3 代码复审是如何进行的,是否严格执行了代码规范

由于开发阶段任务比较急促,代码复审的工作主要是自行完成,后端代码在再次测试代码时,对代码进行了复审。

团队成员基本遵守了代码规范。

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

一定要将细节的东西再细化些,并对代码进行良好的注释。

一定要根据定好的开发文档进行开发,只有严格遵守文档,才能保证前后端开发的工作不是困难进行

5. 测试/发布

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

测试计划就是很简单的前端界面逻辑以及是否能成功获取数据,发送数据,后端是对自己的接口进行测试,并对自己的service层代码进行测试。

5.2 是否进行了正式的验收测试

没有验收测试,由于开发还在进行中,就没有完整的验收测试

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

前端的测试工具停留在微信小程序开发的开发工具

后端的测试工具是用swapper或者postman进行接口测试,Junit对service层代码进行测试

5.4 在发布过程中发现了哪些意外问题

有出现服务器意外卡崩的现象,所以在发布过程中避开了这部分内容的展示。在发布前出现了接口仍然错误的问题,导致很多逻辑进行了更改。

6. 团队的角色,管理,合作

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

组长角色是团队的发起人,PM角色是组长根据对组员的了解进行任命,前后端角色是大家通过自行选择,选择想去的方向进行分配,前后端的组长也是根据能力了解进行任命,所以算是人尽其才

6.2 团队成员之间有相互帮助吗?

有的,不管是前端还是后端,大家都是很大一部分去学习一门心的技术,所以就会出现技术断层。同时也存在着有的同学学习能力较弱,断层能力就会比较严重。

PM有给前后端组长分配任务,对能力比较薄弱的同学进行帮助。

6.3 当初出现项目管理,合作方面问题,团队成员如何解决?

项目管理问题会在每天晚上22:00进行整体汇总,合作方面问题会向PM进行反应,PM再根据实际跟前后端组长交接,对问题进行反馈,并希望给与合理解决方案

7. 总结

7.1 团队改进计划

beta冲刺需要再次强调文档的重要性,保证组内成员按照文档进行开发,避免更多bug的生成。同时由于此次后端开发任务相对轻松,所以将部分后端人员进行了调整,调整到了前端。

7.2 代码管理质量具体应该如何提高,代码复审,代码规范质量应该如何提高

代码管理仍然使用githubProject,对Project的标签进行细化,代码规范同上次一样定义相似的代码规范内容,要求每一位开发人员自行遵守。代码复审由开发人员日常进行自我审查,并在测试阶段对代码进行二次复审,保证代码合理性。

7.3 整个程序的架构如何提高?如何通过重构等方法提高质量,如何衡量质量的提高?

α阶段就已经保证了前端代码在使用时保证组件的复用,这次β冲刺对于没有开发完全的代码仍然进行复用。后端代码使用Spring进行开发,Spring底层做了很多处理,所以只需要将Mapper,Controller,Service层分好就可以很好的使用。相似功能,考虑使用utils类进行管理函数

7.4 其他软件工具的使用,应该如何提高?

首先是资源进行共享,swapper需要账号才能使用,团队需要及时分享。对于不会使用的软件,可以面向百度,也可以向小组成员进行请教。

7.5 项目管理有哪些具体的提高?

issue的划分相较于上一次更加明细细节,并对issue的标签作详细划分

7.6 项目文档的质量如何提高?

项目文档保证自行复审,并交给负责人再次复审。对于大型文档,会发到群里让大家共同复审。

7.7 对于人的领导和管理,有什么具体可以改进的地方?

对于项目任务要做到弹性布置,并保证项目内容的及时督促,保证团队日常代码进度。

7.8 对于软件工程理论,规律有什么心得体会或不同意见?

自己的任务一定要及时完成,才能保证项目的进行。同时开发时一定要注重阅读开发文档,避免开发的额外问题。


程序员灯塔
转载请注明原文链接:逐梦校友圈——alpha冲刺阶段问题总结
喜欢 (0)