敏捷开发看板方法的起源_敏捷开发 看板 - CSDN
  • 今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?! 我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效...

    今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

    我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

    • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。

    • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。

    • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

    可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!


    那么 Kanban 到底是什么呢?我们先来看看这张表格吧:

    image

    下面我们来理解一下这个表格吧!

    • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)

    • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)

    • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

    在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

    实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

    需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

    也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

    对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

    好!继续我们的 Kanban,有意思的事情即将发生!


    image

    产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

    开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

    开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


    image

    现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


    image

    有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


    image

    部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


    image

    此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


    image

    完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


    image

    所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


    image

    部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


    image

    整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


    image

    看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


    image

    几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。


    我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!

    image

    展开全文
  • 看板方法 看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。 经过60多年的发展和...

    看板方法

    看板(Kanban,来源于日语)最初是丰田汽车公司的大野耐一于20世纪50年代发明的,当时是从超级市场的运行机制中得到启示,将看板作为一种生产、运送指令的传递工具而被创造出来的。

    经过60多年的发展和改进,今天所谈的看板管理大多是指精益看板之父 David J. Anderson 发扬的管理方法,它既继承了丰田体系的精髓,又增加了诸多针对现代团队,企业管理非常有益的看板实践方法。现代化的看板系统始于2004年,最早是在微软的XIT软件维护团队中实施,得益于这个先河性的看板系统实施, 微软的XIT团队在生产率上有了超过200%的提升,前置时间减少了90%,在可预测性上也有了大幅提升。


    看板管理有哪些优势?

    通过使用看板系统,我们可以将团队的在做任务(work-in-progress)限制在一个设定的能力阈值内,根据已完成任务的交付速率来平衡交给团队的工作需求。(看板原理:利特定律)

    看板提供了视觉化的直观管理感受,它能迅速暴露那些影响团队效能的问题,因此,在使用看板管理的团队所面临的挑战是:如何专注于解决问题以维持稳定的工作流。(看板原理:消除瓶颈)

    看板很好的展示下游环节的当前状态,根据已完成工作确定前一环节可以投入多少资源,而不是前面环节使劲投入,不管后面环节是否能应对。(看板原理:拉动生产)

    看板也为质量和过程中出现的问题供了可见性,使得缺陷、瓶颈、变异性以及经济成本等因素对工作流与交付速率的影响变得更明显。仅就使用看板来限制在做任务这一做法,就能促成更高的质量和更高的效能。(看板原理:可视化)

    通过看板建立团队稳定的任务节奏,实现始终如一的可靠交付,这能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。而信任关系对每一方都是非常重要的。(看板原理:时间箱管理)


    展开全文
  • 今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它...
    今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它也可以和很多其他敏捷方法无缝连结。

    看板方法的起源
    中文意思带来误解
    看板方法的英文为kanban,和中文的看板正好音同,这个当然不是巧合了,看板起源于日本,它的日文注音也正好是'kanban',在日文中它也可以写作汉字“看板”,当然也可以写成日本假名。但是这两个意思完全不同,写作看板时接近“可视化的板”,而日文假名则为“信号卡”。
    软件开发中的看板应该更接近于信号卡,但是在国内,大家往往因名生义,把它看做可视化的板,所以往往忽略了其本质的意义,这也是看板系统在国内被普遍误解的一个重要原因。但是在国外,英语有对应的可视化的板---“kanban board”。所以我们称其为看板墙。
    信号卡的概念来自于精益制造,最早出现于丰田生产系统(TPS),我们先可以从制造中的看板学起,
    从而帮助我们理解本质,消除误解。

    我们可以从上图中看到,丰田生产过程有多个工序构成,其中有加工站,前工程,后工程。
    我们可以看到当后工程取件的时候,这个时候,前工程会有产品被拿走,导致空缺,然后加工站会根据前工程的产品空缺来进行生产,填补空缺。
    看板时丰田生产方式的两个核心工具之一,看板向上传递的信息流拉大乡下的物流,一直到交付客户,这样就导致了实际上最终拉动生产的是客户的需求。而产品开发则是借鉴的这个思路。
    这里我们就要讲一下什么是拉式开发和推式开发了。
    传统的推式开发,各个工序按照预先计划生产,将完成的组件推向下游,最求每个工序的产能最大。
    而拉式开发则是通过用户需求,从下游向上游传递信息,达到控制。
    那么拉动生产方式到底有哪些优点呢:
    1。控制库存:下游需要时上游才开始生产,有效控制库存
    2。加速流动:进入生产环节的物料和半成品,很快就被拉入下一环节,实现了保证安全库存的前提下物料最快流动,提高工程的运转效率。
    3。灵活响应:用户需求变化通过看板行程的信息流快速传递至各个环节,系统能够做出快的响应。
    4。促进改善:库存降低和流动加速,能够使生产问题快速暴露,比如生产环节的质量问题很快就会被下个环境发现。
    但是产品开发和生产制造有本质的区别,所以我们不能照搬看板方法,产品生产要有自己的看板方法。
    David J. Anderson 最早在软件开发中借用了看板实践,并且形成为完整的方法体系。我们下面按照看板方法5个核心实践来介绍。

    建立看板系统的3个实践:
    1)可视化价值流:产品开发中的价值流是不可见的,这样也就很难管理和优化。为此,看板方法首先要让工作和工作流可视化。
    从上图中我们可以看到可视化价值流的三个特点:
    • 首先可视的是用户价值,产品开发的目标也是交付用户价值,工作也应该从用户的角度来组织,图片中每个蓝色的卡片代表一个用户的价值,典型的是一个可以验证,可以交付的用户需求。
    • 接下来是用户价值端到端的流动过程,这里的端到端是指价值提出到价值交付的整个过程。
    • 最后所有问题和瓶颈也都要可视化,问题指的是阻碍价值流动的因素,包括需求不明确,技术问题,外部依赖等。而瓶颈包括价值积压等。

    2) 显示化流程规则

    价值流动过程也是团队协作交付价值的过程。为了更好的协作,团队还需要明确价值流转的规则。如下图所示,流转规则是价值从看板上一列到下一列必须达到的目标。
    显示化指的是明确并达成共识,这点和可视化不能混为一谈。
    所谓显示化流程规则只明确价值流转和团队协作的规则并达成共识。这个也是团队改进的基线,团队可以进行修正。
    3)控制在制品

    在制品(WIP)指的是在某一环节内所有的工作--包括进行和等待的。上图中红色数字就是在制品。
    环节内在制品数目小于这个数目的,可以从上一个环节拉入新的工作,否则不允许拉入。
    控制在制品数量可以是环节内并行工作降低,当个工作项的完成加等待时间缩短,工作项从进入看板到交付的时间也会缩短。因此,加入用户价值的流动。
    而且更重要的是,控制在制品数量可以帮助团队暴露问题和瓶颈。举个例子,上图中如果测试的在制品数目达到上限,就不能在拉入新的工作了,团队应该聚焦于完成当前的工作,及时处理出现问题,如果测试这里长期积压,那么说明这个地方已经成为了团队工作的瓶颈,更早的 暴露问题所在。

    控制在制品实际上成为了一种拉动机制,下游工作顺畅的时候才能从上游拉动工作,这样最终拉动整个用户价值流的交付。控制在制品是整个看板方法的核心,也是很有争议的地方,因为它很难落地在实际开发环境中。这个问题如果有兴趣的读者我们可以进一步根据实际例子交流。

    运作看板方法的2个实践:
    1。 管理价值的流动
    管理工作流包括三个部分,
    1)准备队列填充,准备队列是整个看板系统的输入和价值流动的源头,管理好准备队列非常重要
    2)站会。站会是管理价值流动的活动,一个站会要发生每天的同一个时间看板前,团队成员更新并且根据看板上的卡片,关注出现的问题和阻碍,并且形成解决方案。
    3)评审。评审是需求发布前的活动,决定上限哪些功能和相关的策略。

    2。建立反馈,持续改进

    其实现实中总会有各种问题让价值流动不畅或者阻碍,同时这也是我们的改进机会。当然这个前提是团队必须建立有效的反馈系统,从问题中发现根本原因。
    反馈的目的是为了改善。团队根据反馈形成系统的认知必须最终落实到具体的改进行动,而这些行动也可以放到看板系统的调整中,而且其中一部分也可以放到看板外,比如说产品设计,团队调整,环境及工具的改进等。但是无论哪种改进,效果都要通过看板系统中价值流的状态的度量来考察,从而形成看板系统的改进闭环。
    本文初步介绍了一些看板相关的知识,其中看板的核心方法是控制在制品数量的拉动系统,通过这个来暴露问题,团队能够根据问题进行反馈和改进,从而提高价值交付能力。



    展开全文
  • 看板方法起源于丰田精益,最核心的理念就是减少浪费。而精益生产分析技能在敏捷中的体现,就是“价值流程图”工具,可以帮助我们识别 7 大浪费,减少浪费就是在增加价值。7 大浪费如下,可用 WIDETOM 来便于记忆: W...

    看板方法起源于丰田精益,最核心的理念就是减少浪费。而精益生产分析技能在敏捷中的体现,就是“价值流程图”工具,可以帮助我们识别 7 大浪费,减少浪费就是在增加价值。7 大浪费如下,可用 WIDETOM 来便于记忆:

    W - 等待 waiting 
    I - 库存 inventory 
    D - 缺陷 defect 
    E - 额外流程 extra processing 
    T - 运输 transportation 
    O - 过度生产 over-production 
    M - 动态 motion
    

    让我们带着减少浪费的想法,引出和思考敏捷其中的三个概念,看是如何与看板当中的概念相结合的。

    概念一:WIP(work in progress)在制品限制

    理想的WIP是,5名团队成员WIP为5,即每名团队成员同时只做一个任务。这样有助于:

    创造专注高效的工作环境。WIP通过限制团队成员,让团队成员更专注的做当前的任务,避免工作时间碎片化,每一次被打断,都需要浪费时间来重新找回思路,往往结果就是一天都很忙,但是产出不尽如意,容易失误产生 bug。因为多任务的切换,会造成恐怖的 20% 到 40% 的工作浪费,这是跟随 WIP 的指数增长的曲线。

    实践敏捷尽早反馈的原则。周一同时开展 3 个任务,周三同时完成,产品经理和测试的反馈时间周期,每个任务都为 3 天。如果换成每天完成 1 个任务,每个任务的反馈时间周期都为 1 天。产品经理、测试和开发,团队中的各个角色,可以更均衡的工作产出,避免前期开发后期集中或者压缩测试时间,能够更稳健的长久的进行敏捷实践。也可以用更低的开发成本拥抱变化,来实现更高的产品价值。

    Xnip2019-12-25_13-34-30.png

    (看板中的 WIP 在制品限制)

    概念二、Pull 拉动式生产

    拉动式生产,即下游自由选择完成职责范围内的任务,而非上级安排给下级,组长安排给组员等等。那谁来拉动,推进任务,答案就是自组织团队中的每一个成员。

    拉动式能够避免产生,任务堆积库存产生的浪费。假设一个常见的开发情景,团队成员因为能力不同,任务复杂度不同,任务的完成时间很难按照理想时间卡点完成,进而造成,某些成员头上有多个未完成任务,某些成员已经没有任务可做,任务堆积在某个成员身上,形成整个协同开发流程的小瓶颈。这种瓶颈可能出现在团队中的产品经理、架构师、设计师、开发、测试、运维等各种角色成员身上。

    如何解决卡时间点协同的问题?当任务不是分配,而是团队成员空闲时自己领取新任务,就自然而然的解决了。任务的自领取,还可以强化责任心,做自己感兴趣的任务,有更强的自驱力,和自身能力匹配的新技能学习。有些公司还喜欢通过加班完成,但这也违背敏捷可持续的原则,和信用卡透支一样,未来都需要偿还更多的利息。

    如何保证团队成员领取,自己能够胜任的任务。首先敏捷中相信和不抛弃每一个成员,他们都能最大化发挥自身的价值,自组织团队。然后,敏捷中提倡 T 型人才,高可通用性。这样可以达成更低的任务依赖复杂性,每个人都可以胜任每一个任务,而不是卡在架构师、运维等关键节点。

    减少库存产生的浪费,同理在 DevOps 当中的单件流(one-piece-flow)概念,云计算的 Serverless,都能看到减少库存浪费的影子。

    Xnip2019-12-25_13-32-25.png

    (向右拉动式生产)

    三、可视化的概念

    看板在敏捷中是重要的信息发射源工具,贯穿在 Scrum 冲刺中的各个角落。例如每日站会中浏览一下,干系管理中实时协同进度。好的信息发射源要简单、影响、直观、当前、高可见度等等。

    Xnip2019-12-25_13-31-32.png

    (全屏模式)

    Xnip2019-12-25_13-35-32.png

    (看板自定义设置)

    Xnip2019-12-25_13-33-06.png

    (按照用户故事分组查看,与按照负责人分组查看)

    Xnip2019-12-25_13-33-57.png

    (全部收起/全部展开)

    最后,我们可以看到敏捷中的理念和工具,都是相辅相成,而非孤立存在。我们可以借助看板工具,来实践敏捷,减少浪费从而产生更多的价值。

    Worktile官网: https://worktile.com/

    本文作者:Worktile 高级工程师 甄帅
    文章首发于「Worktile官方博客」,转载请注明来源。

    展开全文
  • 看板方法是精益产品开发的重要实践。与其它敏捷精益方法相比,它在很多方面优势明显,如 :更强的可实施性、提升端到端价值交付能力、更好支持规模化实施和更系统的改进等。同样重要的是看板方法可以与持续交付、...
  • 增量交付开发 敏捷开发 当操纵金属和塑料而不是一和零时,是否有可能进行敏捷开发过程? 还是敏捷开发硬件的想法是错误的? 事实是,越来越多的组织给了瀑布式的支持,并转向基于scrum , lean和看板的模型,因为...
  • 一个采用瀑布模型开发的传统团队进行敏捷转型应该从哪里开始?怎么开始?除了前期的相关准备工作(包括敏捷松土、导入敏捷培训、价值流分析等等),在我的实践经验中,我认为最好的做法是直接从看板开始。将工作中的...
  • 敏捷是一个术语,用于描述软件开发方法,强调增量交付,团队协作,持续计划和持续学习,而不是试图在接近结束时立即交付。 敏捷专注于保持流程的精益,并创建最小的可行产品(MVP),在最终结果出现之前经历多次...
  • (2)初识看板

    2017-07-23 16:43:43
    今天我们来介绍一下敏捷开发中常用的第二个实践,看板方法。其实,看板方法实际上可以说是精益产品开发的重要实践,与其他敏捷方法相比,它具有更强的可实施性,提升端到端价值交付能力,更好支持系统的改进。而且它...
  • 广义而言,精益与敏捷是两组具有高度兼容性的价值观和原则,都阐述了如何成功地进行产品开发。Scrum、XP和看板则是将这些原则运用到实践中的三种具体方法。换句话说,它们是精益和敏捷软件开发里轻度重叠的三种不同...
  • 敏捷项目管理(SCRUM+看板+极限编程XP) 多年项目管理实战经验,多项项...
  • 摘要:敏捷这个含着金钥匙诞生的“霹雳娇娃”是软件开发行业的救星,从头到脚、从里到外无不闪着...为此,社区之星第15期采访了敏捷开发老兵陈勇。他站在企业管理者的角度来讲解敏捷开发并分析的字字珠玑。陈勇,16年
  • 本文将分享自己对敏捷开发的认识,和实现敏捷开发思想的核心方法敏捷开发: 一、什么是敏捷开发?   AgileDevelopment是一种以人为核心、迭代、循序渐进的开发方法。 1、以人为核心 vs  以文档为驱动   ...
  • devops和敏捷的关系 看板并不新鲜。 实际上,它早于本文的大多数读者。 从我们对DevOps文章的DNA分析得出的时间轴图像中,我们将丰田在其主要工厂机械车间中引入看板的年份(1953年)变得很明显。 二十多年来,我...
  • 我们经常被问到这个问题:什么是敏捷方法论 (Methodologies)?很简单,敏捷是IT行业用来描述项目管理的替代方法的炒作词。 敏捷是一个过程,可以帮助团队快速,不可预测地响应他们在项目中收到的反馈。它为在开发...
  • 职能筒仓在软件开发当中,尤其是敏捷开发当中,貌似带着负面的光环,最新的特性团队建设试图打破职能筒仓。而在看板列设置的时候,按角色划分的看板列在形状和内容上都太像职能筒仓了,难道看板这样的列设置走了回头...
  • 敏捷开发人员结构 敏捷已成为开发软件的默认方法。 有时,似乎每个组织都在做(或想做)敏捷。 但是,许多公司没有尝试改变其文化以使其变得敏捷,而是试图将诸如scrum的框架强加给开发人员,寻找提高生产率的神奇...
  • 第三章 敏捷软件开发

    2019-07-12 17:34:03
    第一节 敏捷软件开发敏捷早于devops适用于DevOps的软件工程...·当前公认的适合于DevOps的软件过程方法敏捷软件开发(包括Scrum、eXtreme Programming、Kanban等),尤其是敏捷软件开发中的Kanban(看板方法。·...
  • 敏捷开发 敏捷个人 如果不是最好的话, 敏捷宣言可能是软件开发中最好的书面宣言之一。 简洁大方。 好vs差1 2 3 4,完成。 如此简单,以至于我一直对互联网上流传的大量内容,什么是敏捷,什么不是敏捷,如何做敏捷...
  • 敏捷是什么

    2018-08-09 16:43:12
    敏捷是一种过程控制论,一种做事情的方法敏捷是一套工具集;看板、站会、用户故事等等都是它的工具; 敏捷是一种企业管理方式。可以通过敏捷的方式把大团队拆分若干个敏捷小组。 他是一个用于开发和维护复杂...
1 2 3 4 5 ... 9
收藏数 169
精华内容 67
关键字:

敏捷开发看板方法的起源