标签：文档 复审 校友 如何 逐梦 alpha 团队 代码 进行
| 这个作业属于哪个课程 | <福州大学2021春软件工程实践S班> |
|---|---|
| 这个作业要求在哪里 | 团队作业六——beta冲刺+事后诸葛亮 |
| 团队名称 | 逐梦校友圈 |
| 这个作业的目标 | alpha阶段问题总结 |
| 其他参考文献 | 项目管理之事后诸葛亮会议 |
1. 设想和目标
希望开发一款能让大学生有认同感的“校友圈"微信小程序，通过组队自习、拼车、拼单等搅局项目让同学之间快速融入，拉近彼此的距离，增加对学校的归属感。
1.1 预期功能标准
- 前端
- 展示校友圈内容，将帖文展示，可以实现发帖功能
- 展示组局信息，可以加入组局
- 展示个人信息界面，可以对个人信息，个人认证信息上传
- 后端
- 对五个不同的部分的数据库操作，并给与
1.2 现实进展
可以做到页面的展示，但是校友圈内容，组局内容bug还比较多，但是由于内容实在是过多，导致对接之后暴露的bug更多，修改起来很花费时间。
2. 计划
α阶段计划如下
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,团队,代码,进行 来源： https://www.cnblogs.com/zmxyq/p/14875226.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。