精华内容
下载资源
问答
  • 正是由于其灵活性,Scrum 方法现已成为团队软件交付方法的首选,近期发布的15届敏捷状态报告也显示,66%的受访者及其所在的敏捷团队最常用 Scrum 方法。 但随着敏捷在团队中得到越发广泛的实践,越来越多的人意识到...

    Scrum 能够帮助一个5-9人的小团队以迭代增量的方式开发产品,在每一迭代结束时,交付潜在的可交付的产品增量。正是由于其灵活性,Scrum 方法现已成为团队软件交付方法的首选,近期发布的15届敏捷状态报告也显示,66%的受访者及其所在的敏捷团队最常用 Scrum 方法。

    但随着敏捷在团队中得到越发广泛的实践,越来越多的人意识到全组织规模化敏捷实践在当下带来的机遇。但当人们简单地将 Scrum 套用到多团队实践中的时候,又出现了各种各样的问题。为了解决大规模开发团队的敏捷应用问题,一款多团队的规模化敏捷框架 Large Scale Scrum(LeSS)应运而生。
    在这里插入图片描述

    在之前的文章中,介绍过 LeSS 的“诞生”,在此就不再赘述。在这篇文章中,我们会详细聊一下 LeSS 的具体实践:

    一、框架

    为了让框架更好地应用到多团队中去,Bia 和 Craig 两人决定要尽量避免向框架内添加角色、工件、流程等情况,防止因过多的定义而限制团队的经验实践。其中,他们还提出了“守、破、离”三个阶段:
    守:在守的阶段,要先打基础,这时候团队的行动是循规蹈矩的;
    破:在破的阶段,要善于打破规则,发现适合自己的情境;
    离:在离的阶段,要学会逐渐找到适合自己团队的方式。
    基于此,LeSS框架保留了Scrum的许多实践与想法,如产品负责人、开发团队、Scrum Master三角色,以及Sprint计划会议、每日站会、回顾会议等。尽管这些概念与Scrum中的实践相同,但侧重点会有所不同。

    1.产品负责人

    产品负责人有两个关键的职责:一个是对产品待办列表中的事项进行优先级排序,另一个是与团队合作澄清产品待办列表中的事项。
    在这里插入图片描述

    澄清产品待办列表中事项需要产品负责人在团队与用户/客户之间担任桥梁的作用,帮助团队与用户/客户直接对话,避免产生产品的需求理解分歧。

    2.团队

    团队的要求在前一篇文章有也有提到过,主要是自管理的、跨职能的、专注的、长期存在的,以及共处一地的。这将会让团队中的每位成员为实现团队的共同目标,决定自己如何去做。

    3.Scrum Master

    在LeSS框架中,Scrum Master需要作为一个全职角色来帮助团队解决过程中遇到的困难。一名Scrum Master最多可管理3个团队。

    二、Sprint

    LeSS中的Sprint是产品级的Sprint,这意味着,各个团队处在同一Sprint中,而在这一Sprint结束后,多个团队将交出一个集成的潜在可交付产品增量。这意味着,所有团队的Sprint计划会议、Sprint评审与回顾会议都是同时进行的。在具体的实施层面,LeSS又给出了一套应用流程:
    在这里插入图片描述

    1.产品待办列表细化会议

    产品待办列表细化会议(PBR)分为三层:

    1)整体PBR

    整体PBR是一个简短的整体产品待办列表细化会议,主要包括产品负责人以及所有团队成员。这一会议主要为团队分配要实施的事项。

    2)多团队PBR

    在LeSS中,多团队PBR通过专家、用户/客户、产品负责人、团队成员的共同参与,来推进Sprint,提高跨团队的适应性。多团队PBR一般只有两个团队。

    3)单团队PBR

    但团队PBR在LeSS中比较少见,一般会应用在巨大且模糊不清的项目背景下,需要先让一个团队清除迷雾,后续逐步加入其他团队的情况中。

    2.Sprint计划会议

    Sprint计划会议分为两部分:

    1)Sprint 计划会议1

    这一会议是所有团队的会议,会议将划分各个团队的具体工作事项。如果团队的数量较少,可以全体团队成员参与这一会议。如果有两个以上的团队,则需要每个团队派出一个团队代表(除Scrum Master外)参与会议。

    2)Sprint计划会议2

    这一会议是各团队内部的会议,团队在此会议上制定自己团队的Sprint计划。有时为了团队之间的分享与学习,两个或多个团队可能会在同一房间的不同区域举行自己团队的计划会议。
    在这里插入图片描述

    3.每日站会

    与Scrum中的每日站会不同的是,其他团队的成员可以加入该团队的每日站会,进行信息共享,更好地协调团队之间的合作。

    4.Sprint评审会议

    Sprint评审会议需要所有团队一起评审该Sprint交付的潜在可交付产品增量,应实现所有人就产品进行协作的机会。这里的所有人指的是除产品负责人之外,还包括团队成员、利益相关者等。

    5.Sprint回顾会议

    回顾会议最长持续45分钟,分为两种情况:其一是团队内部展开回顾会议,其二是产品负责人、Scrum Master、团队代表进行整体回顾,主要讨论跨团队的协作、系统问题。

    与Scrum一样,在一整套带有流程的框架下,LeSS提供了足够的具体实践,以及足够的灵活性以及扩展性,帮助大规模团队探索自己的敏捷之路。在此基础上,大规模团队可以调整团队实践,最终打造出真正适合自己的规模化敏捷实践。

    此外,还要注意的一点是,LeSS框架更适合于8个以下的团队数量,如果团队数量超过8个,就需要应用LeSS Huge框架。具体LeSS Huge框架是如何应用的呢?详见下一期。

    往期文章链接:

    规模化敏捷LeSS(Large Scale Scrum)的诞生
    规模化敏捷LeSS(二):LeSS团队实践指南

    展开全文
  • 选择一名教练的指引-大规模敏捷LeSS Guidelines for Selecting a Coach - Large Scale Scrum (LeSS) 一个好的培训师/教练会在你的LeSS实施过程当中发挥重要作用,使得效果显著。那么如何选择他们呢?你可以参考...

    选择一名教练的指引-大规模敏捷LeSS

    • Guidelines for Selecting a Coach - Large Scale Scrum (LeSS)

    一个好的培训师/教练会在你的LeSS实施过程当中发挥重要作用,使得效果显著。那么如何选择他们呢?你可以参考这些指引:

    • A great trainer and a great coach will make a world of difference in your LeSS adoption. How to chose them? Use these guidelines:

    拥有实践经验

    • hands-on experience

    确保你的培训师/教练在LeSS实施上拥有实践经验,包括作为内部的团队成员和外部的教练角色。避免那种完全不关心谁来教授的培训提供方,避免只懂理论知识的培训师,这些都帮助不了我们。

    • Ensure your trainer/coach has hands-on experience of LeSS from both inside (as a team member) and outside (as coach). Avoid training providers who don’t care about who teaches, and avoid trainers with only theoretical knowledge. They aren’t useful.

    选择个人,而非选择公司

    • a person, not a company

    选择教练服务就是选择该教练他个人,选择他身上拥有的独特能力。找到他并与他形成长期的合作关系,避免大型的咨询公司和培训公司。

    • You are looking for a unique person. Great coaching is personal. Find your coach and form a long-term relationship. Avoid giant consulting companies and training companies.

    对IT技术有深刻理解

    • technical depth and understanding

    LeSS需要追求卓越IT技术。技术、团队、组织决策都是紧密结合在一起的,你的教练需要有广泛且深刻的理解,避开那些技术不佳的人,他们过去通常都是PMI系的项目经理。

    • LeSS requires technical excellence. Technology, team, and organizational decisions are strongly related and your coach needs to have this broad and deep perspective. Avoid people with no or limited technical expertise. These are often ex-PMI-project managers.

    长期合作关系

    • long-term engagement

    LeSS实施是需要很长时间以及需要耐心的。找到那个愿意承诺并长期陪伴该实施的教练。避免选择一个任务驱动型的人,他们仅仅是来到,评论,批评,然后离开。

    • LeSS adoptions require patience and take time. Find a coach that is committed to see your adoption through—for years. Avoid ‘drive-by’ coaches that come, comment, criticize, and go.

    质量高于成本

    • quality over cost

    如果招聘了一个价钱较便宜但不符合以上几点因素的教练,是个得不偿失的愚蠢决定。这个LeSS实施大概率会有缺陷和失败,因为一个不好的教练一点帮助都没有。

    • Hiring a cheap but bad trainer/coach (ignoring the previous factors) is truly penny-wise and pound-foolish. Flawed and failed LeSS adoptions are certainly possible; a bad coach doesn’t help.

    不要把决定权委托他人

    • don’t delegate the selection

    不要把这么重要的决定交给不直接参与其中的人员。避免将决定权交给另外一个部门,例如PMO,采购部,人力资源部,因为他们没有足够的参与程度来了解以上几点重要的因素。

    • The decision is too important to leave to people who aren’t going to be directly involved themselves. Avoid delegating the selection to a separate department, such as a PMO, Purchasing, or HR group—they aren’t involved enough to see the important factors.

    不要过分强调认证

    • deemphasize certification

    大多数人和课程的认证都是意义不大的。也许他们没有带来坏处,但他们也没有带来可靠的指引。显然以上几点因素更为重要。

    • Most certification of people and courses is almost meaningless. It probably doesn’t hurt, but it’s not a reliable guide. The above points are infinitely more important.

    对多个教练进行评估

    • evaluate multiple people

    最好的团队会在作出选择和形成长期合作关系之前,先对多个教练进行过评估。

    • The best groups evaluated multiple people before making a decision and investment in a long-term relationship.

    原文地址:https://less.works/coaching/guidelines-for-selecting-coach


    作者:Vaycent 孙维

    邮箱:157289692@qq.com

    个人微信:hello_world_88

    公众号:SeriousPlay4Agile

    本文由博客一文多发平台 OpenWrite 发布!

    展开全文
  • 从上世纪 90 年代初开始,Scrum 框架在全球范围内已得到了广泛应用,有报告显示全世界范围内采用敏捷开发模式的公司里有68%以上使用Scrum框架。Scrum团队中包括: 三个角色 1.产品负责人 2.开发团队 3.Scrum ...

    Scrum简介

    如果你知道敏捷开发,Scrum你一定不会陌生。从上世纪 90 年代初开始,Scrum 框架在全球范围内已得到了广泛应用,有报告显示全世界范围内采用敏捷开发模式的公司里有68%以上使用Scrum框架。Scrum团队中包括:

    三个角色

    1.产品负责人
    2.开发团队
    3.Scrum Master

    三个工件

    1.待办列表
    2.Sprint待办列表
    3.潜在可发布产品增量
    Sprint是Scrum 的核心,其长度为1~4周的一个固定长度时间盒,这段时间内构建 一个“完成”、可用的和潜在可发布的产品增量。在Scrum指南中定义了

    四个Sprint活动:

    1.Sprint计划会议
    2.每日站会
    3.Sprint评审会议
    4.Sprint回顾会议
    在常见的实践中通常会在Sprint周期中间增加一个产品待办列表Refinement会议,用以初步讨论澄清下一个Sprint潜在要做的用户故事。看起来是不是很简单?Scrum是一个轻量的,易于理解但难以掌握的敏捷框架。

    LeSS简介

    Scrum开发团队最佳规模是足够小以保持敏捷性,同时足够大可以在 Sprint 内完成重要的工作,一个建议的数值通常是7加减2人,这样既可以保持敏捷性又可以在Sprint内交付潜在可发布的产品增量。对于小规模产品,1个Scrum团队也许可以很好的应付,然而现实中大规模产品开发时常常会涉及到多个团队协同开发一个产品。
    如果我们继续采用Scrum的方式进行产品研发,我们就不得不需要思考一个问题:不同团队如何一起有效的合作完成一个产品的开发?行业里目前有一些大规模敏捷的解决方案,如 Large Scale Scrum(LeSS), Scrum of Scrums, Scaled Agile Framework(SAFe), Disciplined Agile Delivery(DAD),NEXUS等等。这里简单介绍一下LeSS这个框架,当年在NOKIA的时候用的就是这套框架。
    “LeSS is Scrum applied to many teams working together on one product.”简单说LeSS依然是Scrum,依然是那三个角色,三个工件,五个会议。LeSS框架想要解决的问题是如何将Scrum的原则,元素尽可能简单够用的使用到多个团队,合作开发一个产品的场景里去。LeSS框架分为两类:LeSS以及LeSS Huge,超过8个Scrum团队的时候使用LeSS Huge框架。不要问我8是怎么来的,就这么定的,当然在实践的过程中需要考虑产品负责人以及Scrum团队成熟度适当调整,理论总是要联系实际。

    LeSS实践

    笔者去年的时候接手了一个研发团队,准备开发一个公司内部DevOps研发平台产品。团队成员包括3个前端JS开发,9个后端JAVA开发,1个测试,1个交互;前后端分离设计,前端基于React,后端基于SpringBoot;团队成员几乎不懂敏捷开发,Scrum以及LeSS等。如果是你,你会如何开始?
    没有合理的团队设计让产品研发事倍功半,而有了合理的团队设计让团队事半功倍。团队设计是影响团队绩效的一阶因素。团队设计简单说包含两方面考虑,一个是团队自身结构的设计,一个是团队间沟通协调方式设计;团队自身结构设计上通常有两种选择:组件团队或特性团队。
    在组件团队模式下需求拆分为组件子需求,往往一个需求会涉及到多个组件团队,通常会产生以下一些影响:
    组件团队缺少产品整体视角,关注组件交付而非客户价值交付;常见的句式是:“我的做完了”。
    组件团队通常资源共享,关注资源效率,而非价值交付效率。当一个组件团队服务多个业务方的时候,往往容易导致组件团队陷入公共绿地的困境,不用白不用,白用谁不用,各个业务方拼命争夺组件团队资源,在整体沟通信息不顺畅的时候,一个潜在的结果是最会哭最会喊的那个业务方需求获得了资源,而不是对于公司或客户最有价值的业务方需求获得。
    组件团队组织产品研发时通常也会采用项目制开发模式,从各个组件团队抽调资源,组建短期项目团队。不同的PM,不同的团队成员,不同的做事风格,不同的项目复杂度,不同的完成标准,不否认有非常牛X的项目经理带领非常牛X的团队完成非常牛X的项目,但整体上看,往往整个项目进度,质量,效率不稳定可控。同时在短期的项目团队里,人往往被视作实现项目目标的一个资源,成员工作动力不足,高效的团队是需要长时间磨合的。
    项目制方式加上关注资源效率,通常产生的一个现象是团队/个人多任务并行。适当的并行可以提高团队的吞吐量,但同时会延长客户价值交付周期。当并行超出某一个限度的时候往往会导致整体质量效率下降。在一定程度上这是一个投入产出比平衡的结果。
    跨组件团队沟通时需要非常清晰明确的公司策略,产品优先级等信息支持,才能更好的协调多个团队协作开发。但现实的情况往往是整个信息不够透明。另一方面团队都会有自己的屁股,有做大做强自己组件的冲动,往往导致跨团队沟通协调成本高。在沟通协调不顺畅的情况下,往往会产生强烈的项目管理需求。笔者曾见过比较极端的case,一个人半天代码量的需求,前前后后花费了不同团队10个人讨论了3天,最后在外力的介入下才拍板。
    客户价值匹配组件团队技能,而非团队技能匹配客户价值;当某一组件需求集中涌现的时候,容易产生扩大团队的冲动;当某一组件团队高优先级需求不足的时候,并不会缩小团队规模,反而会找活做,容易导致低价值交付,后果是不断扩大的组件团队;在某些组织里经常会看到组织调整,一个原因就是不断扩大的组件团队,导致研发成本不断攀升,但研发成本攀升的同时并没有实现同等客户价值价值交付,投入产出比降低,所以需要动一动,也算是一种应对的方式,只是这种变化通常更剧烈一些。
    当需求被拆分到各个组件团队后,带来的另外一个后果是后期集中集成,集中测试,反馈周期往往拉长,并且将风险留在最后,往往导致项目延期,交付周期变长。
    相对于组件团队,特性团队:
    长期稳定存在,长期的合作利于打磨高效团队,质量和效率稳定可预见。
    跨技能,团队成员技能中包含前端,开发,测试等多种技能。
    跨组件,团队覆盖的范围同时横跨多个组件。
    团队能独立完成客户价值交付。
    团队间协调合作从项目管理域转移到代码技术域。
    当然特性团队也带来了一些挑战:
    每个人都需要掌握所有东西?整个团队需要拥有产品交付的所有技能,并在客户需求开发过程中不断学习扩大个人技能领域,这是一个长期的过程,取决于团队学习的能力。BTW:在现在以及未来的千变万化的社会中,无论是个人还是团队,学习能力将是一个非常重要的能力。
    如何保证组件代码质量?需要工程实践上的配合,例如主干开发,持续集成,保证产品不被破坏;组件守护者,review组件相关修改,技能指导;不同人从产品交付的角度修改组件促进代码学习以及程序员社交。
    整体上特性团队对外更加关注客户价值价值,促进创新;对内打破团队边界,促进组织转型升级;对个人促进个人学习,提升个人技能。
    敏捷原则之一“我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。”对于一个从0到1的产品,持续不断的满足客户需求,持续不断的从客户收集反馈对于产品来说非常重要,特性团队更适合当前的产品研发场景。笔者选择组建了三个特性团队,每个团队4人,其中包含前端开发,后端开发,可以独立完成产品需求交付。
    团队自身结构设计好了,接下来需要考虑团队间沟通协调方式。团队间沟通协调方式会受到产品需求组织方式的影响。团队将要开发的DevOps平台是一个非常复杂的产品,涉及的需求领域很多,比如环境管理,应用管理,版本管理,持续集成等,同时这是一个从0到1的过程,每个需求领域都有着充足而稳定的产品需求,并且每一个领域都需要一定的领域背景知识才能更好的设计实现产品,所以笔者决定划分为4个产品需求领域:环境,应用,版本,持续集成。在LeSS里是没有需求领域的,需求领域是LeSS Huge里的概念,当团队个数大于8个的时候建议使用LeSS Huge,并且区分需求领域,每一个需求领域里依然是LeSS工作方式,同时增加APO角色负责一个需求领域。
    笔者虽然只有3个特性团队,但依然选择划分了需求领域,这点和LeSS有所不同。笔者的考虑是团队个数是一个划分需求领域的参考,同时产品复杂度和产品所处的阶段可能也是需要考虑的一个维度。在LeSS里不区分需求领域的情况下,每一个特性团队在一定程度上是等同的,提供最大的灵活性。需求领域的划分在一定程度上降低了团队跨需求领域的灵活性,但是在当前产品初期从0到1的情况下,每个领域高优先级需求充足而稳定,足以保证每一个特性团队持续的高价值交付,团队的跨领域灵活性暂时不是笔者考虑的最主要的问题。
    最终团队整体设计如下图所示,一份产品待办列表,划分四个需求领域,每一个需求领域由一个特性团队负责需求,特性团队中包括前端开发和后端开发,其中特性团队C负责两个需求领域。这在一定程度上即保持了产品特性团队的特征,又减缓了特性团队在工程实践上带来的挑战,当然也牺牲了一定的团队敏捷性,这是当下的选择。需要指出的是,团队的结构设计不是一成不变的,随着产品的演进,需求领域不断的涌现和消亡,团队的结构设计也是随着时间调整的,未必一个团队就只能工作在一个需求领域,或者一个需求领域只能一个团队工作,甚至是否还需要需求领域划分,这是需要根据现实的情况来调整的。
    完成了团队自身结构设计以及产品需求组织结构设计之后,那么团队之间如何在LeSS框架下协助完成一个产品从0到1的开发呢?敬请期待大规模敏捷开发框架LeSS实践(二)。

    总结

    简单总结一下,Scrum是敏捷世界里广泛使用的一个框架,简单,易懂但难于掌握。LeSS是大规模敏捷开发世界里一个常用的框架,它的本质上依然是Scrum,它想要解决的问题是如何将Scrum的原则,元素尽可能简单够用的使用到多个团队,合作开发一个产品的场景里去。
    在LeSS框架里,很重要的一点在于团队设计。记得以前去拜访一个公司,公司领导介绍了公司的组织结构,交流中我会问他一些潜在的问题点,他会很惊讶于你怎么知道?组织的很多问题根源在于组织结构设计,相同的结构设计上往往存在相同的问题。没有合理的团队设计让产品研发事倍功半,而有了合理的团队设计让团队事半功倍。团队设计是影响团队绩效的一阶因素。BTW:世界上没有所谓的最佳实践,没有所谓的银弹,有的仅仅是在特定的上下文里合适的实践和方法。


    本文作者


    展开全文
  • 这三种方法分别是Dean Leffingwell的Scaled Agile Framework(“SAFe”),Scott Ambler的纪律敏捷开发(DAD)和Craig Larman和Bas Vodde的大规模Scrum(LeSS)。在还没有搞清楚一个团队的敏捷转型时,对于在公司...
  • 顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的?\背景\J.P.摩根的全球核心处理技术集团由Simon Cooper领导,是一个遍布全球的...\之前他们曾零散地采用了\"Scrum-But\"及各种敏捷工程技术,主要是...
  • 顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的?背景J.P.摩根的全球核心处理技术集团由Simon Cooper领导,是一个...之前他们曾零散地采用了”Scrum-But”及各种敏捷工程技术,主要是在开发团队...
  • 规模化敏捷-简要对比SAFe、LeSS和DAD模式 http://blog.sina.com.cn//s/blog_15e1409550102x5yx.html 分类:敏捷开发 目前有三种将Scrum扩展到大型企业的方法。 这三种方法分别是Dean ...
  • less

    2019-03-18 22:42:10
    1.less的定义 less是一个CSS预处理器,可以为网站启用可自定义,可管理和可重用的样式表。 做为 CSS 的一种形式的扩展,它并没有减少 CSS 的功能,而是在现有的 CSS 语法上,为CSS加入程序式语言的特性,以便可以...
  • LessLess基础

    2019-10-09 03:39:01
    Less基础 一、Less基础 http://www.bootcss.com/p/lesscss/ 历史 LESS由Alexis Sellier于2009年设计。LESS是一个开源。LESS的第一个版本是用Ruby编写的,在后来的版本中,它被JavaScript代替 什么...
  • bootstrap Less

    千次阅读 2016-10-14 23:36:44
    bootstrap Less
  • 什么是LeSS框架?Scrum / LeSS / LeSS Huge

    千次阅读 2019-12-02 14:09:10
    LeSS是一个轻量级的敏捷框架,用于将Scrum扩展到多个团队。从2005年开始,Bas Vodde和Craig Larman在大型项目中使用Scrum原则和规则后开发了LeSS框架。他们的目标是在不受Scrum约束的情况下成功开发大型项目。 LeSS...
  • LeSS框架

    2019-12-02 15:49:49
    LeSS提供了两种不同的大规模Scrum框架。LeSS的大多数扩展要素都集中于将所有团队的注意力转移到整个产品上,而不是“我的一部分”。全局和“端到端”的关注可能是扩展中要解决的主要问题。这两个框架(基本上是Scrum...
  • Less 教程

    2018-05-11 06:54:56
    1. Less 基本教程 1.1 Less 入门简介 1.1.1 什么是LESS? CSS(层叠样式表)是一门历史悠久的标记性语言,同 HTML 一道,被广泛应用于万维网(World Wide Web)中。HTML 主要负责文档结构的定义,CSS 负责文档表现...
  • 学习笔记-Less

    2019-05-13 18:34:29
    Less Less is More ,Than CSS-少即是多,比CSS 什么是LessLESS支持创建更清洁,跨浏览器友好的CSS更快更容易。 LESS是用JavaScript设计的,并且创建在 live 中使用,其编译速度比其他CSS预处理器更快。 LESS保持...
  • 敏捷开发】| 作者/Edison Zhou在过去的五年时间里,我所在的公司和团队一直使用的都是敏捷开发模式,我也在2018年底获取了Scrum联盟的CSM认证,对于敏捷的理解也是从最初...
  • 敏捷交付Assurance and Agile — two words not commonly seen together, and for good reason. The early and iterative delivery of product increments using Agile, constantly reviewed and inspected, ...
  • 常见的问题敏捷是如何解决的? 敏捷痛点及解决方式 问题 解决方式 团队目标或任务不明确 敏捷章程愿景、使命和使命测试 团队工作协议不明确 敏捷章程...
  • 导语 敏捷团队由产品所有者...现在,许多组织和团队通过大规模Scrum(LeSS,Large Scale Scrum)之类的扩展敏捷过程框架有效地解决了企业中的Scrum扩展问题(规模化问题)。 什么是 LeSS(Large Scale Scrum)
  • Leangoo多团队大规模敏捷开发模板是基于大规模敏捷模型定义的,可以适配基于Scrum of Scrums, Scrum@Scale,LeSS和SAFe等模型。Leangoo多团队大规模敏捷开发模板,在团队级使用的是标准的Scrum模型。 Scrum是用于...
  • 敏捷≠Scrum

    2020-03-21 23:00:02
    敏捷≠Scrum
  • 敏捷实践流程学习

    万次阅读 2019-12-07 12:50:55
    敏捷的目的是及时沟通,高效交流达成一致,持续集成与迭代,提高效率与资源利用率,及时保证高质量交付。 敏捷宣言: 个体和互动 高于 流程与工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 ...
  • 作者简介:姜信宝(Bob Jiang),中国北方第一位CST(Certified Scrum Trainer),国内知名电商资深敏捷教练、金牌讲师,Certified LeSS Practitioner,《Scrum精髓》译者。同时也是CSDN敏捷知识库特邀编辑团队领头...
  • Leangoo基于多团队大规模敏捷开发需求,也提供了可适配Scrum of Scrums, Scrum@Scale,LeSS和SAFe等模型的项目模板。 如果是单团队进行敏捷开发,请查看单团队敏捷开发 开始使用Leangoo 创建多团队敏捷项目...
  • less语法详解

    千次阅读 2018-08-21 10:57:21
    1.less的定义 less是一个CSS预处理器,可以为网站启用可自定义,可管理和可重用的样式表。 做为 CSS 的一种形式的扩展,它并没有减少 CSS 的功能,而是在现有的 CSS 语法上,为CSS加入程序式语言的特性,以便可以...
  • 敏捷与CMMI的同与不同

    千次阅读 2019-08-09 09:52:34
    CMM我是从1998年开始接触的,到现在大概20年了,... 敏捷我是2005年接触的,到现在14个年头了,2008年左右也成了认证的Scrum Master, 去年成为认证的大规模敏捷顾问,2018年成为敏捷性能合弄模型的评估师。10多年来...
  • 敏捷项目管理进阶之规模化敏捷 多年项目管理实战经验,多项项目管理资质认证。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,944
精华内容 1,177
关键字:

less敏捷