转移到持续交付
随着时代的转变，我们需要应对新常态。 客户要求我们在短时间内提供可用的软件。
如果我们不能交付，客户就会去找我们的竞争对手。 因而竞争极为激烈。 随着互联网的发展，我们随时面临来自全球的竞争。
和我们处在同一软件生成领域的竞争对手所提供的工具在某一方面上已经做到了极致。
我们需要快速交付，而且我们的产品必须优质。 在实现此目标的同时，还应做到软件产品价格便宜且质量高。
为了实现这一点，我们需要类似持续交付的方法。
我们需要向这样一种局面迈进：不是将价值堆积起来一次性发布，而是通过管道流式发布。
正如图中所示，一个弹珠代表一项工作。 一次只能有一部分工作流经管道。
因此，必须以正确的方式对工作进行优先级排序。 如你所见，管道具有绿色和红色的出口。
我们希望设置这些反馈循环或质量关口。 反馈循环可以是不同的内容：
- 验证代码的单元测试。
- 验证源代码的自动生成。
- 测试环境中的自动测试。
- 对某个服务器的监视。
- 代码中的使用检测。
如果其中一个反馈循环为红色，则弹珠无法通过该出口，并将最终进入“监视和学习”托盘中。
这里便是“学习”的地方。 将对问题进行分析和解决，以便下一次弹珠通过出口时，其显示为绿色。
每一个工作流都会通过管道，直到最终进入价值托盘为止。
自动化程度越高，价值流经管道的速度就越快。
公司想要转向持续交付。
- 他们看到了价值。
- 他们听到了客户的声音。
- 公司希望尽可能快地交付产品。
- 质量应该更高。
- 转向生产环境的速度应该更快。
- 应降低技术债务。
改进软件开发做法的一个好方法是引入敏捷和 Scrum。
去年约 80% 的公司声称他们采用了 Scrum 进行软件开发。
通过使用 Scrum，许多团队可以在为期两到三周的冲刺(sprint) 后生成可工作的软件。
但创建可工作的软件不同于交付可工作的软件。
其结果是，所有“完成”的增量都需等待下一次发布时交付，而下一次发布将是几个月之后。
我们可以看到，现在非敏捷公司内的敏捷团队陷入了交付漏斗。
瓶颈不再是可工作软件的生产，而变成可工作软件的交付。
完成的产品在等待交付给客户以获得业务价值，但交付迟迟不进行。
持续交付需要解决此问题。