zoukankan      html  css  js  c++  java
  • 《看板方法实践体系》读后感

    最近拜读了一份看板方法的相关文章《看板方法实践体系》,在这里总结分享一下。本篇文章分为两个部分,第一部分会对文章做一个大致的梳理和总结,第二部分我将从个人的角度来谈谈对看板方法的感想。
    首先,文章全篇将看板拆分为五个部分:

    1. 可视化价值流动,重点要素有三个:
      • 可视化的价值单位应该是用户价值,要以用户价值为导向,每一个价值都应该是一个可验证、可交付的用户需求。
      • 要体现用户价值端到端的流动过程,就是价值从提出到交付的过程。
      • 问题要被可视出来,能从看板中看出阻碍或流动不畅的环节。
        此外文章还给出了可视化价值的建模方法:分析价值流动,选取可视化元素,建模价值流动。这个部分偏向时间话,这里就不叙述了,有兴趣的朋友可以移步文章。
    2. 显示化流程规则,文章提出了流程规则的三个步骤:
      • 组织和明确流程规则,包括规划价值的流转规则(在各环节中流转的规则),周期性活动的规则(站会、需求发布、上线等等),其他协作规则。
      • 团队共同拥有流程规则,团队成员要明确和理解规则,团队对规则理解一致自主的决策和协作。
      • 持续改进流程规则,对明确的规则进行改进和落实。
    3. 控制在制品数量,这里讲道了三个概念:
      • 束水攻沙,更少的在制品就可以更快的流转,将价值快速的流动(加速价值交付),对应的阻碍和问题也会凸显出来(即时暴露问题)。
      • 暂缓开始,聚焦完成,控制在制品数量的思想核心,“完成越多才交付越多,而不是开始越多交付越多”。
      • 湖水岩石效应,要从可行但有用的值开始,逐步暴露和解决问题,渐近改善交付能力。
    4. 管理工作项流动,这里也分为了三个实践来讲诉:
      • 看板站会,站会的目的是:检视价值流动状态,促进价值顺畅流动。
      • 就绪队列填充,确保输入能够符合团队的输入标准(能够合理迅速的流动);建立合理的输入节奏(填充频率过低会损害决策的质量和团队的敏捷性、填充频率过高带来额外的成本)。
      • 发布规划会议,建立发布规划的DoD、解耦部署和发布(蓝绿部署,特性开关、模拟环境)。
    5. 建立反馈和改进,通过度量看板的数据进行反馈,可用的工具有:累积流图、控制图、前置时间分布图。

    总结完文章,接下来分享一些个人的看法,首先是个人总结归纳的看板方法三个核心:

    • 可视化价值
      • 文章提倡以用户价值作为核心及单位,我的观点则略有不同,我觉得以交付的价值为核心会比较贴切一些。原因有二:其一,对于面直接面向用户的项目而言,交付价值等于用户价值,但是在一些非直接面向用户的项目下,用户价值这个概念可能会十分模糊且难以界定;其二,我认为看板方法应该是一个工具,一种方法,它可以被抽取复制在其他类似的领域或小规模的活动中,这时使用交付价值的概念就会更加的准确,便于方法的复用。
      • 详细体现信息在环节中流动的过程,由于每个人感知不同,所以问题与瓶颈是不客观唯一的,通过看板可以将问题聚焦在价值流动,能够客观的反应出问题的存在,同时也能反向推动团队成员来进行感知。
    • 控制价值的流动,我将显示化流程规则和管理价值流动整合在了这个条目内,这两点其实都是对于价值单元的控制。在这里将这也点重新划分为两大类:
      • 一是价值流动的类型,环节/价值自身的流转规则(自动化规则,即价值单元在各个环节中流转的规则,由团队成员自觉遵守,执行过程中无需变更);中间过程规则(对应手动规则,比如每日站会就是一个进行价值单元监控,人工干预控制流转的机制)。
      • 二是价值数量变动的类型,价值的输入(需求规划、紧急需求)、输出(价值交付)。
    • 建立反馈持续改进,基于发现的问题、瓶颈、实施过程中的感受等反馈,对整套看板方法和开发中的一切作出调整优化和定制化。

    看板方法是一个工具,虽然方法完整且相对较易于实施,但实践起来还是有诸多的难点,我认为有以下几点:

    • “人之蜜糖,我之砒霜”,看板方法不能简单的套用所有项目,这点在文章中有讲到,需要对应团队的情况来进行具体的实施和改进,而这是一个依靠经验和长期实施的过程,需要团队不断的踩坑试错改进才能成功。
    • 作为工具而言的门槛和学习成本其实很高,整套方案的实施具备一定的复杂度。比如文章介绍的全套看板方法,就有将近20个步骤和概念,且每个点都具有一定的理解难度和深度,看板方法作为一种“方法”十分依赖实践经验;文章在部分内容上讲得较理论化,比如介绍可视化价值案例时就省略了具体改造的过程,这对于学习者来说比较难以理解,更别说具体应用到整个团队上的情况了。我觉得应该对看板方法的进行拆解,拆分为若干个独立的功能模块,再结合团队当前的现状,针对病结所在“对症下药”,同时小步试错快速迭代,降低实施难度。
    • “看板方法应该被团队所拥有”,一个工具它应该为团队带来价值并落实到每个人的身上。其实,作为一个管理工具,看板方法需要与团队成员的自身利益产生关联,如果团队感受不到工具带来的好处从让团队自发的推动和执行,那工具就只是为团队带来额外的负担,进而在实施上只能依赖团队负责人进行推动,这又会产生几种情况:负责人管理任务过重无法兼顾开发和管理,一旦出现在高强度的开发工作时容易忽视管理,就会导致实施停滞难以继续推动;或是负责人过于注重管理和实施,成员只是遵照指令运作,由于下级是非自主的进行实施,容易产生消极倦怠,失误、反馈缓慢等等各样的问题,长期之后管理任务会更加繁重,形成恶性循环,管理难度也会不断爬升,最终导致实施失败。

    最后,看板方法是一个已经被业界证实的优秀先进且完善的项目管理方法,但同时,看板方法也经常被错误地理解和使用。其实,看板方法就是一个工具,它应该被团队所理解,应该被团队所拥有,更应该为了团队所服务。

  • 相关阅读:
    WINXP下安装IIS+PHP5+MySQL5 +Apache
    centos下配置apache+php+mysql!
    在C#中如何调用记事本
    使用c#捕获windows的关机事件(转载)
    C# WinForm中DataGrid列设置(转载)
    软件开发五要五不要原则
    ASP.NET2.0中将文件上传到数据库(转载)
    如何用C#和ADO.NET建立一个数据绑定网格(转载)
    SQL基础:常用SQL语句详解
    什么是极端编程?
  • 原文地址:https://www.cnblogs.com/qbzf-Blog/p/12500317.html
Copyright © 2011-2022 走看看