对于作者提到的关于软件交付的问题，虽然自己没有太多的经历，但是从身边人的阐述中也听说过关于软件交付的问题,因为软件部署交付引起的加班最正常不过了。
书中列出了几个传统模式下的软件部署方式，也就是书中总结的<strong>反模式</strong>：
部署流水线
- 手工部署软件——手工容易出错，结果不可预测，重复性高，消耗的人力多，时序问题。
- 开发完成之后才向类生产环境部署——由于其他的外部因素导致运维人员在开发完成甚至发布到生产环境的时候才第一次见到软件，发布周期长，后期维护代价高，在最后期限之前有很少的时间去修复出现的问题。
- 生产环境的手工配置管理——为发布准备环境时间长，无法回滚到以前的版本集群中各个节点承担的负载不同
针对以上的几点原因，作者也给出了相应的解决方法，从<strong>速度与质量</strong>两个方面来解决交付过程中出现的问题：
- 速度——减少周期时间
- 质量——以一种高效，快速，可靠的方式交付高质量而且有价值的软件
为了实现解决问题的方法，我们应该怎么做呢？
1.自动化——让本来需要人工做的事情尽可能自动化，构建，部署，测试，发布一系列的行为自动化，让这些动作变得可重复，相比手工降低出错的几率。
2.频繁做——频繁发布，让每一个版本之间的差异减小，降低发布的风险，更容易回滚，加快反馈速度。
感觉这一点跟小步提交有一些联系，通过小步提交减少代码版本之间的差异，也能够更快的发现代码的错误在哪里。发现错误之后也能够很快的回到之前的版本。
将自动化与频繁做结合起来——频繁地自动化来说，反馈十分重要，反馈地三个标准很有用：
1.无论什么样地修改都应该触发反馈流程——构成软件的可执行代码，配置信息，运行环境和数据任何一个部分发生改变都有可能导致软件行为的变化。
2.反馈应该尽快发出，——我理解的就是出现问题自动化的形式能够及时反馈，相对于手工的动作更快。编写测试跟自己手动测试代码当然直接点一下运行代码看有没有通过速度更快。
3.交付团队必须接收反馈，并根据其做出相应地行动——就拿自己写代码的过程来说，通过测试或者是其他的方式发现自己的代码存在问题的时候，必须先解决自己目前存在的问题，解决之后才能够继续后面的开发。如果将自己的错误累计以后再进行修改的话，代价会比及时解决的方式高很多。
小结：
感觉通过自动化的方式能够帮助我们更快的接收到错误信息的反馈，把错误细节话能够帮助我们更快的意识并解决遇到的问题，与此同时，版本控制工具的使用让我们在错误之后回滚到以前的版本，将二者相结合能够帮助我们实现一部分的自动化。
团队之间的合作也至关重要，大家有共同的目标，并在实现目标的过程中互帮互助，持续交流，或许我们能偶在问题出现之前就发现问题呢。对于持续改进，我觉得可能codereview和retro就是两个结合起来能够帮助我们实现持续改进，每个人都参与到过程当中，同时不断的提出问题与反馈，促进大家之间的相互协作，效率应该能够高很多。
网友评论