【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

如何通过解决精益问题提高敏捷团队生产力

  • 2018-01-16
  • 本文字数:4647 字

    阅读完需:约 15 分钟

本文要点:

  • 面对问题时,科技公司的员工总有要迅速找到解决方案的压力
  • 这些解决方案也许有用,但不总是最佳方案,还可能会产生意想不到的后果
  • 应用严谨的方法明确地描述问题、诊断根源、实施相关的纠正措施、评估效果、帮助人们更好地了解工作并改善日常工作实践
  • 精益思想以结构化的方式揭露和消除开发过程中的浪费
  • 不同类别的浪费要用不同的方法解决

如今的科技公司正面临数字时代潮流的挑战:不断提高的用户期望、技术的断档和激烈的竞争。管理人员和 IT 从业人员在效果不确定时倾向于主动推动技术解决方案以解决问题,但他们总是遭遇失败……甚至有时有些选项从未被评估过。他们缺乏正确和严谨的方式来明确地描述问题、诊断根源、实施相关的纠正措施、评估效果、帮助人们更好地了解工作并改善日常工作实践。

本文中提到的 Marek 是一家法国移动开发公司的 CTO,在文中提到的 Kevin 是一位程序员。通过耐心地观察开发人员的工作及软件各部分是如何流转及停止的,Marek 揭示了在验证和部署过程中的浪费,这些浪费严重影响了开发人员的生产效率。

文中详述了一个实例,其中的移动应用程序敏捷团队成功地将其生产力提高了 15%,通过该实例您将看到精益管理的方式和问题解决方案具体是如何帮助敏捷团队的。

移动解决方案合作伙伴

总部位于巴黎的 BAM French 公司为企业和初创公司提供移动解决方案和专业知识,以帮助他们应对业务挑战。BAM 员工尽可能高效和快速地工作,为其客户提供价值,他们采用的是精益创业方式和 1 周冲刺的 Scrum 方法。

事实上,应用的部署真是又费时又费钱。

作为精益工程师,BAM 员工遵循一系列的步骤来创造这个价值:

  1. 被视为客户的产品所有者(product owner,简称 PO)正式确定一张 Trello 卡的功能(Trello 是一个数字任务板软件工具)。
  2. PO 优先考虑新功能。
  3. 技术团队承诺每周开发一套功能。
  4. 每个功能在被视为“完成”前遵循其自身的工作步骤:
  5. 开发人员领取一张 ticket 并开始工作。其有责任完成该 ticket 所对应的功能,并且必须得到 PO 对该 ticket 的验证。
  6. 开发人员为实现该功能进行编码、测试、重构代码等等操作。
  7. 代码一旦写好,至少要让一位团队中的其他成员审查。
  8. 一旦他们的反馈有效,该 ticket 马上被部署到暂存平台上。
  9. 负责该 ticket 的开发人员现在检查“完成定义”中指定的所有设备上,所开发的功能是否与 PO 在 ticket 中写的功能描述相一致。
  10. 开发人员通知 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 分钟(参看下图)。

有哪些影响?

Sprint

Points

Total features

Time lost per week (17 vs 10 min)

Sprint 9

147

51

5h 57min

Sprint 10

98

34

3h 58min

Sprint 11

158

57

6h 40min

对于与 BAM 有时间和材料合同的客户来说,相当于每周有一个开发日在等待部署完成的过程中浪费掉了。

而且客户必须消化掉这些浪费:每次部署一个功能时,其不得不通过大量手动步骤(移动浪费)更新应用程序:在其设备上安装过程要消耗大约 2 分钟(安卓和 iOS),每天要重复一到两遍。

对于开发人员来说,这种部署时间是种浪费,也让人感到不愉快。

对于 BAM 作为企业来说,这意味着生产力的浪费:每周有一人天被用于部署,也就是在冲刺过程中有 2 个或 3 个功能没能为客户进行开发。在项目结束时,就意味着少了 5% 的功能:对于一个有 10 个冲刺的项目来说,就是有 20 到 30 个功能没有实现!

什么是标准过程?

现在我们来看看构建一个移动应用程序所需的步骤顺序:

Ideal Step

Ideal Time

Build the updated application

1’’

Install the update on the devices

1’’

Manually test the feature on production devices

Dependent on the feature

Notify the client that the new feature is available

1’’

移动应用程序开发员 Kevin 利用计时器测量了部署一个功能所需的每个操作的消耗时间:

Ideal step

Step

Waste family

Time needed

Build

Android build

Waiting

2’08’’

iOS build

Waiting

4’44’’

Install

Walk to the device lab and unplug the devices

Transport & Over-processing

30’’

Install the update on all devices

Motion

3’16’’

Test

Test the feature

复制代码
**416’’**

Install (back to initial state)

Tidy the device lab, re-plug the devices

Transport & Over-processing

1’25’’

Notification

Back to computer, login, Trello, move the card

Transport

45’’

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,能够帮助你识别有意义的问题并予以解决。

作者简介

Kevin Raynel 是架构师、程序员,曾在 BAM、现在 Theodo 从事培训工作。在过去的 5 年里,他一直利用不同的技术开发移动和网页应用程序。除了工作中的技术部分,他还利用精益思维和问题解决方法专注于帮助其公司及客户用最可能高效的方式开发应用程序。

Marc Legru 为 CEO/CTO、管理人员、团队领导者和团队培训敏捷 / 精益 IT。他帮助初创公司的 CEO/CTO 持续成长。他是 Operae Partners 的合伙人,该公司是一家专业为初创公司和传统组织提供精益 IT 和精益服务的咨询公司。Marc 和法国初创公司 UNOW 合作撰写了第一个法国精益管理入门 MOOC。他的推特账号是: http://twitter.com/MarcLegru。

Stéphane Wojewoda 帮助人们和企业以可持续的步伐成长发展。他热衷于紧跟技术和文化领域的最新潮流。当与其合作的团队达到这个目标:理解其所从事的工作,能够在正确的时间用足够的努力做正确的事时,他会为之感到高兴。

查看英文原文: https://www.infoq.com/articles/lean-problem-solving

感谢冬雨对本文的审校。

2018-01-16 16:491773
用户头像

发布了 199 篇内容, 共 81.4 次阅读, 收获喜欢 293 次。

关注

评论

发布
暂无评论
发现更多内容

raft协议中, 候选人角色能参与投票吗

程序员老王

raft

手写一个Vue风格组件

林浩

Java 大前端 webpack

kubernetes 集群安装(kubeadm)

小小文

Docker Kubernetes 群集安装 etcd

Swift十年

SwiftMic

Swift十年

负载均衡+分布式数据库

鲁米

ARTS打卡第3周

Scotty

流量控制算法

架构 流量控制 流控算法

Android | Glide细枝篇

哈利迪

android 源码

【总结】性能优化

小胖子

区块链技术助力打造新公益样板

CECBC

看动画学算法之:排序-选择排序

程序那些事

数据结构 算法 动画

生活困境

落曦

redis系列之——数据持久化(RDB和AOF)

诸葛小猿

redis 持久化 aof rdb

区块链想要拥有互联网级的用户体验,如何从应用层与公链去改进?

CECBC

那些好用的命令

北漂码农有话说

个人博客网站搭建

北漂码农有话说

第七周作业

田振宇

Flink 生态:Pulsar Connector 机制剖析

Apache Flink

flink

Debug ArrayList源码

Noneplus

Java

架构师训练营第六周课后总结

Cloud.

隐私计算:实现数据价值释放的突破口

CECBC

密码学 政策扶持 隐私计算 发展现状

写一个并发测试工具

罗亮

使用 Docker 部署 Django + MySQL 8 开发环境

AlwaysBeta

MySQL django Docker Dockerfile Docker-compose

命令行一键启动Hadoop集群

我是个bug

大数据 hadoop hdfs YARN Big Data

架构师训练营架构第七周总结

Cloud.

追光逐影:曝光相对论(1)

北风

摄影 影调 曝光 黑白

架构师训练营第六周-总结

王权富贵

tcpdump 实例-获取网络包的50种方法

Rayjun

TCP/IP tcpdump

CAP原理

鲁米

《架构师训练营》第七周命题作业

《架构师训练营》第七周总结

如何通过解决精益问题提高敏捷团队生产力_精益_Marc Legru_InfoQ精选文章