如何通过累计流图，发掘更深的项目管理风险（part two）：环境

在半个月前，有一篇文章讨论了「用累积流图发现团队运行问题」。

在接下来的一个迭代中，团队执行了文中所指出的如下建议。

• 每个迭代少安排一些开发工作量。为了每个迭代都很平滑，开发人员也要参与 下一迭代的需求准备工作。
• 安排多个时间点进行质量验收，例如，每周三和周五。可组织PD，交付经理（如有必要，甚至是开发人 员）及时对已完成的需求进行质量验收。
• 发现 Bug ，尽早修复，尽早验收。

有同学问，为什么开发人员也要参加需求分析工作。我在《持续交付2.0》的第六章已经进行了阐述，如下图所示。

今天要说的是：即使我们执行了上述建议，成果如下。

后一迭代的累积流图如下：

在后一个迭代中，团队成员都积极遵守约定，尽早进行验收。

产品质量有所提高，迭代中的风险也较可控，迭代结束之前几天的加班情况有所减少。

但是，仍旧未达到我们的预期。

这是为什么呢？

通过参加团队的每日站会，认真听项目进展，以及每个成员说出他们每日遇到的阻塞问题，和讨论的解决方案，你就可以找到答案，即：环境准备和使用流程出了问题。

对话的模式

1. 产品验收人员：昨天的XX需求没法验收，因为 M 模块（就是一个微服务）还没有部署到 SIT（System Integration Test，系统集成环境）
2. 子领域 B ：你提的 Bug 并不是 Bug，是因为在 N 模块没有把最新代码更新到 UAT（User Accecptance Test，预生产环境T）
3. 子领域 C ：我这部分已经开发完了，但是 子领域 D 的模块还没有准备好，所以无法验收。
4. 子领域 D ：我开发的功能被外部团队的一个依赖项阻塞了，他们说，需要再等两天，他们才能把功能发布。
5. 子领域 A ：我们的服务是在开发网，与生产网不通，无法直接使用子领域 D 提供的服务，需要换个新方案，已经讨论完了，正在开发中。
6. 子领域 C ：你提的 Bug 是因为子领域的 P 模块发布了一个新版本，带进琮一个 Bug。
7. 子领域 A ：你提的 Bug 并不是 Bug，因为原来的需求中，数据接口格式是 XXX，代码实现的时候发现那样走不通，所以现在的数据接口格式是 YYY，你改一下再试试。

「复杂的」微服务系统

这是一个采用了微服务架构的集成性平台软件。其系统逻辑结构如下图所示：

注：
上图并不包含类假于服务发现之类的公共标准依赖服务，以及更底层的数据库基础设施服务等。
图中的外部依赖全部为业务依赖，即：需要这些依赖服务提供业务输出。

• 主要有四个子领域协同。
• 六个子系统。
• 十多个微服务。
• 服务部署需要跨两个网络(开发网和生产网)。
• 每个子系统需要分别与其它软件平台集成。

「复杂的」测试环境

由于这个系统中的几个子应用分别部署于开发网和生产网， 所以，其系统的相关测试环境也需要横跨两个网络。

因为有一些外部依赖服务只能放在生产网，另一些外部依赖服务只能放在开发网， 所以，即便是以测试为目的建立的环境，也需要横跨两个网络。

如下图所示：

因环境准备工作量巨大而「凑合着向前推进」

项目初期，开发团队保持原有的旧式工作习惯，自己拉一个特性分支，并将这个分支上正在开发的代码部署到 SIT 环境中，进行开发调试。也有的团队成员使用 UAT 环境进行调试。

再加上前面提到的两个「复杂」，导致很难知道 SIT 和 UAT 环境的状态到底是什么样的？每个模块部署的是什么版本？

研发流程在一开始并没有对如何使用这些环境给出明确的流程定义与规范。

因为没有测试人员，没有人对各类环境负责。所以直到几个迭代后才发现，

大家都声称自己开发完了需求，但是需求却无法验收，或验收因各种原因导致验收不能过。

既然知道了问题的根源，解决方案也非常明确，那就是建立标准的 SIT ， UAT 和 Prod 环境定义，并且将其变成自动化部署，并能够自动化地进行环境健康检查。

虽然解决方案明确，但由于各种各样的奇怪问题，这个环境梳理和准备工作花了各子团队两周的时间。

自动化环境的创建管理可能还需要一段时间才能搞定。

想要持续交付，任何产品在写第一行代码时，就应该考虑可测试性。

• 架构是否支持易测试；不只是生产环境上的可测试，而是各个环境的可测试性。
• 开发环境和测试环境如何可以自动化准备
• 自动化测试所用的环境和手工测试所用的环境如何管理
• 如何为每个人分配相互隔离的工作环境。