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

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

     

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

     

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

     

     

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

     

    看板一词来自日本(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敏捷开发框架

    展开全文
  • 相对于项目管理,我更喜欢看板的主要原因之一就是,项目管理关注的是项目,而看板关注的是流程,是程序。   流程作为精益管理巨大的优势之一,翻译到如看板等工具上面就是,它强调的是打造并维护一个可以允许不同...

    项目 vs. 流程

     

    相对于项目管理,我更喜欢看板的主要原因之一就是,项目管理关注的是项目,而看板关注的是流程,是程序。

     

    流程作为精益管理巨大的优势之一,翻译到如看板等工具上面就是,它强调的是打造并维护一个可以允许不同的“包(Pakcage)”以相同的质量进行通过的流程。这里关注的改进之处永远都是在流程方面,所以在这个过程中所获得的经验和教训都必须是可以应用到整个流程上面,而不仅仅是当前正在通过该流程的某个特定的项目,某个特定的“包”上面。通过这种方式,你在持续改进方面所付出的努力将会在任何时候都能体现出效果。

     

    看板流程的三个重大组成部分:

    完成的定义(Definition of Done)

     

    "完成的定义“是每个阶段的目标。这是”内部客户(比如,下一个阶段)“希望前一阶段所交付的内容。这是你在你的看板流程中为每个阶段进行角色设计的一个方法,且,更重要的是,它保证了通过看板流程的所有“包”的质量。“完成的定义”为在项目的进展过程中大家究竟需要瞄准什么样的目标提供了指导方针。它定义了团队在看板流程的每个阶段中所要努力达成的目标,却又不对完成该目标的方法进行限制。

     

    对于打造一个伟大的产品,发现问题并正确的理解该问题是至关重要的。事实上,没有正确的对问题进行认识往往是一个产品所以失败的主要原因之一。所以,作为一个不断迭代循环和改进的过程,我们在每个项目中进行学习,对每个阶段的“完成的定义”进行改进。通过这种方式,每个“包”通过这个流程时所给我们带来的知识,都能应用到所有紧跟着的“包”上面来,以确保同样的错误不会出现两次 -- 这又是另外一个精益管理上非常重要的因数。

     

    流程的持续改进

     

    说起来天下第一,做起来有心无力!针对流程而非流通这个流程的“包”进行突破,这听上去是非常反直觉的,但是在精益管理上面,这对你的产品又是至关重要的。

     

    举个例子,在发布一个新功能的过程中,你发现大量的用户生成了大量的需要客服支持的凭证,抱怨说他们不知道如何运用这个新功能。那么因为一次用户教育的失败,这就有可能会影响到用户的参与度(engagement)。此时你的技术支持团队应该已经开始着手帮助这些客户解答他们的疑问,同时你的开发团队应该也在动手提供一个针对性的更新。但正重要的是,精益管理会迫使你去找出究竟哪个环节出了问题,然后迫使你对这个流程进行改进,这样才能避免同样的错误不会在其他地方(项目,功能,增强,“包”,等等)再次发生。比如,在内测环节?易用性测试环节?还是在早期的解决方案设计环节?

     

    持续改进是确保其他项目不会犯同样的错误的关键,所以请记得将其应用到你的流程上面去。

     

    流程

     

    流程,就是你打造你的产品或完成你的项目的方式。流程的设计很大程度表示了你的团队如何开发你的产品,同时它也反映了你的团队及你的公司所宣扬的价值取向。

     

    世上并没有一个统一的标准来告诉你该如何定义你的看板流程,但根据你的产品的需要,倒是有着不少来自其他地方的值得借鉴的优秀实践。同时,随着你的生意的成长和你的产品的日催成熟,你的看板流程也会相应的跟着改变。我们为我们的产品打造MVP时候所用到的看板流程,和现在我们在用的看板流程已经相去甚远。回首当年,我们那时对产品的的认知还相当有局限性,且我们当时是一个只有10个人的团队(相比我们现在,可以说是个小团队了),随着我们对产品的深入学习和认识,团队成员也随之达到了200多号人,所以我们面临的挑战也是不可同日而语的。

     

    你的流程进行设计和改进应该源于你此前的学习成果,但也需要正确的反映你的公司的价值取向。确保你对你的生意,你的雇员,以及公司的价值取向有正确的认识。通过以提升和加强你希望在你的团队和产品中看到的价值取向的方式来使用你的流程。这同时还会是一个传播你的企业文化的非常强大的工具。

     

    以上提到的这些好处只是看板所带来的众多好处的冰山一角。看板的使用以及精益管理的原则,对于产品开发以及团队的持续交付来说,都有着极高的价值。所以我们应该从今天开始尝试在你的产品打造过程中应用上看板流程,并且确保不断的在学习的过程中改进你的看板流程。

     

    同时欢迎大家将你的看板 精益管理的应用心得在评论中提出来,以便同行们进行讨论和学习,让我们一起进步。

    展开全文
  • jira 敏捷看板 过渡到敏捷实践的大型组织通常会陷入... [了解您的企业如何在敏捷开发中脱颖而出 。 | 将您的敏捷职业提升到新的水平: 如何提高您的Scrum Master技能 。 | 不确定“敏捷”的真正含义是什么? InfoWo...

    jira 敏捷看板

    过渡到敏捷实践的大型组织通常会陷入两个相互竞争的原则之间:

    • 授权自组织团队自行解决问题并管理团队中协作的敏捷原则。
    • 组织需要制定可在多个敏捷团队中应用的治理,标准,报告和关键绩效指标。

    [了解您的企业如何在敏捷开发中脱颖而出 | 将您的敏捷职业提升到新的水平: 如何提高您的Scrum Master技能 | 不确定“敏捷”的真正含义是什么? InfoWorld 解释了敏捷方法 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

    两者看似矛盾。 如果您实施过多的治理或标准,则会限制团队的自由,以制定能够使其成功的战术决策。 但是,提供的指导太少会使新团队难以采用最佳实践,或者使团队很容易因疏忽而使组织脱离合规性。 没有标准的组织也不知道在哪里以及如何管理那些偏离路线或表现不佳的敏捷团队

    要找到适当的平衡,需要敏捷的领导者定义在哪里以及如何应用一致的标准,同时仍然要赋予团队自我组织的能力。

    为此,一些组织采用了标准框架来扩展敏捷性,例如Scaled Agile框架(SAFe)Large-Scale Scrum(LeSS)Spotify推广Squad框架 许多组织通过采用最佳实践的混合,并经常使用敏捷教练来指导他们,从而围绕目标,文化和物流发展自己的实践。

    根据我在多个组织中担任“敏捷发起人”并领导其敏捷转型计划的经验,我发现找到一致兴趣的一个地方是配置敏捷项目管理和协作工具。 团队宁愿不必花费大量时间来配置这些工具,并且如果它们易于学习和使用,它们通常会接受标准化配置。 然后,只要团队不认为实施过于苛刻,组织就可以创建标准和引入实施的治理。

    这是我在Atlassian流行的敏捷协作工具Jira中配置的一些标准。 尽管我的建议围绕Jira展开,但您可能会在其他敏捷工具中找到等效的配置。

    1.标准化有关定义史诗,故事和子任务的约定

    Jira具有三级层次结构,其中的史诗可以包含一个或多个用户故事以及其他问题类型。 Jira使用通用术语“问题”来反映组织选择选择配置的史诗,故事,任务,子任务,缺陷和其他自定义类型。 然后,一些团队将其用户故事分解为子任务,并将其分配给个人。

    这是我的有关使配置和语言在多个