看板有什么问题?

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

在观察了过去十年的看板实施之后,出现了一个问题,即为什么我们中有这么多人未能使其发挥作用?我们试图找出导致看板失败的最常见原因。看看你的想法?

“它只适用于线性过程”

一种信念,因为看板最初是用来管理单线流程的,所以它应该保留下来,而您可以而且应该预见并在流程中注入任何额外的步骤,并真正将其可视化,以真正从看到哪里受益就是这个项目卡的最多,可以做些什么来改进它。

人们仍然将看板与汽车制造联系在一起,这确实遵循一个方向的过程,但事实是它一直被描述的方式并没有真正确定看板的作用。看板 - 作为一种变更管理方法,它是 - 旨在用作查看流程的方式,而不是作为规定的严格方法。

“看板是一种现成的工作方式”

不断将看板与 scrum、xp、瀑布和其他管理方法进行比较——同样,从一个角度来看,看板是一种带来变化的方式,这些比较毫无意义。将渐进的变更管理方法和任务管理流程结合起来试图权衡哪个更有价值,没有真正的目标,也没有价值。看板本身,没有任何定制和彻底的过程分析,对于复杂的项目——比如软件开发——可能是不够的,因为它没有带来严格的规则或实践。

它是一种管理变更的工具,要求您找到自己做事的正确方法,它不是一个随时可用的系统,它需要相关团队在其基础上进行构建。无论它是看板中的另一个系统,还是只是一组供团队遵循的良好实践,您都需要多参与一点。关键是不断改进和发展。

“我的团队不能做看板”

看板实施的一个经常观察到的问题是由人引起的。但是等等,这绝对可以应用于涉及人的所有事物。参加 scrum、什么都不做、卖面包的人——在这些情况下,相关人员会导致并遇到问题。这真的是看板问题吗?不。

然而,对于做看板的人来说,有一些很好的技巧,可以降低与看板相关的制造困难的可能性。他们是:

  • 让看板保持 最新 ——如果团队正在做一件事而看板显示的是完全不同的东西,你就知道事情会出错。确保董事会反映工作。

  • 让董事会代表正在遵循的 真实流程 ,而不是团队渴望拥有的流程。

  • 坚持设定的在 制品限制 - 有时打破它们可能是允许的并且可能是有益的,但将其作为一种常见做法等于完全放弃看板。他们在那里是为了改善流量,而不是为了战斗。

如果说有什么可以从中吸取的话,那就是不要将看板视为一种自我实施的神奇工具。它会很好地工作,只要你认真对待它并花时间让它尽可能地遵循你真正在做的事情(包括所有等待、回收和重新思考类型的列)并不断回过头来看看哪些步骤没有需要、应该添加什么以及需要进行哪些整体改进以使过程更好。