熬夜会秃头——alpha阶段问题总结随笔

这个作业属于哪个课程	2301-计算机学院-软件工程社区
这个作业要求在哪里	团队作业—beta冲刺+事后诸葛亮
团队名称	熬夜会秃头
团队项目	多场景应用的对象存储平台
这个作业的目标	总结并分析alpha阶段存在的问题
团队置顶随笔	熬夜会秃头——Beta冲刺置顶随笔

一、设想和目标

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

当今时代，随着互联网应用的爆炸式普及和应用，人们每天上传海量的照片、视频、音乐等，全球每天新增亿万级的内容，其中80%为非结构化数据。另一方面，随着企业应用的丰富多样化和企业运营时间的增长，企业数据越来越多，且数据类型越来越多样化，企业对文档、图片、音频、视频等非结构化数据的管理需求也随之增加。非结构化数据量迎来的爆发性增长，且一些数据需要长期存储，传统的存储管理方式如SQL数据库存储已经不再适用。因此，需要有更强大的底层存储能力来应对海量非结构化数据的存储需求。
　　对象存储具有GB价格低廉、扩展能力优异、对节点故障具有高度数据弹性和持久性等优势，对象存储在数据归档、数据备份和二次数据应用等场景有着巨大的应用价值。
　　本项目旨在创建一个基于本地文件系统的对象存储平台，该平台能够进行数据归档、数据备份和二次数据应用，并以尽可能少的存储空间存储更多的数据。

2.我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？)

1.原计划功能已完成了大半，具体内容可见alpha阶段总结随笔。
2.已按照原计划交付时间交付，并完成了alpha阶段答辩。

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

1.和上一个阶段相比，软件的制作已经初具规模，不再只是单纯的一个概念。同时因为加强了分工合作的关系，再加上每天召开的站立式会议，小组的各个成员对于项目的理解也加深了更多，而这对最终产品的质量的提升极为有益，因为大家知道了自己要做什么，怎么去做。
2.前端的工作由于还在初学阶段，因而具体的成果都是伴随着知识的加深而提高，在有了原型设计作为前期准备工作的前提之下，ui界面的总体效果要更规整，更美观了许多。后端在组内大佬的坐镇之下几乎成为了绝对领域，不过学无止境，整体质量依旧提升了10% 。

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

1.加强代码规范的审查。毕竟大家很少经历过如此大规模，系统性的项目，因而在编写代码的时候依然保留了一些个人习惯，这导致在进行测试时出现了纰漏，延缓了测试工作的进度。虽然这个问题可以通过沟通来解决，但能不浪费时间还是不要浪费时间更好。
2.在进行分工的时候需要考虑得更加细致，避免出现任务分配不均的情况。由于一开始错误估计了前端各个功能之间的任务复杂度，因而导致在人员分配上出现了不合理的现象。虽然最终还是赶在时限之前完成了大概的任务，并没有产生太大的后果，但是为了确保之后工作的有效进行，这一点最好加以改正。

二、计划

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

多亏了其他科目的作业和考试，因此在alpha阶段并没有太多的时间进行计划，也确实在这上面吃了些亏。

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

开会的目的就是探讨不同意见的可行性以及之间的联系，如果产生了较为明显的分歧，则是会先做一个简略的示意图或者是小的demo，再有投票最终决定要使用哪一个方案。

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

只能说百分之九十九完成了，至于剩下的百分之一则是因为工期太紧的缘故，毕竟大家都挺忙的。

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

没有发现。

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

对于后端，已经确定好的功能自然需要严格的定义，毕竟软件的根本在此，不可疏忽，而判断的标准自然是一开始设立的目标以及测试文档所注明的。至于前端，由于前端的价值更多在于好看的界面和良好的交互体验，因而这一块并没有严格的标准，全靠用户自己的体验。当然，基本的功能肯定是不能出差错的。

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

在进行测试的时候因为代码规范的关系出了些差错，导致测试的工作遭到了延误。这个风险其实有预料到，只不过大家一开始没太把这当回事，没想到后果居然还有一点点严重，下次是不能再犯了，至少也要多沟通才行。

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

有留下缓冲区，实际上也确实在项目进度遭受阻挠是发挥了作用。但是缓冲区实际上能发挥的作用也有限，真的遇到大型bug的时候多半还是得靠加班。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

缓冲区这个词说的倒是蛮高大上的，实际上在我们这种小作坊里，万一真的遇到什么情况的话那肯定只能加班啊。
至于接下来的计划，由于快要进入到考试月了，所以在项目的进度上得加快一些，能提早完成尽量提早完成。

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

人类从历史中学到的唯一教训，就是人类无法从历史中学到任何教训。虽然从这次实践里收获了不少经验，但是计划赶不上变化，一个问题的修改可能会引发更多的问题。如果说下一次要做什么改进的话，那就是加强沟通吧，很多问题其实一开始就能解决了。

三、变更管理

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

得益于聊天软件的强大，大家都能够通过群聊及时地收到变更消息。对于未及时回复的组员则是采取私聊以及线下见面解决。

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

设计文档之于软件工程亦如宪法之于所有法律，而若是设计文档里没有提到的东西，则是通过开会进行解决。

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

完成了所有事先预期的功能自然是做好了，而若是一些无关紧要的功能没有做完，则根据目前剩余的时间以及人力资源再做决定，毕竟发布了总比没有发布好。

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

技术类的难题如果无法解决，那就只能通过开会的方式对部分功能进行取舍。如果是工期太紧的原因导致项目变更，那么就通过的人员调度尝试进行解决。在大多数情况下，沟通就能够解决问题。

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

大家都是6+3+3上来的，抗压能力还是有一些的。

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

能不开的会尽量不开，大家都有自己要做的事情，如果开会只是说一些废话的话则完全没有意义。

四、团队的角色，管理，合作

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

由于整个项目是围绕着组内大佬的知识储备运作的，因而最重要的后端部分一开始就已经解决。至于剩余的后端以及前端部分则是先划分好工作内容之后，由组员自行选择决定，

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

如果没有大佬的话，根本就不会有这个家（）。很难想象一个小组如果组员之间不互相合作的话该会是怎样的一副光景。
平日里交互最多的其实就是隶属同一任务的组员，毕竟有很多工作内容需要相互共同才能更进行。另外，和家里找不到的袜子老妈一来就能直接找到一样，有些问题自己搜索无果之后，找别人来帮忙立刻就能够得到结果，真是奇妙的世界现象（）。

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

沟通，再不济就开会，这两个词已经出现很多次了。有些问题不及时提出就会发展成更大的问题，这在无数次实践之中早已验证。

五、设计/实现

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

一个项目最开始的工作当然就是设计，在由组内大佬牵头之后，剩下的所有人都参与了设计工作。合适的时间自然谈不上，因为最早开始的工作就是这个，至于合适的人，其实一万个读者就有一万个哈姆雷特，很多好的想法往往来自于灵光一现，并不存在有谁更适合这一说。

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

模棱两可这种情况其实还蛮少见的，或者说是根本没有意识到。至于那些有着细微差别的设计，则往往需要通过实践来确定哪一个更好，这种情况下就需要先围绕问题设计出一个简单的demo，然后再有剩余组员进行评判。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

由于在先前的个人作业有用到单元测试，本学期的其他课程也有学习到UML，所有这两个工具实际上还是发挥了作用，尤其是UML能够更好地帮助组员理解项目的功能。在设计阶段还使用了Axure进行了原型设计。

4.什么功能产生的 Bug 最多，为什么？ 为什么我们在设计/开发的时候没有想到这些情况?

uniapp发送请求的bug是最多的，因为uniapp自带的uni.request不能发送formdata格式的参数，以及在app端没有自带的方法可以选中系统文件（只能选择图片或者视频），选择文件的方法只能去插件市场下载，但是市场上的大多是不兼容安卓13或者不兼容app的插件，好不容易遇到一个插件可以兼容任何端口的，居然要添加各种代码依赖，更不用说后面做大文件分片上传中MD5的进制问题以及分片逻辑了。因为之前没有相关的开发经验所以没有想到有这样子的情况

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审主要由非此代码编写者来复审，即交叉审查。这一点其实没有做到位，在面对一些不理解的问题，以及对于不符合代码规范的代码时，代码复审人员并没有很好地履行职责，进而导致在测试阶段出现了问题。这点需要多加注意。

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

任何事物的存在都有自己的道理，例如代码规范。虽然代码规范在现阶段可能存在感不是很强，也不是很重要，但既然有相关的规范，那我们最好去遵守，否则一时的偷懒可能会带来无穷无尽的麻烦。

六、测试

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

有测试计划，甚至在开发的过程中，无时无刻不在进行着单元测试。

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

在阶段的收尾环节，专门进行了一次大型的测试以检验前端的逻辑和后端的接口功能。

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

前端测试采用jest，后端测试采用apifox。

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

总体上只考虑了覆盖率和压力测试，并且覆盖率的测试并不是很系统。测试工作的主要目的还是在于应付一些不太常见的现象（因为常用的功能在代码编写阶段基本都已经单元测试好了）。

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

要提早做计划，并做好合理的安排，尽早进行测试才可以发现问题。