敏捷实践之谈(二)

       上一篇编写了敏捷实践之谈，还有一个阶段没有写（开发编写代码到发布生产发布结果），现在进行补充。这个阶段是敏捷实践耗时最长的时间，也是出现风险最高的阶段，也是决定发布质量的关键阶段，也是体现团队敏捷性的最佳时机。下面从我们所在团队的经验来说下这个阶段如何开展各项工作，从而达到高质量高效率的团队。

1、开发编写代码。所谓一千个读书者就有一千个哈姆雷特，好看的皮囊千篇一律有趣的灵魂万里挑一。如果想要高质量的代码，良好的编写习惯。那么就需要团队有一套严格的编码标准和准则，从而形成良好的编码习惯。也需要有一些经验丰富的开发者，让他们去教导学员从哪些角度设计系统从而达到较强的系统健壮性和可扩展性，如何避免埋坑，并且领导者能够根据每个人的不同的编码水平，制定因人而异的改进方案，进而提示个人乃至整个团队的综合水平。这个阶段如果出现任何和产品不一致的情况，会在每日站会上得以体现，并及时反馈跟踪和解决。如果存在于第三方对接的问题，也会及时提出并大家讨论作出一个很好的应对措施。这样能看到开发人员每天进度都是向前的。

2、提交测试。这个阶段一定要制定一个提测模板，包括提测时间，提测内容，提测人员，提测环境，提测内容，提测注意项。。。作为衡量开发人员是否晚于提测时间，是否存在提测内容和设计评审不一致的情况。也作为后面测试人员测试的主要参考标准。

3、执行测试。测试人员做冒烟测试、功能测试及集成测试的阶段。测试人员核对编码与需求的一致性，如果发现不对称，及时拉会反馈和解决。这个阶段如果发现bug，要及时录入到bug系统中。并每天发送测试日报，如果是大项目，抄送人员包含开发、测试、领导、以及关注项目和项目有干系的人员。测试日报要提现项目进展，项目风险，后续项目计划，以及需要解决的项目问题。不同事态的风险用不同的颜色标记。最终做完集成测试要发邮件给产品，让产品人员参与UAT。项目上线前3天进行代码合并，并开始做回归测试。一定要提前预留三天做，为避免后面回归测试时间不足，带有问题上线。

4、版本发布评审会及上线发布。一般发布前2天召集运维、产品、运营、开发和测试参与版本发布评审，会上会确定发布内容，发布顺序，发布应用，发布脚本，发布回退方案以及发布验证方案。各方确定后发出会议纪要，各方按照会议纪要执行。发布后，产品和测试参与线上验证发布结果。如果验证有问题评估及时修复还是回退，一般都是及时修复。最好验证后发布版本发布结果，验证通过或者版本回退，会标准后续待跟进项。PMO会把待跟进项纳入下个迭代中，形成从输入和输出的一个闭环敏捷实践。

以上是全部的敏捷实践，其实中间还有很多细节没有提及。在写这些内容个过程中，突然发现我看着别人的敏捷路程，经历了从0到1的一个实践者。我相信肯定有机会在新工作中实践并发挥它的价值。

也欢迎对这方面感兴趣的人提出问题及交流沟通~