宝宝说敏捷(BoB Jiang敏捷新闻) – 2017年03月

宝宝说敏捷简书专栏开通,欢迎大家关注。
宝宝说已注册域名,现招募一名网站设计的小伙伴,一起搭建宝宝说网站。
对于宝宝说敏捷如果您有任何想法或建议,欢迎我和联系。

内容大纲

  • 新闻
  • 社区
  • 荐书
  • 课程

新闻


3月我陆续写了9篇文章,具体可以参考我的简书专栏
主题包含敏捷与成长,如Agile的起源、Scrum和看板的区别、如何快速学习新知识、理想与现实等

社区


Agile1001四月份活动预告 – 4月16日 DevOps实战

荐书


《在Toyota学到的只要纸1张的整理技术》- 本书的核心内容是思路整理,工具是用的一张纸。简短易用的一本书。具体可以参考链接

课程 – Certified Scrum Master (CSM) 敏捷认证课程


2017年4月16日17日 上海 http://yihuode.io/activities/444
2017年4月24日25日 深圳 http://yihuode.io/activities/436
2017年5月25日26日 北京 http://yihuode.io/activities/419

关于我


姜信宝 (Bob Jiang)
中国北方第一位CST(Certified Scrum Trainer)
资深敏捷教练、创新教练
旨在帮助企业改进工作方法以取得更好的商业价值
Certified LeSS Practitioner,《Scrum精髓》的译者
Agile1001 (敏捷一千零一夜)联合创始人
我的博客 http://www.bobjiang.com

邮件: bob@bobjiang.com
微信: bob_jiang_xinbao
电话: 13910939018

如何学会欣赏

2017年4月1日,是第九届一块的年会,我非常幸运地参加了这次“傻气与勇气”并存的年会。本次年会的主题是“用AI与未知共舞”。其中的AI是爱的谐音,也是Appreciation Inquiry的缩写。即用欣赏式探询与未知共舞。

两天的(4月1日4月2日)时间里,80多名来自全国各地的小伙伴齐聚西安,共同探索未知。在活动的第二天,收集了大家很多有关AI的疑问。其中一个问题的研讨给我非常大的触动。这个问题就是“如何锻炼欣赏的肌肉力?”

带领大家探索未知的是几位一块的伙伴(一折、Julia Zhu、任伟、嘉佑)。一开始一折跟大家分享了几个金句:

The truth is local. 真相都是在地的。

意思是真相是每个人自己的视角观察到的。所有人的真相是并存的(也可能是冲突的)。

Your word creates your world. 语言创造了世界。

先不解释了,有兴趣的小伙伴可以当面交流理解这句话。(书面可能表达不是那么清楚)。

在这个过程中,大家对于真相,视角,以及身体里的恐龙(恐惧)展开了激烈的讨论。在争论快要失去平衡的时候,Julia开始带领大家探索未知。

一开始,Julia先问了大家3个问题:

  1. 现在每个人你自己是不是ok的?
  2. 你认为场上几个引导师(一块的伙伴)是不是ok的?
  3. 当下的气氛和环境是不是ok的?

接着Julia介绍了一个okness模型,如下图

Okness模型

模型的三个角分别对应刚才Julia提问的三个问题,即我、他、环境。

首先是我自己当前是不是ok的?即我是否接纳当下的自己?当下如果我不舒服是因为什么,是否有察觉,是否接受?不能接纳自己的情况下,是无法做到欣赏的。

其次是他人当前是不是ok的?我是否可以接纳他人的状态?是否察觉到自己的情绪随着他人在变化,是否可以接纳这种情绪的变化。不能接纳的话,也很难做到欣赏。

最后是当下的环境是不是ok的?对于当下的环境我的觉察是什么,是否可以接纳这个场景,我的情绪是什么。如果无法接纳的话,欣赏也不是那么容易做到。

通过这三个层面我们发现,其实对于如何做到欣赏,有三个重要的步骤:

  1. 觉察
  2. 接纳
  3. 欣赏

上述3个步骤是层层递进。
最重要的是从觉察开始。我有没有觉察到……不论是自己的状态、情绪,他人的语言、情绪,当下的环境和场景等等,我是不是有这个觉察的能力。

那么如何锻炼自己的觉察能力?在座的小伙伴有不错的方法:

  • 练习每日感恩日记
  • 每日冥想

接纳。一旦我们觉察的能力提升,往往容易陷入苦恼的情绪中。因为好像突然之间发现了好多不如意的地方。那么这时候就需要开始接纳。接纳我是一个人,一个普通的人,不论什么情绪都是可以接纳的。甚至痛苦都是一个非常棒的礼物。(来自Hide Enomoto)

欣赏。觉察和接纳后,才有可能做到欣赏。当时大家在讨论的时候,有个伙伴分享她每天也会写感恩日记,可是觉得总找不到可以感恩的内容,练习1个月之后就无奈的停止了。我的个人感觉是她还是没有接纳自己,也可能是觉察还不够。而这个时候感恩日记会倾向于流于表面。

最后总结一下:想要做到欣赏,是一个循序渐进的过程。首先是觉察,其次是接纳,最后才是欣赏。而这里面关键的练习方法(或者工具)是每日练习感恩日记,或每日冥想(或者其他可以独立思考的方法)。

让我们一起来锻炼欣赏的能力吧!

Scrum的本质与看板方法的本质

敏捷宣言以来,随着敏捷软件开发方法的普及,很多企业踏上了敏捷转型的道路。这里宝宝将跟大家一起说一下敏捷当前最流行的两个框架(Scrum和看板方法)——从它们的起源来分析各自的本质。

Scrum

Scrum的起源

Scrum一词来源于英式橄榄球(rugby)中重新开始比赛的争球的术语(是体育术语,不是缩写简写)。详情参考Wikipedia

Scrum之父Ken Schwaber和Jeff Sutherland为什么选择这个词呢?这是因为他们受到一篇1986年哈佛商业评论上的论文影响——《The New New Product Development Game》。论文中开篇提到了:

许多公司意识到仅仅依靠高质量和低成本,已经无法从今天的市场中脱颖而出,它们还需要速度和灵活性。……而传统的顺序式或“接力赛”方法(比如按阶段的产品规划)可能和追求速度和灵活性的目标相冲突。相反,一种全局的或“英式橄榄球(rugby)”(团队通过前后配合传球的方式,作为一个整体单元推进)可能更好的适应了这种目标。

另外,在Scrum指南中也非常强调团队(开发团队),它们具备如下特点:

  • 自组织的,没有人来命令(或告诉)团队如何把产品列表变成潜在可交付的产品增量。
  • 跨职能的,团队作为一个整体,拥有开发产品增量所需的全部技能。
  • 全职的,团队成员100%在团队内工作。
  • 规模较小的,一般5-9人

虽然Scrum指南中还定义了Scrum框架的其他内容,但通过Scrum的起源(那篇论文)和指南中对于团队的描述,我们不难看出Scrum的本质是以团队为核心。

Scrum的本质

Scrum本质是以团队与产品(产品列表Product Backlog,这里就不展开介绍产品列表了)为核心。注意这里指的团队,和我们平时说的团队之间的差异。Scrum中的团队是自组织的、跨职能的特性团队。这样的团队的好处是:

  • 特性(客户需求)在一个团队内完成,去除了移交、等待之类的浪费
  • 团队的业务知识快速增长
  • 团队稳定,从而有助于团队隐性知识的积累

“搭班子、定战略、带队伍” ——柳传志

柳总的管理心法是在做事之前要先有一批志同道合的人,有班子,然后再考虑定战略。这个管理思路和Scrum是一脉的。Scrum的本质也是先打造自组织跨职能的特性团队,然后再遵守Scrum指南的其他规则。

看板方法

看板方法的起源

看板方法的重要来源是Donald G. Reinersten的《The principles of product development flow》。这本书强烈推荐大家读一下。该书中共介绍了175个产品开发的原则,其中不乏一些反常识性的原则,另外还介绍了一些具有实践性的方法:

  • 改善决策的经济性
  • 管理队列(对比一下肯德基和麦当劳的取餐模式,很有趣)
  • 减小批量大小
  • 应用WIP限制
  • 去中心化

看板方法的本质

由上述Don的书中核心理论可以看出,(产品开发流动的原则)他强调的是流动以及价值流动,这个是看板方法的本质。看板方法通过一系列原则促进实现价值的快速流动,比如:

  • 可视化
  • 限制WIP
  • 减小批量
  • 管理度量队列
  • 等等

Scrum和看板方法的对比

上面分析完Scrum的起源、本质和看板方法的起源、本质后,我们不难看出这是两个完全不同的解决问题的方法。

  • Scrum侧重于团队和产品,先有自组织跨职能的特性团队,然后围绕着产品列表进行交付。
  • 看板方法侧重于工作事项,先让价值流动起来。

那么这两种方法孰优孰劣,这个很难衡量。以下仅代表个人观点:
Scrum的特点

  • 打造真正的团队
  • 多数情况下组织结构需要变动(跨职能团队)
  • Scrum转型的切入点是组建团队和梳理产品列表

看板方法的特点

  • 价值快速流动
  • 多数情况下组织结构不需变动(保留当前的现状)
  • 看板方法转型的切入点是梳理工作的价值流

适合场景

Scrum更加适合产品开发,比如一个全新产品或原有系统的增强等。围绕着先组建特性团队、梳理产品,然后每个Sprint产出产品增量。

看板方法更加适合运营型(或运维性)项目。该项目特点是很难提前做出预测。比如我们无法预知明天会出现几个线上故障。

课后思考题

基于以上的Scrum和看板方法本质和特点,你会怎么选择呢?是否可以结合Scrum和看板方法呢?
欢迎回复留言进行探讨。

—广告—
2017年4月16日17日 上海CSM敏捷认证课程 http://yihuode.io/activities/444

如何快速学习一个新知识

一听到学习,很多人就想起来在学校里听老师讲课的场景。这样的学习真的是一个好方法么?还有没有其他更好的学习方法呢?

今天我就要跟大家介绍一个快速学习知识的方法:费曼学习法

费曼学习法的原理

“I learned very early the difference between knowing the name of something and knowing something.” – Richard Feynman
“我很早就学会了知道名字和知道某事之间的区别”——理查德 费曼

学习不是要记住某事,而是需要理解并能将其融入到自己的知识体系中。

怎么样

费曼学习法有五步:

  1. 选择一个新知识
  2. 将这个知识讲给其他人听
  3. 查明这之间的知识差距(比如哪些地方讲不好,讲不清楚)
  4. 使用类比(最好是生活中的例子,尤其是专业知识,可以假设对方没有该领域的背景)
  5. 简化你的讲解(用更精炼的句子)

举例

本文就是一个最好的例子。为了记住费曼学习法则,我自己查找相关资料,并认真记录下来。(记录也是一个讲给其他人听的例子,不过这个是写给其他人看)

回应上面的五步:

  1. 选择一个知识(费曼学习法)
  2. 用博客记录下这个知识(强化学习)
  3. 一边写,一边找出自己哪里还没有搞清楚
  4. 费曼学习法,就像中国的古语“授人以鱼不如授人以渔”。要学会方法。
  5. 费曼学习法,是一个学习的方法。可以用来学习任何新知识。

总结

本文除了介绍费曼学习法,还有另外一个很重要的介绍新知识的三板斧,即Why, What, How。

  • Why – 为什么介绍这个知识,它的原理是什么,有什么作用。
  • What – 这个知识是什么
  • How – 如何应用

多数介绍的时候,是按照What How Why的顺序,也有可能打乱这个顺序,比如先介绍Why, 然后What How。

今天的关键字:费曼学习法;学习知识三板斧;

我们反驳的是什么

开始今天的话题之前,先讲一点题外话。用面向对象的方法和大家介绍一下类的设计。

面向对象类图设计

类图设计

声明:由于手头没有合适的工具,所画的类图并不标准,但表达的意思都在图里了。

简单介绍一下这个类图:如上图所示,一共有两个接口,分别为Animal(动物)和Plant(植物);动物这个接口有3个实现类,分别为Dog,Cat和Tiger,而植物这个接口有2个实现类,分别为Tree和Grass。这里省略了接口和类的内部定义。

假设现在有一个问题是,我们觉得有点热,想要凉快一点。针对这个问题,Dog类可能不会有什么好办法(假设狗真的无法解决这个问题)。不过有人发现Tree可以很好的解决这个问题。

那么我们能否把Tree(树)叫做动物呢?

显然不可以!动物就是动物,植物就是植物。
狗也可能有办法让我们凉快一点,不过确实不如树提供树荫这个方案更好。但这无法改变狗是动物而树是植物,这两个概念!

隐喻

第一节提到的类图,其实是一个比喻。现在我们换一下类图中的几个概念。比如

  • 敏捷替换动物
  • Scrum替换狗
  • 心理学替换植物
  • 催眠替换树

现在假设某个组织内采用Scrum效果甚微(暂且不讨论是如何采用的),而恰巧催眠这种方法较好的激活了个人意愿,从而改变了组织。那么这种情况下,催眠能不能叫做Scrum?或者催眠能不能叫做敏捷?

显然不可以!Scrum就是Scrum,催眠就是催眠!敏捷就是敏捷,心理学就是心理学!这是两个不同的概念。

我们反驳的是什么

上面两节里面讨论的概念,来源于最近敏捷社区里面的热议,从而也给我写这篇文章的灵感。

社区里面热议的焦点,主要集中于敏捷教练不同意“催眠是敏捷”。

那么大家反驳的到底是什么呢?
是敏捷社区不接纳新事物、新想法么?以我这几年在社区的经验,答案是否定的。

大家真正反驳的是什么?
如果我们仔细回看一下就会发现,这里面有一个非常明显的概念混淆,即催眠是敏捷。这是大家不能接受的。

敬畏知识

最后引用一位朋友的话,作为最后一节内容:

敬畏知识。

为什么要敬畏知识

知识是不断创造并积累的。我们需要敬畏知识有两大原因:

  • 尊重概念的提出者(知识的源头)
  • 不会误导他人(传播知识)

很显然,所有的概念都不是完美的,都会有相应的适用场景和改进的空间。那么如果概念有缺陷我该怎么办?我的做法是会找到概念提出者(或者最接近的人)进行讨论,交换彼此的想法。

如果我擅自在原概念上加入其它体系的知识并传播,就是在误导他人。这是作为知识工作者不应该有的态度。

如何敬畏知识

想要做到敬畏知识,有两个小窍门:

  • 引用原概念,然后发表自己的观点
  • 创建新概念,在原概念启发后可以有自己的知识体系

比如敏捷已经有敏捷宣言,那么我不会去修改敏捷宣言。而有可能创建新的宝宝说

对于今天的分享,您有不同观点?欢迎回复留言讨论。

理想与现实

题目的由来

这个题目是怎么来的呢?我在3月24日25日参加Bill的CSPO课程,一开始有一个大家讨论的问题是,“你认为产品成功的条件有哪些?(或项目)”

大家讨论的结果并不重要,重要的是在这个过程中大家开始讨论产品与项目的联系和区别。

以前我的理解是产品是长期存在的,而项目是(一个或多个)产品的一部分,即阶段性成果。

课程当中还有一段乔布斯早年的访谈视频片段(遗失的访谈)。其中讲的是乔布斯解释想法与产品实现之间的鸿沟,以及团队是如何一起协作的。

这段视频中给我一个启发,那就是“产品是理想的而项目是现实的”。即我们今天要讨论的标题“理想与现实”。

现状

德国人有一句名言是

生活是具体的。

这反应出在我们的生活中,多数事情是具体存在,即现实的。

而什么是理想呢?
记得小学的时候老师总是会问,“你长大后的理想是什么?” 还记得很清楚,我的理想是当一名老师。虽然现在已经距离理想很遥远,但理想就是一个目标在前方指引着我。

因此

  • 理想是遥远而触不可及的、长期目标;
  • 现实是具体存在的、短期利益;

而我们的生活就是在理想和现实之间不断的进行取舍。最终就如图1所示,停留在理想和现实之间的某个地方。

图1 生活工作的现状

理想

既然我们认为理想是遥远而触不可及的、长期目标,那么如果我们一直盯着理想而完全忽视现实的话。如图2所示:

图2 只看理想而忽视现实

会有什么问题呢?
常见的完美主义者,就属于这个状态。完美主义者并不是不好,而是陷入其中的话,会忽略现实,而错过了市场机会。

现实

现实是具体存在的、短期利益。如图3所示:

图3 注重现实而忽视理想

常见的现实主义者,属于这个状态。现实主义者的问题往往是忽视了我们应该打造完美的产品。

理想与现实

回到主题,我们来看一下在软件开发当中,理想与现实是如何结合的。

传统的瀑布式软件开发

在传统瀑布式软件开发中,认为软件开发就像在流水线生产一样(属于简单工作)。把软件开发当做理想来实现,所以到最后结果往往并不能让客户满意。(理想是丰满的,而现实是骨感的)

Scrum软件开发

在Scrum敏捷软件开发框架中,非常好的平衡了理想与现实。产品(以及产品待办列表)代表了软件开发中的理想,这是团队的美好目标。而每个Sprint结束后潜在可交付的产品增量代表了现实,这是团队的现实情况。

就如图1所示,Scrum是完美地结合了理想与现实。既有理想的产品目标,又有现实的产出。

Scrum转型

Scrum框架本身也是完美的框架。在组织转型的过程中,作为敏捷教练要坚持Scrum框架(以及敏捷的价值观),不能妥协。作为现实的工作,在某些地方或多或少会有一些妥协,但是请谨记,此时的妥协只是临时方案。

最后,送给大家一句话。

Done is better than perfect.

让我们动手尝试一下吧。

Scrum的定义

Scrum 的定义

Scrum: Scrum 是一个框架,在这个框架中人们可以解决复杂的适应性问题,同时也能高效并有创造性地交付尽可能高价值的产品。
Scrum 是:

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

自上世纪 90 年代初期以来,Scrum 就已经应用于管理复杂产品的开发。Scrum 不是开发产品的一种流程或一项技术,而是一个框架,在这个框架里可以应用各种流程和技术。 Scrum能使产品管理和开发实践的相对功效(relative efficacy)显现出来,以便进行改进。

Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的,对Scrum的成功实施和运用都至关重要。

Scrum 的规则把事件、角色和工件组织在一起,管理着它们之间的关系和交互。Scrum 的规则会贯穿这份文档。

上面是摘自《Scrum指南》中文版的介绍,即Scrum的官方定义。这里面几个点需要格外强调:

Scrum是一个框架

Scrum是一个框架,而不是一个流程,也不是一个方法,更不是一项技术。这里面有什么不同呢?框架指的是这些内容组成一个整体,不可裁剪或修改。一旦裁剪或修改,框架就不稳固,容易出问题。

我们可以看看采用Scrum的组织中,出问题的大多数情况是在我们这里需要裁剪一下Scrum而造成的。比如每日站会太浪费时间,能否一周开两次。团队看起来没什么需要改进的,回顾会是否可以取消?等等

如果把Scrum裁剪了,请不要说在采用Scrum。

解决复杂的适应性问题

Scrum最适合解决复杂问题,比如软件开发这类复杂问题。另外还有适应性问题,即强调灵活性,需要团队可以快速响应变化。这是敏捷的本质,可以参考之前的博文“为什么敏捷是Agile,而不是Cgile或其他词”。

更多的解读,大家可以参加CSM敏捷认证培训了解详情。

参考材料:Scrum指南

为什么敏捷是Agile,而不是Cgile或其他词

很多人都知道敏捷,即Agile,也知道这个词是来自2001年的敏捷宣言。但你们知道为什么是Agile,而不是Cgile或其他的词吗?

我们来看看Craig Larman是怎么说的。(敏捷宣言是17个轻量型软件业的先锋于2001年共同签署完成的。Craig Larman当年也被邀请参加,但由于种种原因未能出席)

你看到“敏捷”这个词,或者你的组织进行敏捷转型,你首先想到的是什么?
你想到的是提高效率、生产率、降低成本和提高质量、提高可预测性、或完成项目计划吗?
如果你想到的是上述内容,对不起,你想的不是敏捷。(那一定是假敏捷)
敏捷(Agile)这个词最初的含义就一个,是
Flexibility 灵活性

更多有关敏捷不是快的信息,可以参考我的博文“敏捷不是快”

当年大家是怎么选择敏捷(Agile)这个词呢?据称当时有两个提议:

  1. Adaptive 来自Jim Highsmith的提议,和
  2. Agile 来自Mike Beedle的提议

为什么Agile会胜出呢?这里我们可以八卦一下。(原因是Adaptive Software Development已经由Jim H采用,如果大家都同意Adaptive,那么Jim就会抢占市场先机。所以……)

Agile一词虽然由Mike提出,但他自己在这之前并没有采用并推广。据Mike自己说他是从一篇1992年的(名为“21世纪制造业企业策略”)文章中受到启发的。

I was at IBM when the formation of the Agile Consortium occurred – IBM was part of that consortium, so I had a copy of the 21st Century Manufacturing Enterprise Strategy, which was published in 1992, and already used the word “agile” to describe development and manufacturing.
— From Mike Beedle

所以敏捷最早的启发是来自于制造业。有兴趣的小伙伴可以下载回去自学哈。

参考资料:Craig Larman介绍敏捷来源

《在TOYOTA学到的只要纸1张的整理技术》读书笔记

《在TOYOTA学到的只要纸1张的整理技术》
作者:浅田卓

本书的核心

一句话,用一张纸整理思路。

适合场景

  • 工作清单
  • 会议(培训)记录
  • 市场分析
  • 新商品策划

一张纸文件的共通点

  • 目的
  • 现状
  • 课题
  • 对策
  • 日程

如何用一张纸进行整理

  1. 第一步,将思考用的基础信息整理到文件内
  2. 第二步,将自己独有的思绪、归纳到文件内
  3. 第三步,文件的内容要传达、沟通的对象

讲概念的三板斧

  • Why,这个概念的目的是什么,有什么好处
  • What,这个概念是什么,听众想听什么
  • How,这个概念如何用到我的工作或生活中

举例子

如何用一张纸进行自我介绍

  1. 在一张A4纸上画出8个(或者16个)格子
  2. 在左上角的格子内写上自己的名字
  3. 30秒内迅速填满剩余格子(填写内容为你想到自己特点的关键词,即你想要介绍的方面。只写关键词即可)
  4. 格子之间找关联,相同类型的标识一下
  5. 排序,介绍的时候先说哪个部分,再说哪个内容

下图是工作坊中大家介绍的例子,大家自我介绍完后都觉得这样进行介绍太轻松了。

用一张纸进行自我介绍的示例图

为什么一张纸这么有效

最后这里我自己总结了一下为什么一张纸这种方式有效。因为这种方式它有效地帮助我们进行了思考的分类。
比如上述的例子主要分为三大步骤:

  • 收集整理数据。这个步骤做的事情是发散,头脑风暴。目的是记录脑子里出现的所有和目的或主题相关的词。
  • 思考、归纳、找出联系。这步做的是思考。在上一步的基础上,审视已有的关键词,找出它们的联系,进行深度思考。
  • 做出决策。最后基于上面的思考,进行最后的决策。

有关于决策,也叫作选择,是一个很大的话题。下一次我想专门来聊一下选择这个事情。

下一个话题你期待吗?

敏捷回顾最高指导原则–敏捷回顾工具箱

Norman Kerth 在《Project Retrospectives》一书中曾提到回顾会议的primary directive principles:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

如何理解回顾会议最高指导原则

这句话至少有三层深意:

  • 信任
  • 对事不对人
  • 发展的眼光

信任

人与人之间很重要的一层关系是信任。唯有信任,团队才是真正的团队;唯有信任,人与人之间的协作才能顺畅。在回顾会议中,第一个要传递的信息就是信任。管理者对于团队是信任的,相信团队每个成员都已全力以赴。团队成员之间也是互相信任的。我们在现有已知情况、个人的技术水平和能力、可用的资源下已经做到最好。

对事不对人

回顾会议的目的是帮助团队提高与改进工作的流程。在这个过程中,团队必然会碰到发生过的问题。那么针对每个问题,必须明确的一个原则是对事不对人。我们现在讨论这个问题,目的是能从这个问题洞察到更深层的原因以避免之后发生同样的问题。而不是为了羞辱一个人。作为引导师,需要密切关注会议中的氛围。一旦发生针对个人的行为,引导师需要立刻采取行动。根据行为的严重程度采取的应对方式不同,细节可以参考引导方面的书籍。

发展的眼光

指导原则中提到“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况……”,这段话说明即使现在发现了问题,部分是由于个人技术水平和能力有限,那么给我们一个很好的启示是,团队现在某个方面技术水平和能力需要提高,即团队(或个人)总是有提高发展的空间。

如何使用回顾会议最高指导原则

我最常使用这个原则的方法是:每次回顾会议开始的时候,团队全体成员集体朗读一遍。确信大家都理解之后才进行下一个环节。

—————————————————————
最后广告时间 — Scrum联盟的CSM敏捷认证课程
2017年4月16日-17日 上海
2017年4月24日-25日 深圳
2017年5月25日-26日 北京

什么是CSM