Alpha 冲刺的问题总结

这个作业属于哪个课程	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，直接在后端的服务上一起发布前端项目，这样就把这个问题解决了。

五、团队的角色 & 管理 & 合作

很多时候，会发现组会讨论问题时，并不是每个人都参与其中，这说明我们的团队的凝聚力还需要进一步加强，大家在团队中有时不能敞开心扉谈自己的想法，这也一定程度上影响了团队提升的速度。

不过，我们还是尽量坚持使用每日例会的方式，让每个人都总结当日的进度，促进组内成员的交流。

六、成员自我总结

成员	角色	总结
吕宇昕	前端	软件工程不只是打代码
唐靖钧	前端	编码仅仅只是软件开发里面的一个模块；团队合作密切
陈凯琳	前端	更加重视非编程阶段；每个人的进度都会对整个团队的进度造成影响
林智信	前端	前期的项目的设计还是不够完善
梁晓键	后端	团队配合得较为默契；数据库设计阶段所做的工作还不够；前后端分离的重要性；良好的开发规范也极为重要；单元测试也是比较重要的一环
杨泽	后端	良好的系统设计的重要性；前后端分离的好处
彭三福	后端	前后端分离带来的好处；普通小型项目的部署和维护是比较简单方便的
王嘉泓	后端	系统设计、文档在团队项目进程的重要性；团队协作的重要性
邹铭鸿	后端	团队中合作的重要性