负责整个ThinkSNS+移动端的开发也10个月了.期间也大大小小负责了很多Manager方面的事情,成为了H5,PC,和移动端与服务端直接的润滑油.总结一下感觉和自己当初的规划有了些许偏差,距离技术lead越来越远,管理Manager方面倒是越来越清楚熟路了.没有办法,公司这方面有所欠缺,就只能逐渐补充.话不多说,今天不能分享技术开发方面的干货了,直接讲讲最近花了较长时间实践出的TS+软件发布计划吧.
问题是啥
10个月的开发时间,TS+完善了基础的用户系统,动态,圈子,找人,即时聊天等等功能.但是Boss依旧对产品不满意,多次表示了对产品开发周期长,交付内容质量低下方面的担忧.作为项目负责人的我自然是难逃其责的.进过了较长时间的总结后,产品本身的开发周期不能算长,如此多的功能,新的团队需要磨合.
那么为什么Boss还是不满意呢?其实是因为发布周期太长导致.TS+项目还是沿用了以前的瀑布式开发,3个月左右才能交付版本进行测试.
在总结出这个问题后产品2期开始迭代周期修改为了1周,即每周发布一个版本,提供增加的部分新内容和修复了旧问题的版本.但是引发了新的问题:
新的问题
TS+团队只有2名测试,也因为开发周期紧,需求不明确等原因.没有安排测试人员编写单元测试.每周发布一个版本导致测试压力巨大,每周四发布新版本后,测试人员没有办法在一天完成iOS端和安卓端的回归测试.只能简单的按照测试用例检查新的功能.
TS+ 开发的后4个月,就在这套问题不断的开发流程中走了下来.测试频繁漏掉检查项目,很多一眼就能看到的问题没有测试修复就交付到了内测用户手上.开发人员每周编写的更新日志也和实际发布版本内容对应不上,出现很多更新日志提到的功能还有明显BUG的情况.产品差评不断.
最严重的1个月,商务部门反映完全没有完成任何一笔有效成交订单.
问题总结
前段时间,工作压力巨大,整个项目开发风险都需要我来承担.花了一些时间我总结了已有的问题:
- 大量的工作都集中在了周五一天.数据迁移,后台功能发布,新版本测试,旧功能回测,开发修复等
- 修复后的版本没有测试时间.例如周五早上测试出问题后,周五晚上开发才修复完毕.
- 商务的更新日志是错误的
解决方案
新的发布计划在我脑海中逐渐成型:
在开发之初就决定该阶段的发布计划:大概的发布内容,和Alpha版本Beta版本发布时间:
截图任务制定时间是8月18日(周五),Alpha发布时间是8月25(第二周周五)Beta发布时间9月1日(第三方周周五,截图显示的8天前).TS+每周都会制定发布计划,修复上一个Alpha版本和Beta发布.
然后初步制定开发任务:
这个开发任务的意思是在0.8.6版本发布时会完成图上标题和正文中提到的内容.以及一些开发人开发开发标签等信息.在开发任务制作出来后会打上future标签,表示是新增的功能,开发人员真是开发完该任务后,会增加上complete标签.
Alpha版本发布
任务开发完毕发布Alpha版本后,进入测试阶段,测试反馈问题,版本发布当天,后台提供测试服务器用于灰度测试.
测试服务器的作用:同步正式服务器上所有的数据和环境,但是只提供给内部人员测试使用.留出1周的时间测试修复问题,然后再提供给用户进行更大范围的测试.
测试反馈问题如图:
开发人员在9月1日到8月18日之间修复该问题后,将标签修改为下图.意思是告诉测试人员该BUG已经在0.8.6.X版本上被Gorcat开发修复了.
编写更新日志
根据上面2张图,测试人员就可以在收到Alpha版本后根据该开发任务检查新增内容.根据BUG修复情况复测BUG.当测试人员确定开发任务验收通过,BUG修复完毕后,将关闭该任务:
然后根据新增内容的验收情况和BUG修复情况编写更新日志和决定是否发布.确认可以发布后.
更新日志:
1. 新增加了A功能
2. 修复了B问题
3. 优化了C部分
等等等等
总结
沿用这套更标准的发布流程后,开发和测试人员的压力都进一步下降,对外发布的Beta版本质量更有保障,也保证了每个阶段都能交付产品给用户使用,每个版本的后台更新发布对正式服的影响也降低到了最低,商务部进行销售.变相的提高了发布时间.(当然,这里也有一些瀑布式开发切换到敏捷开发的功劳)测试部门也可以根据开发内容和BUG修复情况提供准确的更新日志.我呢,也能少掉一些头发了.
