开发负责人和测试负责人沟通以后，总结了让他们痛苦的事情，如何解决？
估算不准确、临时插入事情多、项目计划很难做；
到了计划的测试时间点，开发人员还没有联调完，无包可测；
当有软件包可测的时候，测试人员却被调去测试其他项目了；
好不容易有测试人员了，一测试就发现很多低级问题，可能都启动不了；
没法继续测下去，还要打回给开发，继续修复；
测试环境和测试数据的准备要耗费很长时间；
测试时需要将线上环境的一些配置同步下来，因为那才是最可靠的环境；
反反复复提测好几次，手工重复测试真是受不了；
终于可以准备上线发布了，还要排队等待；
当轮到自己的项目上线了，还要把前面已经上线的代码拉取合并，再测试；
假如前面上线项目出了问题要回滚，我们还要把代码剥离出去，再打包，再测试；
写了一大堆上线文档，交给运维人员，运维人员说不符合运维规范，要重新修改；
运维人员终于可以部署了。可是，刚部署上去，就出问题，原来是把配置文件搞错了；
...
改进目标包括 短期目标 和 中期目标 。
短期目标如下：
项目近预期时间交付。
创建新的软件研发协作方式。
建立必要的基础设施，以支持后续的持续发布模式。
中期目标如下：
缩短发布周期，可以快速上线。
不降低生产环境的质量。
降低测试人力总投入。
这两个目标分别对应两个实施阶段。
第一阶段是以持续集成牵引的“敏捷101”，顺利完成一次发布，并为后续的持续发布奠定流程与工具基础。
第二阶段是向 DevOps 工作模式转型的持续发布之旅。
了解更多：https://t.zsxq.com/09LbXB56P
推荐阅读
加入读者圈子
