开发流程

本周团队一起开了一个迭代回顾会，主要议题就是找出项目开发过程的痛点，然后通过制定一些合适的开发流程来解决大家的痛点。经过大家的积极吐槽，尤其是我们的测试人员更是不吐不快，目前大家的主要痛点如下：

代码没有及时交付给测试人员进行测试
上线范围不清晰，上线包版本混乱
开发人员随意部署UAT环境，影响正常测试工作
开发人员未通知测试人员随意修改代码，例如自己发现bug自己就直接修改了，导致测试工作无法覆盖这部分代码，最终可能导致上线失败
需求变更管理做的不好，经常只有对应开发人员知道变更需求，而测试人员根本不知道，还在用老的需求进行测试，不仅造成资源浪费，还可能影响测试进度
开发人员不认真评审测试人员的测试用例
开发人员和业务人员有时不把需求文档给到测试
更新禅道上面的任务进度不及时
好多设计方案没有经过大家的评审
大家开发时并不是认真遵守API开发文档，很多时候开发调试时
开发Service API时，开发人员通常随意测试一下就交付给联调方进行联调测试，结果导致联调失败，浪费时间
JAVA开发规范不统一，主要是指各种JAVA开发实践的使用方法不一致
团队集体代码Review比较少，主要依赖Merge Request时的一对一Review，少了一层代码把关以及集体学习的机会
Git等开发工具使用不规范
前端开发人员和后端开发人员割裂，不知道对方的打包方式，经常导致另外一方不在时无法打包，另外前端开发人员也应该学会如何去服务器上面看日志等操作
开发人员遇到难题时，经常是基于技术来做决定，而不是找业务人员从业务的角度解决问题
大部分开发人员都只对部分代码比较熟悉，导致开发人员之间的可替换性差，大家都只做自己熟悉的那部分功能
整个项目组没有维护一个全局统一的Backlog，大家对产品的未来的规划不是特别清晰
开发人员从设计、开发、自测、Merge Request到交付测试人员的SIT测试以及业务的UAT测试的一整个Task的开发周期不是很规范
目前开发人员都是基于业务方一个一个相互独立的任务进行开发，整个团队的产品意识不强

针对以上的痛点，我们积极讨论解决方案，目的时各位小伙伴很愉快的干活，最终我们制定了以下的解决方案：

需求管理

讨论需求时，业务人员、开发人员以及测试人员必须坐在一起讨论需求，确保三方对需求的理解时一致的。需求文档需要放入Git Document中进行维护，以便团队成员可以快速找到该文档，同时也确保大家使用的同一份文档。
发生需求变更时，同样是要三方人员一起重新讨论，切忌出现业务人员直接通知开发进行更改，而测试人员毫不知情，这样会导致测试人员一致基于老的需求文档进行测试。业务人员必须将更新后的需求文档发送给开发人员和测试人员，同时更新 Git Document中对应的文档，开发人员拒绝接受口头需求变更或者简单的邮件通知，必须出更新后的需求文档。
如果是重大需求变更，必须通知Master，重新确定需求的优先级，然后重新排期，基于优先级决定什么时候做，而不是业务人员决定什么时候做。
开发人员不可以在自己的任务之外修改代码，比如随意的代码优化，自己发现的bug等，甚至业务方发现的bug。开发人员自己发现的bug也必须由测试开发人员录入bug管理系统，同时确定优先级，决定什么时候修复。对于代码重构或者性能优化等工作，需要录入任务管理系统，并且明确告诉测试人员它的影响范围，以便做回归测试。
测试人员如果没有需求文档，应该拒绝测试

开发环节的流程规范

开发人员每次都是从自己的任务列表中寻找优先级最高的任务进行开发，从而确保优先级高的任务先被开发，同时测试人员也可以根据任务的优先级编写测试用例，业务人员同样是根据测试用例进行准备UAT测试工作。
开发人员在开发一个Task时需要先设计解决方案，然后需要整个团队快速过一下，如果重要功能，整个团队必须参加，如果影响不大，则部分人可以先讨论一下。一定不要出现没有评审过就直接进行开发，免得返工。
对于每一个Task，我们并不需要详细的设计文档，可以在纸上画或者在白板上画都可以，主要目的是评审或者讨论时使用，交付一个Task时并不需要设计文档。
代码开发完成后，首先自己自测，通常是在本地和SIT环境下面测试，完成后就提交一个Merge Request，进行代码检查并且合并到develop分支上，合并到develop分支后就可以通知测试人员进行测试了，这时候开发人员就可以把这个任务标记为完成了。测试过程中发现的bug根据优先级进行处理。
开发在通知测试人员进行测试时，首先要帮忙Review一下测试人员的测试用例覆盖了所有的业务场景，毕竟开发人员对业务的各种条件分支还是挺熟悉的，可以帮忙测试改善测试用例。如果无测试用例，可以要求先补上测试用例后再进行测试。
开发接口时，比如Service API，强烈要求先制定API文档，联调双方都要根据API文档进行开发，不要出现口头约定或者修改的情形。测试人员同样要对接口进行测试，未来考虑对接口做自动化测试。
开发人员提交Merge Request时要包含单元测试的代码，正常情况下不允许出现补单元测试这种场景。
代码提交到Git前一定跑一下单元测试的代码，全部过才可以提交代码。

测试环节的流程

SIT环境时开发人员自测用，UAT环境时测试人员和业务人员测试用，每一个Ｔask都需要经历开发人员在SIT环境的自测、测试人员在UAT的测试以及业务人员的UAT测试。
原则上只有测试人员才可以部署UAT环境，Jenkins上develop分支自动构建产生的安装包就是UAT包，测试人员开始测试时自己就去下载一个安装包部署到UAT环境中进行测试，这样UAT测试环境就不会经常因为开发随意在UAT上部署包而被中断。如果SIT环境不能满足开发人员的SIT测试要求，则需要和测试人员协商部署包到UAT环境，不允许偷偷部署。
测试人员是开发和业务之间的桥梁，一个Task在测试人员测试完成后，由测试人员通知业务人员进行UAT测试，业务人员测试遇到问题就找测试人员沟通，如果测试人员也不确定则由测试人员找开发人员确认，不要出现业务人员直接找开发人员确认的场景，因为这会打断开发人员的思考。业务人员发现bug就自己提交到禅道中，指派给测试人员，最终由测试人员确定优先级以及分配给相应的开发人员。
测试人员需要根据迭代初制定的User Story优先级安排测试计划，安装优先级进行测试，而不是开发给啥就测啥，同时也要协调业务方的UAT测试安排。所以测试人员要适度的督促开发人员按照任务的优先级以及时间估算按时交付功能，否则可能会打乱测试安排的，因为每一个Task必须经过测试才能上线，所以开发必须给测试留出足够的测试时间。

生产上线流程

我们是每个迭代的第二周周四上线，为了保证上线质量，所以必须在周二结束前完成所有要上线功能的开发工作，冻结上线代码，如果不能冻结则将该功能推迟到下个迭代上线。周三的主要工作是给测试和业务做一次完整的回归测试。
每个迭代都需要维护一个上线的checklist，就是列出本迭代上线的所有功能点，以及它们的影响范围，便于测试人员和业务人员检查上线前测试是否有遗漏，以及上线后做生产验证使用。上线前的周二需要根据实际进度给出最终的上线checklist。
每个迭代都需要维护一个上线依赖清单(dependence list)，记录上线要处理的依赖关系，比如需要打通的网络，机器的准备等情况，同时标记每一项是否处理。要经常检查依赖的处理情况，确保最终上线前没有遗漏。这个由各个Task的开发人员各自维护。
周三晚上打出所有的Release包，提交上线机房单，目前经常出现提交上线单太晚，导致很快才上线，或者到处找领导签字。

技术相关

在白板上维护一个“重要但不紧急”的任务清单，不要一味的赶紧度，要带着把清单上面的任务项处理掉，因为这些大部分都是自己曾经挖过的坑，不及早填坑只会挖更多的坑，而且未来更是没人敢去填坑了。重构要一直进行下去。
目前好多JAVA开发规范和实践不统一，因为在开发过程中逐渐摸索出更加合理的使用实践，需要把这些实践总结出来并且文档化，最后需要和整个团队分享沟通，确保大家理解时一致的。
Git使用规范：开发时从develop分支拉取最新代码，fork功能分支进行开发，提交前需要先将所有的commits使用rebase方式合并成一个commit，然后将分支push到server，然后进行Merge Request。关于Git的详细使用规范需要建立一个详细的使用手册。

文档使用规范

每个Git group下面都建立一个document项目，专门用于维护整个工程的所有文档，不把文档放在各个项目里的原因是一个工程可能有多个项目(Git项目划分比较细，通常projects会比较多)，文档太分散查找不方便，集中放在一个独立的Document project里便于查找维护。
工程里的所有业务给的原始需求文档都需要在Document project里进行维护，方便团队查找。
对于系统架构图、网络拓扑图等设计图需要将设计的原始文件放入Document project中，便于将来更新设计图。例如Viso文件类型、Powerdesigner文件类型等原始设计文件。
除了上述提到的文档，其它类型的文档建议通过WIKI的形式进行维护，因为WIKI比本地更方便查看以及编辑。比如之前提到的checklist，dependacy list，还有开发环境的各种信息都需要维护在WIKI中，非常方便团队获取到相关信息。
总之，任何团队都应该知道的信息就应该用文档或者WIKI中维护起来，团队成员应该知道的信息就应该方便的获取到，避免每次需要相关信息时就相互询问。

计划会与回顾会

回顾会的主要目的不是为了批斗与自我批斗，主要目的有２个，一是寻找团队做的好的地方，以便将来做得更好，二是寻找团队的痛点，并且制定或改进流程来解决他们的痛点。当然制定了流程后的回顾会就要关注流程是否有效得到执行，或者制定的流程是否合理，是否需要重构。
计划会开始前开发团队需要和业务一起从产品的Backlog中挑取高优先级的功能点作为本次迭代的开发内容，计划会上整个团队一起把User Story分解成若干个Task，确定每个Task优先级，然后通过打牌的方式估算每个Task的故事点。
大家自由领取感兴趣的任务，但是尽量按照任务的优先级高低轮流来领取，即大家依次从高优先级的任务中领取感兴趣的任务，一个人不可以都领取优先级差不多的任务，否则会block住开发进度。通过按照优先级自由领取任务，这样团队中每个开发人员就会逐渐接触到项目中所有代码。

其它

开发人员每天都要及时更新禅道以及看板，这样方便把控整个项目的进度，降低项目风险。