DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

08 | 精益看板(上):精益驱动的敏捷开发方法

石雪峰 2019-10-29
你好,我是石雪峰。
提到敏捷开发方法,你可能会情不自禁地联想到双周迭代、每日站会、需求拆分等。的确,作为一种快速灵活、拥抱变化的研发模式,敏捷的价值已经得到了行业的普遍认可。但是,即便敏捷宣言已经发表了将近 20 个年头,很多公司依然挣扎在敏捷转型的道路上,各种转型失败的案例比比皆是。
我曾经就见过一家公司,一度在大规模推行敏捷。但是,这家公司很多所谓的敏捷教练都是项目经理兼任的,他们的思维和做事习惯还是项目制的方式。即便每天把团队站会开得有模有样,看板摆得到处都是,但从产品的交付结果来看,并没有什么显著的变化。没过多久,由于组织架构的调整,轰轰烈烈的敏捷转型项目就不了了之了。
这家公司虽然表面上采用了业界流行的敏捷实践,也引入了敏捷工具,但是团队并没有对敏捷的价值达成共识,团队领导兼任 Scrum Master,好好的站会变成了每日工作汇报会。甚至在敏捷项目复盘会上,领导还宣称:“敏捷就是要干掉变化,我们的目标就是保证团队按照计划进行。”这种“貌合神离”的敏捷,并不能帮助企业达到灵活响应变化、快速交付价值的预期效果。
作为一种最广泛的敏捷框架,Scrum 的很多理念和实践都深入人心,比如很多时候,迭代式开发几乎等同于跟敏捷开发。但是,Scrum 对于角色的定义并不容易理解,在推行 Scrum 的时候,如果涉及到组织变革,就会举步维艰。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • maomaostyle
    敏捷推行的最大阻力就是改变管理层的价值观和对问题的认知

    作者回复: 呵呵,我之前去台湾参加DevOpsDays活动,就给我老板带了一本书做礼物,书的名字是《原来你才是团队绊脚石》,你也可以试试看效果如何哈。

    2019-10-29
    1
    5
  • 陈斯佳
    这篇文章纠正了我一个观念,就是看板不等于可视化板。看板的核心是加快价值流动,以拉动式生产为典型特征,约束制品数量为实践,灵活响应业务变化,快速交付价值。如果用这个标准来衡量敏捷程度,就不容易跑偏了

    作者回复: 是的,看板没有严格的时间盒的概念,虽然也会按照一定节奏的发布,但其实更理想的情况下就是随时发布,这对于内部平台来说并不是什么难事,你们可以在内部尝试一下😝

    2019-11-01
    3
  • sugar
    总有插入队列的“紧急需求”;前期没有明确,开发过程中持续掰扯。看到老师可视化流程这个,想起三年前有个领导针对开发团队提出过看板方法,不过富哦随着那个领导短暂的停留,也没继续保持下去。

    作者回复: 我在团队中也试行过很多实践,看板是自始至终坚持下来的,也的确经历了相当长的过程来养成习惯,但是一旦习惯了这种做法,整个状态的可视化会让你眼前一亮的。另外,我们经常会各种紧急需求打断,说实话一般也很难Say no,但是如果长此以往问题也不会自己好转,所以适当的积累一些数据也是很有必要的。

    2019-10-29
    1
  • Robert小七
    老师文章中提了站立会,想请问老师,正确的站立会应该如何做?

    作者回复: 你好,正确的站会我觉得应该有以下几个特征:自组织,暴露问题,反馈行动。自组织是说即便没有团队leader组织站会,大家也能按照既定的节奏来自发的组织站会,所以被动到主动的转变。暴露问题,就是团队敢于在大家面前暴露问题和风险,而不是一味的说明成绩,也就是心里紧张到心里安全的转变。反馈行动,就是站会上发现的问题能够直接影响接下来的行动,快速处理问题,也就是边说了白说到立竿见影的转变。

    2019-10-29
    1
  • Jxin
    1.精益创业
    2.去年从10x了解到精益创业和老板,就开始兴冲冲的想推行精益看板。结果从同事到领导一致否决了。最终也就只有站会推行下来了。事后我也有过思考,为什么推行不下去。首先,一开始看这么做是有维护成本的;其次,其价值并不直观,不具备一定知识背景也不容易看到价值;最后,人们在应对变化往往都会本能的敌对,特别是老领导对年轻下属,语重心长的拒绝有木有。
    所以,最好的办法就是在自己可控的小团先推行,拿的价值去说法,这样才是科学高效的方式。想单纯通过自己的嘴皮子说服所有人,除非你是忽悠大师,不然真的挺有难度。

    作者回复: 哈哈,即便是忽悠大师也很难长久吧,你看,连看板这种渐进式的变革方式都这么困难,就可以理解为什么很多敏捷转型死在半路上了吧。其实,我到认为,在一个小团队里面让任何可视化,不仅是什么价值提升,单纯的只是对于管理团队的进度而言,也有很大的帮助呀,即便你们每天在开站会,那对着一个物理看板,电子看板,大家也不至于空想对吧,所以在我经历过的团队中,看板的起步阶段还是比较顺畅的,最难的就是向前扩展到业务方,要跟他们掰扯限制任务数量,调整优先级上面,研发团队其他还是比较好沟通的。

    2019-11-08
  • 陈文涛
    关于看板,其实我一开始想做到我们的研发平台上的,但是后来想了下,还是不做的好,还是物理结构真实的贴便利贴的更具备仪式感,更有作用,老师您说是不是?

    作者回复: 没错!仪式感很有必要!人与人的沟通才是最直接有效的,你没看公司里面解决问题最快的方式就跑到他座位旁边吗😝 不过电子看板也是很有必要的,否则数据没法沉淀下来。

    2019-11-07
  • linda.zx
    关于老师提供的看板例子,“就绪”和“需求”不太理解,感觉只需要“就绪”就够了,为什么会考虑加“需求”这一列呢?

    我公司一直在高呼搞敏捷,但是偶觉得最大的坑就是留于形式的敏捷,披着敏捷的皮干着瀑布式项目。例如:需求虽然做着细化,但是还是一个人负责一个模块;一个需求开发完成了,测试人员并不会去测试,而是等到积累到一定程度才会开始测试。敏捷所带来的好处似乎根本没有体会到~

    作者回复: 简单理解需求就是Backlog,就绪就是待开发,从Backlog进入待开发状态是有门槛的,首先需求拆分要合理,可行性评估通过,跟研发沟通工作量实现等都没问题,说白了万事俱备就等开干。而Backlog里面会有大量的未经分析的需求,甚至很多都是一句话需求,实际上这个需求还可以站在需求分析的角度进行展开,比如需求提出,分析,评估等环节哈。

    2019-10-30
  • scorpiozj
    实践中 站会往往开成三四十分钟的汇报会!

    作者回复: 每日汇报会很常见,一开始大家也不习惯自组织的形式,我的建议是组织者后退一步,而不是站在中心的位置,约定好每次从不同人开始,尽量控制时间,当然如果有物理看板建议还是围绕在看板旁边,说话的人向前一步,这时候他就是中心哈。

    2019-10-30
  • iiiqueena
    关于最后一张看板图片,有些疑惑:
    1、通常需求“就绪”的定义是怎么样的?
    我所在的团队对“就绪”的定义是大家对需求达成共识,产品经理的PRD、设计师的交互设计稿准备完成。接下来的工作是开发进行编码/构建,与此同时测试同事进行测试用例/测试脚本编写。
    2、多维度的看板
    在1的在这种情况下开发和测试时并行的,我们的看板时采用需求-子任务(开发任务、测试任务)的形式展现。一个需求下的多个子任务(比如前端开发、后端开发、测试用例编写)会在同一时间处于一个泳道上。我们可以看到在这个看板上看到每个需求的子任务状态,而需求的状态只能通过手工去做维护,这是比较痛苦的一点。这可能需要通过另一个看板去专门表现需求维度的状态(类似于最后一张图片),这就增加了维护成本了。

    最后,希望老师介绍一下常见的看板流的最佳实践,谢谢。

    作者回复: 你好,关于需求就绪的定义,实际上就是DoR的概念,也就是Definition of Done,通俗理解就是类似你说的,万事俱备,只等开发投入就行的状态,但是我想提醒一下的是,需要有明确的验收条件。

    第二个问题,需求拆分是比较常见的场景,我没太理解你说需求状态只能手工维护的痛点,实际上如果使用了泳道,每一个泳道就是一个需求,可以把需求卡片贴在最前面用户故事列,然后前端,后端,测试任务放在各自的列中,只有当这些子任务都完成之后,才会连着需求和子任务卡片一起向下流转,其实还是比较清晰的呀。

    最后这个问题有点泛泛,不知从何说起,我的理解可以先遵守规则,再寻求发挥,可以先把看板的几项原则执行起来,所谓最佳实践会自然浮现出来的。

    2019-10-29
  • leslie
    其实老师的话题中不觉得在抛出另外一个问题么:敏捷是否真的敏捷?敏捷只是且仅仅是安排的紧凑且快捷而已。软件的目的是产生效率或者说简化人工操作/沟通的量:本质上还是节约人力成本。
         就像网银和手机支付其实节约的是许多超市大量的收银员雇佣的成本:为了敏捷而敏捷其实就脱离了本质,其实国内不少企业就用了丰田生产系统的做法融入其中。
         其实学这门课的同时在学<全栈工程师修炼指南>:相互融入才能合理。其实敏捷不适合在开发环节,个人觉得适合在运维中,运维经常充分利用任何程序的等待时间去做其它事情。

    作者回复: 将敏捷注入运维工作正是DevOps之所有诞生的源动力啊,我在公司里面也经常有种感觉,我们在关心流程,关心工具,关心业务,唯独没人关心人的问题,除了要考查人的效率高低之外。敏捷说的再神,说到底还是需要重视人的价值,就像用户故事,如果不让整个团队带入场景之中共创好的解决方案,而只是单纯的宣讲需求分配任务,那么谁还对敏捷感兴趣呢。

    2019-10-29
    2
收起评论
10
返回
顶部