Outfits——alpha阶段问题总结随笔
Outfits——alpha阶段问题总结随笔
1 设想和目标
一、我们达到目标了么？
-
前端
-
1、社区部分还有部分逻辑需要完善
- 原因：开发时间不足
- 改进：在β阶段优先完成此功能
-
2、我的版块UI样式以及交互逻辑还需要优化
- 原因：（1）开发时间不足（2）负责此板块的同学对界面编写规范不是很熟悉
- 改进：对安卓技术熟悉的同学进行页面的优化重构
-
3、由于成员在往github仓库中上传代码的时候没有修改好所有的bug，导致其他成员pull以后无法成功build并运行项目
- 原因：（1）没有指定完整、规范的github协同规范（2）对版本控制的理解不够深入
- 改进：在使用github仓库管理代码的时候，我们将会进一步规范push新功能的流程，采用创建issue来提出新需求或遇到的bug，新建分支来解决自己负责的问题或新功能并在完成后合并。
-
与后端的接口测试过于仓促，由于接口文档的不及时更新导致网络请求部分逻辑编写做了很多无用功、
- 原因：后端的接口文档管理有些混乱，未完全按照规范来实现
- 改进：督促后端完善接口文档，及时给出反馈
-
-
后端
-
1、算法框架部署部分未完成：java调用python文件时出错
-
原因：开发时间不够
-
改进：（1）在分配任务时，延长部署算法框架的开发时间（2）让已经完成自己任务的同学一起帮忙
-
-
2、没有进行压力测试
-
原因：（1）不知道用什么工具进行压力测试（2）开发时间延长，导致给予的测试人员的时间太短（3）没有制定详细的测试计划
-
改进：（1）向身边有测试经验的人多询问（2）应预留一个缓冲时间，（3）在项目开发阶段前，研究好如何制定一个详细的测试计划，让测试人员提前学习测试工具的使用
-
-
3、没有返回天气信息到搭配界面
-
原因：编写天气相关的工具类的同学分工时没有要求要写一个返回天气信息的方法，后来验收时发现了这个问题，但是开发时间不够了
-
改进：（1）编写返回天气信息接口的同学要提前向该同学提出这个工作请求（2）在计划中设置一个缓冲区
-
-
2 计划
一、是否有充足的时间来做计划？
- 在冲刺开始前，我们具有充足的时间来制定计划。但是经过alpha阶段的冲刺后我们发现，如何去指定一个可执行的计划，大多数人都不太清楚。
二、团队在计划阶段是如何解决同事们对于计划的不同意见的？
- 我们小组采用的是整体评议制度。
- 在计划安排初期，前后端的组长会分别组织会议安排任务下放，并直接设定任务完成的时间点，先行拟定负责人后，再开会明确该负责人能否参与任务，在小组开会时就解决这一问题。
三、有没有发现你做了一些事后看来没必要或没多大价值的事?
-
1、安卓端将网络请求逻辑单独放到了一个工具类中，导致在处理返回数据时造成了一些麻烦
- 原因：对网络请求框架的理解不够深入
- 改进：β冲刺阶段的网络请求逻辑采用新的写法，不放在工具类中
-
2、没写工具类的时候，大家重复写了同样的方法。但是工具类写好后，还要删除掉原有的代码，调用工具类的中封装好的方法
-
原因：分工时候没有将可复用代码编写的优先级提前
-
改进：分工时先设计可复用类的名字以及输入和输出，大家可以直接使用还未完成的可复用类，这样虽然做不到在写完代码后能直接测试，但是可以做到并行开发。
-
-
3、两个Dao都写了同样的数据库操作，产生代码冗余
-
原因：Dao是按模块分给不同的人进行编写
-
改进：Dao应该和Model一一对应，在进行连表操作时也应新建一个Dao
-
四、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
- 前端
- 衣柜以及搭配主界面的逻辑比较复杂，嵌套布局较多，花费了大量的时间以及精力去编写，导致进度有些落后于计划。并且后端的接口完成时间比较晚，导致网络请求逻辑编写比较赶、比较仓促，主要因为接口文档编写比较不规范。
- 后端
- 项目开发前期按照计划进行，但是在项目后期前后端对接的时候发现前后端接口有挺多对应不上，然后就是返工修改，这导致项目总体完成的时间推迟了，也导致测试的时间变少。前后端接口不能完全对应上，这个风险没有完全估计到，因为接口文档的确定工作没有完全做好。
五、在计划中有没有留下缓冲区，缓冲区有作用么?
- 没有，有的任务被安排在冲刺的最后一天，比如测试任务。缓冲区是有作用的，它可以压缩每个任务的完成时间，能提前暴露出项目的不足，这样就能提前修改，提高了项目的目标完成率。
六、将来的计划会做什么修改？（全体）
-
1、在计划中添加缓冲区
-
2、明确细分任务完成状态
3 资源
一、我们有足够的资源来完成各项任务么?（整体）
- 我们小组具有开发经验充足的同学，在代码开发和学习资源上并不缺乏。
- 然而在时间资源上，我们注意到还是需要合理调控任务完成的性价比，尽量做到让有能力的同学高效的完成任务。
二、你有没有感到你做的事情可以让别人来做（更有效率）?
- 1、
-
某同学：在前一次冲刺中，我担任了测试负责人，这部分我觉得给别人做可能效率更高。
-
原因：本人个人原因不会将测试分成各个模块然后分配给他人，导致测试效率低下。
-
改进：选择新的测试组长，让我负责做一些测试工作，而不是安排测试工作。
-
三、各项任务所需的时间和其他资源是如何估计的，精度如何?
-
在分工之后，询问每个任务相关的负责人，按照他的时间安排以及开发经验进行估计。大多数的任务估计的时间都比实际开发的时间要短。
-
可能原因：相关任务的负责人在估计自己之前没接触过的任务时，没想到学习也需要较多的时间成本，而且任务第一次的质量往往不高，需要频繁的反工
-
改进：对没没有开发经验的任务，适当延长完成时间。
4 变更管理
一、每个相关的员工都及时知道了变更的消息?
- 是，平时开发和生活都距离比较近，比较好联系，而且在每日SCRUM会议里，大家都有及时反馈自己的工作进度和遇到的困难。
二、 员工是否能够有效地处理意料之外的工作请求？（整体）
- 略
5 设计/实现
一、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 在项目开发阶段前，不同的模块根据每个人对该模块的熟悉程度和技术栈进行分配。
- 设计工作就放在具体编码开始之前进行设计，由前端组长，后端组长以及负责原型设计的总负责人一起进行设计，将讨论的人数降低，同时又具有话语权，能在设计完成之后带领其他组员进行设计，使设计具有可行性。我认为是最合适的人和相对合适的时间了。
二、设计工作有没有碰到模棱两可的情况，团队是如何解决的？（整体）
- 略
三、 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
-
（1）在测试工作中有用到单元测试，用IDEA的JUNIT工具对项目的一些工具类进行了单元测试。利用了IDEA所带的 JUNIT中的ContriPerf对后端DAO层进行性能测试。它的测试结果能反应DAO层编写的正确性，所以是有效的。
-
（2）在设计时用到了UML，以StarUML为工具构造类图、顺序图和泳道图。开始的UML是用processon绘制的，类图的箭头只能集中到一个点，不够直观，starUML重绘后比较直观清楚。UML文档本身的内容不需要更新。
四、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 因为功能还有没完成的，到最后一天还在改代码，所以在最后没有进行总的代码复审。没有严格执行，大家在编写代码时的想法是先写代码，能不能完成功能是最重要的，完成之后再补注释。
五、什么功能产生的Bug最多，为什么？
-
存储图片到服务器时产生的Bug最多
-
原因：（1）服务器是Linux系统，文件路径和我们平时用的Win10不同，由于测试时是在Windows系统上测试的，导致插入数据库的路径夹带了反斜杠（2）springboot框架默认上传文件最大为10MB，一次上传多张图片时会超过最大限制，导致服务器一直报错
-
改进：（1）拼凑路径时将反斜杠改成正斜杠（2）修改springboot框架的上传文件大小限制
6 测试/发布
一、团队是否有一个测试计划？为什么没有？
- 后端：没有，因为后端对测试的重视程度不够，觉得只要用postman测试接口成功了，大体的功能就完成了。
二、是否进行了正式的验收测试？（整体）
- 略
三、团队是否有测试工具来帮助测试？
- 有，使用IDEA自带的JUnit进行单元测试，使用Postman进行接口测试
（改进计划，使用自动化测试工具，还需补上）
四、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 略
7 团队的角色，管理，合作
一、团队的每个角色是如何确定的，是不是人尽其才？（整体）
- 略
二、团队成员之间有互相帮助么？
- 有，在每日SCRUM会议里，团队成员都有汇报自己遇到的困难，有办法解决这个困难的人现场就会提出解决方案，并且在会后进行交流。
三、当出现项目管理、合作方面的问题时，团队成员如何解决问题？（整体）
- 略
