| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/2020SPRINGS/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/2020SPRINGS/homework/10784 |
| 团队名称 | 知社 |
| 这个作业的目标 | 总结本次 Alpha 冲刺的问题 |
| 作业正文 | https://www.cnblogs.com/zhishe/p/12945239.html |
| 其他参考文献 | 项目管理之事后诸葛亮会议 |
一、计划
alpha 阶段的计划如下：
-
第一阶段：前后端各自根据 API 文档开发
day task 4.25 首页及接口 4.26 社团管理及接口 4.27 社团活动及接口 4.28 各种申请及接口 4.29 各种审核及接口 4.30 社团公告及接口 5.1 附件管理（文件、图片） 5.2 权限管理 5.3 code review 5.4 refactor -
第二阶段：前后端接口联调
day task 5.5 测试用户、社团、申请接口 5.6 测试活动、评论接口 5.7 测试其余接口 -
第三阶段：总结本阶段进度与计划下阶段任务
可以看到，我们的联调开始较晚，带来的风险较大，之前并没有进行前后端的整合，不过由于项目还是稳步推进的，因此最终的联调成功也是水到渠成的。不过，接下来，我们也会对计划多做一些审核，避免出现这种高风险事件的出现。
同时，在项目初期，并没有统一好 GitHub issue 的使用，带来了前后端沟通上的不便，也幸亏及时调整，在接下来的 beta 冲刺中，我们依然会使用 GitHub issue 作为 feature/bug tracker。
二、资源
首先说说人力资源方面。我们项目的分工主要是采用”自助“的方式，虽然这可能导致前后端人力不均，但是我们是比较幸运的，前后端人数大致相当。这样的一个好处是：大家都做自己熟悉的任务，效率也会比较高。
虽然我们的进度总体上是比较客观的，GitHub 的提交次数也是相当之高（前端 220+，后端也是 220+），但是人员的贡献比出现了极大的不均衡，这说明人力资源的分工还是存在一定的问题，包括：
- 有些成员的项目经验不足，不能及时调整负责的模块；
- 有些成员能力可能较强，但是分到的任务反而较少
这就导致了项目的进度没有达到最大值，成员没有发挥出自己的最佳状态。
这一定程度上可能和这几个方面有关：
- 随机组队，和陌生队友一起组队，不好意思和大家交流；或者说积极主动性不够；
- 技术栈不熟悉，虽然有提前去看了项目用到的相关技术，但实践操作还是不够得心应手；
- PM 没有对团队分工做出及时调整，没有对组员进行良好的沟通；
这些问题应该是项目中的拦路虎，只有把这些问题最小化，我们团队的效率才可能最大化。
其次是项目资源。项目中用到了一台远程服务器，用于 MySQL 远程数据库和 Redis 数据库，运维方面做得还是不错的，但由于有时候没有及时部署最新版本，导致最新的测试总是无法上线。这个问题可能要后端方面去解决：如果提交了比较重要的 feature 或者 patch，后端开发人员应该及时提醒运维部署后端项目到远程，方便前端开发人员的接口测试，不过这样也增加了沟通成本和运维的工作量。很多时候只能做个折衷，不能尽善尽美。
三、设计和实现
我们的设计是在系统设计和数据库设计阶段完成的。
然而，我们的最初设计考虑不周，很多细节问题并没有考虑清楚，导致代码构建阶段还频繁变更数据库表结构，这在软件开发中真的是犯了大忌！接下来的 Beta 接口，对于具体的业务，我们会对设计进行认真复审后再进行编码，减少编码阶段的问题。
说到构建阶段的单元测试，我们的单元测试开始的比较晚，这个一定程度上需要 PM 背锅：没有事先考虑好构建阶段需要做得任务。不过，由于我们的冲刺开始时间较早开始（4.25），因此后面的缓存时间确实是比较充裕的，因此，这个问题也很快得到了解决。
我们项目中遇到的一个大问题就是权限管理模块。刚开始没有考虑到前端复杂的权限切换：用户在不同的社团内的权限可能不同（社长、社员），后端很难及时响应前端的角色切换。搭建项目时，我们直接上 Spring Security 框架，以为这就完事了，然而，在项目中期的时候，发现切换问题确实很难通过框架实现。最后，我们还是乖乖地用了 Spring AOP 对需要权限的接口加上注解，手动处理这些权限问题。这个问题也给我们敲响了一个警钟：凡事预则立，不预则废；框架固然强大，还是需要开发者的灵活使用才能发挥最好的效果。
我们比较欠缺的是代码复审。不过，项目组中似乎没有人想主动接手这个任务， 可能大家对这块不熟吧。这个任务也自然就落在了组长的肩上。代码复审目前只对后端进行了比较全面的复审。前端由于关注较少，目前存在的问题是页面没有组件化的思想（相当于 C++ 中的 include），这样会使代码的可读性和维护性较差，这个问题会在接下来的 beta 阶段得到关注。
通过 alpha 阶段，我们认识到代码质量的重要性，软件工程的基础就是质量，没有质量，效率再高也没有用！其实，很多时候，编码前需要把问题想透彻了，才开始做；做的时候也应该考虑这样做可能会有什么问题，有没有更优雅的实现方式。只有让自己的脑子进入优化状态，时刻保持对代码的敏感，写出的代码的质量才可能更高。这也是 40-20-40 的一种体现。
四、测试与发布
测试问题在上面已经提到了。接下来就谈谈发布项目时遇到的问题。
原本是打算把项目通过 GitHub 直接发布到 GitHub pages，但最后一步总是无法成功：进入页面后，请求后端项目的接口总是失败，这个问题 Google 上一查，才发现 https 是不能请求 http 的资源的！这个坑出现后，我们就放弃的 GitHub pages，直接在后端的服务器上一起发布前端项目，这样就把这个问题解决了。
五、团队的角色 & 管理 & 合作
很多时候，会发现组会讨论问题时，并不是每个人都参与其中，这说明我们的团队的凝聚力还需要进一步加强，大家在团队中有时不能敞开心扉谈自己的想法，这也一定程度上影响了团队提升的速度。
不过，我们还是尽量坚持使用每日例会的方式，让每个人都总结当日的进度，促进组内成员的交流。
六、成员自我总结
| 成员 | 角色 | 总结 |
|---|---|---|
| 吕宇昕 | 前端 | 软件工程不只是打代码 |
| 唐靖钧 | 前端 | 编码仅仅只是软件开发里面的一个模块；团队合作密切 |
| 陈凯琳 | 前端 | 更加重视非编程阶段；每个人的进度都会对整个团队的进度造成影响 |
| 林智信 | 前端 | 前期的项目的设计还是不够完善 |
| 梁晓键 | 后端 | 团队配合得较为默契；数据库设计阶段所做的工作还不够；前后端分离的重要性；良好的开发规范也极为重要；单元测试也是比较重要的一环 |
| 杨泽 | 后端 | 良好的系统设计的重要性；前后端分离的好处 |
| 彭三福 | 后端 | 前后端分离带来的好处；普通小型项目的部署和维护是比较简单方便的 |
| 王嘉泓 | 后端 | 系统设计、文档在团队项目进程的重要性；团队协作的重要性 |
| 邹铭鸿 | 后端 | 团队中合作的重要性 |
七、代码贡献
前端
后端
