如今的科技公司正面临数字时代潮流的挑战：不断提高的用户期望、技术的断档和激烈的竞争。管理人员和IT从业人员在效果不确定时倾向于主动推动技术解决方案以解决问题，但他们总是遭遇失败……甚至有时有些选项从未被评估过。他们缺乏正确和严谨的方式来明确地描述问题、诊断根源、实施相关的纠正措施、评估效果、帮助人们更好地了解工作并改善日常工作实践。
本文中提到的Marek是一家法国移动开发公司的CTO，在文中提到的Kevin是一位程序员。通过耐心地观察开发人员的工作及软件各部分是如何流转及停止的，Marek揭示了在验证和部署过程中的浪费，这些浪费严重影响了开发人员的生产效率。
文中详述了一个实例，其中的移动应用程序敏捷团队成功地将其生产力提高了15%，通过该实例您将看到精益管理的方式和问题解决方案具体是如何帮助敏捷团队的。
移动解决方案合作伙伴
总部位于巴黎的BAM French公司为企业和初创公司提供移动解决方案和专业知识，以帮助他们应对业务挑战。BAM员工尽可能高效和快速地工作，为其客户提供价值，他们采用的是精益创业方式和1周冲刺的Scrum方法。
事实上，应用的部署真是又费时又费钱。
作为精益工程师，BAM员工遵循一系列的步骤来创造这个价值：
1、被视为客户的产品所有者（product owner，简称PO）正式确定一张Trello卡的功能（Trello是一个数字任务板软件工具）。
2、PO优先考虑新功能。
3、技术团队承诺每周开发一套功能。
4、每个功能在被视为“完成”前遵循其自身的工作步骤：
· 开发人员领取一张ticket并开始工作。其有责任完成该ticket所对应的功能，并且必须得到PO对该ticket的验证。
· 开发人员为实现该功能进行编码、测试、重构代码等等操作。
· 代码一旦写好，至少要让一位团队中的其他成员审查。
· 一旦他们的反馈有效，该ticket马上被部署到暂存平台上。
· 负责该ticket的开发人员现在检查“完成定义”中指定的所有设备上，所开发的功能是否与PO在ticket中写的功能描述相一致。
· 开发人员通知PO该功能已经开发完毕，可以在应用程序的新版本中进行测试。
这里至关重要的是没有库存、没有批处理。每一个功能都直接放入验证环境，理想情况下一旦通过验证，就直接进入生产环境：BAM员工采用的是One Piece Flow技术。BAM的做法不鼓励还没在设备上检查先前的功能前启动另一张ticket。
如果功能和ticket上所描述的不匹配，或者发现了错误，开发人员必须马上解决问题：他们必须马上行动以避免影响验证过程。
对BAM来说，功能的部署是关键过程。
我们来看一个实际项目：一家能源公司计划将其整个业务，从订购到账务和客服，进行数字化。BAM团队由全职的三位开发人员和一位开发架构师组成。
下面是采用科学方法（PDCA）的问题解决方案，它展示了这种方式的优点。
P代表Plan，计划 !
问题是什么？
Marek是BAM的CTO，他在来自Operae Partners的Marc的指导下，注意到在项目的Go & See的过程中部署和验证一个功能要花费相当长的时间，大约为20分钟。团队中的每个成员每天要花费一小时左右的时间在验证设备上部署功能：在部署时要缩减这个时间。
BAM员工试图历史性地将整个构建过程外部化：合并一个功能将自动启动一个新的部署。
于是，他们使用了一个专门的移动部署服务Bitrise。它运行良好，但是有几个主要缺点。首先，整个构建环境在每次部署时必须重建。它的确是自动的，但非常慢：在Bitrise上，整个部署和验证过程长达35分钟！
在Bitrise或CI上构建的速度比在开发机上要慢。
一开始，自动构建过程看起来是个好主意，因为它使得开发人员在等待部署完成的同时启动另一项任务。其缺点是会偏离One Piece Flow并增加了在制品（work in progress，简称 WIP）。
在部署仍然在进行时启动另一项任务是低效的：开发人员需要暂停在新功能上的工作来测试前一个功能，或者修复在开发环境中没有被发现的一两个错误等等。
最终，BAM完全停用了Bitrise（其部署时间长达35分钟）来部署，回到了最早的人工方式（部署和测试总耗时约20分钟）。开发人员在部署过程中需要等待，但是他们可以做其他处于等待状态的任务（读写邮件、更新问题解决表单）。
在BAM，没有标准的部署和测试ticket的最多耗时设定：根据Marek CTO的建议，要达到的目标是10分钟（参看下图）。
有哪些影响？
对于与BAM有时间和材料合同的客户来说，相当于每周有一个开发日在等待部署完成的过程中浪费掉了。
而且客户必须消化掉这些浪费：每次部署一个功能时，其不得不通过大量手动步骤（移动浪费）更新应用程序：在其设备上安装过程要消耗大约2分钟（安卓和iOS），每天要重复一到两遍。
对于开发人员来说，这种部署时间是种浪费，也让人感到不愉快。
对于BAM作为企业来说，这意味着生产力的浪费：每周有一人天被用于部署，也就是在冲刺过程中有2个或3个功能没能为客户进行开发。在项目结束时，就意味着少了5%的功能：对于一个有10个冲刺的项目来说，就是有20到30个功能没有实现！
什么是标准过程？
现在我们来看看构建一个移动应用程序所需的步骤顺序：
移动应用程序开发员Kevin利用计时器测量了部署一个功能所需的每个操作的消耗时间：
Kevin想要改善的是构建和安装这两个步骤。
那么，为什么呢？
Kevin确定了造成构建缓慢的两个主要原因。
第一个是构建时间，几乎要7分钟。目前，整个应用程序（二进制包和JS源代码）分别为安卓和iOS系统重建两次。在一个功能开发的过程中，二进制部分几乎是一样的，但是无论如何都要重建：这是一种过渡处理的浪费。
第二个原因是安装，一种动作浪费。在4台设备上更新应用程序需要3分钟。在这个步骤中，开发人员必须：
· 发布HockeyApp应用程序（开发人员专用应用商店）
· 刷新应用程序列表
· 找到应用程序
· 下载整个应用程序的更新包
· 安装整个应用程序更新包
现在要做什么呢？
关于应用程序的构建，需要一个新过程，允许只重新构建更新的代码，无需编译整个应用程序。这也许需要一个新的构建工具。
至于安装时间，开发人员只需要在设备上安装更新的代码，无需为每个功能重新下载整个更新包。
Kevin在CodePush tool中看到一些有意思的东西：
1、构建时间：不是重新构建本地模块，只是绑定资源和JavaScript代码。
2、安装时间：只下载更新过的JavaScript，而不是大小有10到20Mb的整个应用程序。
为了哪些预期结果？
对于这个全新的构建过程，所预期的结果是充分考虑这个新标准或新目标，也即在设备上构建、安装和测试新功能的耗时少于10分钟，其中包括4分钟的功能验证时间。
为了达到这个目标，构建和安装时间需要减半（从13分钟减至6分钟）。
做!
Kevin安装了默认自动更新的Codepush的本地模块，重新构建本地应用程序，在设备上安装并推送更新。
第一印象：构建时间更快，感觉上安装时间也更快了。Kevin把Codepush保留着，继续做了一周的软部署。
>它太可怕了！
为什么？因为开发人员永远不知道该应用程序何时被更新了，现在运行着的是代码的什么版本。开发人员只是启动了该应用程序，等待永远不会到来的更新，杀死这个应用程序，获取更新……
于是，Kevin把CodePush和该应用程序进行整合，并加以改善：他增加了一个带有安装状态的更新按钮，并显示CodePush的版本号和已部署提交的id。
手动安装更新让开发人员真正地感受到是他们在控制更新。显示已部署的版本号改善了他们和PO的沟通：一旦出现错误，他们知道到底是哪个提交在接受检测。
检查
结果如下：
· 构建时间从10分钟缩减到大约5分钟。
· 安装时间从3分钟缩减到1分钟以内。
· 安装更快了，开发人员经常让设备和设备实验室保持连接：这样可以节省额外的30秒钟。
整个过程从使用Bitrise的35分钟，缩减到手工操作的17分钟，最后是用CodePush的大约9分钟。
行动
通过解决这个问题，Kevin创造了一些新的“工作标准”。这是一个针对创建、安装及测试时间最大值的标准，同时创造了一个相应的新部署过程。
他采取的第一个行动是在横向范围内讨论这个问题：他召开了一个Yokoten研讨会议，在会上分享了这个问题并提出了解决方案。
他采取的第二个行动是在一些应用程序中为实施CodePush编写了新流程。现在，BAM的每个新员工都意识到了这一点，并在初期培训课程中接受训练。
Kevin采取的最后一个行动是实施“CocePush Dojo”，并鼓励大家在他的帮助下在他们的应用程序上安装CodePush。
如果我们专注于精益方法，就可以做如下记述：
· CTO的Go & See很关键，这让开发人员看到他们逃不掉的浪费，同时帮助他们自己识别出浪费。
· 要谨慎对待所谓能一次性解决众多问题的“银弹”式自动化解决方案（Bitrise）。
· 专注于单件的流转，避免多样工作同时进行。
· 通过缩短交付期，确定和量化可以消除和减少的浪费。
结语
面对数字时代潮流的挑战，管理人员和IT从业者往往会为了解决问题而去主动推进技术解决方案，而并没有了解细节，也没有去实际检查情况是否有所改善。
作为管理者或从业人员，应该抽身出来，让你的下级去思考如何改善他们的工作。精益系统已经被证明是一种可以帮助个人及团队成功的结构化方法。在IT领域，它就是所谓的精益IT，能够帮助你识别有意义的问题并予以解决。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
