在校学生小团队Scrum实践经验与反思

       本学期的敏捷软件开发课程要求学生自己组队（4人）使用Scrum方法开发一个项目。我们一队四人虽然以前没有实际scrum开发经验，但是靠课上以及参考资料的指导，还是在努力践行Scrum流程与思想。本文内容包括以下三部分：在校研究生践行Scrum的固有困难、我们的实践过程及过程中对流程的适应与改造、Scrum对于学生的一般性课程项目的潜在价值。

在校研究生践行Scrum的固有困难

       显然，Scrum实践已经默认了应用的团队是一个全日制工作的、工作技能熟练的开发团队。在此基础上，才有可能组建“全职能团队”，才有可能“把办公桌安排在一起”，并在旁边树立看板作为信息辐射器，让大家随时了解Sprint进度之类的信息。
       而这些要求，对于在校研究生来说，并不现实。首先，大家选的课程并不相同，在大家的闲暇时间重叠不多的情况下，还有可能有其他活动占去这些宝贵时间。这导致能够做到一起工作、即时交流反馈的机会很少。其次，（由于本专业热门）一部分研究生本科并非本专业，基础薄弱，影响工作质量，本人所在团队就有这种情况。即使是基础较好的学生，如果课程项目提出了对新技术/框架的使用需求，也会变成基础薄弱的开发者，影响工作效率与质量。
       综上所述，在校研究生践行Scrum的固有困难是“共同工作时间少导致交流受阻”与“水平不足、需要大量时间来学习和踩坑导致工作效率、质量低”。受这两个因素影响，在校研究生想要采取某些Scrum实践可谓困难重重。比如：由于工作效率低，人数也不多，所以几乎不可能支持结对编程；由于共同时间少，协作靠QQ群，所以请求到响应的时间间隔很长。

我们的实践过程及过程中对流程的适应与改造

       本团队从使用故事地图进行需求分析之后，便开始进入迭代开发阶段。从那时到假期有三周半，我们便决定把时间分成3个迭代，每个迭代持续一周。
       首次会议包括对这三个迭代的功能点的大致划分以及对Sprint1的故事的分解、分工。在会议上，我们得到了以下商讨结果：

1. 由于没有“客户参与”，验收标准就没法非常精确。虽然之前大致写了故事验收标准，但设计得复杂还是简单，要不要复杂的安全性保障机制等等，都没有说明。所以我们最终同意从流程中去掉每周展示会议，只要前后端调试成功，前端开发能够覆盖功能点即可。
2. 由于共同开发时间不好找，所以“进度自行把握”，取消每日站会，不规定共同开发时间。
3. CI平台作为敏捷开发关键要素之一，应当尽快搭建并纳入使用。前端由于微信小程序的特殊性质，不使用CI。
4. 两名同学开发SprintBoot框架的后端、两名同学开发微信小程序前端。协作依靠后端发布、更新api文档，沟通靠QQ群。
5. 计划按照故事点的数目将所有故事平均分到三个迭代中去。第一次迭代完成优先级最高的1/3的故事点的需求。

       在这样的结果下，我们开始了Sprint1开发。本人与另一名同学A负责微信小程序前端。提出前端使用微信小程序形式的就是A同学，而本人其实并不熟悉微信小程序开发。在Sprint1的一周内，团队内的主要交流便是api文档的发布。以及在QQ群里对于api文档的少量修改要求。我们主要感受到的问题包括：

1. “注册/登录”等辅助功能其实不比普通的业务故事的工作量要少，然而在故事地图里面没有写到这些功能。
2. 后端SpringBoot技术比较简单，负责的B、C两名同学很快就完成了api设计与实现，配合CI自动部署，两天就完成了Sprint1的开发工作。而前端与其进度差异巨大。对于本人、B、C，学习微信小程序开发都是较大的工作量。这使得我们无法按照Scrum说明的“有余力的开发者应当主动承担更多任务”，给B、C分配前端任务。而我也几乎只是完成了微信小程序的大致学习。
3. 由于没有共同工作时间、没有站会，交流只靠QQ群，所以当A发现了api设计不合理之处并在QQ群要求修改时，得到反馈的时间间隔相当长。
4. 在上面1、2、3的情况叠加下，A几乎只完成了注册、登录功能。从前端来看，Sprint1的故事全都没有完成。

       对于以上问题，我们在Sprint1回顾会议上面进行了仔细分析，认为问题的根源是交流不畅。所以我们在Sprint2中进行以下流程改进：

1. 根据每人的课程表，（虽然不容易，也要）规划出都有空闲的共同工作时间，即使每两天只能规划3小时，也能对于难度较低的本项目起到帮助。
2. 每两天（与共同工作的频率一致）晚上11点在一间宿舍开一次站会，交流共同开发以及自己零碎时间开发的成果。
3. 作为一种松散的要求，大家多看看QQ群，尽可能及时处理其他成员提出的要求。

       经过改进以后，我们在Sprint2工作效率上升明显。我们清空了Sprint1遗留下来的故事，也完成了Sprint2新计划的故事。虽然本人学习完成、效率提升对这个结果有贡献，但我们明显能够感到：共同工作、及时交流修改的流程确实为整体经验不足的团队带来了提升。
       在Sprint2的工作中，我们仍然遭遇了一些开发上的障碍：

1. 在后端同学更新完api文档之后，发布的是Markdown格式的。由于api的更新不是在共同工作时间完成的，更新时有时负责前端的同学在上课或者没带电脑只有手机，就不方便检查api的设计缺陷。如果后来忘记，就会一直等到前端开发到这个接口时，才会发现问题。这时修改又会耽误时间。
2. 后端虽然写了单元测试，但由于对测试框架的不熟悉，发生过把request parameter当成request body(json)的情况，还测试成功了（说明实现代码写错了）。结果前端根据api开发，怎么也调不好，最终发现是后台开发经验不足导致。

针对这些问题，我们在Sprint2回顾会议上，研究出了一些解决办法：

1. 每次上传更新的api，也在QQ群里传一份pdf格式的，保证前端开发者即使只有手机也能及时检查。这样有机会使一些api修改提前。
2. 除了自动化的单元测试，也使用Postman软件进行每个接口的测试。Postman测试用例可以导入导出。当后端开发自测成功，便导出易读易理解的Postman测试用例集合给前端开发，保证两组人对于api有着共同理解。

       接下来我们将开始Sprint3的开发。在本迭代内，我们有可能会继续调整流程，使得流程更加适合我们的具体情况。

Scrum实践对于学生的一般性课程项目的价值

       在本次Scrum实践中（虽然项目还没有结束），我们体会到了许多Scrum实践对于我们课程项目的价值：

1. CI工具的使用。我们使用了Jenkins对系统后端进行了自动构建部署，每当Github代码更新，便集成一次。这使得我们在初期本来跌跌撞撞的开发有了一丝光明。过去开发C-S架构项目，调试时可能需要频繁修改，也就伴随着频繁的手动构建部署，令人不胜其烦。这次我们部署好Jenkins一套，虽然SonarQube只起到了令人心烦的作用，但其它部分都实打实地减少了我们的工作量。甚至当测试出现问题（unstable build）或部署失败（failure），还能自动发邮件提醒。
2. 短迭代周期确实降低了修改成本。虽然我们目前只完成了两次迭代，但由于后端开发经验不足，api频繁修改。令人欣慰的是，由于每个迭代新增的故事点数目可控，新增的api数量也可控，这样犯错范围小，影响范围小。这样在迭代结束时，本迭代内的设计缺陷都能够修复，下一次迭代对之前api的影响很小，后端数据库设计每次修改幅度小，前端实现修改幅度也小。我们的项目才能够快速进步。如果按照以前一次设计完所有接口，开发时到处都是问题，可能所有接口会因此修改多遍，相应的前端开发也会严重受阻。
3. 多迭代周期配合任务看板降低了拖延症发生风险。如果粗放地将三周半时间划为一个长Sprint，将所有故事点一次全放进看板，那么即使合理设置了截止时间，团队成员在看到长长的任务清单，也会望而生畏，想把任务往后拖。这种情况一般只发生与学生团队，不影响职业开发者（毕竟被老板开了就没饭吃了）。一个迭代周期任务未完成的看板（尤其是变成红色的日期）能给学生带来更大的危机感，促使学生在下一个迭代进行努力工作。同时，迭代的顺利完成会成为对团队成员的激励，使其更有动力接受下一次的挑战，治愈拖延症。这对于职业开发者也适用。