我们小组从 5 月末开始 alpha 版本的冲刺，现在已经到了 6 月中旬，alpha 版本的冲刺基本接近尾声。我们使用 github 的 issue 功能来管理任务和进度，如下图所示
到今天为止，我们已经完成了 prototype 版本的所有 issue。为什么叫 prototype 而不是 alpha 呢？这是一种比较谦虚的叫法，因为游戏规则等需要多次迭代，所以我们称这个版本为“原型”。
同上一篇博文一样，我还是分技术和管理两个方面来谈我的心得体会。
先说技术。在冲刺阶段，我们产生了大量的测试需求，因为游戏很难在程序员电脑上部署（需要 scala 运行环境和 mongodb 数据库，而且最好是 Linux 系统），而组员们大多使用 Windows 和 Mac，因此游戏只能在服务器端进行测试。持续构建（CI）在测试过程中起到了非常重要的作用，程序员只需要完成修改并提交到 Github，2-3分钟后服务器就能自动刷新，完成新版本的部署，程序员就能进行测试了。但这个还有一定的改进空间，如不同分支可以部署到不同的地址，以便拥有相互隔离的测试环境；前端可以单独部署，因为前端的部署只是推送文件，而后端的部署需要完成构建，这部分工作很花时间。除了 CI，测试的时候还应该能了解服务器运行情况，因此，我设置了 log 路由，让前端能知道服务器运行是否正常。每次测试如果都从登录开始，无疑是相当耗时的，因此我在服务器中设置了测试账号，让测试人员可以直接输入网址进入游戏界面。为了测试前后端消息传递情况，我设计了 console.html ，用简单的控制台模拟了游戏过程，既可以作为测试时候的输入后门，也可以为前端提供交互样例。后端的架构比较稳定，除了地图部分进行了小范围重构外，其他地方工作得很好，在冲刺过程中后端发挥非常稳定，有了 bug 也能很快修复。
再说管理。首先我是采用了 issue-related 的管理方式，用 github 的 issue 来分配任务，并在其中讨论代码的实现方式。其实在我后来了解 gitlab 的工作方式后，发现 gitlab 的 issue 似乎更友好，有任务面板之类的东西，coding.net 也有类似的东西，下次可以尝试一下，GitHub issue 还是太粗糙了一些。在冲刺阶段，我让大家每天都在群里说自己今天的工作，然后由朱同学发博客，并附上燃尽图，以督促大家紧跟进度。
团队协作做得还是不错的，沟通上基本没有障碍，有了问题也能很快解决。可能小团队就是这样的吧，管理上的事情不需要做得太精细，效率反而比较高。不知道大团队管理起来有什么区别，有机会真想试试管理大团队。
原文地址：https://www.cnblogs.com/nicekingwei/p/9188835.html