老九门——alpha阶段问题总结随笔
| 这个作业属于哪个课程 | 2021春软件工程实践S班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 团队作业六——beta冲刺+事后诸葛亮 |
| 团队名称 | 老九门 |
| 这个作业的目标 | 记录alpha阶段存在的问题并总结 |
| 其他参考文献 | 无 |
一，设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是一个福州大学软件工程课程网站，一款专属于软件工程课程的项目。老师可以通过这个平台发布签到、作业和小测，可以在论坛发布问题或者回答问题。学生们则可以通过这个平台便捷地接收老师的通知和习题，也可以发布问题或者回答老师或其他同学的问题。师生可以通过这个平台进行简单的交流。进一步加强师生的交流与互动，与线下课堂教学形成互补。
有清晰的描述。典型用户（《软件工程实践》的老师，助教，学生），典型场景（签到，答疑讨论，小测，通知，课程资源）
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ )
在我们的原计划中功能点的实现如下。我们最终按照原计划交付时间交付了
前端
[√] 登录静态页面及接口数据连接
[√] 首页静态页面及接口
[√] 前端课程资源、资源上传页面
[√] 前端学生管理页面
[√] 前端课程作业页面
[ ] 前端课程签到页面
[ ] 前端课程小测
[√] 前端答疑讨论页面
[ ] 前端学科成绩页面
[√] 课程通知页面
前端现实进展大致完成预计计划，因为部分内容在alpha后期阶段暂未和后端对接上，所以暂时未完成，计划在beta阶段继续完成。
后端
[√] 教师对于学生的增、删、改、查
[√] 下载录入学生名单格式的excel
[√] 上传录入学生列表的excel
[√] 学科成绩的查询
[√] 录入单个学生成绩
[√] 修改评分规则
[√] 下载录入学生成绩格式的excel
[√] 登录
[√] 修改密码
[√] 通知的增删改查
[√] 课程资源的查询、删除、上传、下载
[√] 课程作业的发布、查询
[√] 作业的批改
[√] 学生提交作业、上传作业附件
[ ] 发布签到、学生签到、更改签到时间
[√] 小测链接增删改查
[√] 防SQL注入
[√] 防CSRF攻击
[√] 权限验证
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
在后期前后端交接的时候，遇到一些困难，导致了时间上有些许紧张。如果能重来，我们会更早进行前后端的交接，留出更多的精力到测试方面，减少bug的出现。
二，计划
1. 是否有充足的时间来做计划?
从团队集结开始，到α冲刺结束，有充足的来做计划
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
群里自由发表建议，言论，择优采纳。对于计划，更趋向于所有成员都能接受，都同意的一个方案
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
组长：没有，因为项目初期还在学习前端框架，没有花很多时间去完成编码。刚刚开始做比较大型的项目，对项目管理的方法不太了解，任务分配完之后自己不能很好的调动组员的积极性。
组员一：签到模块的后端对接出现了一些问题，数据无法返回。主要原因是时间紧凑，交互不充分
组员二：原计划负责的工作基本完成，但存在一些由于时间没有解决问题。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
组员一：没有
组员二：在学习前端框架的时候，有些知识是可以互相交流得到的，但是有时候交流少了，自己只能把视频看完。但如果队员已经学习完某个技术后，就可以直接教其他人了，这样省时省力。所以学习交流还是很有必要。
5. 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务都根据原型设计和项目系统设计作为衡量的交付件
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？
是的，整个计划都按照计划进行的，没发生什么意外。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
组员一：冲刺只有十天，但实际上是超过十天的，有些天没有发布博客就是在解决一些问题。
组员二：有，让时间分配更加灵活了。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
组员一：期末考试月，还是以学习为重，尽量避免一直在软工实践上加班。
组员二：因为Beta冲刺的同时还要准备期末考试，所以还是要设置缓冲区，时间的安排也会做出相应的改变。
组长：各司其职，把分配到的任务尽快完成。最近面临着期末考，需要留出时间复习，留给项目的时间不多。加班没必要就不要了。
三，资源
1. 我们有足够的资源来完成各项任务么?
从现在的角度看，我们是有足够的时间和人力资源来完成各项任务的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
组员一：人为估计，偏差挺大的，有时候会在预想不到的地方花费更多的时间。
组员二：在进行冲刺之前开了个会，大概计划了每天要工作的内容，精度还行。
组员三：主要看各项任务的负责人来估计，根据负责人以往的项目经验，学习能力等来判断。精度在一天左右。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
组员一：测试时间不充足，因为全员都参与到开发中，没有专门的测试人员，以致于最后测试显得匆忙。
组员二：留给测试的时间不是很多，因为项目进度有拖延。人力和软硬件资源是足够的。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
组长：自己负责的模块还是自己继续完善好，除非是别人懂自己不懂的，这些需要挑一个时间交流一下，集中处理。
组员二：有，比如代码部分，有的队员技术水平比较高，让他来做的话效率更高。
四，变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，每次发生变更的时候，相关的人都会第一时间通知到每一个人。但是，因为我们在开发的时候是前后端分离的，所以开始阶段，消息变更只会发生前端和后端。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
关于必须实现的功能，是我们小组基于对这些功能的实用性和实现的困难性进行综合考量来决定的，决定方式是通过小组成员集体商议。关于推迟实现的功能，是结合alpha冲刺阶段的现有时间和完成程度，和我们后面时间可能可以完成的任务量来决定的。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
通过单元测试，成功完成交接，可以正常的进行操作，数据都没有问题。
4. 对于可能的变更是否能制定应急计划?
可以的，我们小组前后端人员充沛，基本所有人都参与到了写代码的工作中，而且大多数模块都是独立的不会存在缺少某个模块就进行不下去的情况，如果遇到变更，我们可以制定应急的计划
5. 员工是否能够有效地处理意料之外的工作请求？
可以的，我们小组组内关系氛围和谐，每个人都会互帮互助，遇到意料之外的工作请求，在我们小组的共同努力互帮互助下，相信可以克服。
五，设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是根据老师的软件工程设计实践任务时间开始的，在α之前。是我们小组所有成员共同完成的。因为是在老师的合理安排下，所以我们的设计工作进行的时间是合适的，小组成员也是合适的人。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有的，不光是设计工作，通常我们遇到的很多模拟两可的工作都是通过投票商议的方式解决的
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
在设计阶段我们小组使用了UML来实现，是有效的工具。后期出现调整的时候，会产生区别。需要更新uml文档。
4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在进行代码复审的时候，以自我进行代码复审为主，然后交予组内较为厉害的技术人员进行二次代码复审。严格执行了代码规范
5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
组员一：我负责的区域中在内部测试找出的问题是在与数据库相关的问题，比如一开始我在本地发现了问题：在设计数据库的时候文件名字长度设置实在太短了，于是修改了数据库，通知了队友之后，但是队友忘记了。以至于后来又花了一些时间在找这个问题上。也有问题是设计时不合理造成的，中途也更改过数据表，增加了工作量。设计的时候没解决的原因大概是问题太小，太容易忽略了，大家也没太注意。
组员二：前端交互，开始编程的时间太晚了，很多交互没有写。页面布局定死了，在演示的时候按钮不能点击（doge），设计的时候没有对项目进度做出严格要求，进程偏慢了。
六，测试/发布
1. 团队是否有一个测试计划？为什么没有？
有的，但是我们小组的测试计划比较简单。测试计划就是测试数据的交互，后端是对自己的接口进行测试，并对自己的service层代码进行测试，由于是用SSM框架进行的后端开发,因此测试框架也就使用了Java适配的Junit,通过不同数据整合完成,由于之前有使用过Junit的一些测试经验,在测试用例出来后,测试的结果基本还是比较符合预期的.。
2. 是否进行了正式的验收测试？
没有正式的验收测试
3. 团队是否有测试工具来帮助测试？
有的，前后端接口测试使用firefox、vue-devtools。单元测试、接口测试使用了JUnit、Jmeter
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？
没有进行压力测试
5. 在发布的过程中发现了哪些意外问题？
没有什么意外问题
七，团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
我们小组是组长自愿发起，6+3组成的。前后端的人员确定都是通过部分人员先行选择，剩余人员进行补充的方式。前后端的分组是由组长决定的（一个后端配备两个前端），模块和功能点也是由组长决定并分配的。
2. 团队成员之间有互相帮助么？
有的，我们小组组内氛围很好，我们有共同的目标，遇到困难，会互帮互助。无论是前端还是后端，还是前后端交接，遇到问题，我们都会一起讨论，相互请教，共同解决
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
加强沟通交流，如果有解决过类似问题的组合，会相互请教。每天的任务记录，和站立式会议，就是我们解决问题的最佳时间，这个时间我们会讨论交流遇到的问题和困难，
八，总结:
1.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
目前处于规范阶段
2.心得
| 队员 | 心得 |
|---|---|
| 康伟泽 | 这次的alpha冲刺让我认识到了做项目是一个巨大的工程，让我深刻认识到了一个项目开始编码前系统设计的重要性，设计阶段没有做好，到后面实现的时候会出现一堆问题。冲刺前学习不够积极，学的慢，吸收慢，太晚写代码了，导致与后端对接拖后了，对接的时候又出现了好多问题，这又加大了工作量。能看到大家积极学习新知识，尽自己最大努力完成任务，我觉得这就是团队的魅力，不能因为个人拖累整体。同时，这次作为组长，在管理团队方面没有经验，管理团队做的不好。 |
| 林明昊 | 这次的冲刺让我深刻地认识到编码前的各种准备工作有多么重要，如果之前的设计可以做到近乎符合最终结果并且有一套好的编码规范的话，编码过程可以轻松很多。自己的技术能力也存在不足，有些东西花了很久的时间学习，也有些东西没做出来。对接过程中也出现了很多问题，比如文件的上传下载。这次冲刺也学到了很多新知识，受益匪浅。 |
| 傅江峰 | 这一次α冲刺，深深体会到了设计的重要。以前没明白为什么设计如此重要，这次总算是明白了。刚开始时，以为一切都设计好了，只要按部就班，就不会出什么问题。结果就遇到了这样的问题：中期时遇到一些不太合理的设计，我选择不改变原来设计的数据库，在后端代码中多做一些处理。但是后一天，在会议是讨论到这张数据库表的问题，在我们的讨论之下，还是改变了数据库表结构，造成的后果就是原来写的那些相关代码就“翻新”了一遍。虽然花费的时间不是太长，但是这其实是设计的时候可以避免的。还有对每天的心得体会，我的态度不够端正，这一点要反思，但其实在这10天的冲刺中，很多天是没什么心情去写什么心得的，想的是“有那时间不如休息一下”。不知道工作中真实的项目里有没有这东西。最后的就是关于对接了，对接过程中出了很多的问题，我们团队合作的能力还有待提高。 |
| 宋日荣 | 这一次alpha冲刺可以说是感触良多，对团队合作开发也有了新的体会。从一开始摸索着搭建项目框架，再到具体实现样式和数据处理时发觉自己学的知识还不够，再到alpha冲刺最后几天的熬夜完成代码，每一部分都十分地令人难忘。通过这次项目冲刺，体会到了知识的实践的重要性，还有在前后端对接时及时的沟通是必要的。 |
| 李淇 | 这次的α冲刺目对我是一个很大的挑战，不仅要学习很多新的技术，还要学习如何与人合作完成一个项目，有很多天都熬夜到很晚。通过这次α冲刺，我意识到了团队之间的沟通很重要，有问题要多和团队反馈，与此同时我也非常感谢队友们对我的帮助。 |
| 张骁 | 历经这十天的冲刺时间，让我深深的感受软件工程的魅力，从学习，到运用，从前端，到对接。此次冲刺还有前面的设计等等，都让我清晰的感受着软件工程。此次冲刺，首先最想说的，就是感谢我的队友，这十多天的陪伴，，共事，你们孜孜不倦的工作精神感染到了我，总是能有耐心的帮助我解决我的问题，人生中的第一次集体凌晨代码生活也发生在了这次冲刺中，毋庸置疑，这是一次美好的记忆 |
| 王冠儒 | 不知不觉α冲刺已经接近尾声，历时十天的团队合作让我感触颇深。这应该是我参与过的时间最久，人数最多的多人协作活动。这次无疑是一个难忘的记忆，感谢我的队友们，谢谢大家互相帮助，在我遇到困难时细心帮助我，也感谢我们的组长，项目经理，大家都是这么负责才会有我们这次的成果。经过这次团队协作我意识到自己技术真的很是欠缺，以后这方面要多下功夫才行。这次我主要负责答疑讨论的前端界面。这次编程我遇到最大的困难无疑是用一种全新的方式vue来写前端代码，这种组件化的编程方式无疑让我适应了许久，也遭遇了许多难题。最终在查阅资料以及队友的帮助下算是完成了任务。通过这次组队编程，我发现掌握一门技术真不是看一天两天视频就能解决的，只有足够多的编程经验才能帮助自己更好的掌握。 |
| 陈鹏桢 | 这是一场持久战,开始之初没有意识到总结的重要性,所以在每天钻研完成自己的工作后感受到的更多是无力和成就感并存的状态,但是在第二天的工作中缺少之前的总结,中期时收到了来自老师的建议:"对待心得体会要写的更加具体一些",于是,抱着一定的怀疑态度将自己之前每天辛苦成果重新做了一番想法整合,确实开始发现了不同点,在这之后的几次冲刺中,可以明显感觉到渐入佳境,轻车熟路的氛围,虽然在沟通上和想法上仍存在和队友之间的与一些出入,但好的总结和好的经验是能提供相比于埋头苦干别有一番滋味的收获 |
| 黄隽芊 | 这十天的α冲刺生活，充实而紧张，把所有的工作合理的分配到α这十天的每一天。每日的工作汇报，小组会议，和填写小组心得体会，这都让我感受到α的魅力，合理安排进度，及时沟通交流，了解小组出现的问题和困难并加以解决，每天的工作都是一步脚印，团队和个人相辅相成，α冲刺让我学到了许多。 |
3. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
多使用代码管理工具，增加代码复审和代码规范的次数，来提高质量。
4. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
可通过组件的复用来提高，
5. 其它软件工具的应用，应该如何提高？
可以通过学习，查询来提高熟练度。用的多了，自然就顺手了。
6. 项目管理有哪些具体的提高？
通过开一些issue，来管理和记录功能实现进展。可以通过燃尽图和issue的完成情况和剩余情况方便的管理项目进展。
7. 项目文档的质量如何提高？
在写完之后小组成员一起审核，并提出意见更改，提高质量。
