普通视图

发现新文章,点击刷新页面。
昨天以前Bob Jiang's Blog

CSM认证完全指南 - Certified ScrumMaster认证

2025年1月26日 08:00

CSM认证完全指南

CSM (Certified ScrumMaster) 是由Scrum Alliance颁发的全球认可的Scrum Master专业认证。本指南帮助您全面了解CSM认证的价值、获取流程和职业发展路径。

什么是CSM认证?

Certified ScrumMaster (CSM) 认证是Scrum Alliance提供的入门级ScrumMaster认证,证明持证者:

  • 理解Scrum框架的核心概念和价值观
  • 掌握ScrumMaster角色的职责与技能
  • 能够引导团队进行敏捷转型
  • 获得全球认可的专业资质

了解更多: 什么是CSM认证

CSM认证价值

职业发展

  • 薪资提升: 2019年CSM认证薪资调查显示,持证者薪资普遍高于未认证从业者
  • 职业晋升: 成为敏捷教练、Scrum Master、敏捷项目经理的必备资质
  • 全球通用: 获得国际认可,增强职场竞争力

知识体系

如何获得CSM认证

第一步:参加CSM培训课程

CSM认证要求参加由Certified Scrum Trainer (CST) 授课的16小时培训课程。

培训内容:

  • 模块1:敏捷与Scrum概述
  • 模块2:Scrum三大角色(ScrumMaster、产品负责人、开发团队)
  • 模块3:产品列表与用户故事
  • 模块4:敏捷估算与规划
  • 模块5:Scrum五大会议

课程形式:

  • 2天集中培训(16小时)
  • 游戏化学习体验
  • 实战案例分享
  • 小组互动讨论

查看最新课程安排: 敏捷培训课程表

第二步:通过CSM考试

完成培训后,您将收到Scrum Alliance的考试邀请邮件。

考试信息:

  • 题型:50道单选题
  • 及格分数:37题正确(74%)
  • 考试时间:60分钟
  • 语言:英文(可使用翻译工具)
  • 费用:包含在培训费中
  • 重考:2次免费重考机会

考试准备: CSM考试常见问题 | CSM常见问题解答

第三步:获得认证

通过考试后,您将获得:

  • ✅ CSM认证证书(电子版)
  • ✅ Scrum Alliance两年会员资格
  • ✅ 可在LinkedIn等平台展示的数字徽章
  • ✅ 16 PDU学分(PMI认可)

CSM认证续证

CSM认证有效期为2年,续证要求:

Scrum学习资源中心 - 从入门到精通

2025年1月26日 08:00

Scrum学习资源中心

欢迎来到Scrum学习资源中心!无论您是Scrum新手还是希望深入学习的从业者,这里汇集了全面的Scrum学习资源,帮助您系统掌握Scrum框架。

📚 Scrum基础

Scrum官方指南

Scrum框架核心

什么是Scrum?

👥 Scrum角色

ScrumMaster

Product Owner

开发团队

🎯 Scrum工件

产品列表 (Product Backlog)

Sprint Backlog & 增量

📅 Scrum会议

全部会议概览

每日站会 (Daily Scrum)

Sprint计划会 (Sprint Planning)

Sprint评审会 (Sprint Review)

Sprint回顾会 (Sprint Retrospective)

产品列表梳理会

📏 Scrum估算与度量

估算方法

度量指标

🎮 Scrum敏捷游戏

通过游戏化学习体验Scrum:

What is Decentralization Autonomous Organization (DAO)

2022年3月29日 08:00

What is Decentralization Autonomous Organization (aka DAO)

In this post, I will introduce what is DAO, and I will introduce how to start a DAO in next post. So here is a definition from Aragon -

  • Member-owned communities without centralized leadership.
  • A safe way to collaborate with internet strangers.
  • A safe place to commit funds to a specific cause.

DAO definition on Ethereum.org

So let’s go into details about DAO from 3 perspectives:

What is GitcoinDAO

2022年1月29日 08:00

What is GitcoinDAO

More info - GitcoinDAO 101 - workstreams

Scrum指南最新版 2020 Scrum权威指南 游戏规则

2020年11月12日 08:00

Scrum 官方权威指南

收听有声版 | 官网下载PDF

由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护

版本:2020中文版 | 查看旧版本(2017)

Scrum 指南的目的

在 1990 年代初,我们开发了 Scrum。在 2010 年,我们撰写首版 Scrum 指南,以帮助全世界的人们理解 Scrum。自那时起,我们通过小的功能更新对 Scrum 指南进行了演进。我们是 Scrum 指南的共同后盾。

Scrum 指南包含了 Scrum 的定义。框架的每个元素都有其特定的目的,这对于使用 Scrum 实现全部价值和成果是至关重要的。如果更改 Scrum 的核心设计或理念、遗漏元素或不遵循 Scrum 的规则,将掩盖问题并限制 Scrum 的好处,甚至可能变得毫无用途。

我们关注到 Scrum 在日益复杂的世界中应用越来越广泛。我们很荣幸地看到 Scrum 在许多本质上具有复杂性的工作领域中被采用,超越了 Scrum 的起源领域——软件产品开发。随着 Scrum 的应用范围不断扩大,developers、研究人员、分析师、科学家和其他专家都能在工作中应用。因此,我们在 Scrum 中使用 “developers” 一词并不是为了排除其他使用者,而是为了简化统称。如果您从 Scrum 中获得价值,那么您可以将自己视为其中一员。

在使用 Scrum 时,可能可以找到、应用和设计适合本文中所描述的 Scrum 框架的模式、过程和见解。它们的描述超出了 Scrum 指南的目的,因为它们因 Scrum 的使用具体情境不同而不同。这些使用 Scrum 框架的特定技巧有很大的差异,因此不在本文中描述。

Ken Schwaber & Jeff Sutherland 2020 年 11 月

国王的晚宴 King's dinner

2020年7月9日 08:00

作者:Ron Jeffries
译者:年志君 (微信公众号:敏捷家)

背景

这个小故事根据资源、质量、范围和时间的关键度量变量,来描述了一个有效的团队运作方式。故事由罗恩·杰弗里斯翻译自原始的巴比伦楔形文字。

开始啦

从前 … 有一个伟大的国王,他想为几千位最亲密的朋友举行国宴。他把首席工匠叫来,告诉他晚餐的安排。国王描述了他想要最好的餐桌摆设,全部镶入黄金,并镶嵌有错综复杂的珠宝。首席工匠画了一些草图,并与国王就摆设达成了一致。他们同意在几周后再见面,看看餐桌摆设制作的进度计划。

几个星期过去了,首席工匠来报告。他向国王展示了一个时间计划,该计划包括创建摆设的原型,国王的审查,以及最终餐桌摆设的展示。计划表显示,晚宴布置将在11月完成,但国王愿意在10月举行宴会,此时天气仍然晴朗。首席工匠同意在下次会议之前调整工作,以便在10月前完工。

按计划,首席工匠带着原型和修订的10月完工的生产计划展示给国王。而且,工匠还建议与国王要定期见面,以检查进展情况。国王审阅了由于工期缩短而简化设计的原型。国王要求在盘子上要有更多的小天使,在镶嵌的珠宝上有更漂亮的雕刻,在刀叉上增加更复杂的卷轴。首席工匠抗议说,这些新的功能将延迟完工计划,但国王提醒他谁是国王,谁不是。首席工匠退了出去。

落后了

在下一次的项目审查中,事情已经明显落后了。准备好的珠宝太少了,盘子也不够完整,刀叉也做得太少。国王要求工匠们更加努力地工作。首席工匠抗议,但国王再次提醒他们的相对地位。国王要求增加审查的次数,甚至比已经同意的还要频繁。

在下一次审查中,任务并没有完成太多。国王坚持要去现场看看正在做什么。第二天他到了,工匠们有点紧张,但他们知道他们自己的技艺,并且他们大多数都像往常一样努力工作。

  • “那个人在干什么?”国王指着一个明显的懒鬼问。
  • “国王啊,他正在休息。”工匠首领回答说。
  • “这是对我们时间的极大的侮辱。” 国王斥责道: “他们应该在晚上休息,而不是在工作的时候。”
  • “国王啊,就照您说的办。”工匠首领回答说。
  • 国王问:“那边那个人在干什么?”
  • “国王啊,他在磨刀。”
  • “又是在浪费我们的时间。难怪你一事无成。从今以后,工具要在夜间磨,不能在工作中磨。”
  • “国王啊,如你所愿,”首席工匠叹息道。至此告别,直到国王下次审查。

在下一次审查的中途,首席工匠找国王的首席管家,要求增加一些新的学徒帮助完成任务,特别是磨刀的任务。这位管家考虑到国王的财政预算,以管家古老的方式解决了这个问题,没有回应首席工匠的请求。。

在下一次审查时,实际上完成了更多的工作。国王视察了一堆已完成的盘子和器皿。起初,他满意地笑了笑,但当他更仔细地查验时,他的微笑变成了皱眉。

  • 他咆哮道:“这些盘子,这些小天使很粗糙,不像早期的盘子那样精致。如果你就这么做了,客人们是不会有什么好印象的。”
  • “国王啊,工作粗糙,是因您的命令使用了钝的工具。”
  • “我没有命令你做差劲的工作,我命令你不要浪费时间!
  • “噢,国王,”工匠解释说,“就像陛下没有好的食物和环境就不能举办一个好的宴会一样,我的工匠们也不能用粗糙的工具创造出好的艺术。”
  • “我必须把一切都告诉你吗?”国王尖叫道。“可以让别人磨工具吧!”
  • “国王啊,我已经为此请了新的学徒,但您的管家没有答应我的请求。”
  • 国王咆哮道:“工匠,不要拿这些内部事务来烦我。我可是国王。让工匠们在需要的时候磨砺他们的工具:但他们必须通过加班来弥补时间。”
  • “哦,国王,就照你说的办吧。”首席工匠闷闷不乐地回答。

国王回到视察的地方。很快,他又被激怒了。

  • “这些盘子,很多还没有雕花的珠宝。这里出什么问题了?”
  • “哦,国王,珠宝损坏的情况越来越严重了。”首席工匠答道。
  • “是什么导致了这一切,“国王大叫道,“你的人如此无能吗?
  • “恕我直言,国王陛下,珠宝雕刻是一项微妙的工作。由于没有频繁的休息时间,雕刻者眼睛疲劳,双手颤抖,导致工作失败。
  • “你这个傻瓜。”国王大声说。“你必须惩罚那些破坏我珍贵珠宝的工人。显然,他们不够小心。”
  • “应该是这样的,”首席工匠鞠躬答道。

在第二次视察时,国王带着怀疑和明显的挑战神气走了进来。当他看到雕刻的质量有所提高时,他平静了一点,当他看到大部分的盘子都镶嵌着宝石时,他几乎高兴起来。然而,随后,他数了数已完成的工作,发现尽管质量提高了,但完成的工作并不多。

  • “你现在做错了什么,工匠?”你自己要受什么惩罚呢?”
  • “啊,国王,”首席工匠答道,“我的几个主要的工匠因为您的惩罚而生病了,不能工作了。还有一些人离开自己的王国去了邻国,说他们的工作在那里会更受赏识。结果,我们的工人更少,生产的工作也更少了。”
  • “我命令你的工匠们加班,”国王咆哮道,“难道这还没有改善吗?”
  • “国王啊,事实恰恰相反。同样,也有一些人离开了王国,去寻找一个他们会更受赞赏的地方。留下来的大多来自基层,虽然他们精力充沛,但缺乏做你所要求的工作经验。当他们因为加班而疲惫不堪时,又出现了损坏和无效的工作。”
  • “这是不可接受的!我对你们非常失望,工匠。回到你们的住处,等待我决定你们的命运。”

首席工匠退出了,他确信他的时代结束了。

国王非常担心。那个首席工匠辜负了他的期望,他一定会死的。不过国宴很重要,晚宴布置也必须完成。尽管国王不愿意承认这一点,但工匠还是尽力按照命令去做了。国王决定咨询他的巫师,巫师从小就是他的导师和心腹。

巫师

他还没来得及召唤使者,一声巨响和一团烟雾宣告了巫师的到来。据说,当人们想到他的时候,这位巫师总是知道的。 国王跳了一下后,并没有浪费时间。他向巫师描述了围绕晚宴发生的事情,然后表达了他的担忧。“巫师,我觉得首席工匠违抗了我的命令,必须得死。然而,由于我们无法给他适当的建议,我们是否对这个问题也要承担一些责任呢? 不管怎样,没有了首席工匠,我的工匠们怎么准备晚宴呢?”

巫师伸手从稀薄的空气中抓取了一只鸽子。他拔出匕首,打算仔细观察鸽子的内脏,只是刚好想起自己是在王宫里。他把鸽子塞进一个宽大的口袋里,却打了个响指,发出了短暂的火光,接着是一缕烟雾。他观察着烟雾消散的过程,辨别出只有他才能看到的模式。最后,他转向国王。

“陛下,我研究这些问题已经很久了,可以提供一些见解。我们必须考虑工作的四个方面,而且只有四个方面。这些我称之为资源、范围、质量和时间。不可改变的自然法则与这些方面有关。让我们仔细思考,看看他们之间有什么关系。”

  • 巫师继续说:“我把陛下所要求的工作称为所有任务的总和,即范围。”
  • “一个奇怪的名字,巫师,但我熟悉你的神秘方式。说下去。”国王说。
  • “现在考虑一下资源:陛下有多少工匠。如果一个工匠失踪了,他的工作或工作范围是增加还是减少呢?”
  • “这要看丢失的工匠是好是坏,以及他被赋予了什么责任。”国王回答说。
  • 国王,您是明智的。然而你的工匠们很有能力,正如你所要求的那样,他们肯定会明智地分担责任。那么,减少资源的结果是什么呢?
  • “我们仍然要求我们所要求的。”工作还是最高质量的要求。“那一定要花更多的时间,”国王若有所思地回答。
  • 巫师点点头。“是的,国王。如果范围和质量没有改变,资源减少,那么时间就会延长。您是明智的。”
  • 巫师继续说道:“现在,国王啊,考虑一下,如果我们保持资源不变,并要求工匠在更短的时间内完成同样的工作,将会发生什么。然后会发生什么呢?”
  • “他们会更加努力地工作来取悦陛下吗?”国王满怀希望地问。
  • “这就是陛下的经历吗?”巫师俏皮地问。
  • “没有,”国王承认,“尽管他们尽力了。一开始,似乎是有效的,但总的来说,他们做得更少,当我要求更多的产出,工作本身是差的。努力工作只会导致糟糕的结果,一些关键的工匠实际上逃离了王国。”
  • “国王啊,你能把这个用在在范围和质量上吗?”
  • “让我想想,巫师。我明白了…,如果资源和范围保持不变,时间减少了,那么质量就不可避免的降低了。
  • “是的,国王,”巫师表示赞同。
  • “但这是不可接受的,”国王叫道。“我们收到的物品必须是最高质量的!”
  • “那么,陛下,可以做些什么呢?”巫师问道。
  • 国王沉思着,凝视着他的王国。“你的问题很有挑战性,巫师。”但让我想想,我能猜透你的“迷宫”。等等,我想到了!你让我意识到,即使是我,你的国王也不能随意支配这四个方面。如果我限制资源、时间和质量,那么自然范围就确认了。然而,如果我限制资源、质量和范围,那么自然时间就必须受到控制。这是你的教训吗?”
  • 巫师回答说:“国王,你说得很明智。正如你所说的那样。你的工匠在限定的范围内很好地为你服务。他们会在任何时候都将自己的技能发挥到极致,但他们无法改变这一自然规律。”
  • “那么我无计可施吗?我能不能知道要完成什么或什么时候会完成吗?”国王喊道。
  • “国王,不是这样的。在他的作品中,你的工匠很好地理解了各方面之间的关系。如果你告诉他你的三个愿望,他可以估计第四个的价值。尽管可能会在细节上改变结果,但可以让你了解他估计的进展情况,让你及时为结果做好准备。如果你在这些方面与他合作,他就能最有效地进展,而你也能有效地引导他取得最好的结果。”
  • “做得好,巫师。你帮助了国王,而且救了一个首席工匠的命。”

说完,国王转身想打发巫师走,却发现他已经走了。国王耸了耸肩,召见了首席工匠。首席工匠走进房间,期待着最坏的结果,但他心里知道,他和他的工人们已经尽力了。他战战兢兢地等待着国王的命令。

Scrum完整剧本

2020年6月16日 08:00

敏捷快速入门指南

《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法,对于那些希望获得一些一般性指南(并非旨在作为说明性准则,但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题(Scrum事件)上。其他主题涵盖了作为敏捷教练经常遇到的领域。

Scrum主题

其他主题:

Product Backlog Refinement

简介:产品列表梳理会议(也称为需求梳理)不是Scrum指南中定义的活动。然而,产品列表梳理的实践在Scrum团队中是非常普遍,以至于一些从业者认为这是普遍接受的Scrum实践。

定义

产品列表梳理会议是为即将到来的(如接下来的1-2个)迭代(Sprint)准备用户故事的一个持续过程。产品列表梳理有两个主要方面:

  • 由产品经理和产品负责人领导的,需求功能不断定义、完善、澄清以及重新确定顺序;
  • 在Sprint开始之前进行的一次协作会议,以评估新信息,确保准备开发下一组故事。

频率

  • 每个Sprint一次(通常是Sprint中,下一个Sprint开始前的1-5天不等)

注意:某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint,可能一周梳理1次。

持续时间

团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时,团队更有可能在相当短的时间内完成产品列表梳理。(另请参见编写清晰明确的用户故事快速入门指南。)

参与者、输入、输出

  • 参与者 – 产品负责人,ScrumMaster,开发团队
  • 输入 – 主要输入是为即将到来的Sprint预测的用户故事,这些可能是后续Sprint的不错选择。处于就绪状态的用户故事要多于下一个Sprint可能会有所帮助。因此,如果团队确定依赖性,并有了影响多个故事的优先级或工作量的新信息,那么就可以灵活处理。
  • 输出 – 整个团队达成共识,就一组排好序、清晰定义且独立的用户故事达成共识。

活动

产品列表梳理期间的活动通常包括:

  • 查看从当前Sprint中学到的新信息
  • 讨论最快速度、可能速度和最差速度
  • 是否对当前的Sprint进度进行检查 - 我们是否认为我们将完成Sprint期间的所有工作?
    • 在回答这个问题时,请牢记可持续的步伐
    • 对于团队来说,在Sprint中去现实地评估事情,比等到Sprint结束后再进行任何变更,要好的多(香不香?)。
  • 查看并澄清即将发布的用户故事
  • 讨论并同意验收标准(Acceptance Criteria),以确认双方的理解。以及确认估算大小和拆分太大的故事
    • 提醒:任何故事,如果团队在一个SPrint内无法完成4个,那么就是太大了。
  • 同意下一个Sprint的计划
    • 根据我们的速度预测和大小确定,这是一个现实的计划吗?
    • 如果对上一个问题的回答为"否",则拆分故事,或交换优先级相近的小故事,直到团队对计划充满信心为止

注意:另请参阅多年前我写的产品列表梳理

Daily Scrum

定义

每日Scrum(又称每日站会)是开发团队通过简短的、有针对性的对话来确保他们每天保持一致。每日Scrum期间发生的主要事情:

  • 分享知识
  • 找出帮助其他团队成员的机会
  • 识别依赖性、风险
  • 同意删除障碍的后续步骤

频率

每天一次(一般SPrint第一天除外,因为已经有了计划会);每天同一时间、同一地点,会降低复杂度。

持续时间

每日Scrum的持续时间不得超过15分钟。

参与者、输入、输出

  • 参与者 – 开发团队,ScrumMaster(或其他主持人),产品负责人
  • 输入 – 主要输入是自上次"每日Scrum"以来的任何工作。其他潜在的输入包括在测试过程中可能出现的任何异常情况、优先级的更改,或其他可能影响Sprint计划的任何情况
  • 输出 – 团队成员之间在以下方面达成共识,例如何解决已出现的任何障碍,以及如何在接下来的24小时内最有效地合作以将正在进行的工作项移至已完成方面达成共识

注意: 与会者按重要性顺序列出:每日Scrum用于开发团队,因此会议属于团队的。Scrum Master通常作为主持人出现。但是,团队中的不同成员轮流担任主持人也很常见(不一定只有ScrumMaster来主持)。对于产品负责人而言,阐明可能出现的任何与产品相关的问题也可能会有帮助。

Scrum指南 Scrum权威指南 游戏规则

2017年11月12日 08:00

Scrum 官方权威指南

收听有声版 | 官网下载PDF

由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护

版本:2017中文版

Scrum 指南的目的

Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本 Scrum 指南 包含了 Scrum 的定义,其中包括 Scrum 的角色、事件、工件,以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum,Scrum 指南也由他们撰写并提供。总之,他们是 Scrum 指南的后盾。

Scrum 的定义

Scrum(名词): Scrum 是一个框架,在此框架中人们可以解决复杂的自适应难题,同时也能高效并创造性地交付最高价值的产品。

Scrum 是:

  • 轻量级的
  • 易于理解的
  • 难以精通的

Scrum 是一个框架,自上世纪 90 年代初以来,它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说,它是一个框架,在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清晰地显现出来,以便您可以持续改进产品、团队和工作环境。

Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的,其对于 Scrum 的成功与使用是至关重要的。

Scrum 的规则把角色、事件和工件组织在一起,管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。

使用 Scrum 框架的其它不同特定技巧将不在本文中描述。

Scrum 的应用

Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始,Scrum 在全球范围内已得到了广泛应用:

1. 研究与确定可行的市场、技术和产品能力;

2. 开发产品和增强功能;

京东敏捷软件开发精髓

2015年9月2日 08:00

大家好,我是今天的分享老师:姜信宝,Bob Jiang。我来自京东商城-技术研发管理部,是京东的敏捷教练。

很高兴受到“京技院“的邀请,能有机会与大家分享关于京东的敏捷软件开发商的一些心得体会,希望分享的内容能给大家带来一些收获。这次准备的时间有些仓促,同时我也是第一次通过微信的形式做这种交流,有不足的地方还希望大家能够理解。:)

今天我的分享话题会分为两大部分:

1.案例分享 2.敏捷软件开发的精髓

下面我们来看一下第一个案例,京麦团队。相信如果关注京东敏捷开发的朋友,对于这个团队并不陌生。京麦团队是京东的第一个敏捷团队。到目前为止该团队没有一个员工离职,这在互联网行业可以说是一个奇迹了。

案例1:京麦

2012年底,有一个屌丝团队,他们做的产品慢慢被边缘化,客户不满意现有产品,技术负债高,并且团队马上要被解散去做其他产品了。这个场景听起来熟悉吗?

很幸运的是,团队leader旁听了一次敏捷的工作坊,知道敏捷应该怎么玩,也知道了和其他团队之间的差距在哪里。因此京麦团队决定试一试,用敏捷开发的方式进行软件开发,有了想法马上行动。

第一步,组织团队进行敏捷培训,全员知道什么是正确的敏捷软件开发。这是敏捷软件开发的第一步,也是至关重要的一步。

第二步,团队坐在一起,这里团队指的是产品、研发、测试整个团队,而不仅仅是研发。团队坐在一起的好处有很多,比如有了问题,直接喊“张三这个问题我们一起看一下?” 又或者产品和研发正在讨论某个具体的需求,测试人员听到后立刻加入进来,信息快速共享并达成一致。

另外,团队坐在一起还有其他的好处,团队的每日站会更加容易同时一起开,代码评审也会随时随地的发生,任务板上的任务团队更容易更新。简言之,团队坐在一起更容易促成团队之间的沟通,以及信息共享。

第三步,按照Scrum框架的定义,严格地开展每一个会议,如迭代计划会、每日站会、迭代评审会、迭代回顾会以及产品列表梳理会。每一个会议都不能省略。

第四步,Scrum会议坚持开的情况下,团队可以尝试引入已经被证明有效的良好工程实践。如持续集成、结对编程、测试驱动开发等。

在坚持以上四步之后,京麦团队达到了如下的成果: 1.交付周期从之前的12周,降到现在的2周 2.同时在线的用户数提升了3倍 3.活跃用户数提升了5倍

京麦团队到现在敏捷转型接近三年,团队也已经拆分成4个小团队,整个团队还是在坚持着使用Scrum的方式,每两周一个迭代,持续交付价值,持续改进。下面是他们团队任务板的一个持续改进图,供大家参考。

这是他们第一版的任务板

kanban1.jpg

第二版

kanban2

第三版

kanban3

最后在京麦团队的带动下,整个POP团队都已经开始了敏捷转型之旅,非常感谢京麦团队不懈的坚持。以上是第一个案例的分享。

案例2:物流开放平台

介绍这个案例之前,我想先说一下团队的收获。这个团队在人员数量不变的前提下,2015年上半年就完成了2014年一年的任务量,即团队效率至少提升了1倍。想知道这个团队是如何做到的吗?我们一起来看看这个团队的例子。

首先这个团队经理是很开放的一个人,喜欢新鲜事物,喜欢尝试。这是非常好的开端。 第一步,仓储团队的总监找到我们,商量进行大团队的敏捷转型。这里多说一下,为什么这个团队的总监会找到我们。前期我们(敏捷教练)在POP京麦团队的成功试点,很多团队也都听说了敏捷可以成功的,因此越来越多的团队也想进行敏捷转型。也就是说通过早期成功的样板团队,树立了榜样,也为后期的敏捷转型铺好了路。

第二步,敏捷导入,即进行普及性的培训。上面提到的团队经理和他手下的几个leader都来参加了ScrumMaster敏捷训练营的培训。

(这是团队经理听完培训之后的反馈:“在京东第一次接触敏捷研发管理的思想,是在今年春节前一次公司组织的敏捷培训课程上,听了敏捷教练BOB的授课,感觉这种管理模式既可以改善现有研发工作中的一些问题,又能给团队带来很多新鲜事物,真是我们迫切需要的。于是,在部门领导的倡导下,我们几个三级部门开始了各自团队的敏捷之旅。”)

第三步,团队开始按照Scrum进行敏捷软件开发,并且持续改进。大多数团队一开始都会选择两周作为一个迭代周期,因为两周是一个很好的开始点。

制定了团队规则之后,就要执行。比如“最初开站会的时候,大家都不是很积极,到了规定的时间,很多人还在忙自己的事情,不叫不来。后来敏捷团队制订了奖惩机制,每天不按时参加站会又不提前请假的,都要扣20块钱作为水果基金。这下大家的积极性提高了,每天参加站会的人也比较齐全了。有一次一个同事因为处理问题,晚来了2分钟,本来是有情可原的,但为了兑现承诺,他主动买了5盒草莓分给大家。”。

另外,回顾会议是非常关键的。“在敏捷回顾会上,大家都要总结上个迭代周期里工作情况,包括做得好的地方和需要总结提高的地方。会议由Scrum Master主持,每个人会拿到不同颜色的便签纸,蓝色的便签纸上写做的好的实例和总结,红色的便签纸上写的是待提高的事例和建议。在写完总结后,大家会按顺序轮流发言,提出自己的意见和建议,最终汇总到Scrum Master处。每次回顾会,都会让大家获得很多的经验和宝贵的意见,从而提升整个敏捷团队的工作质量。”

在部门领导和公司管理层的支持下,我们敏捷团队鸟枪换炮,从以前传统的墙面看板,上升为触摸电视屏幕的电子看板。怀着激动和感激的心情,我们几个小伙伴瞬时间将高大上的触摸电视和支架组装完毕。

e-kanban

在团队敏捷转型的一开始,为了让大家对Scrum有更全面的了解,团队还自发组织了读书行动。每天固定时间固定地点,团队花30分钟共同阅读同一本书,并且大家会就这一个主题进行讨论。

reading

可视化的读书结果

以上就是第二个案例分享,物流开放平台。

案例3 - 京东途牛融合项目

5月8日京东和途牛联合宣布,双方展开深入战略合作。6月下旬,我作为敏捷教练进驻途牛团队,帮助途牛项目一期进行敏捷软件开发的辅导。

针对全新项目的转型,有以下几点需要注意。 第一,需要先梳理出第一版的产品列表(Product Backlog)。一开始我就和途牛团队的8位产品经理进行产品需求的梳理,并且使用用户故事地图进行了产品需求的大概规划。

第二,团队坐在一起。产品研发和测试全部坐在一起。由于这个项目的特殊性,需要和途牛进行频繁的接口测试和联调,途牛团队也安排坐在一起了。

第三,形成Scrum of Scrums(SoS)会议。这个项目有四个团队,跟团游、门票、平台、途牛方。每个团队都有自己的每日站会,固定每天下班前每个团队代表和产品经理一起开SoS会议,同步团队开发中遇到的问题、障碍和风险。

第四,团队坚持Scrum的会议。并不断改进产品和团队一起的工作方法。

266958343874433578

以上就是京东途牛融合项目的案例分享。3个案例已经全部分享完了。

-———————————————————————————————————

下面重点来了,当当当当!来说一下京东的敏捷软件开发的精髓。这就是一个核心,四个基本点。

agile_essential_core

一个核心:价值驱动 四个基本点:透明、迭代、持续改进、教练

价值驱动

不以价值驱动为导向的敏捷转型就是耍流氓。我见过很多团队要进行敏捷转型,而如果你要问他们为什么要敏捷,则答案是五花八门。老板的要求,听说敏捷能让我们效率提升,质量提高。也有很多负面的声音,敏捷不适合我们团队,我们公司文化和敏捷不匹配,敏捷就是加班,等等。这些都没有回答到点子上。

而敏捷软件开发的精髓就是尽早频繁的交付商业价值(感谢Alistair Cockburn博士)。任何不以价值驱动的敏捷软件开发都是伪敏捷。那说了这么多价值驱动,以价值为核心,具体到实践层面要怎么做呢?

这里我给大家介绍一个非常非常有用而且简单的工具—产品列表(Product Backlog)。团队敏捷转型,在接受了普及培训之后,第一个要做的事情就是建立一个且是唯一的产品列表。为什么要这么做?最重要的原因就是需求统一入口。

折飞机-团队建设游戏-敏捷游戏

2015年7月3日 08:00

游戏准备

游戏道具: 白纸若干,折好的飞机一个,折飞机文档一份(见12种折飞机的方法)

游戏目标:在8分钟时间内,每个人按规定折好一个纸飞机。

参与人员: 3个小组,每组5~9人

游戏步骤

第一组——文档:组员拿到一份文档,按文档说明制作纸飞机;

第二组——反向工程:组员得到一个已完成的纸飞机,他们要重现制作纸飞机的步骤。

第三组——指导:“首席设计者”按步骤制作一只纸飞机,而组员重复完成每一步。

结果

在在一系列有趣的试验中,让大家理解在敏捷项目中传递知识的最佳途径。实验结果如下:

在限定时间内,

只有12.5%的人能够按照文档完成任务。

使用反向工程方法,有25%的参与者成功做出飞机。

采用教练指导方法,则可以让100%的参与者全部成功做出飞机。

结论

健康的沟通和指导,是传递和分享知识的最佳方式。对于需要经常沟通和反馈的软件开发来说,这个原则更具价值。

补充

假如我是一个开发人员,我发现了一个技巧,可以将一些数据绑定到某个用户界面里的控件中,而且写出了代码实现。这个技巧构成了一种模式,与我一起开发的同事们希望了解具体做法。

如果你是我的同事,有三种方法:

我给你一个说明该技巧的相关文档;

我告诉你代码在哪里,建议你自己弄明白;

我跟你结对编程,通过一组新数据实现该模式。

你会选哪一种?

反思:

将某种情形下的知识从一个单位(可以是个人、团队、部门、组织)传递到另一个单位,这就是知识传递。

很多组织用了很多时间将自己积累的知识记录成文档,希望知识传递过程能由此变得更顺利、高效。而敏捷并不鼓励文档,它强调“可工作的软件胜过面面俱到的文档”。

——-12中飞机的折法—————-

(https://www.360doc.com/content/12/0324/23/2567933_197411378.shtml)

12种折飞机的方法

幸福的笑脸

2015年6月30日 08:00

游戏收益

小伙伴们,你想通过游戏学习精益理论吗,尤其是精益的核心,拉动式生产。通过这个简单的游戏,你可以学习到:

  • 假设预测时长及预先规划的经济问题
  • 看板原则——看板的核心是什么?
  • 现金流和投资回报的重要性

时长:60分钟

物料

  • 每组4-6人 (一共5组)
  • 每组50张蓝色和黄色的纸(A4大小或略小)
  • 每组2个胶棒
  • 每组3把剪刀
  • 每组1卷美文胶带

游戏步骤

我们在经营一家制作纸笑脸的公司。这个笑脸包括:

  • 椭圆形的蓝色脸蛋
  • 2个三角形或长方形的黄色眼睛
  • 1个三角形或长方形的黄色的嘴巴

我们一共有4种类型的产品:

  • The Mike张三 – 三角眼,三角嘴
  • The Don李四 – 长方眼,长方嘴
  • The Aleem赵五 – 三角眼,长方嘴
  • The Jessica王二麻子 – 长方眼,长方嘴

第一轮——推动模式

每个组预先猜测一下上述类型的笑脸,市场分别会需要多少,悄悄地写下这些数字(不要告诉其他组)。小组根据这个猜测设置自己的流水线:

  • 用蓝色的纸裁剪椭圆形脸
  • 画上眼睛和嘴巴(必须的步骤)
  • 粘上眼睛
  • 粘上嘴巴
  • 把做好的脸贴在墙上(交付)

在开始之前每组至少先做一个脸熟悉一下。这一轮4-5分钟。结束后,揭秘市场需要的实际订单数量。每组根据订单数,按照下面的指示计算纯利润:

  • 每个做好的且卖出去的脸 = 400元
  • 每个做好的但没卖出去的脸 = -200元
  • 每个半成品的眼睛 = -25元
  • 每个半成品的嘴巴 = -50元
  • 每个半成品的脸 = -100元

有的组可能会赚了一点钱,但大多数都会是赤字或破产了。讨论一下这个业务模型,以及这种生产业务和库存会发生什么。

做好的笑脸例子如下:

IMG_2675

第二轮——拉动模式

每个组将根据市场订单进行生产。每组设置如下的流水线:

  • RFQ - 准备好的脸队列: 2个只有眼睛的未完成的脸。1个是长方形眼睛,另一个是三角眼。
  • MQ - 嘴巴队列: 2个嘴,一个长方形,另一个三角形
  • FQ - 脸蛋队列:1个空的脸
  • EQ - 眼睛队列:2对眼睛,一对长方形,另一对三角形

这次每个组只有听到订单才开始生产。因此当你喊“张三”的时候,准备好的脸队列(RFQ)的人就从嘴巴队列拉一个三角嘴粘上,并交付给客户。紧接着这个就会发信号让RFQ和MQ进行补充。每个组都制作一个笑脸,并且在真正开始之前把材料补充好。

敏捷需求游戏

2015年6月23日 08:00

游戏目标

这个游戏的目的是让“开发团队”根据“需求团队”写的书面需求文档创建一幅图形。

游戏步骤

  1. 每组对半分成2个小组。一半是“开发团队”,另一半是“需求团队”。最好是2个小组能地理上分开。比如一个小组在屋外,另一个在屋内。(注意:分组的时候可以让原来写需求的人做开发,而不写需求的人来写需求)

  2. (开发团队到屋外休息)需求团队留在屋内,给他们展示一幅图形。然后让需求团队在10分钟内根据图形写出需求。

  3. 需求写好之后,开发团队进屋,需求团队到屋外休息。(注意:开发团队和需求团队的成员要一一对接,即找到自己的接口人)

  4. 开发团队根据写好的需求进行开发,时长10分钟。开发团队如果对于需求有问题,可以给需求团队写邮件沟通(写好之后由引导师送信)。写信的内容只能是文字沟通,不能用图形,数字或者符号。

  5. 需求团队和开发团队不能进行口头沟通或者暗示等。

  6. 所有的需求必须是以文字形式描述。不能用图形,符号或数字。

  7. 需求文档要求尽可能的详细。

  8. 开发团队完成后,大家一起评审结果。

原文:https://www.bigvisible.com/2010/11/spec-writing-game/

游戏中用到的图形可以参考附件:Specification Exercise_oppgaveomkravformidling1

老板和走路人的游戏(boss walker)- 敏捷自组织团队游戏

2015年6月19日 08:00

这个游戏一共分两轮

第一轮

  • 两人结对
  • 一人是老板,另一人是走路人
  • 老板负责给出指令:走,停,左,右,快,慢
  • 走路人必须遵守老板的命令
  • 老板负责保证走路人在60秒内完成60步
  • 走路人负责数步子
  • 老板可以命令走路人,但不能有身体接触,也不能帮忙
  • 不能站在原地,必须结对行动
  • 必须在房间内

第二轮

  • 老板也要参与到走路的过程,即老板也变成走路人
  • 走路人自己负责找出如何走60步
  • 限定时间30秒
  • 其他规则同第一轮

总结

这个是一个非常简短而有力的游戏,快速地体会命令控制和自组织团队的差别。总结的时候可以结合Richard Hackman写的《Leading Teams》里面授权矩阵,介绍自组织(自管理)团队的职责,以及自指导和自统治团队是什么样子的。

敏捷估算--Scrum系列

2015年5月14日 08:00

本文谈及的均为Scrum中的估算行为,这些方法不是Scrum原创的。

为什么要估算

谈估算,我想先从为什么要做估算谈起。

每次在我的培训课上,学员们会给出各种各样的答案。比如为了估计成本、为了设定发布日期、为了知道什么时候可以做完、为了……。但我认为估算最重要的目的是为了

达成共识

如果没有进行估算,关于需求或任务会有一些假设或者背景被忽略掉。因此在Scrum中,估算是一个集体行为,而不是某个专家拍拍脑袋出来的结果。

如何做估算

估算的方式分为两大类,绝对估算和相对估算。绝对估算耗时更长,并且需要依赖上下文,最后的结果也会产生较大误差。而与之相对,相对估算更快,结果容易达成一致。Scrum中对产品列表(product backlog)的估算常常使用的就是相对估算,估算单位为故事点(没有意义的单位)。【注意:不要将故事点和小时数做一一对应!】最常用的方法就是计划扑克。

计划扑克是由斐波那契数列组成的一串数字扑克,如下图:

crispdeck

对产品列表条目(product backlog item)进行估算的步骤,简单描述如下:

  1. 首先估算需要开发团队所有成员参加,每个人手里有一套上图的扑克
  2. 取出一个产品列表条目,产品负责人进行描述
  3. 每个团队成员根据自己的理解,拿出一张代表估算值的扑克并扣着放在桌面上。(这个过程不要讨论,不要说话,不要把你的结果告诉其他人,具体原因参见百度百科“锚效应”)
  4. 所有成员出牌完成后,大家同时亮出自己的结果
  5. 接下来邀请估算最小的成员解释一下原因,还要邀请估算最大的成员解释一下原因。讨论过程中注意遵守团队礼节。
  6. 解释完毕后,重复步骤3到步骤5,直至最后大家的估算结果一致。

相对估算还有另外一种方法,称为三角估算法。

  1. 从产品列表中挑选一个较小但不是最小的条目,比如条目A,并设定它的估算值为3 (故事点)
  2. 从产品列表的最上面取出一个条目B,和A进行对比。如果比A大,放在A的右边。如果比A小,放在A的左边。如果和A差不多大小,放在A的下面。
  3. 继续从产品列表取出条目C,重复步骤2,分别和条目A与条目B进行比较。直到为条目C找到合适的位置。
  4. 重复步骤2和步骤3,直至所有的产品列表条目都完成放置。
  5. 比较一下A左边的产品列表条目,估算值为2还是1,把左边的所有条目估算值设置为2或1.同样的把A右边的条目,按列标明估算值。
  6. 最后的结果如下图:

123

Scrum系列:

产品列表梳理(需求梳理)--Scrum入门基础系列

2015年2月23日 08:00

产品列表梳理会议是Scrum中非常重要,而很容易被忽略的一个会议。说它重要,是因为Scrum开始之前就需要有准备就绪的输入,这个输入就来自于产品列表梳理会议的结果,即初始的产品列表。而对于刚开始转型敏捷的团队,往往会忽略掉产品列表梳理会(需求梳理),从而造成迭代计划会时间过长,或者无法准时开始迭代等等问题。要想解决这个问题,需要首先明确为什么在迭代开始之前要进行梳理会议,以及谁需要参加这个会议,在这个会议都有哪些活动等。

产品列表梳理会议,是迭代就绪的很好的指示,即只有产品列表准备好了,才可以进入迭代。另外,梳理会议是由产品负责人发起或负责,可以召集开发团队参与,也可以只有相关的开发团队成员或相关的利益干系人参与。

产品列表梳理会议的内容可以总结为如下几个字:增删改。首先需要明确一点的是产品列表不是固定不变的,它是可以随着新需求的出现而变化的(即好的产品列表符合DEEP原则,参加博文产品待办列表和用户故事)。

  1. 增:那么当出现新需求的时候,就需要增加一条产品列表条目,并且针对新的条目也需要符合良好用户故事的标准(INVEST)。
  2. 删:某条需求如果已经不再需要,或者市场条件变化后该需求就可以删除了。
  3. 改:产品列表的修改还可以分为以下几类:
    • 重新估算用户故事大小、
    • 重新排用户故事的顺序、
    • 用户故事拆分等。
    • 调整发布计划

Scrum入门基础系列:

❌
❌