| 这个作业属于哪个课程 | 2020春|S班（福州大学） |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 团队名称 | 学长帮帮组 |
| 这个作业的目标 | Alpha阶段问题总结 |
| 作业正文 | alpha阶段问题总结随笔 |
| 其他参考文献 | 暂无 |
一、计划
-
预计划
| 时间 | 后端 | 前端 |
|---|---|---|
| 4.26 | 熟悉Pycharm的基本使用，阅读代码规范 | 熟悉Android Studio的使用，阅读《第一行代码》 |
| 4.27 | 数据库的构建以及环境配置 | 完成登录 注册 找回密码等基础功能 |
| 4.28 | 完成注册、登录、找回密码等基础功能 | 完成认证 学业情况 笔记模块布局 |
| 4.29 | 完成认证、获取成绩接口、笔记模块等基本功能 | 完成修改头像 个人中心 |
| 4.30 | 完成获取头像、获取资料等用户基本操作接口 | 完成发布笔记 查看笔记 我的笔记 辅导模块布局 |
| 5.01 | 完成笔记模块的基本功能以及辅导模块的初始化构建 | 完成发布辅导 查看辅导 我的辅导 |
| 5.02 | 完成预约等基础功能 | 完成辅导预约 |
| 5.03 | 完成辅导模块所有功能 | 完成查看辅导记录 辅导评价 |
| 5.04 | 迭代更新完善接口代码 | 完成辅导列表 辅导搜索 |
| 5.05 | Alpha版本程序测试 | Alpha版本程序测试 |
-
每日进程是否与预定计划吻合，当日任务未完成的原因？
根据alpha阶段的每日站立式会议汇报，我们组的每日进程与预定计划大部分吻合，这是因为组内在此之前已经明确分工了，每个组员在拿到任务之后立即投入状态，一般都能在deadline之前完成自己的模块。
其中有一些模块细节没有按时完成，追其原因是组内在分配任务是没有客观地预估某个模块的工作量，并且后端用python编写，组员在新技术的应用上经常遇到困难，需要查阅资料或者寻求组长帮助，这也是一个重要原因。
另外测试阶段也耗费了比预估更多的时间，是因为没有考虑到测试工具的学习以及测试文档的编写。
二、任务分配
-
alpha阶段的任务是怎么分配的？
我们在项目初期就已经确认了前后端分离的模式，并根据组员的意愿进行分组，前后端再各选出一个组长。
在alpha冲刺阶段由前后端组长划分任务，然后组员自行领取，根据任务的工作量和难度分配贡献比。由于两位组长都是项目经验比较丰富的同学，能更好的把握任务分配的粒度，不会出现某项任务过难或者过于简单的情况。
同时，组员根据自己的工作能力和所掌握技术选择自己擅长的模块。这样的好处是在具体实现的阶段，不会出现不感兴趣/任务难度与自身能力不匹配的情况。
-
不合理性
- 一些组员比较内敛，没有匹配到适合自己的模块，又与组长组员缺少沟通，导致进程跟不上。
- 组员缺乏项目经验，在采用新技术的时不能很好的学以致用，出现了困难问题只能找组长帮忙，导致了组长任务过重的情况。
- 整体积极性不高，出现问题的第一时间没有沟通解决。
-
启示
前后端组长不要给自己分配给过多的任务，因为要抽出较多的时间进行团队的管理。
把每个人每段时间要做的任务写成文档，该文档最好是由任务的执行者来执笔，因为很多时候你给组员交代任务的时候，他看上去是听懂了（他自己当时也认为是懂了），可是做到中途的时候，才发现是似懂非懂，模凌两可，这时候他估算的时间自然也就不可靠了，整个项目的进度自然就比计划的慢了。
每日例会时应该让每个组员都有发言汇报的机会，发言内容为自己的当日计划是什么，实际完成度如何，哪些地方需要其他成员帮助，最后进行简短总结。这样一方面起到互相监督的作用，组员可以对比自己和其他人的任务进度/完成质量，从而进行自我调整。另一方面使得每天遇到的困难都能及时曝光解决，不会出现问题堆积的情况。
三、资源
-
人力资源
在人力资源方面，由于一开始的随机分组策略，每个小组是由8-9个人随机组队，人员的任务按照先意愿，后调剂的方法分配，组长根据本组的选题和开发需求确定前后端的人员分布。
有几个同学偏向于前端的开发，但由于前端意向的人数众多，所以有两个同学被调剂到了后端。之后的开发都跟随各自的组长进行，而前后端的每日任务由前端组长和后端组长进行衔接之后制定。
在人员分配的部分较为合理，每日任务也稳步推进。 -
软件/硬件资源
虽然由于疫情原因无法回校，但本组成员放假时均有将自己的笔记本电脑带回家，家中网络情况也十分稳定，所以硬件资源满足。而对于相关的软件资源，前端组长分享了《第一行代码》，后端组长也分享了《Flask Web开发》等相关资源供组员进行借鉴学习，之后也参照着《构建之法》进行软件管理。
所以在软件/硬件资源方面较为充足，组员互帮互助，项目循序渐进。 -
经验教训
在开始冲刺之前应该更早地让大家进行基础知识的学习，尽量在alpha冲刺阶段更完美的完成制定的计划。
四、具体实现
-
设计
- 原型设计由小组对APP功能进行商讨后由负责原型设计的同学设计
- 数据库设计由后端同学进行设计
- 接口设计由前端组长和后端组长商量设计
- 模型设计由前端小组进行设计
-
代码复审
- 由于代码规范在编码之前制定，所以组员在编码期间都有遵守相应的代码规范。
- 代码复审方面是由组内成员进行合作互审，但由于alpha冲刺阶段对该方面重视度不够，所以没有进行规范的代码互审，在之后的beta冲刺阶段会加强对该方面的重视
-
经验教训
原型设计较为粗糙，而之后的设计文档编写较为简陋，导致在开发过程中还经常修改原型与数据库的设计，这是十分不好的习惯。之后应该注重一下设计文档的编写和原型的精确度，以便之后开发工作的顺利推进。
五、测试/发布
-
测试
前端界面/功能测试工具为Android Studio虚拟机/真机。后端用Postman测试接口。目前组内已经完成了用户模块、辅导模块和笔记模块的测试，其余模块需等实现后才能进行测试，测试文档随时更新，发布在：
在alpha冲刺阶段测试主要是寻找前端不适配问题以及一些界面布局方面的问题。后端接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。发现问题的话，提交给对应的组员进行修复。
-
目前发现的bug：
- 发布辅导信息无效，界面不显示（已修复）
- 用户笔记中插入的图片不能显示（已修复）
- 下载附件失败（已修复）
- 聊天记录退出清空（进行中）
- 界面不适配（进行中）
本次测试工作安排的人员较少，并且对测试工具不熟悉，未能在预期时间内完成。
-
发布
-
服务运行后,客户端无法访问服务端,提示超时
解决方法:进入阿里云控制台,将服务端口加入安全策略中开放访问
-
运行提示模块未找到
解决方法:使用pip安装缺失的依赖
-
六、个人总结
- 曾宏健：编写代码的时候要更加细心，要加强与后端的沟通合作
- 陈志达：团队合作才能更使开发更加效率，应该加强软件项目管理
- 郑小华：不仅要多学习Android知识，更要注重团队合作，原型设计也应该加强
- 李康华：在巩固基础、学习新技术的同时更要多加实践才能深入理解，每个人都是团队的一部分，要注重个人对团队的影响。
- 王玉珊：拿到任务后要做好时间管理，遇到问题第一时间寻求组员帮助
- 何翱翔：写代码要细心，代码复审环节应该加强
- 林琳：熟能生巧，注重细节，数据库设计应该更加完善
- 林轶凡：知识要多学习并且多运用才能更好的掌握，团队协作才能使项目稳步推进
- 沈明炜：在开发过程中要安排好时间，提前进行学习，在开发中熟练使用，文档编写也是十分重要的
七、改进
-
代码管理
如同alpha冲刺阶段那般，要求组员开发过程中对代码规范进行熟读并应用，改进自己的代码风格，打规范的代码；而代码复审方面，是我们团队需要加强的一部分，我们此次将采用组内成员合作轮流互审的方法，以求代码风格统一。
-
程序架构
在beta冲刺阶段，我们组打算使用MVVM架构进行软件重构,这样能够有效降低项目中的代码耦合,更有利于团队合作开发。
-
工具应用
部分组员对于软件开发工具的应用和软件项目管理工具的应用还不是得心应手，在开发代码的过程中还在不断地查询相关的知识，所以在此次beta冲刺阶段我们将加强组员之间的交流，在每日例会中交流软件应用的心得，以免有些组员重蹈覆辙。
-
项目管理
pm将与前后端组长一起推进项目进度，分工合作，携手前行。
-
用户数据
在项目跟踪用户数据方面,考虑接入友盟统计来实现日活周活等数据
-
文档质量
关于文档质量的提高，我们组主要是想通过pm的“质检”来提高文档质量，将任务截止日期设置得靠前一点，留给pm足够的时间检查文档并督促组员进行完善。
-
人员管理
pm、前端组长和后端组长相互合作，为任务设置deadline，并督促组员完成任务。
-
心得体会
此次冲刺让我们充分体会到了40-20-40规则，即在整个软件开发过程中,编码的工作量占20%,编码前的工作量占40%,编码后的工作量占40%。前期的设计阶段留下的不足导致编码阶段十分被动，这让我们感悟到设计阶段的工作更应该审慎完成。
八、会议截图
