标签：处理 dea 了解 dac 游戏测试 expand 任务计划 code 好的
就团队整体层面，五月初，团队项目走上了正轨，前、后端使用的技术和框架已经确定，稳定撰写代码。五月中旬完成了发布前最后一次游戏测试，收到了反馈，并且据此修正团队项目前进的方向。五月下旬，我们迎来了团队负责美术的同学，前端不再受困于设计。小组会议维持在每周至少一次（4小时）的频率，上周开始为了加紧进度，除开小组会议之外的时间，每天也要安排一定的输出。
小组进度看似顺利，实则遇到了一些比较大的困难。首先，前端架构为了优化性能进行了一次重构，付出了一定的适应新架构的时间成本。其次，最后一次游戏测评之后，游戏规则有了一定的改动，后端已完成的结构需要添加和修改。最后，在后端主要模块GodActor编写过程中遇到了异步处理原理上的障碍，技术攻关需要一定的时间。
上周说的预计6月1日发布Alpha版本，现在看来可能性非常小。其原因一是我们对任务量和自身能力的错误预估，二是在实际开发的过程中会产生许多计划外的新问题，带来额外的工作量。
我在团队中的工作是博客撰写发布和后端代码编写。在这两个本职工作方面都学到了不少东西。
团队博客的撰写过程中，学会了如何使用Markdown进行简洁快速的排版，如何合理使用简单的工具，比如使用Excel和画图工具进行工程示意图的绘制，养成了分类整理文档的习惯，打字速度有所提高。
后端方面主要收获是：
①使用的技术是Java，学习新语言的收获自不必说。
②在完成代码的过程中，也学习到了一些新的概念，比如Actor模型，位图，多线程和并发的原理等等。③养成了单元测试的习惯（没有使用JUnit框架而是自己编写）、学会了使用assert语句进行测试。
④Java常用技术工具Git、IDEA的使用也更加熟练。
⑤从文档中提取程序所需信息的能力也大大提升（阅读游戏设计者提供的规则， 并将其转化成代码）。
五月之初由于前端人手不足，我作为原本的后端程序员和本组组长一起临时加入前端进行了一定的前端代码编写。因次也学会了一定的前端技术。
前端本组使用的是HTML5和JS、CSS来进行Web开发。开发中使用了开源游戏框架Phaser，因为框架的存在，不需要对H5和JS的原理有太深刻的认识，依葫芦画瓢即可，因此仅大致了解了H5、JS的语法和组成。在编写前端期间，收获主要为：
①了解API文档的重要性，并且学会了查找阅读API文档（大多开发工具的文档是英文，需要逐渐习惯英文文档阅读）。
②对开源知识有了一定的了解，知道如何寻找开源资源并合理利用（先看lisence）。
③学习技术工具VSCode的使用。
团队项目开发过程中，对于软件工程方面也有了一定的收获。
1、需求问题
在工程启动的最初阶段，就要做好需求调研，不能一味埋头拉车。即使在开发过程中，需求也有可能不断的变化，因此，即使在开发阶段，需求调研也是不能停滞的，需要随时根据测评和调研的结果修正开发的方向。我们的游戏项目本来只有作出原型才可以测评，但由于游戏本身存在桌面版（卡牌、地图等等），使我们可以开发的过程中并行对游戏的各方面进行调研。但电子版与纸质版仍存在一定的不同，电子版原型一定也要尽快开发。
2、进度和规范
保证进度，主要在于监督和规范。不能将任务堆积起来，而应该分散至每一天，但是这种分散会受到惰性、懒散的制约。其实这时候，项目经理使用各种手段去监督团队成员，比如任务墙、每日自述、燃尽图、每周绩效等等，就可以一定程度上解决这个问题。这些手段看起来只是形式和规范问题，但实际实行后，不仅任务计划更清晰，组员在这些手段的监督之下，除任务DDL的压力外，也会形成一些自我约束的习惯。产出可以少，可以没有，但是必须汇报。“今日无进度”的自述相比于“今日进度...，遇到...的问题，解决...的问题，明日计划完成...”的自述，还是能让人产生不少罪恶感的。
我对此深有体会，本组的项目经理是组长隆晋威同学，在课堂上要求规范项目管理之后，由他制定每日自述和任务墙、绩效的形式。但由于更新博客收集信息的需要，我有时会在QQ群中催促大家进行每日自述，还会把commit次数和任务墙截图，在几天过后，大家已经开始自觉发布每日自述，说明任务的分配开始有了一定的改善。我本身也养成了任务分摊、大小进度多汇报的习惯。
值得一提的是，项目管理不一定必须要用禅道、TeamAmbition等专业工具。合理使用我们都会的，平时看起来可能很Low的工具，也能做到同样的事情。比如：架构示意图用WIN自带的画图软件即可，燃尽图可以用EXCEL很简单地画出，而Github的Issue功能也是实现任务墙功能的很好的工具。
标签：处理 dea 了解 dac 游戏测试 expand 任务计划 code 好的
原文地址：https://www.cnblogs.com/Ignoramus/p/9116049.html
