09 | 精益看板（下）：精益驱动的敏捷开发方法

石雪峰



该思维导图由 AI 生成，仅供参考

你好，我是石雪峰。在上一讲中，我给你介绍了两种常见的敏捷框架：Scrum 和精益看板。我重点提到，关注价值流动是精益的核心理念，限制在制品数量则是核心实践。此外，我还给你介绍了实施精益看板第一步：可视化流程。那么今天，我会继续介绍剩余的四个步骤。
先提一句，如果你比较关心工具使用方面的问题，我给你分享一份有关常见的工具配置和使用方面的资料，你可以点击网盘下载，提取码是 mrtd。
好了，现在正式开始今天的内容。
第二步：定义清晰的规则在完成可视化流程之后，看板的雏形就出来啦。接下来你要做的，就是定义清晰的规则。
可视化的意义不仅在于让人看得见，还在于让人看得懂。工作时间久了，我们很容易产生一种感觉，那就是沟通的成本甚至要大于工作的成本。沟通的最主要目的就是同步和传递信息，如果有一种途径可以提升信息传递的效率，那岂不是很好吗？
而看板恰恰有一个重要的意义，就是状态可视化。团队的所有成员可以通过看板了解当前在进行的任务状态、流程中的瓶颈点、任务与任务之间的依赖关系等信息，从而自发地采取相应的活动，来保证价值交付的顺畅，使整个项目能够有条不紊地交付。
当然，如果想要做到这点，光靠可视化流程还远远不够，你还需要在看板的设计中融入一定的规则。这些规则可以大大地降低团队成员之间的沟通成本，统一团队的沟通语言，形成团队成员之间的默契。看板的规则包含两个方面，一个是可视化规则，另一个是显式化规则，我分别来介绍一下。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

精益看板方法是一种旨在提高团队交付效率和质量的精益驱动的敏捷开发方法。文章介绍了实施精益看板的六个步骤，包括可视化流程、定义清晰规则和限制在制品数量等关键步骤。在管理工作流程方面，文章提到了每日站会、队列填充会议和发布规划会议等常见会议形式。此外，建立反馈和持续改进被强调为方法的终点，强调持续优化的重要性。作者还提到了精益看板的成熟度模型，用于指导中大型团队实践看板方法。总的来说，精益看板方法强调通过规则设计和在制品数量的限制来提升团队的敏捷性和交付效率。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《DevOps 实战笔记》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(7)

最新
精选

Una_琴
在看板实践中，接触到很多开发人员，会觉得每日站立会花2-3分钟汇报自己的，花20-30分钟听别人的跟自己不相关，觉得很浪费时间，这个问题怎么解决呢？
作者回复: 我想问题的关键就是不相关，我猜你们的组织结构是职能型划分的，所以每个开发人员只关心自己的开发任务，对于其他需求跟我无关自然不关心。对于DevOps来说更推荐的是跨职能团队，大家作为一个完整的交付单元，交付完整的功能，自然彼此之间有依赖，也就不会不关心啦。
2019-10-31
3
9
leslie
抛开之前的第一点：其实今天课程的限制在制品数量、管理工作流程中的队列填充会议与发布规则会议确实是现实软件开发过程中很好的补充。不能说难点吧：可能很多没有想起且实际执行过程中肯定不容易，这就像<说透中台>的课程中王健老师讲中台的规划和落地一样；很多度如何去把控且什么阶段到什么样的程度-这个确实不容易推动和把控的。可能与其说精益驱动开发：不如说是利益驱动开发。几门课程一直在学习在相互补充：其实DevOps的落地和数据中台在某些方面是接近的。期待老师后续的分享。
作者回复: 呵呵，中台这个事情有点神话了，能整明白的公司也没几家，我们就是在挣扎中前进。。。
2019-10-31

3
陈斯佳
好奇的问一下，您有用过IBM的RTC这个工具吗？如果用过，您有什么比较好的学习资源推荐吗？我们公司现在正在推这个软件作为DevOps转型的主要工具…
作者回复: 你好，我还真没用过这个工具，然后稍微打听了一下国内某大型银行的一个项目使用的是RTC工具，我理解对于这种商业工具来说，他们应该会提供配套的支持服务吧，如果你们在使用中有什么具体问题，我可以帮忙打听一下😝
2019-11-04

1
happychap
老师，您好！有个实际问题一直很是困扰，即：不管选用哪种敏捷方式，都是需要拥抱需求变化的，然而，在我们的组织里面，在开始一个项目之前是有立项阶段的，这个阶段是需要规划需求、进度、人力资源、风险等等事项，进而决策项目是否准予立项~~ 感觉这和敏捷思想是冲突的，但是如果没有这个阶段，又无法在前期与需方（业务方）就项目范围、成本等达成一致，进而到项目后期扯皮~ 老师可以给些解决方法建议么？
作者回复: 你好，其实项目制在很多公司都是通用的，你提到的目标管理，项目管理，资源管理是典型的需求前的阶段，我们公司也不例外。但是，我觉得开发过程采用敏捷方式并不冲突，因为项目的目标需要进行需求，任务的拆分，实际开发和监督，过程也是渐进式的，比如可以把项目目标拆分几个大的需求，然后增量交付，解决开发过程的问题。
2020-02-03


Hunter Liu
矩阵型的组织架构，每个开发身上都背着好多项目的任务，我只能让开发在我的项目中的部分流程小范围试用。就怕还是换汤不换药。
作者回复: 你好，我们之前也是项目制的团队，根据项目临时组建，一套成熟的精益看板做法，非常适合新人加入团队，降低沟通和磨合成本，大家做起来也不觉得有很大负担，所以可视化这步可以先行推进起来。
2019-11-13


怀揣梦想的学渣
我以前的公司采用紧急项目发日报，非紧急项目发周报的方式替代每日站会。汇报主送项目负责人和问题需要求助的人，抄送与自己任务关联的人。内容包好（今日进展，遗留问题，明日计划）。项目负责人的助理会更新到总的时间表做标记，发给任务关联人。所有人都被拴在一起，一个人的任务受阻塞，关联人都可以看到任务阻塞带来的负面影响，会被迫的主动去协助处理问题的阻塞点。好处是项目里每个人都能看到进度条，并且知道进展细节。缺点是只要有人隐瞒或者敷衍上报，整体进度都会出现进展隐患，需要每个人都不能隐藏问题。
2023-06-01归属地：山东


Robert小七
现在很多团队是scrum+看板，工作流程还是用的scrum的4大会议，需求可视化用看板，一般没有限制在制品数量，看板中就绪状态后的所有状态都是一个迭代中的需求，按照迭代发布！只有一个迭代发布后才会进入下一个迭代！这种方式好像更加适合初期转型的团队，等到持续部署成为可能，再转为完全按照老师介绍的看板方法是否更好？
2020-09-23



收起评论