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