H5对局玩法（2018.8-2018.9）
整体流程规划
初次尝试敏捷，在流程上，还是采取了较为保守的传统宣讲反宣，并在程序排完计划后，根据计划来划分阶段。
初版排期，还是采取传统的瀑布式开发
初版计划还是像以往一样，前期搭框架，后期出效果，能体验时已经过了三周。和程序沟通能否把看时间效果提前，便出了新版排期，主要是安排一个程序专门负责表现部分，以便与策划沟通，随时调整效果。经过调整，将看局内基础美术效果的时间变为7月20号，提前了一周。
新版排期，工作任务进行了调整，红框部分主要为表现相关
当时的想法是，脱离实际的计划制定都是耍流氓，但实际上每个阶段具体的时间没有那么那么重要。正确的思路，应当是在宣讲之前就进行阶段划分，再让程序据此进行任务安排，最后得出排期。而且这个脑图当时是PM做的，实际上应该由策划来制作。
根据程序排期，结合策划设计思路定下阶段划分
美术方面相对灵活：UI和特效可以全程跟；模型H5不需要；原画设计在宣讲前便基本敲定；动作工作量较饱和，提前安排好就行。
实际制作流程
进入实际制作后，第一阶段的时间基本满足，少量内容因为未完成推迟至第二阶段。而原计划在第二阶段进行的局内效果完善，因为考虑到小灵通框架移植带来的重复工作，一些细节优化意见（特效、UI等）被推迟至第三阶段框架移植完毕后进行。框架移植工作在起初的计划制定阶段并未考虑，同时局外的时间安排无法满足7月底介入，所以局外逻辑接入被推迟为第四阶段进行。同时，由于不确定小灵通框架的性质，原定于第一阶段进行的手感校准工作，也被推迟到第四阶段进行。
规划的阶段流程
阶段流程路径变化带来一个最主要的影响是，原本在前期就能进行、工作量较大的手感校准工作被安排在了最后，导致时间紧张，效果没达到最好。原因在于，一开始在落实方案的时候，所有人没有完全同步小灵通框架移植的问题。程序为了尽快给出可体验的版本，先在已有框架上搭了基础对局，结果就是需要后期进行移植。如果起初思路达成统一，不用那么急着看效果的话，可能整体的时间安排和开发节奏会更加科学。
通过计划表可以看出，在第三、第四阶段，依然在进行一些细节优化工作。如果按照规划流程进行，很多优化工作能够在第二阶段就完成。
第二阶段完成时的计划表
第四阶段途中的计划表
复盘问题汇总
开发结束后，对所有敏捷参与人员提出的关于流程方面的问题进行了汇总，主要分为前期的计划安排与中期的执行方法两类。针对提出的大部分问题，后续会通过规范敏捷流程的方法进行处理。
策划部门问题
策划的定位不够明确，实际上在敏捷开发中应当承担类似PM的角色，既要负责设计目标的实现，又要领导组员共同走向这个目标。除了个人能力，一些敏捷方面的规范和说明也是必要的。
美术部门问题
原画人物、场景需求：初期需求不是很明确，但策划对于人物的风格有较强的执念。初版效果出来后，不满意但是又给不清楚方向，僵持了2周没有明显进展，最后通过拉会+参考图+leader旁听拍板+换原画的方式才最终敲定方案。
UI：一开始没有明确的风格需求，是等主界面背景图出来之后，根据其风格进行设计。后期因为担心和手游风格类似，换了设计。
动作：需求中给了游戏中的3D舞蹈动作进行参考。关于动作的制作规范要对接清楚，如是否随音乐节奏同步、“一个动作”的定义等。此外动作排期较紧张，尽量提前给需求、提前看效果。
程序部门问题
基本上都是首次进行敏捷开发，开发经验不足，对功能划分和节奏把控都不明确。每个阶段的开发，都没有安排联调时间，阶段时间过紧，只能自己抽时间去解决开发遇到的问题。同时，刚开始入手H5的时候，大家都不熟悉代码结构和type script的语言，会影响开发进度和代码质量，由于学习和其他任务的原因，大家的进度都有略微延迟。
流量问题：歌曲大小偏大；貌似没有缓存机制（因为看到每次开局很多东西都会下载，有可能是代码没有判断本地是否已经下载）；看浏览器插件中，歌曲信息每局似乎会下载多次。
兼容性问题：花屏问题（官网有说明，但没有给出解决方案）；内核版本过低，不能使用map（代码中新增了map的使用），开局崩溃等；不同分辨率下，有些界面显示不全，需要增加元素界面滚动或适配；界面元素不居中，需要根据当前屏幕大小调整界面元素位置。
测试部门问题
主要是介入的时机相对偏晚，后续压力较大，以及问题同步及记录问题。
手感调试
从运营处取得安卓手机列表，但目前只有助手端的统计，没有具体小灵通用户统计。与手游现有机型比对，确认所需手机后，安排测试从手游测试那边借手机，策划每天能调10台的手感，并记录不同机型中产生的适配问题（浏览器无法打开、界面显示不全等）。全部调整（80台）用了约三周。
目前结果是调整了50.02%安卓助手用户的手感，其余未调整的型号，因时间紧张，便采用loading图提示调整的方式。之后此类情况，应采取手游初次进入对局强制引导手感调试的方式处理。
IOS因各机型手感数值相同，调整相对简单。
助手环境相关问题
开发组直到第四阶段，一直是采取在浏览器看效果的方式，并未实际进入助手环境中。原先是说只有等灰度时候才能看，但是助手内核和浏览器有很多区别，如灰度遇到问题再进行修改肯定来不及。和程序沟通后，采取通过和运维搭建DNS服务器将地址映射到助手内的方式，实现了助手环境。
因为h5对局是首次把音乐播放引入助手，同时h5主界面改版也添加了背景音乐，导致出现了一系列相关问题（对局内的音乐点进到其他功能还是能听到、锁屏背景音乐还在播放等），运营因为排期紧张不能全部解决。今后考虑完善助手功能。
体验时希望局内能够全屏显示，便从x51小灵通那里要到全屏接口，但是经过程序分析后发现现有逻辑框架无法支持接口应用（变全屏需要重新传输数据），斟酌后最终接受局内不全屏的方案。如果全屏方案一开始就能确定，要到接口后程序以此开发，应当是能实现需求。
弱网测试，测试提供IP给运维做端口映射。