Scrum敏捷实践集

Scrum_tp

RingCentral Tech | Scrum框架下玩转敏捷实践

前记:

在铃盛,每一个产品项目都有着自己独特的敏捷玩法。在这里给大家介绍一下我比较熟悉的一个项目团队是怎么玩转敏捷的。

首先晒一下团队成员照:

QQ截图20191104100727

敏捷团队部分成员照

该项目参与的团队有以下基本特点:

1.采用Scrum敏捷框架

2.3个Scrum研发团队,3个PO,1个ScrumMaster

3.每个团队都有开发测试成员,负责产品特性端到端的交付

4.每个Scrum团队人数7~9人

对于熟悉Scrum敏捷框架的朋友来说,这样的团队组成并不陌生。那么是什么让这个团队在Scrum敏捷框架下独具一格,不断成熟并高效运作呢?我想是跟团队对优秀敏捷实践的不断追求和践行是分不开的。

这里介绍几个该团队行之有效的敏捷实践供大家参考,欢迎交流指正。

敏捷实践特色一:DoR

DoR是什么?

DoR(Definition of Ready),敏捷开发发展了几个年头之后,人们发现进入迭代开发应当满足一定条件,否则过于模糊的需求会导致迭代的失败,在迭代内花费过多的时间去做需求澄清,因此给进入迭代设立门槛,就是Definition of Ready,简略称之为“DoR”。

在该敏捷团队中, DoR的具体做法包括以下几点:

输入:

1.需求 – 清晰的用户故事 User Story

2.设计 – 被批准的UI/UX

3.流程图

时间:迭代开始之前

参与人员: 跟该用户故事有关的群体,包括开发、测试,必要时产品经理,产品设计师等同事都被招呼过来,在确认满足DoR“输入”的前提下,一起讨论并得出DoR的“输出”。

输出:

1.验收标准AC(Acceptance Criteria)

2.测试策略 – 使用什么样的测试覆盖

3.对于产品性能的影响

4.依赖识别

5.子任务的拆分

QQ截图20191104100806

DoR输入输出示意图(流程图+测试策略)

QQ截图20191104100817

DoR的一隅

作用:

1.确保需求和设计在迭代前ready(准入条件)。

2.确保团队成员对产品需求(Know What),功能实现和测试策略(Know How)足够清晰。

3.避免功能实现或者测试点遗漏,尤其是非功能部分的需求。

4.质量内嵌(Build-in Quality),争取第一次就把事情做对,提高质量

5.思路清晰,提高交付效率。

6.每次DoR热烈的讨论过程都是一次增进团队各角色之间相互理解和支持的机会。

敏捷实践特色二:CI/CD 

CI/CD是什么?

CI(Continuous Integration) – 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CD(Continuous Delivery) – 是一种软件工程手法,让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间,减少风险。

为了实现持续集成/持续交付(CI/CD)的目标,敏捷团队使用了Jenkins Pipeline工作流框架来进行具体实现。

具体做法:

1.一个特性一个开发分支。

2.鼓励开发人员尽早地经常地集成代码。每次集成前必须运行并通过单元测试(Unit test)和被影响的端到端测试,建立开发团队对开发产品的信心。(持续集成)

3.合并回主分支发起合并请求(Merge Request)时要通过静态代码检查,单元测试覆盖率检查,并且要按照DoR阶段输出的测试策略进行单元测试,集成测试以及端到端自动化测试等。

4.在发布之前,把代码部署到的 Stage 环境中进行更多的测试, 比如在更多的浏览器上测试,覆盖更多的测试场景以及性能方面测试等等。

5.如果代码在Stage环境通过测试,会自动发布验收(Acceptance)的内测版本,通过验收后可以继续部署到生产环境中。(持续发布)

基本作用:

1.通过静态代码扫描,保证没有静态错误。

2.通过单元测试,保证没有单元测试错误。

3.单元测试覆盖率不低于目标分支,保证没有降低单元测试覆盖率。

4.保证没有构建/部署错误。

5.通过指定范围的端到端自动化测试。

通过使用Jenkins Pipeline框架实现CI/CD,可以在以下几方面获益:

1.通过CI/CD,开发人员能够尽早地发现和解决代码中的问题,在成为下游主要问题之前进行修复,以降低错误代码导致的长期开发和业务成本。

2.通过CI/CD,可以增加产品的发布频率,持续不断的软件版本发布也会根据用户对应用程序的反馈,允许开发团队对其进行及时微调。

3.通过CI/CD,可以保证每个发行版本的风险较低。当使用CD方法发布时,开发团队也会更有信心,因为在整个开发生命周期中,所有内容都经过了多次测试,保证了代码质量。

QQ截图20191104100842CI/CD 示意图

敏捷实践特色三:打造学习和分享型团队

为了满足客户的要求和实现公司的战略目标,产品开发的需求不断涌现,团队成员也在不断地增加,新员工的有效培训以及产品的快速交付是团队面临的两大挑战。

培养学习和分享的团队文化是快速提高团队整体生产力的有效方法,而团队的生产力是保证产品快速交付的必要条件。

为了营造知识技能分享的氛围,打造学习型团队,敏捷团队主要采用了以下实践:

导师机制(Mentor机制)- 每个新员工都有一个mentor。新员工入职第一周,导师和团队要组织“迎新餐”欢迎新同事的加入,让新员工快速和大家熟悉起来,融入团队。另外,导师负责给新员工制定有效的学习计划,帮助新员工快速成长,迅速参与到项目当中,也可以培养老员工的领导力,增强团队互助氛围。

结对编程 – 每个开发同事都有一个结对的同事。结对编程可以帮助新人快速成长,提高团队整体技能;不同的思维碰撞,让编程充满乐趣和更多可能。

QQ截图20191104100926团队结对编程

Code Review - 每个同事的代码都需要pair和一个资深同事的review,规范编码习惯,采用“四眼原则”。

DoR – 这个环节上文有介绍,绝对是一次知识分享思想碰撞的好机会。

技术方案、实现设计探讨 – 技术方案的“讲解和提问”互动环节以及具体实现设计(比如类图)的讲解让大家的知识和技能得到进一步的分享和交流,是一个充分深入的学习机会。

QQ截图20191104100947团队探讨技术方案照片

这样的敏捷实践,赋予了整个敏捷团队信任与透明,相互尊重和支持的工作环境,让大家能够乐于配合并且积极接受挑战。

Scrum敏捷框架是“容易理解却难以掌握”的一种敏捷框架。敏捷的价值观为道,敏捷原则为法,实践为术。以道法指导术,以术彰显道法,让敏捷的价值观和原则具象于不同的敏捷实践中,让敏捷真正落地。

敏捷教练主要心得:

1.保持开放积极的心态,多聆听来自不同职能不同角色的声音。综合判断并采取相应的应对措施。

2.多看到团队的成长,一个敏捷团队的成长需要时间。当问题很多的时候,尤其需要耐心的引导和帮助。尤其要重视Scrum回顾会议。

3.根据团队的实际情况,采用不同的敏捷实践,并适时调整改进。

4.明确各角色的职责,并保证各角色尽到自己的职责并且能彼此顺畅地合作。

后记:

在Scrum创建之初,Scrum之父,敏捷软件开发运动的领导者之一Ken Schwaber(肯·施瓦伯)就指出Scrum敏捷框架只是一个起点,他建议人们从原装的Scrum入手以保持稳定的过程框架,并进而自行发挥。

基于Ken的建议,个人认为凡是不违背敏捷精神的研发管理方法,均为敏捷。所有的敏捷实践者以敏捷框架为基础,结合公司和产品的实际情况,凭着经验技能和直觉,去践行适合自己所在环境的敏捷实践方法。

以创造价值为核心,让团队能够享受工作带来的乐趣,使其获得协作的满足感,并生成强大的凝聚力。

让团队充满能量并不断追求卓越的敏捷之路,任重而道远,是我们所有敏捷教练应致力的方向。与君共勉。

 

本文作者:Sara Lu,  铃盛软件Sr. Scrum Master, CSM, CSP, SSM , PMP, PMI-ACP,曾在诺基亚Nokia通信技术有限公司,库卡KUKA机器人有限公司担任Scrum Master。 拥有7年以上敏捷教练工作经验,对Scrum和SAFe等敏捷框架有着丰富的实践经验。

本文转载自:https://mp.weixin.qq.com/s/8hlrpeAoYwbbFdhWqj1A5g

Scrum团队

Scrum团队初建的十一件事

越来越多的公司(IT/非IT)正在做或者计划做Scrum转型。很多的团队往往对于转型无从下手,且转型开始后实际效果往往并不如人意。在这里我们系统性的去讲一讲怎么把一个新的Scrum小组从0做到1,怎么让大家快速热身起来

1. 要有充分的准备期

很多的公司可能拍脑袋说我们下周开始做Scrum吧,然后Scrum就开始了。还有一部分公司请Scrum Coach来给大家做一个两天的培训,然后就期望Scrum团队就完美了。

希望是美好的,现实是残忍的。如果我可以选择Scrum 培训热身的时间,我觉得1-2周会是一个比较合适的时间,给团队足够的时间去消化理解,因为在Scrum Guide里清楚的写明了Scrum is easy to use, but hard to handle。不过我并不赞同完全设置培训Sprint,在开始的Sprint我们还是要交付增量的,但是我们可以交付的少一点。

在互联网节奏的今天,很少有企业让大家有1-2周的时间培训,理解和消化。如果只有两天,我个人会选在一天讲述Scrum的基本知识,第二天让大家在一起团建,在团建中通过一些游戏,活动,交谈加深协作的理解,同时让大家更加熟悉对方。往往这样的准备能够让团队更加快速进入Scrum的状态。这也许就是所谓的磨刀不误砍柴工吧。

 2. 对团队其他成员的工作的熟悉时间需要占据自身工作的一半

很多人觉得对于一个全新的团队才需要做很多熟悉的过程。其实不管是新旧团队,只要是一个新的Scrum团队,一个新的里程碑式的开始,让大家互相熟悉,信任对方,对工作都是有百利无一害的。

在这个过程中我时常做的是让每个人描述他/她最想成为的那个漫画英雄和背后的原因,或者做一个自己生活的时间线的分享。这些都能从侧面映射出团队成员的性格和偏好,从而能帮助团队快速的进入协作的状态;并增加团队的归属感和认同感。

3. 开始的失败是为了未来的成功

正因为很多时候管理层的期望过高,大家觉得花费了这么多成本去培训,Scrum应当可以解决很多的问题。但是实施Scrum后,往往和期望值有着非常大的差距。

作为团队的开始,允许失败,甚至是鼓励失败是未来成功的关键。这里的鼓励失败不是说大家无底线的乱做一气,降低质量标准,或者任由大家去自由发挥。这里的鼓励失败更多的是希望团队要有勇气去面对挑战,有勇气去尝试自己不熟悉的技术,环境,语言。同时怎么在失败种吸取教训,减少下次失败的可能性。

很多国内的Scrum Master是原来的技术经理或者大咖,往往在开始的几个Sprint后发现团队效果不好,或者基于管理层期望值的压力,很可能又回到原来的管理模式,去替代团队做很多决定。 这种行为会伤害团队的成长,同时对于今后Scrum的发展带来非常大的阻碍。

 4. 永远不要停止Teach

基于上面说的很多的团队都会选择2天的培训作为Scrum的开始,往往之后也只有团队里的1到2个人还专注在Scrum可持续提高的研究上,这往往变成了Scrum Master一个人的指责。

其实在Scrum的实践中,Scrum Master一定要发现在任何时间节点可以培训Scrum的机会。当团队出现问题,或者遇到困惑的时候。这是最好的Teach的时机。所以千万不要被自管理这句话迷惑了,那是针对特别成熟的团队。在非常青涩的初始阶段,频繁反复的培训有助于团队快速纠正之前的工作习惯。(这其中有很多游戏可以帮助大家到大家,会在另外的系列里展示)

 5. 建立团队的文化

Scrum的终极目标实际上是解决一加一大于二的问题,随着沟通协作的增加,团队的效率在降低,所以Scrum才设计出一种工作模式(3-9人)能够在这个空间里把战斗力发挥到极致。

这里给大家分享一个塑造团队的小游戏,让团队成员每人分别给出最好和最坏的团队的一些特征,然后让大家结对讨论,最后在做陈述的时候,让大家一起加入到讨论。这个练习能帮助团队对什么是好的团队达成共识,并能对不好的行为进行预防。

 6. 建立团队的契约精神

扁平和透明是Scrum团队的显著特征,在创建团队初期,我们就需要定义好每个人的职能,我们可以设置一些非常简单的问题来抽样调查大家对Scrum认可程度。尤其是commitment,这是所有团队的一个重要基本素质

同时也需要给团队一个清晰的目标,包括管理层对大家的期望值。这些也是在团队初建时对团队成员的一种鼓励和鞭策。

 7. 选一个团队名号

给团队起名看似是一个很幼稚的游戏,但是这却是一件花小钱办大事的工作。团队选择的名字往往也代表着团队向往的状态,对提升团队士气有着很重要的作用。

我们通常做的是,让每个团队成员自己给团队起一个名字,然后投票选出最优方案。 这样做会带来团队更多的团队归属感、团队荣辱感。

 8. 设置合理的期望值

老板们总是希望有更多的产出,所以怎么管控管理层对团队的期望值显得很重要。过高会对团队的压力很大,团队很可能会出现人员流失不稳定的情况,过低也不利于团队自我创新和突破。

我觉得设置阶梯的期望值,比如1-5个Sprint是什么情况,之后根据现状在做适当调整是一个比较好的选择。当然,Scrum是应该越做效果越好的,如果越来越糟,Scrum Master有义务去找寻问题出在哪里。

 9. Retrospective/ Retrospective/ Retrospective

如果让大家选择Scrum的核心组件,很少有人会选择Retrospective。其实Retrospective和其他组件一样重要。 在Scrum这种体系下,我们更应该关注人,而Retrospective是唯一一个正式的可以帮助大家的机会。同样在Sprint任何时间节点都不要放过可以帮助大家提升的空间,当然对于一些比较复杂或者不清晰的问题,我们可以放到retrospective上再做详细的讨论

 10. 尽量让管理层也参与进来

让管理参与到Scrum中来是一个很难完成的任务,但是请至少确保他们能参加大部分的Sprint Review, 并第一时间传递对产品的反馈和市场的新要求。

另外,影响是相互的,这也是一个很好的机会让团队可以把自己的意见想法模式影响管理层,帮助他们更好的理解产品是如何迭代的产出的。相反管理层的介入也会让团队在后续工作中更有信心。

 11. 培养团队自己做决定的习惯

毫无疑问我们最终希望团队能够达到的就是能自我管理并解决绝大部分问题。好的Scrum Master是帮助团队解决问题而不是替团队解决问题。循序渐进的解决问题会提升团队的自信心,帮助他们在未来尽快能够实现自管理

罗马不是一天建成的,让团队自管理也不是短期可以实现的,Scrum Master和公司管理层都需要有信心和耐心给团队成长的空间和时间。

在团队初期,大家可以做较多尝试怎么去热身团队,但是一旦发现不适合的时候,一定要及时纠正。请记住Scrum是基于经验主义的框架,更多的定义不如实践得出的真理。也欢迎大家在这里留言讨论。

 

本文作者:

Derek Ding 丁志润,11年IT行业从业经验,曾在全球前三的跨国科技公司,全球前三的在线旅游科技公司工作,拥有近十年项目管理,敏捷的经验,CSM,CSP,PMP。

scrumcn_tp

Scrum团队从创建到成熟的四个阶段

在当今的乌卡(VUCA)时代, 越来越多的企业开始导入敏捷和Scrum,然而很多企业的敏捷实施却不尽如人意。Scrum不仅仅是一个流程框架,更重要的是通过Scrum来打造团队,提升团队能力,团队磨合的程度几乎决定了Scrum实施的效果。但是团队的成功不是一蹴而就的,在团队不同的阶段如何打磨团队对大家都是一个挑战。

本文着重介绍Scrum团队从创建到成熟的4个阶段,帮助大家定位自己的团队阶段,找寻突破下一个阶段的方法。
Read more

用户故事

用户故事是否可以不写 “So that” ?

1. 背景

最近在微信群里,有一些关于用户故事书写的讨论,其中有一些观点

观点1:用户故事的格式不用完全按照标准格式那样,拘泥于形式。

关于格式这一点,不在这里讨论。

观点2:用户故事的 “So that” 必要性不大。

必要性不大的几个理由:
a) 企业已经运作很多年, 赚了很多钱了. (So that 强调的价值, 不大。)
b) 百人级别的产品总监,焦点在哪? (So that提不起他们的兴趣?)
Read more

Scrum_tp5

华为LeSS大规模敏捷案例分享

作者:吕毅,中国首位CST,LeSS认证导师
原文链接:https://yihuode.io/articles/324?from=timeline
原文主题:LeSS在华为 – 没有Scrum的LeSS

“没有Scrum的LeSS”描述了我们在大规模敏捷导入中从应用LeSS的组织设计元素切入 – 而非直接引入Scrum团队 – 的一次经历。自下而上的团队先行的方式虽然更常见,但是在大规模领域的导入中采用多少显得有些天真。相比之下这里呈现的组织先行的方式更接近在《LeSS:大规模Scrum》书中描述的LeSS导入指南“三个导入原则”之一:自上而下和自下而上并重来导入。为什么需要并重?因为合适的组织设计为后续辅导提供了坚实的基础,从而能放大辅导的有效性。我们在同一公司的两个不同产品开发部门都采用了这种方式。两个部门的规模不同,分别代表了LeSS和LeSS巨型的案例。

1. 背景

这个报告描述的是发生在2015-2016年期间华为杭州的两个产品开发部门的经历。我的工作是作为一个咨询师帮助他们的大规模敏捷导入。公司规模巨大,在产品开发上就有几万人。他们组织成业务线和开发部门,每个通常都有几百到几千人。之前也尝试过敏捷导入,只是多少有些偏差,比如他们实现的“迭代”事实上更象小瀑布,经常把测试和缺陷遗留到下个迭代;而“持续集成”更多只是每日构建和测试自动化,而非开发人员真正持续地集成他们的代码。
Read more

Scrum

ScrumMaster指南:Scrum Master的情景领导力模型

作者:Mike Cohn

译者:李洁(Jerry Li)

审校:廖靖斌(Eric Liao)

本文由Mike Cohn授权翻译,未经许可请勿转载

 

几年前,我把几个高尔夫球打到湖里了,一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了,但他仍在没完没了地建议。他说:“问题是,你得把球打得更远。” 他这样说还不如告诉我,“问题是,你打了很多次才把球打进球洞。”  我当然需要打得更远。但怎么做到呢?

类似的,你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。

Read more

Scrum_tp

团队需要Scrum Master做这六件事

我一直在和你的团队交流,好吧,可能不是你正在带的团队,而是很多和他们类似的团队。这些团队跟我分享了他们期待Scrum Master做的六件事情。

1. 帮助他们理解职责边界

敏捷团队被告知他们是自组织的。但是,这并不意味着每个企业的自组织都完全一样。比如说:

  • 团队是否有权将团队的技术需求添加到Sprint中?
  • 团队是否可以决定谁在这个团队中?
  • 团队是否可以在不询问Scrum Master的情况下改变他们的Sprint长度?
  • 在未经许可的情况下,团队可以在工具、团建活动或任何其它事情上花多少钱?

等等等等,这个列表可以无限长。
Read more

Scrum_TP

给Scrum Master的十个建议,你值得拥有

你想成为一个优秀的Scrum Master吗?

我想是的,除非你是一个产品负责人或者其他的角色。我作为一个Scrum Master已经有20多年了,这些年,我给出了很多很多的建议,也收到了很多建议。我甄选出了我认为最棒的十个建议给大家。

1. 如果没有和团队商议,请不要代表团队做任何承诺。

作为一个Scrum Master,你没有任何权利代表团队接受需求变更,不管它有多小。即使你可以完全确定团队可以搞定它。你可以这么来回答:“我需要和团队沟通后再确认是否可以接受。”
Read more

Spotify-scrum中文网1

Spotify敏捷模式详解三部曲第三篇:工程文化

摘要

在本系列文章的第一篇和第二篇,我们分别介绍了Spotify的敏捷研发团队和研发过程。

在本篇,我们将介绍Spotify的敏捷工程文化。

引言

Spotify通过文化和价值观来进行管理,在本篇中,我们从如下八个方面来介绍Spotify的敏捷工程文化:

一、 如何管理小队的自主性

二、 如何管理标准化

三、 如果做到以人为本

四、 如何管理部署上线

五、 如何管理创新

六、 如何管理失败

七、 如何处理浪费

八、 如何管理文化

一、 如何管理小队的自主性

Read more

Spotify-scrum中文网

Spotify敏捷模式详解三部曲第二篇:研发过程

摘要

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。在本篇,我们将介绍Spotify基于敏捷开发和精益创业思维的产品研发过程。

引言

在本系列文章的第一篇,我们介绍了Spotify的敏捷研发团队,以及它独特的组织架构。Spotify的研发团队采用的是一种非常独特的组织架构,如下图所示:

屏幕快照 2019-01-02 上午10.26.32

整个研发组织有多个称为“Tribe部落”的单元组成,每个部落中包括多个“Squad小队”,从横向的维度,把拥有类似技能的人放在一起形成“Chapter分会”和“Guild协会”。 Read more