团队作业6——复审与事后分析

团队作业6——复审与事后分析

Alpha 阶段项目复审

作业要求	团队作业6——复审与事后分析
作业所属课程	计科22级12班
作业目标	评审与事后总结

小组成员经过评审符合后，由复核人代表小组意见；

复审人：徐嘉炜

小组名称	优点	缺点	排名
嘿嘿哈哈！！！	1.团队作业博客完整的记录了开发的流程，态度十分认真；2.团队仓库 git 详细记录了开发的流程，开发可溯源，真实度与可信度高；3.团队项目的需求直击社会痛点，面向社会度高，项目立意较为深刻；4.测试反馈修复及时，测试样本多，覆盖面广；	1.可完善部署文档等部署方式，供用户方进行使用；2.用户方可能需要一定的性能门槛	1
三人成行	1.项目是一个具体的游戏，较为新颖；2.作业内容充分，能完整展示开发过程；3.开发难度性相对较高	1.团队 git 提交颗粒可更小，便于 bug 出现回滚等操作提高容错	2
OJteam	1.项目代码分层合理，具有详细的说明文档，提供良好的部署便利性；2.内容新颖，能吸引用户；3.简介的界面交互，使用起来较为方便	1.内容可能面向的用户名较为狭窄，若对编程兴趣不大的用户很难吸引；2.用户注册后若忘记自己账户密码没有提供找回方式；3.测试量可能还需要增加，提高项目稳定性	3
管你对不队	1.内容新颖，实用性强，能满足用户的兴趣；2.内容广泛，短视频领域可以包含较多方面的信息，能快速捕获用户喜爱；3.合理的适配审查机制，有利于维护网站内容	1.推荐算法不准确，可能与用户的期望相差较大，较难满足用户需求；2.用户注册后若忘记自己账户密码没有提供找回方式；3.用户量大情况下可能出现服务器负荷	4
DreamToByteDance	1.项目功能较为完善，能满足绝大多数用户需要；2.项目仓库代码逻辑清晰、注释齐全，可见团队成员及其深厚的代码功底	1.界面交互可以再丰富些，较为简洁了；2.项目运行部署可以添加适当指导或说明	5
*铜锣湾代码王*	1.界面引导清晰，有利于用户的使用；2.项目仓库代码逻辑清晰、注释齐全，可见团队成员及其深厚的代码功底	1.前端样式可以再深究下技术，提供更丰富的交互界面；2.可以多为用户量增加时对并发能力的提升；3.可以尝试开发更多的功能，当前功能较少	6
P人大联盟	1.内容较为创新，从一个独特的点创作项目；	1.项目体量庞大，部署需要一定的性能配置，不能满足绝大多数用户的考量；2.部署方式较为复杂，会让用户觉得不易用，吸引力下滑；3.使用的门槛较高，即使说明较全面，用户也不易操作使用（主要点是用户不方便使用）	7
汪汪队	1.界面元素较为丰富，图片和其余组件分布合理；2.git 提交粒度十分详细，能体现出开发的过程；	1.项目的部署方式最好能够发出统一的脚本或包进行部署，步骤流程稍微有些多了；2.同等功能的项目较多，可能缺乏些竞争力；	8
我们都队	1.界面引导相对完善，有助于用户使用；2.对用户的身份保护相对完整，有忘记密码功能；	1.功能元素相对简洁，可以适当添加下功能；2.项目运行发版较为麻烦，需要使用源代码编译，容易泄露；	9
按时睡觉队	1.项目需求完成度相对较高	1.界面较为简单，可尝试使用更多元素的 ui 进行编辑；2.功能需求可以再相对拓展；	10
TPG NO	1.界面元素较为丰富，配色合理，使用感观好；2.对整体的需求把握到位，需求较为完善	1.团队的 git 仓库提交粒度可以更小，体现出开发的流程；2.考虑下用户忘记密码的情形，还有用户数多时并发量提升的系统稳定性；	11
Goodbye World	1.项目内容为二手书管理平台，能直击大学生群体的需求，容易融入用户	1.功能上略微欠缺，界面交互有少许生硬；2.测试群体较小，缺乏线上稳定性；3.具体代码内容因权限无法访问，此处不做评价	12
数据流浪者	1.项目使用较为轻量，使用较为方便；2.使用时附带直观的页面和导航，给用户提供帮助	1.功能上可能稍微欠缺，可多添加些功能提供给用户；2.测试数据量较小，难以覆盖大部分用户使用情况；	13
菜鸟队	1.界面较为简洁，提供用户间沟通的平台	1.往期作业中没找到附带代码链接（可能是没看到），较难评价具体效果	14

事后诸葛亮分析

作业要求	团队作业6——复审与事后分析
作业所属课程	计科22级12班
作业目标	事后诸葛亮分析

• 事后诸葛亮会议照片

设想与目标

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

   该项目旨在为用户提供一个简便轻量级、满足日常音乐需要的音乐播放平台。市面上部分同类型的 APP 存在大量广告推广杂糅，既影响用户体验，又在一定程度上增加了用户设备的性能占用（包括内存占用、网络资源等）；本项目为扫清这部分的障碍，应运而生；

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

   原计划功能基本实现，除用户模块因时间与人力赶不上项目规模暂未实现;

   交付时间合理

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

   代码质量我们一如既往保持良好；

   团队开发的效率一直在线，每个成员都在自己的位置上奋斗；

   需求逻辑符合软件工程设计，需求分配合理；

4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

   用户量比预先数量稍少，对重要功能的接受程度与设想一致；

   团队目标总体距离目标接近；

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

   用户数量不是特别重组，在推广上欠缺策略；用户需求上调研充分，但实现的人力物力稍微缺乏，重来一次可能会着重添加功能开发的人力；项目迭代速率因人力缺乏稍慢，但迭代流程正常。

计划

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

   项目开展初，我们已计划充分，并且在项目开发的过程中都遵循计划；

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

   通过召开会议，团队成员们彼此面对面交流，分歧能在其中消除，并让团队成员有更多的想法和空间，最终走到一致认同的道路上；

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

   用户信息模块最后没能完成，其余都正常完成了；

   未完成的原因是：项目体积代码较为庞大，缺乏开发人力时间去完成该模块的开发与设计；

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

   部分额外的需求或许并不是用户的刚需，我们曾在这些需求上开发，花费了不必要的时间；

设计实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
3. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范

测试/发布

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

   是，团队测试成员对项目进行完整的用户模拟，将每个功能板块都予以点击使用，去测试项目的完整性和稳定性；

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

   有，完整的测试计划帮助我们观察程序中有可能潜在的问题或障碍；

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

   无，并没有什么自动化的测试工具能够模仿用户的日常使用去对项目进行测试使用；

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

   

   

   我们通过 Android Studio 中的 Profier 监测内存状态与 App Inspection 观察数据库情况、网络请求情况和线程情况追踪项目运行情况。

   通过这个工具，我们在实际开发过程中捕抓到一些内存泄漏情况，并及时予以改正；

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

团队各个成员都学会了在开发中找到自己的角色定位，并认准了自己的能力与贡献范围，共同协作进步；

学会基本的软件工程思想，对项目环境的搭建以及部署，掌握基本的软件开发流程；

如果重来一次，我们会制定更加严谨能落实的开发计划，实地考察好用户的需要，对症下药进行开发，以最大的开发性价比满足用户的需求；

总结

本次项目是一个挑战，更是一个学习的机会。尽管在团队项目开发时我们都各司其职，尽可能的完成好自己的任务，但还是难免会有查漏补缺；我们了解了软件工程开发的整个流程，深度体验其中，了解到开发程序只是项目中的一小环，更有的是项目需求的探索、测试流程等环节需要共同协助；今后我们在面对更多的挑战时，通过这一次的经历与经验，相信能更加得心应手；

团队贡献分

(顺序不分先后)

• 陈祥意（PM）：25分，为项目开发指定方向，了解并调查用户需求
• 陈祖民（UI）：25分，界面UI画手，提供精美图案
• 陈大锴（开发）：25分，项目具体逻辑开发一把手
• 蔡家显（QA）：25分，项目开发全期测试，提供了很多意见
• 林楦（UI）：25分，布局画手，整理团队布局层次，简洁代码发挥更大功效
• 肖商（QA）：25分，负责用户体验测试，及时为开发提bug，进行深度测试
• 徐嘉炜（开发）：25分，项目开发的查漏补缺，负责修复开发中遇到的问题