三、发现浪费

　　从精益思想出发，为了尽早交付价值，必须首先找出整个流程中的浪费，并将其消除，从而提高流程效率，让“一个想法从提出到实现”可在短时间里完成。那么，浪费到底表现在哪里呢？

　　● 一些不必要的多分支开发，合并后发生问题的风险高。多个项目中可能都要修改同一个模块的代码，每次在后合并代码时都会出现一些问题，非常痛苦，尤其是修改比较大的时候，合并及修复时间较长。

　　● 推迟问题被发现的时间。每个开发人员会将需求分解成多个技术任务后开发。所以，所有任务完成之前，应用程序一直处于不可用状态。当后在一起联调时，常常会发现一些意想不到的问题。

　　● 基于流程平台的沟通。在提测环节中，沟通完全基于内部项目管理平台和即时消息工具或Email。比如开发人员在提测前，需要在项目管理平台上申请该项目的4位版本。拿到4位版本后，才能提交平台统一编译。如果编译失败，那么问题解决后还要再次申请4维版本。如果成功，则在项目管理平台上填写表单，回答一系列的问题（比如，是否做过单测？测了哪些功能点？部署步骤是什么？），发起提测工作流，管理平台会自动发送电子邮件给相关测试人员，通知他们进行测试。测试人员收到该提测工作流后，必须在平台上进行相关确认操作，通知开发人员已收到该版本。如果测试人员对部署和测试内容有疑问的话，还会通过即时通讯工具或邮件与开发人员进行确认。

　　● 常规的例行工作很难自动化。上线部署也需要通过内部平台来完成。开发人员拿到已测试通过的4位版本后，先要登录到内部平台，再提交上线申请单，填写上线步骤。当运维人员收到上线步骤后，再将其“翻译”成平台可以识别的“半自动上线步骤”，再让平台来执行。如果运维人员不理解上线步骤，要和开发人员通过电子邮件或即时通讯工作等进行反复确认。部署配置信息分散在各处。如下图所示：

　　另外，该产品的一个重要特征是需要不断地尝试调整程序算法策略，以得到佳的流量效果，而这种调整的频率较高（至少每周一次）。当需要调整策略时，开发人员修改代码后重新进行编译打包，由于产品代码发生变化，所以测试人员仍需要进行大量的回归测试，而运维人员在部署时也需要将对二进制文件包进行整体部署，整个周期比较长。

　　从上面这些内容中，我们不难发现，流程中更倾向于将问题推迟到后面解决（比如后集成联调），将工具（平台、邮件、即时通讯）作为协作的基础，而角色间的沟通几乎完全依赖于前一个环节的产物（比如MRD、产品代码、上线步骤）。那么我们使用哪些对策进行优化，达到消除浪费的目的呢？

　　四、应对措施

　　1、无人工干预方式的脚本自动化

　　● 自动化提测——由于已做到了每日集成，所以每天都有可测试的版本，开发人员不再需要为提测进行专门的准备工作，只要从成功构建的列表中选择一个给测试人员可以了。使用Hudson平台后，通过插件即可调用自动化脚本，完成提测版本的标识。

　　● 统一配置信息源——将所有的配置项全部放在Subversion库中进行版本控制；并根据应用环境的不同，分别保存在Dev，Test和Online三个目录中。

　　常规流程脚本化——经过各角色的共同讨论和可行性分析，后配置上线部署的实施方案是：由开发人员将产品二进制包与配置项进行剥离，这样仅做策略调整时，测试人员只要对已修改的配置项进行相关测试即可。运维人员用一系列的脚本代替了内部运维平台的手工上线操作，再通过Hudson平台的插件，以 “Click Button”的方式达到了一键式部署。