交流、项目管理及测试部分的规划

拜拜、爱过 提交于 2019-12-29 17:49:03

交流、项目管理及测试部分的规划


1.交流方式以及交流频率

  因为平时大家都在一块自习,交流其实十分方便,计划每两天晚上开一个小短会,熟悉下队员之间相对进度,避免有人进度较慢卡住集体进度的现象产生,每一周开一次大会,确定一周目标,并作相应记录

2.代码管理

 充分利用GitHub,划分develop与master分支,细化工作,每个人建立开发者仓库,在个人仓库develop分支修改代码,个人审核与测试后,向管理者发送pull request,develop功能完善了,组内成员集体审核源仓库develop代码,完成测试review,全体成员无异议后合并进源仓库,发布新的版本前,可以在master分支分出hotfixes分支用于整个项目测试与bug修复,无误后并入master,发布新版本。
  个人开发过程中,应该以充分细化功能,以创建feature分支,每次完成一个子功能就提交,避免出现bug回退产生不便。 可参考下图: 


3.进度监督、燃尽图、时间管理

  大家相互监督,每周确立目标,由项目负责人对项目开发整体流程进行估计,并且每两天的小会集体批评拖后腿的组员,尽量使一周的工作量保持一致,燃尽图以剩余工作量为纵坐标,时间以周为单位进行绘制,尽力避免下图情况发生。 

 
  前者时间分配不当拼命赶ddl,后者直接gg


4.需求变更管理

  这是一个难以避免的问题,能做的就是尽力的明白用户的需求,做好需求分析工作。 
  确保开发人员与需求分析人员保持良好的沟通,做好需求变更管理。特别是对当前开发产生影响的应该紧急开会进行讨论并并决定。并且确定变更需求通知到每个组员,避免产生无用的工作量。


5.技术攻关

 因为当前组员并没有相关的实际项目经验,所以技术的学习是必须的。

  • 对专业领域的Overview,遇到新的技术尽快的了解其大概。
  • 借助开源代码对问题进行进一步认识,降低学习难度曲线,甚至在协议允许的情况下直接作为api使用。
  • 同自己的认识的技术大牛交流与请教,,假如恰好有这方面的人脉则是非常幸运的。特别是技术高手,一般用不了几句话就能把某项技术的关键问题描述清楚了。从这种交流中,我们受益匪浅。当然,交流之前必须对问题有充分的了解,避免出现低效的交流。但要注意,我们一定要在对该项技术有所了解之后,再去找专业人士交流。否则这种交流建立在信息严重不对称的基础上,就是极其低效的。对该项技术的初步了解,也是让我们能问出真正有效的问题的基础条件。

6.人员变动与外部事务处理

  平时对组员代码进行充分的规范,并严格要求说明文档,假如真的由退课的同学,应提前安排好交接工作。 
  对于个人突发事务,个人应该进行合理规划,为了激发积极性,对于影响了团队开发进度的成员给与贡献分削减


测试计划

1.迭代开发、及时测试以及确定每次测试的时间节点,寻找测试对象相关

 缩短项目的反馈周期,一经发布,尽快联系校内用户进行体验,按照反馈进行代码改动,且通过不断的沟通,还能减少对用户理解上的偏差减少误解,从而降低项目最终完结却发现用户不喜欢的风险。   测试的安排在上面代码管理已经声明,同时在粉丝群中进行内测,修复bug,无误后校内公测。节点为alpha与beta版本确定后。

2测试计划表,测试内容子项,测试意见反馈渠道相关

    • 因为组内成员少,安排专门的测试人员不现实,每次组员完成相应的功能后,应自己编写测试样例,编写测试报告,每周组会内容将测试报告整合,由大家一同讨论有无测试盲区,无误后,整合进一份测试报告。
    • 对于测试内容子项,应当在认为分配中以功能单元为划分,在产品发布前,以功能间的匹配连接为主进行测试
    • 渠道问题,组内以周会为主,内测以粉丝群为主,公测时候应在ui中添加反馈渠道。
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!