| 这个作业属于哪个课程 | 2020春|S班（福州大学） |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 团队名称 | 软工实践互动评价小组 |
| 这个作业的目标 | beta冲刺 |
| 作业正文 | |
| 其他参考文献 |
一、设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的项目是《软件工程实践》互动评价系统，要解决的是《软件工程实践》这门课程提交评分表的这个问题。典型用户和典型场景还是很清晰的。(因为我们就是) - 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基本达到目标。 - 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了。组员们对git工具的使用更加熟练了。 - 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
一致，更近了。 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果能重来的话，会把必要功能和拓展功能定义得更加清楚。
二、计划
- 是否有充足的时间来做计划?
有 - 团队在计划阶段是如何解决同事们对于计划的不同意见的？
如果有队员对计划有不同的安排，我们都会提出来，看看那个更加合理或者更加符合我们的项目进程，但其实这种情况挺少的。 - 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
基本做完了。 - 有没有发现你做了一些事后看来没必要或没多大价值的事?
如果说做了什么事后看来没有多大价值的事或者说意外的话，那可能还是体现在某些部分的设计上。比如当时看到mysql有json格式就拍案决定使用以及时间使用date格式，还有json格式嵌套的问题，都给我们带来了很多麻烦。后来我们进行了重新设计，优化了json结构，使用时间戳代替date，花了较短时间就完成了本来的任务，这其实很大程度都是经验上的问题，如果能有重来的话，一开始选择正确的道路又能节省很多时间。 - 是否每一项任务都有清楚定义和衡量的交付件?
否 - 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否，意外如上题。 - 在计划中有没有留下缓冲区，缓冲区有作用么?
有预留一定的缓冲时间，但开发基本在计划时间之内完成了，预留的时间做了一些结构上的优化。 - 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
之前缓冲区穿插在冲刺周期之间，以后应该会集中一点。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍，计划的制定可能会实际一点。
三、资源
- 我们有足够的资源来完成各项任务么?
基本有，如果学校报销服务器就好了。 - 各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务大概是通过难度和经验进行评估，精度不是很高，每个人的学习进度不一致，而且会遇到无法预期的错误。 - 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的资源不够。都是测试就是人工测试接口了，看到这份表格才知道有一些其他方式，还是经验上的不足。对于一些非编程资源还是有一些低估了，甚至对前端也低估了。 - 你有没有感到你做的事情可以让别人来做（更有效率）?
也许有，但是本次实践重在让大家得到提升，而不是效率高的人把事情全做了。 - 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果能重来的话会使用一些测试工具来帮助测试。
四、变更管理
- 每个相关的员工都及时知道了变更的消息?
有。 - 我们采用了什么办法决定“推迟”和“必须实现”的功能?
取决于实现难度以及时间是否充裕。 - 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
能够完成核心功能流程。 - 对于可能的变更是否能制定应急计划?
能，事实上有一些内容确实变更过。 - 员工是否能够有效地处理意料之外的工作请求？
能。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
变更最重要的是能够及时通知到所有人，我们通知其实挺及时的。
五、设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计就是在之前的作业安排的时候做的，我负责整体的设计，蔡鸿辉负责数据库设计，张增燊负责类图设计，然后我根据原型列出了需要的接口和一些设计规约，各组员完成自己负责的接口部分。设计之前有一些课程内容还没有接触到，所以不一定是合适的时间合适的人。 - 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计会有遇到模棱两可的时候，比如用哪种数据结构好，接口返回的格式应该怎么好，尖锐一点的问题我们就当场讨论了，其他问题我们一般会进行集中讨论，看哪种解决方案比较可行。 - 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
一开始的设计文档和现在有一定区别，区别产生的原因是因为一开始经验上的不足，设计时不够实际，也比较不清楚一些现在比较主流的解决方案。 - 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
我们小组项目有一个核心功能，就是定时任务，系统会在评分表截止时间到的时候自动统算每个小组和每个人的分数，这个功能产生的BUG最多，因为我们当初认为springboot框架好像有自带定时任务功能，事实上这个功能并不好用，后来我们使用了另一个框架来完成这个任务。发布后没有什么重大BUG。设计/开发的时候没想到是因为经验不足。 - 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审使用阿里的代码规范插件。 - 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果历史重来一遍的话，在一些功能设计上会一开始就使用一些主流的解决方案。
六、测试/发布
- 团队是否有一个测试计划？为什么没有？
我们小组开发的时候有一份接口开发测试情况表，上面有接口列表，以及每个接口的负责人，每个人完成和测试后要在文档上进行登记。然后前端进行连接测试，测试到接口出现问题的时候直接根据文档找接口的负责人进行改进。 - 是否进行了正式的验收测试？
根据作业要求完成了测试报告。 - 团队是否有测试工具来帮助测试？
后端用了postman进行接口测试。 - 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
暂无 - 在发布的过程中发现了哪些意外问题？
无，有预演过。 - 我们学到了什么? 如果重来一遍, 我们会做什么改进?
重来的话会使用一些测试工具。
七、团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
每个人的角色是自己选的，不一定人尽其才。 - 团队成员之间有互相帮助么？
我们小组成员之间交流的还是挺积极的。遇到问题也都有在群里讨论，大家也会互相帮助。 - 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
有问题在群里提出来，大家互相帮助，一起解决。 - 每个成员明确公开地表示对成员帮助的感谢：
- 许家诚：首先感谢所有组员们的积极配合，感谢蔡鸿辉为我分担了一部分工作压力，感谢陈茜帮我做答辩PPT。
- 陈 茜 ：感谢所有组员们的配合，每次及时将自己的博客部分发给我。感谢许家诚找的vue.js教程，对学习vue.js有很大帮助。
- 陈家祯：我感谢蔡俊对我的帮助，因为他帮助我学会了从前端接收body格式的数据并插入数据库的方法。
- 肖玮昊：我感谢许家诚、张增燊、蔡鸿辉对我的帮助，因为他帮助我在Json格式下提取数据。
- 张增燊：我感谢许家诚对我的帮助，因为我经常在群里提出一些对程序的疑问他都能耐心地回答，是一个很好的组长。
- 蔡 俊 ：感谢陈家祯，因为他在我对框架某些细节某些注释理解不够清楚的时候抽出时间为我解答，一起共同进步。
- 蔡鸿辉：感谢许家诚同学对我的帮助，因为他教了我如何运用定时任务框架quartz。
- 傅少华：我感谢许家诚对我的帮助，因为：因缺少vue开发的经验，写代码会觉得无从下手。通过借鉴项目中家诚同学在前端实现注册功能的代码，完成了学生管理、助教管理等页面的主要功能的实现。
八、总结：
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
可重复级(Repeatable) - 你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?
规范阶段，目前大家已经可以根据文档来完成各自的开发任务了，但是实现上还存在一些差异的地方，需要进一步规范。 - 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
技术有长进。 - 你觉得目前最需要改进的一个方面是什么?
测试上有一定不足。 - 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
可用的软件是衡量进度的主要指标，我们测试的一个主要指标就是软件是否可用，而不是某个模块的完好。
要做到简洁，尽可能减少不必要的工作，这是一门艺术。我们主要开发核心功能，避免做成大杂烩。
九、正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
我们之前代码管理质量其实还行。我们一开始让所有成员加入协作者，这样commit就不用频繁地去合并，然后大家直接在项目仓库部署本地项目，规定了commit之前要先fetch，然后有更新的话要在群里通知其他组员，然后每个人负责的文件比较少有交叉，通过这些方式来避免冲突。 - 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
我对我们目前的程序架构还算满意，不需要做什么大的改动。降低耦合度。 - 其它软件工具的应用，应该如何提高？
看情况。 - 项目管理有哪些具体的提高？
暂无。 - 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
学习一些工具的使用。根据后台管理系统来判断。 - 项目文档的质量如何提高？
多吸取教训。 - 对于人的领导和管理，有什么具体可以改进的地方？
给一些任务设一个ddl，偶尔催一下进度。 - 对于软件工程的理论，规律有什么心得体会或不同意见？
暂无。