敏捷开发 看板照片_敏捷开发 看板 - CSDN
  • 敏捷其实很简单(4)--初识看板

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

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

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

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

    2) 显示化流程规则

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

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

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

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

    2。建立反馈,持续改进

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



    展开全文
  • 敏捷开发看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?   在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三...

    敏捷开发的看板不仅仅只是看板?在敏捷开发中为什么要采用看板?如何设计好的看板?任务条是改进的关键?

     

    在我的理解中,敏捷开发中最先需要实施的三项重要工作需求用户故事化,沟通站会制以及进度看板化,这三个如果实施好了,不管你是否在实施真正敏捷还是对当前项目管理方式的一种改进,都能在研发管理过程中取得很大的进展。

     

    前面两篇文章讲了用户故事和站会,这章就重点讲述项目进度看板化,本人会结合实际项目操作过程及对看板演进的过程进行讲解。

     

     

    什么是看板?看板不仅仅是看板?

     

    看板一词来自日本(kanban),源于精益生产实践(丰田生产),敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理最大的可视化,但是看板更可以将研发的过程进行管理,记录下用户故事研发过程中的细节和历程。

     

    敏捷开发为什么要采用看板?

    看板可以让研发过程最大限度的可视化,同时解决团队沟通障碍(实践中发现也可以作为和上级沟通项目进展的重要信息)的主要方法之一。通过看板,项目团队可以清楚了解已经完成的情况,正在做的以及后续将有可能需要做的用户故事。

    看板可以作为敏捷团队每天站会的讨论的核心,及时变更看板各个用户故事的状态,通过看板,敏捷团队可以清楚的了解其它成员的工作状况及和自己相关工作的进展。

    在状态墙上,除了用户故事、 bug之外,还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务,这三类任务用不同颜色的卡片,放到状态墙上统一管理。

    敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                                            1.实际项目看板

             看板状态呈现可以很简单,也可以很复杂,这都基于实际项目的需要,我结合我们在实践敏捷研发过程中,对看板的几次改进进行分享。在介绍之前需要对用户故事的“完成”状态下个定义, 用户故事的“完成”是指经过测试并可潜在发布给用户使用的状态

     

     

    第一阶段:简单的反映用户故事目前处于的研发状态

            

    敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                                   2 简单的讲用户故事的任务上墙

             刚开始实施敏捷的时候才用最简单的看板,如上图2所示,只是简单的将用户故事的研发上看板,基于此看板我们能清楚的指导目前用户故事处于的状态。但是这种简单的看板存在一些明显的问题,如研发人员和测试人员的沟通状态无法在看板上进行体现。

             所以在第一阶段我们又进行修改,增加研发和测试的衔接,如下图3所示

             敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


    3 细化“正在做”的状态

             在改进后,我们“正在做”阶段进行细分为开发中,待测试机测试验证,

             这样的看板流程可以有以下一些好处

    1.       通过这个改进流程就可以通过看板呈现研发完成到测试阶段,从测试阶段到完成阶段的展示。

    2.       通过看板上用户故事数量的状况,可以预测目前研发资源和测试资源配比是否合理?根据状况可以及时调整人员。

     

    第二阶段,通过泳道方式,让实现用户故事团队成员间的协作得到反映

             我们开展的项目由于是端到端的系统,所以往往一个用户故事的实现会涉及多个成员的共同参与,所以一个用户故事的完成依赖于多个人员负责的Task完成。所以针对这种情况我们进化了图4的方式,

     

    敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                         3 采用泳道方式进行管理

             具有泳道特性的看板,在移动状态时需要参照以下流程

    1.       当一个用户从“将要做”移到“用户故事”列时,需要将用户故事涉及的多方成员的工作进行任务拆分,拆分成一个个的任务。

    2.       成员针对任务进行工作,当所有成员的任务完成后,将完成的用户移到测试验证列中。

    3.       如果测试发现问题,则将相关的bug报给对应任务的人。

     

    泳道方式的看板具有以下一些优点

    1.       在多个人协助的情况下,每个人可以独立完成分配的Task,相互的影响和制约可以降低到最小。

    2.       每个人完成的Task可以作为用户故事的阶段成果,可以尽早的引入测试进行功能测试。

    3.       可以非常清楚的了解整个用户故事的进展情况,了解用户故事处于的障碍。

    但泳道方式也存在以下不足之处

    1.       由于用户故事被拆分成分工明确的Task了,所以这个用户故事内部进入了阶段提交的过程。

    2.       由于大家被拆分到了Task,所以需要指定特定的人来负责整个用户故事,并需要在内部协调项目之间的工作

    3.       用户故事的工时预计又被模块拆分,在长期实践中,导致工时的预计又进入负责任务的人进行预估的模式。

     

    第三阶段,通合理设计任务条,实现故事,进度,工时和各类衔接工作

             在实践了一段泳道模式之后,我们重新思考了,如何让各类工作更好的衔接。最终在任务条上进行改动是最合适的。所以我们根据实践过程中发现的问题,形成了如下的任务条。

             敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?


                                                            图四 全面体现工作的任务条

    此看板的任务条主要体现几大方面

    1.       用户故事的描述,这个作为任务条核心部分,通过模块和ID和需求系统进行对应

    2.       研发团队先对用户故事进行整体工时预估,得出这个用户故事团队的工作时间。

    3.       涉及这个用户故事的所有人员都列在用户故事的下方,并且通过每天对当前用户故事的总工作量的预估,以及填写昨天的实际开发所耗工时

    4.       用户故事指定相关责任人及依赖关系,可以明确的找到相关人员进行协调和解决

    5.       通过bug list列出发现的问题,开发人员可以及时修改

     

    采用了这种任务条后,就取消了泳道的模式,而是采用需求,UI设计,开发,单元测试,待测试,测试中,完成几个状态来完成。在我们项目中UI设计进行独立管理,是因为在整个UI设计是我们的瓶颈所在,需要及时查看UI任务堆积状况,及时调整UI的工作优先级状态,所以针对UI我们会独立出任务。

     

    敏捷开发 <wbr>如何设计好看板?:敏捷看板成功实施的关键?如何通过看板实现项目可视化?

                                                  5完整看板状况

     

    在做好看板工作时需要注意以下几点

    1.       找到一种好的材料来制作任务条,以确保任务条容易被移动,不易掉落并且容易被收藏。一旦这个环节没有做好,很可能会导致看板维护成本加大,甚至后期不维护看板。

    我们在这个过程中尝试了很多,如中便签条+小便签条, 大便签条, 纸板+橡皮泥等等,最终结合我们的看板是基于玻璃的,最后选择了打印纸+透明胶的方式,移动很方便,而且不容易掉。

     

    2.       及时更新任务条中的各类状态,任务条不仅仅只在看板上移动,更重要的是要记录下研发的过程,这样很容易制作燃尽图,工时消耗图等供全局使用的报表。我们的做法是在站会钱5分钟,大家先更新状态,PO及时统计各类数据。

    展开全文
  • scrum敏捷开发框架 由于Scrum和看板都属于敏捷框架的保护范围,因此许多人将其混淆或认为它们是同一回事。 但是有区别。 一方面,scrum更特定于软件开发团队,而看板则被许多类型的团队所使用,并专注于提供敏捷团队...

    scrum敏捷开发框架

    由于Scrum和看板都属于敏捷框架的保护范围,因此许多人将其混淆或认为它们是同一回事。 但是有区别。 一方面,scrum更特定于软件开发团队,而看板则被许多类型的团队所使用,并专注于提供敏捷团队工作流程的可视化表示。 有人认为看板是要把事情做好,而Scrum就是要把事情做好。

    历史课

    在我们深入了解Scrum和看板之前,让我们谈一些历史。 在Scrum,看板和敏捷开发之前,就已经有了瀑布模型。 它在80年代和90年代很流行,尤其是在土木工程和机械工程领域,这些领域很少发生变化,设计通常保持不变。 它被用于软件开发,但是并不能很好地转化为这个领域,其结果很少有人期望或期望的。

    2001年, 敏捷宣言作为克服瀑布问题的替代方案出现。 宣言概述了敏捷原则和信念,包括缩短交货时间,开放沟通,简化流程,持续培训以及适应变化。 当涉及到软件开发实践和团队时,这些原则就可以发挥自己的生命。 在出现异常情况,错误或客户不满意的情况下,敏捷使开发团队能够快速进行更改,并且软件发布速度更快,质量更高。

    什么是敏捷?

    敏捷框架(或简称为敏捷)是多种迭代和增量软件开发方法(例如看板和scrum)的总称。 看板和Scrum本身也被认为是敏捷框架。 正如Mendix解释的那样

    “虽然每种敏捷方法类型都有其独特的特质,但它们在创建应用程序时都包含了迭代开发和持续反馈的要素。任何敏捷开发项目都涉及持续的计划,持续的测试,持续的集成以及其他形式的持续开发。敏捷框架产生的项目和应用程序。”

    什么是看板?

    看板是日语中“视觉信号”的意思。 它也是一个敏捷框架或工作管理系统,被认为是功能强大的项目管理工具。

    看板(例如Wekan ,一个开放的看板应用程序)是一种视觉方法,用于通过一系列固定步骤来管理产品的创建。 它强调连续流动,并被设计为在板上的列中显示的阶段列表。 看板董事会开始时有一个等待阶段或积压阶段,可能有一些进度阶段,例如测试,开发,完成或放弃。

    Wekan kanban board

    项目中的每个任务或项目的一部分都显示在卡片上,并且卡片在各个阶段中进行时会在此板上移动。 卡的当前阶段必须完成,然后才能移至下一阶段。

    看板的其他功能包括颜色编码(以视觉方式识别任务的不同阶段或类型)和在制品WIP )限制(以限制工作流的不同阶段所允许的最大工作项数)。

    Wekan 与Trello (专有的看板应用程序) 相似 是各种数字看板工具之一。 团队还可以使用传统的看板方法:墙壁,木板或大张纸,上面带有不同颜色的粘滞便笺,可以完成各种任务。 无论使用哪种方法,其想法都是有效,高效和连续地应用敏捷。

    什么是Scrum?

    Scrum通常涉及每日站立和冲刺,以及冲刺计划,冲刺评论和回顾。 每天都有Scrum和2到4周的冲刺(将代码投入生产),目的是在每次冲刺之后创建可发货的产品。

    team_meeting_at_board.png

    每日站立会议允许团队成员共享进度。 (照片来源:Andrea Truong)

    Scrum团队通常由Scrum主管,产品所有者和开发团队组成。 为了使客户满意,所有企业必须同步运行,以生产出高质量的软件产品。

    Scrum还是看板哪个更好?

    以所有这些为背景,我们剩下的重要问题是:哪种敏捷框架是高级,看板或Scrum? 这要看情况。 当然,这不是一个简单明了的选择,也不是一种方法固有的优越性,但是鉴于组织的状态,团队的组成,要生产的产品或服务,一种方法可能比另一种方法更有价值。 在某些情况下,即使同时使用看板和Scrum,Scrumban(如果您愿意)也是一个有效的选择。

    软件开发团队通常使用Scrum,因为发现Scrum在软件生命周期过程中非常有用。

    看板可用于各种团队,包括IT,市场营销,人力资源,转型,制造,医疗保健,财务等。其核心价值是持续的工作流程,持续的反馈,持续的变化,并大力搅拌,直到您达到所需的质量和一致性为止或创建可运输的产品。 该团队从积压的工作开始,直到完成所有任务。 通常,成员将根据他们的专业知识或专业领域来选择任务,但是团队必须小心,不要因过于专业化而降低其有效性。

    结论

    Scrum和看板敏捷框架都有一个地方,它们的效用取决于团队的组成,要交付的产品或服务,项目的要求或范围以及组织文化。 会有反复试验,特别是对于新团队。

    Scrum和看板都是依靠工作流并旨在减少浪费的迭代工作系统。 无论您的团队选择哪种框架,您都将成为赢家。 这两个框架现在都很有价值,可能还会持续一段时间。

    翻译自: https://opensource.com/article/19/8/scrum-vs-kanban

    scrum敏捷开发框架

    展开全文
  • 精益生产最重要的两个理念就是准时化和自働化,由看板为实践工具,最终能够达到高质量、低成本及快速响应。首先摆在大家面前的就有一个问题,什么是看板,它和看板墙又是什么关系?之所以把这个问题一开始就抛出来是...

    精益生产最重要的两个理念就是准时化和自働化,由看板为实践工具,最终能够达到高质量、低成本及快速响应。

    首先摆在大家面前的就有一个问题,什么是看板,它和看板墙又是什么关系?

    之所以把这个问题一开始就抛出来是因为看板的“板”字,很容易让人产生困惑。既然是个板子,那因该就是我们平常所说的物理卡墙,就是因为这点,大家错认为看板就是看板墙。不过当然不是,这个咱们就得来盘盘根,探探底。

    看板这个词是来自于日文,原文是这样写的:Kanban, 当然看起来和拼音没有什么两样,所以当引入中国的时候,估计当时第一个翻译的人就直接按拼音翻译了,因为无论是日本人的发音还是在英语里的发音,听起来都是中国的看板。

    精益制造,相信大家都知道,是由丰田生产方式之父,大野耐一提出的。下面就是真真儿的一张广汽丰田看板照片:

    1240

    大家这下清楚两者之间的差别了吧。看板就是一块块的屏幕,应用到敏捷里面就是一张张的卡片,而承载这些看板的板或者墙,才是真正的看板墙,如下图:

    1240
    展开全文
  • 2011年,敏捷开发试点项目大获成功之后,平安科技驶入敏捷推广的加速车道。2012年试点范围扩大到10个团队,引入Scrum、看板(Kanban)、持续集成等流行的敏捷方法。2013年“开启敏捷2.0”,在组织架构上成立“敏捷中心...
  • 疫情期间,大家都在家远程办公,像Jira和trello这样的可视化电子看板工具可算是立功了,使用了一两个月电子看板之后,大家都熟悉了这种工作模式,仿佛再难回到之前的物理看板模式。所以现在复工之际,大伙统一产生了...
  • 敏捷开发中,团队成员认领的是任务还是用户故事?
  • 敏捷开发团队(Scrum团队)在每天开每日站会的时候会领取当天的任务,这个实践在敏捷开发中叫做sign-up-for-tasks即领任务。这个实践源自极限编程,在1998年,极限编程最早期的介绍中提到了,“指派任务”和“领任务...
  • 引言 ...似乎只有敏捷这条路才能拯救软件行业。在此,让我们回顾一下,软件开发的前世今生。 1,code &amp;fix时代 这是软件开发的原始时代,也是软件行业兴起的初始时代。 用户需求场景: 蒙...
  • 敏捷常见方法论框架比较,在类似的价值观指导下,看板有着比较独特而又简单易行的一些方法实践,越来越多的研发团队正在尝试引入精益看板方法。 看板方法有6个核心实践需要掌握。下面就请跟随本文的脚...
  • 敏捷常见方法论框架比较,在类似的价值观指导下,看板有着比较独特而又简单易行的一些方法实践,越来越多的研发团队正在尝试引入精益看板方法。 林伟丹 神兵Wizard 看板方法核心实践 精益看板开发方法作为...
  • 携程敏捷总动员是由携程技术管理中心(PMO)发起的敏捷项目管理线下主题沙龙活动...Key:Trip.com,携程,携程PMO,携程技术,敏捷开发,PMO,PMI,PMP,Scrum,Agile 1月25日,2019年第1期携程“敏捷总动员”晚餐沙龙在上...
  • 本文是《敏捷宣言》10年系列纪念文章之一, 该系列文章将陆续在InfoQ上发布。 我不是《敏捷宣言》最早的签署者, 我甚至不是诸如TDD等敏捷实践的最早期采纳者。然而, 回望过去,我认为我是敏捷原则的早期采纳者...
  • Leangoo是由国内最权威的Scrum中文网(Scrum培训, 敏捷开发培训 ,权威Scrum认证培训(CSM,CSPO),Scrum敏捷开发咨询及教练等相关服务。)倾力打造的一款项目管理软件,完美支持scrum敏捷开发! Leangoo是一款基于...
  • 1、平常我所在的团队都是几人至几十人的团队,所以触及的敏捷都是限于XP、scrum、看板,至多加上精益。但大至几百几千上万的团队,所用的敏捷方法就不一样了。有DAD、Less、SAFe等。如果对敏捷感兴趣,还是不能仅...
  • 编者按\\“大牛V课堂”是Geekbang核心栏目,通过邀约专业领域内的互联网顶级大牛分享专业知识和见解,让你了解专业领域内含金量最高的知识。关注geekbang01公众号,遇见下一位大牛。\\本文根据腾讯研发平台总监袁琳...
  • 敏捷团队公约 政府提高有效性和效率的最佳方法是什么? 在圣何塞市政厅,我们以一种非常规的方法吸引了人们:非技术团队的敏捷性。 从应急管理到公园计划等所有工作的公务员都发现,敏捷方法可以帮助他们应对最基本...
  • 海沟看板

    2020-06-16 05:59:23
    介绍 在组成软件项目团队的一部分后,该团队于2013年在BBC Worldwide开展了一个重要项目,我... 看板是用于管理软件开发过程的技术。 它并没有告诉我们如何开发软件,而是提供了可以帮助我们执行(作为软件开发团...
  • 导读:平安作为互联网金融的领跑者,...2011年,敏捷开发试点项目大获成功之后,平安科技驶入敏捷推广的加速车道。2012年试点范围扩大到10个团队,引入Scrum、看板(Kanban)、持续集成等流行的敏捷方法。2013年“开启...
1 2 3 4 5 ... 9
收藏数 162
精华内容 64
关键字:

敏捷开发 看板照片