敏捷不是形容词!

阅读《技术人创业攻略》一书中,作者对Dave Thomas的访谈有如下一段话:

真相是,“敏捷并不存在”。它不是一种东西,不是一个名词。人们是把它当做一个名词开始用起来的,但是他们并不理解背后的含义。

“敏捷”不是一种东西,敏捷是一个形容词——它描述了一种东西。你可能有一个敏捷的团队或者一种敏捷的过程,但你却从来不是“敏捷”。

对于Dave的这个定义我并不认同。

首先敏捷是一个名词。作为名词的敏捷,它不是一个状态,而是一个完美目标。

敏捷不是一个状态,不是一个状态,不是一个状态!有不少公司在敏捷转型的时候认为,只要我们做到xyz,我们就是敏捷了!对不起,你们并没有敏捷,你们只是达到了一个新的状态。

而敏捷是一个完美目标。何为完美目标?完美目标,是一个永远无法达到的目标。是的,敏捷就是一个永远无法达到的目标。

敏捷是一个持续学习的过程。持续学习也是没有终点的,是一路上不断地持续地学习。因此前几天微信群有朋友问,有没有敏捷成熟度模型?我内心想说的是,不要用模型限制束缚了持续学习。

其次敏捷是一个动词。作为动词,敏捷的含义让我们感觉是快。这里往往有误解,认为敏捷就是效率高、速度快!

敏捷不是速度快!!!请参考我之前的博文《敏捷不是快

另外我对敏捷的定义是“一个持续学习的过程”。在这个定义中,也没有任何一个字眼说敏捷就是速度快、效率高!


最后广告时间 — CSM敏捷认证课程

2017年4月16日-17日 上海

2017年4月24日-25日 深圳

2017年5月25日-26日 北京

Learning from Boston SA F2F sprint2 (EN)

Keywords: “double loop learning”, “retrospective”, “Scrum”
  • What inspires me to think about double loop learning
  • Scrum is double loop learning (1977 HBR)

1. Before going to Boston, I read a wonderful article from HBR (https://hbr.org/1977/09/double-loop-learning-in-organizations), which illustrates learning in organizations, aka named double loop learning.

To explain it in a short sentence, e.g during our discussion (Boston SA F2F sprint2), we came up an item from product backlog, which is about ensuring core Scrum accurate in SA web content. From my understanding, facing such problem, I would prepare a list of current problem/mistakes in SA web content, and then order them, and fix them.

But before we discussing, Jim York (please correct me if I am wrong), ask a question, “how do we ensure SA won’t make similar mistakes?” That’s a great question, which makes all think about the process of solving problem. And I am shocked by this question. I have never think about question like that. (Is it the different thinking model between Chinese and American? Or maybe in specific, just difference between Jim and me?)

At that time, suddenly I recall the double loop learning, isn’t it some kind of double loop learning? More details, thinking as me, just try the problem solving solution, which is single loop learning. It results that I only can fix the problem. Thinking as Jim, considering problem-solving process first, and then try to fix the problem, which is double loop learning. Fixing problem is the first loop, and fixing the process is the second loop. Thank Jim very much!
I won’t miss this key learning from Boston!

2. Scrum is also double loop learning. Exam Scrum deeply, there are 2 inspect and adapt events by the end of the sprint, which are Sprint Review and Sprint Retrospective. Let’s say Sprint Review is the first loop learning, which is inspect and adapt the product team just develiered. And Sprint Retrospective is the second loop learning, which is inspect and adapt the ways of working in the team.

So every sprint, the team not only learns knowledge from the product they delivered, also learns how they works together.

And I am not sure whether Jeff Sutherland also learned from this model. (Note: double loop learning model is from Chris Argyris, article published in 1977 in Harvard Business Review)

2017.3.6
BoB Jiang@Boston

敏捷软件开发绩效管理系列之度量指标列举

上一篇文章中,我提到以下几点:

  • 绩效管理(度量)的主要目的
  • 度量指标的分类

在这篇文章中,将会展开描述度量指标,详述在软件开发中都有哪些度量指标。

注意:这只是一个度量指标清单,不要照本宣科全部采用(会累死的)。一般建议对于一个组织(或者团队)选用7个以内的指标就足够了。

为了评估公司对产品交付的支持

  • 客户净推荐值(NPV)——推荐产品的客户数/客户样本数
  • 系统稳定性——比如通讯系统的99.99999%

预测进度

  • 燃尽图(故事点或工作小时数)
  • 团队速率(每个迭代交付的故事点数)

提高质量,减少技术债务

  • 生产系统的缺陷数量——发生在客户一侧、生产系统上的缺陷数量(很重要的统计数据)
  • 内部测试发现的缺陷数量(或者说迭代内缺陷)
  • 单元测试的代码覆盖率
  • 违规代码数量(Sonar等静态代码检查)

评估过程的有效性和改进

  • 迭代是否完成目标
  • 是否有回顾会议(反思改进)
  • 需求的周期时间(cycle time)
  • 价值流图

商业效率

  • 产品的整体周期时间
  • 达到收支平衡的时间点(tipping point)
  • 获利的时间
  • 投资回报率(ROI)
  • 现金流(组织内的任何需求都可以折现成$$)
  • 收入增长

评估用户(c端)

  • 每日新用户数
  • 每日留存用户数
  • 每日付费用户转化率
  • 每日净推荐值

企业文化指标

  • 容忍失败,并从中学习
  • 创新意愿
  • 特性团队的比例

下一篇,我将列举一个现实中的团队绩效评估例子,并进行解读。

以下为广告。近期BoB的CSM敏捷认证课程安排如下:

2017年3月16日17日 成都 http://yihuode.io/activities/404

2017年3月23日24日 北京 http://yihuode.io/activities/419

2017年4月16日17日 上海 http://yihuode.io/activities/444

2017年4月24日25日 深圳 http://yihuode.io/activities/436

 

Certified ScrumMaster (CSM中文认证课) – 成都 3.16-3.17

最近的课程:

2017年3月23日24日 北京 http://yihuode.io/activities/419

2017年4月16日17日 上海 http://yihuode.io/activities/444

2017年4月24日25日 深圳 http://yihuode.io/activities/436

价格:早鸟价:6300元(早鸟已满);三人同行每人可享6000元;普通7000元

说明:京东员工、敏捷社区志愿者有特别折扣,详情联系讲师(邮件或微信)

课程简介

从2001年提出敏捷宣言至今已有十余年,敏捷不仅仅在国外发展势头很强劲,在中国也有越来越多的企业开始敏捷转型。一开始是外企把敏捷带入中国,目前国有企业、民营企业、私营企业以及初创企业都在或多或少的应用敏捷实践。越来越多的企业和公司认识到敏捷转型的重要性。敏捷不仅仅是一些方法或实践,更是一种心态的变化,也是一个新的旅程。

在本次课程中,学员不仅从实际操作的层面上掌握Scrum的运用技巧,学员还将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单,但要掌握其精髓却并非容易,讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架,通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏,和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。

课程特色

  • 来自于大型外资企业和互联网行业的一线敏捷实践
  • 内容全面深入,重在实践操作与应用,囊括了大量项目经验
  • 通过游戏化的方式,让学员在课后可以立即启动自己的Scrum

学习目标

  • 帮助学员学习理解Scrum的原则、方法、与实践经验
  • 提升学员对Scrum,以及敏捷最新实践的理解
  • 通过游戏化的方式,学会如何在组织内进行Scrum转型

主要收益

  • Certified ScrumMaster证书
  • Scrum联盟两年会员资格
  • Scrum实战培训手册1本
  • 对Scrum转型有帮助的、有启发性的1G+视频
  • 团队敏捷备忘录1份
  • PMI上可以申请的16PDU

适合人群

  • 作为一名Scrum初学者,我可以系统地学习Scrum,了解Scrum背后的原理以及相关知识,以便为组织的Scrum转型打下基础。
  • 作为一名管理者,我可以了解Scrum框架的工作方式,还可以从Bob那里学习组织转型的经验,以便引导我的组织开展Scrum转型,收获更大的价值。
  • 作为一名传统项目经理,我可以看到Scrum是如何工作并生效的,以便更好得把Scrum应用到项目中。

课程大纲

  • 模块1:敏捷与Scrum概述
  • 模块2:Scrum角色
  • 模块3:Scrum工件之产品列表及条目
  • 模块4:敏捷估算与规划
  • 模块5:Scrum会议

模块1:敏捷与Scrum概述

敏捷软件开发逐步地深入人心,但在敏捷转型的企业中,只有很少一部分可以做到持续不断地交付商业价值,使客户满意。相当数量的企业敏捷转型后,效果并不理想,然而问题在哪儿呢?本次工作坊将会从“道、法、术”的层面来解读敏捷,学员将不仅仅知道什么是敏捷,还会了解为什么需要敏捷,敏捷的核心是什么,敏捷会给企业带来什么好处。

Scrum作为敏捷软件开发的一种框架,很简单,但实现起来并不容易。本模块将会分析Scrum价值观,Scrum的基础以及Scrum的概述。


模块2:Scrum角色

Scrum中包含3个角色:ScrumMaster,产品负责人和开发团队。为什么是这3个角色,为什么没有项目经理,一线经理负责什么。这些问题将会在本模块进行解读。


2.1 开发团队

Scrum中的开发团队是自组织的、跨职能的团队,是小的团队,是蜂拥式的工作方式。如何组建这样的开发团队,如何能够激发开发团队的自主性,这个子模块会重点探讨开发团队相关的问题。

2.2 ScrumMaster

ScrumMaster是一个全新的角色,他不是项目经理。在Scrum团队中ScrumMaster常常看起来很“闲”,没什么事情做。这是一种错觉,也是一种误解。ScrumMaster可以作为教练,辅导团队Scrum转型;ScrumMaster也可以作为牧羊犬,保护团队不受外界干扰,可以在Sprint内专注于完成Sprint目标;ScrumMaster还可以作为引导师,使团队的会议变得更聚焦、更简单;ScrumMaster还是变革大师,不仅帮助自己团队Scrum转型,还要帮助组织进行转型。


2.3 产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。在Scrum中,通过什么工具,以什么方式,产品负责人可以完成上述的工作,以及产品负责人的职责是什么,将会在这个子模块进行探讨。

模块3:Scrum工件之产品列表和条目

产品列表是团队工作的输入,是至关重要的一环。好的产品列表是ODDE的。如何创建一个好的产品列表,如何拆分产品列表中的条目,都有哪些内容可以放在产品列表中,产品列表的一些常见臭味。以上这些话题将在这个模块中进行深入的探讨。


模块4:敏捷估算与规划

敏捷中的估算怎么做,需要细化到什么程度。敏捷宣言中提到“响应变化 高于 遵循计划”,那么在敏捷中是否还需要计划。敏捷中的规划都有哪些,分别是什么用处,在什么阶段使用。本模块主要讨论这样的一些主题。

模块5:Scrum会议

Scrum会议包含:Sprint计划会、每日站会、Sprint评审会、Sprint回顾会以及产品列表梳理会。正是这5个会议支撑起Scrum框架,把Scrum团队的日程工作串在一起。为什么有这5个会议,什么时间开这些会议,都有谁参加会议,开多久,如何开,这个模块会采用一种不同的方式,大家共创出这些答案。

学员评价

课堂风采

其他问题

可以给讲师写邮件(bobjiang@bobjiang.com
或者加微信

付款信息

建设银行光华支行 6214660010030344 姜信宝
对公付款请加我微信单独联系

什么是CSM(Certified ScrumMaster)

请点击参考链接

讲师简介

姜信宝 Bob Jiang

中国北方第一位CST(Certified Scrum Trainer)

国内知名电商资深敏捷教练、金牌讲师

Certified LeSS Practitioner,《Scrum精髓》译者

15年以上的软件开发和项目管理经验,多年不同行业的敏捷转型培训与辅导的经验(传统通讯行业、电商行业、保险行业、银行等)。曾经服务过的客户有GE医疗、HP、诺基亚、爱立信、中国移动研究院、京东、海尔、徽商银行、花旗银行等

中国敏捷社区的守望者,从2011年起组织参与了敏捷之旅、ScrumGathering、敏捷中国、MSUP等大会

敏捷一千零一夜Agile1001(http://agile1001.org)的联合发起人

博客 http://bobjiang.com 

Scrum点滴–敏捷之旅2016北京后记

作者:安宝平 微信ID: abp0616

Scrum 点滴

一直想把自己使用和学习Scrum的一点心得体会写出来,因为各种原因一直没有动手,(主要原因是懒)。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期,再不动手就说不过去了。

在现在项目中折腾了将近4年,经历了很多很多,也和其他公司一些人讨论过Scrum,在此期间自己产生过很多疑问,也了解到别人的一些疑问,发现曾经搞清楚的问题有了答案没有记录下来,过了阵子完全忘记了,或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水,这是件恐怖的事

。趁着还没大幅缩水的时候做个文字版的记录吧。(如下内容是“现在”这个时刻的记录,半年之后会变化很多,至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着,等研究半年后再做个记录。)

先定几个基调,嘿嘿:)

  • 工程师如果知道这么写代码会出bug他肯定不会这么写,基本没哪个工程师故意写出有bug的代码。
  • 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug,不是说开发工程师比其他行业的工作人员更容易犯错,而是由工作本身决定。(一个职员写一封英文邮件,有点拼写错误一般不会出现问题)。
  • 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放,很有可能是在舍本逐末\缘木求鱼。
  • 关于工程师文化:大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧,这有点不客观。脱离客观一般会出问题。
  • Scrum反对教条主义,同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。”

想不出来以什么形式记录这些内容,就用了模拟问答的形式,自己感觉良好。哈哈。

Q(1): 我对于 “敏捷”粗浅的理解?

A:

a) 对于比较庞大的需求,相对于瀑布模式,在敏捷中每个迭代都交付庞大功能的小部分功能,而不是等到所有功能都开发完成之后再交付,这种更早、更快的持续交付就是敏捷,是交付层面的敏捷。

b) 为了保证每个迭代所交付的产出具有该有的质量,要对本迭代和之前迭代的所有交付做充分的测试,这些测试要在短时间内完成,人工测试难以完成,所以施行自动化测试(含单元测试、集成测试和页面交互的自动化测试)辅以人工测试。自动化测试速度比人工测试快,这是QC层面的敏捷。

引用某大咖的话“敏捷是一种心态:一种拥抱变化,拥抱学习的心态,敢于尝试,强调实战,快速反馈,适应环境和市场的变化。需要每个成员的紧密合作,需要积极融洽的团队氛围。”

Q(2):Scrum是什么?

A: 在我看来Scrum讲的是工作流程,职责分工,如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。

Scrum的流程是框架,文化理念才是核心。

Q(3): 为什么要实行敏捷(Scrum)和实行时要注意什么?

A: 每个公司(团队)情况不一样,这个要看出发点或者目的是什么。就怕没有太清晰的目标,同时对于敏捷(Scrum)不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队:稍微问一下就会发现,其实是挂着Scrum的“羊头”卖着自己的“狗肉”,各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。

想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式,再找个Scrum专家(比如我,哈哈~)交流下,自己对Scrum做个深入了解,看看自己能否接受Scrum及Scrum是否适合自己。

Q(4): Scrum Master工作的意义(产出),如何衡量?看起来Scrum Master没有做看得见的工作,凭什么要给你开薪水?

A: 这个么。。要是开发团队没有什么问题, Scrum Master确实没太大的意义,我也这么认为。但…是……,如果开发团队有很多问题,比如产出bug量很多,每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内,整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯,这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变,更是精神面貌的改变。”

Q(5): 实行Scrum不需要对远期的需求做讨论(规划),只把当前几个迭代的需求讨论清楚就可以了?

A: 这个是对Scrum的误解!Scrum说的是不对远期需求做过细的讨论,但不是不讨论。比如:

l 开发的是一个全新的大项目:在开始第一个迭代之前还是要做高层次的开发规划,比如项目有12个功能模块,要在1年之内完成开发,此时要做一个年度的planning meeting。先把12个模块的流程图做出来,有了逻辑关系就有了开发顺序,再评估每个模块需要的人力。对比现有人员,就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。

l 在已有项目上做新功能开发:在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。

个人认为应该加入到Scrum Master培训中的内容:对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。

Scrum强调对于远期的需求不做详细的分析,只对近期要开发的内容做具体的定义,需求的细化是渐进明细的。这里要注意,低层次的、细枝末节的需求可以渐进明细,但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样,在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做,还要做季度和年度的planning meeting,要注意的是,这个年度的planning meeting比迭代中的planning meeting粒度要大的多,绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词,那就是“必须”、“不遗余力”,否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性,耦合性,系统性能等等这些方面做充分的考虑,等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。

Q(6): 实行Scrum之后不需要写文档了?

A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通,避免撰写详细规格说明书,但不等于完全不写任何文档。有些文档仍然要写,并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能,要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design(功能设计文档),所写的functional design由product owner审阅,审阅通过说明工程师对于功能需求理解到位,detail design审阅通过说明工程师在技术实现上基本没有偏差,再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug,很大的原因在于上述QA工作。(不是说自动化测试不需要,不是我们不想做自动化测试,这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。)

Q(7): 我们的项目只能用瀑布模型不能用敏捷,因为做不到每个迭代交付。

A: 这个也是对Scrum的误解。在Scrum中每个Sprint的产出的名字为“潜在可交付产品增量”,这里有个词“潜在”,意思是说,如果需要可以发布到生产环境,不是说每个迭代必须发布到生产环境,是否发布视发布需求而定。这里有两个概念,一个是迭代周期,一个是发布周期,一个发布周期可能包含一个迭代周期,也可能包含多个迭代周期。甚至在一个迭代之内发布多次—刚上线的系统如果问题多多阻断业务流程,哪敢再等到迭代结束时再发布更新。

Q(8): Planning Meeting 如何评估工作量?

A: 开发工程师和tech lead一起对一个product backlog“打牌”:每人手上一副扑克牌,打牌时每个人仅按自己的能力和对需求的理解给出自己估计的工作量,牌面向下交给Scrum Master(或者其他人),Scrum Master取大家所给点数的平均值作为该product backlog的开发时间。此过程牌面全程向下,全过程牌面都向下,永远向下。否则匿名评估本身会收到影响。

此时会有几种情况,如果大家给的点数差不多,直接取均值就可以了。如果点数相差很大,需要有人自愿或者指派一个人讲下对该PB功能和技术层面的理解,再进行第2轮评估。-之所以会有比较大的点数差别是因为每个人对于功能、技术层面的理解不一致,此时某个人再次讲一遍是统一大家认识的过程,认识统一之后打牌的点数就比较接近了。有的时候对于比较大的product backlog经过3轮评估的点数还是差异比较大,此时需要对Product backlog的内容做进一步的拆分(一般不需要拆分Product backlog本身),对拆分后的内容再依次评估工作量,此时会知道大家对具体哪项细节理解不一致,再针对该细节做深入讨论。

Q(9): Planning meeting会随着迭代的进行越来越短?

A: 有这个可能,但有的时候甚至多数情况下不是这样的。虽说在Scrum中planning meeting的时长是按一周开发对应一小时planning meeting折算出来的,但也不能完全照搬。比如我们项目组,开发的是公司自己的信息管理系统,这个meeting时长时短,长的planning meeting中仅仅把一个复杂需求讲清楚就需要一个多小时。

Q(10): Scrum中按大家意愿领取工作,如果大家都想领取某个Product Backlog怎么办?

A: 这个好办。拿出一副点数不重复的扑克牌让大家抽取。点数大(小)者领取。

如果大家都不想领取呢?

方法同上。 :)

上面所述的第二种情况,如果某工程师按“天意”领取的工作是很核心很复杂的工作,但是该工程师明显没有能力完成,这个迭代结束后又必须发布,真这么安排工作的话这个迭代势必要以失败收场,还要这么安排工作么?

那就把这个product backlog调换给合适的人好了,完全按个人意愿领取到的内容进行工作安排,那就太教条主义了。在我们这里个人意愿是高级原则,但有时视情况这个原则会被打破。

Q(11): 实行敏捷对工程师的要求很高?

A: 这个要看具体情况和要求。比如开发团队原来都是初级工程师,不具有实现自动化测试的能力但是要求实现自动化测试,就算不实行敏捷,对于工程师来说要求也是高的。反过来,一个具有较高技术水平及能力的开发团队,所开发项目只需要大家拿出七成的技术水平就可以实现,此时就算实行敏捷大家也觉得要求一点都不高。

Q(12): Sprint采用多长的时间比较合适,越短越好吗?

A: 要看具体情况而定。我们组用过一、二、三周时长的Sprint,最后定在了一周时长上;另一个组一直采用三周时长。具体原因各组情况不同,就不细说了。我们也试用过各种时长的发布周期。最终用户选定一周一个开发迭代,二到四周发布一次。因为这样对于用户来说,一些紧急的开发需求可以尽快的安排到迭代内进行开发,同时不需要频繁的做UAT测试。其实对于我们开发组来说更喜欢一周一个迭代,结束后就发布。因为相对于长周期而言,绝大部分工作都是轻量级的,很容易搞定。如果是两三个月发布一次自己都觉得吃不消。至少整理发布内容的时候对着几十条甚至上百条product backlog只觉得头昏眼也花。

个人建议使用2周时长的Sprint,如果使用1周时长的Sprint,可能会因为时间较短难以产出可用功能,特别是对于做单元测试、集成测试的团队;如果使用3周时长的Sprint,很容易出现的一个问题是,在第3周的时候大家基本上会忘记第一周planning meeting上product owner口述部分的内容,仅能凭着product backlog上的文字理解需求,如果想搞清楚需求还要product owner再讲一遍。–这也是我们不用三周时长Sprint的一个原因。

Q(13): Scrum开始结束时间如何定,Sprint之内包含假期怎么办?

A: 先说Sprint之内包含假期的情况,此时Sprint的开始结束时间和之前保持一致不变,只是实际的工作日少了几天。Sprint时长指的是calendar day不是work day。

关于开始结束时间,建议开始时间定在周三,结束时间定在周二,这样可以有效避免周一、五综合症。这么安排反过来也要求迭代的产出要有较高的质量,没有周末做缓冲的情况下,如果迭代交付有问题周二就是大家的加班日,周三就是大家的nightmare。哈哈。

Q(14): 关于Daily Scrum(每日站会):除了书本中的3句话,建议加上是否按进度完成工作。一定要重视Daily Scrum的质量,每日站会是构成Sprint成功这个大步伐的基础小步伐。

Q(15): 关于Retrospective Meeting(回顾会议): 除了书本上讲的内容还有的意义:这个会议本身有team building的作用;这个会议是工程师平时工作过程中积累的情绪(情感)的一个宣泄口。毕竟对于工程师来说,大多数情况,平时的工作就是对着电脑敲键盘,比较缺乏与人面对面的沟通。

Q(16): 关于Code Review(代码评审):非常、极其重要!就算项目组再没时间也要做。引用某大咖的话“没有时间做code review,肯定有时间fix bug。”最好采用团队共同review的形式进行,对做的好的和不好的都review,不要仅对不好的部分进行review。

Q(17): 关于开发完成的标准:没有比这个更重要的了。如果一件事需要开发工程师做,那就把这件事算做开发完成的标准之一。比如对于边界值、特殊情况的考虑,如果不要求开发工程师考虑处理,等测试工程师发现边界值有问题再返工修改,对于项目组整体而言就存在返工、资源浪费的情况。并且,在这样的开发完成标准之下肯定会出现非边界值、非特殊情况之下也有问题的状况。–取乎其中得乎其下。现在TDD、BDD(测试驱动开发、行为驱动开发)之所以流行,在我看来就是从需求、设计、开发、测试各个环节对用户的需求进行深入的挖掘。用户在业务上有十个场景,如果开发出来的系统能够全部涵盖,这个系统肯定是一个成功的系统,如果只涵盖了七八个,用户感受一般是:系统在多数情况下没问题,到了关键时刻就掉链子。

我们这里对于开发完成的标准:开发工程师开发完成之后不需要在已经完成的工作上做任何进一步的开发,除非需求有变更。

对于测试的标准:所有问题都要提出,只要有认定不合理的理由做支撑。项目组可能因为一些原因不修复或者推迟修复一些bug,但是不允许测试工程师在认为是问题的情况下不提bug。即,对于bug,可以不修,但是不能不提。

Q(18): 关于迭代的工作量:不要把迭代之内的工作排满,留一定时间做buffer。很多团队虽然用Scrum,还是会被管理层要求完成要求的工作量。人做软件开发不等于机器生产。在软件开发过程中会出现各种意料之外的状况,如果把时间都排满,只能说要么不了解软件开发这个工作要么就是自己跟自己或者团队过不去。

Q:(19): 关于收集需求:在《用户故事与敏捷方法》中说了很多,我个人的一个经验是:Product Owner还要代用户使用所开发出来的系统,并且要选择在业务高峰期,因为一般的用户掌握的电脑知识有限,对于软件开发等工作完全没有任何概念。这样的情况下是不能强求用户提出开发需求的。相对于用户来说Product Owner在重度使用系统时会更容易想到做哪些开发可以改进系统。

Q(20): 关于用户需求:避免把“解决方案”当做用户的“需求本身”来处理。意思是,有的时候用户提出的需求并不是需求本身,而是用户需求的一个解决方案,用户自己也没有意识到。如果没有发现这个状况,开发出来的功能有可能还是不能满足用户的真正需求。

Q(21): 关于沟通:按PMI的要求,沟通是否到位的责任由信息发出者负责。所以当发现别人没有按照要求做事时先反思下是不是沟通没有做好。很多做项目管理不久的管理人员经常对工程师的工作不满意,自己生气,工程师也觉得不爽,此时管理人员要先问自己如下几个问题:以工程师的能力和经验他会想到那些在自己看来不应该出现的问题吗?一些事后看起来的问题在事前有跟大家沟通清楚吗?大家在事前对于工作要求的理解和自己一致吗?对于工作要求,做到全员都理解到位了吗?等等。

Q(22): 关于工具的重要性:工具对于人类的意义大家都知道;从北京到上海选择不同的交通工具在时间耗用上差别多么大也很容易计算出。花些时间研究引进哪些硬件、软件提高工作效率是非常值得的。

Q(23): Scrum团队的“自组织”是什么意思?

A: 过去,需要一位经理来设定目标和实现方法,然后团队按照他的计划工作。但是,这样所有人的能力都会受到经理自身的经验、见识和智慧的限制。如果团队成员可以自由决定应该做什么,他们就能够根据实际情况进行调整。他们可以分享各自的想法和技能,共同找出最好的解决方案。他们可以先尝试一种方案,如果不可行,在尝试别的方案。这就是我们所说的“自组织”。这种在团队中集思广益而不仅仅依赖于经理个人想法的管理方式,能让团队的所有成员尽其所能。-选自《30天软件开发 告别瀑布拥抱敏捷》

Q(24): Scrum Master如何管理、领导团队?

A: 建议不要把自己定义为管理者,因为管理和被管理天然就是矛盾的。把自己定义为管理者,团队为被管理者,其实就把双方放在了对立的矛和盾上。结果很可能是举步维艰寸步难行。作为管理层也要意识到,自己要对上负责,对下也要负责,不能一味对上负责,对下只有工作甚至是压榨。管理层的作用是承上启下,承接上层的压力,开启下层的进步。

以下内容选自《30天软件开发 告别瀑布拥抱敏捷》和德鲁克学院的文章:

管理层的任务是引导而不是指挥。他们的职责从督促员工按照计划行事变成了竭尽全力帮助他们实现计划的目标。管理者最重要的职责就是帮助下属,给他们设定一个目标,让他们开始工作。为他们扫清一切障碍,尽一切可能更高效地工作。然后,组织就可以收获他们的工作成果了。

一个优秀的领导并不是裁判,而是同事和顾问,在日常工作上领导同事,一起工作,并相互学习。

领导力就是提升人的境界。领导力就是把一个人的视野提到更高的境界,把一个人的成就提到更高的标准,锤炼其人格,使之超越通常的局限。然后才能把一个人的潜力、持续的创新动力开发出来,让他做出他自己以前想都不敢想的那种成就。

管理的本质,其实就是激发和释放每一个人的善意和潜能。对别人的同情,愿意为别人服务,这是一种善意;愿意帮人家改善生存环境、工作环境,也是一种善意。管理者要做的是激发和释放人本身固有的潜能,创造价值,为他人谋福祉。

很多人把管理当成一种工具,认为管理是用来操控的,因为它的目标是要让工作有结果,就必须操纵控制工作者的行为。胡萝卜加大棒理论,胡萝卜是利诱,大棒是威胁,两者都是在利用人的弱点,即人性中的贪婪和恐惧,去操控工作者,这与管理的本质背道而驰。

最后想说的是:

  • 人对于未知一般都是恐惧的,很多东西在事前讲清楚就好了。
  • 感觉是非常重要的,因为感觉是经验的产物;感觉有时又是错误的,因为是主观产物。
  • 纸上谈兵总是容易的,实际工作总会很困难。

学习了CSM之后又学习了PMP,对于理解Scrum很有帮助,后来又继续学习彼得•德鲁克和爱德华•戴明的管理学。嗯,觉得这个味儿够~ 🙂

附 敏捷宣言

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具

工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

微信ID:abp0616  期待交流~

敏捷软件开发绩效管理系列之如何考核敏捷团队

前段时间有位朋友问我如下2个问题:

  1. 如何衡量一个好的敏捷教练?
  2. 团队达到什么情况时,就是敏捷了,是否有标准?

这两个问题的本质是有关于绩效管理的,因此触发我想写两篇有关敏捷软件开发绩效管理的文章。本篇是系列一——如何考核敏捷团队,即团队敏捷转型前后能有什么变化,或者说团队敏捷的“标准”(这里特意用了引号)。

在开始讨论绩效管理之前,我们先来一起看看绩效管理的目标。

绩效管理的目标

  • 提高个人业绩表现
  • 改善组织结果
  • 决定加薪或升职

提高个人业绩表现

绩效管理的目标之一就是帮助个人提高,或者换个说法,个人在公司里工作的主要动力之一也是可以自我学习、提升个人价值。

反观大部分公司的绩效管理是如何做的呢?

多数公司都是等到了年底的时候,直接经理进行一次性的打分(针对这一年的表现),然后根据这样的打分来决定个人一年的总体表现。这样做,对于提高个人表现有多大的帮助呢?总之,我认为作用不会很大。

改善组织结果

很多组织会有一大堆考核组织(或者团队)的度量指标——多的甚至达到20+。这么多的指标究竟有哪些可以指导组织(或团队)的改进,有哪些有负面作用?

另外,这些考核组织(或者团队)的指标往往掌握在管理者手里(团队成员并不知道)。那么这样的绩效管理对于改善组织结果的作用有多大,是值得商榷的。

用于加薪或升职

正如绩效管理第一个目标(提高个人绩效)中提到的,多数公司是每年(好一点的是半年)做一次绩效评估,然后根据这次评估的结果来决定一个人的加薪或者升迁。这样的话就会导致评估结果不能真实反映实际情况,举个例子,某员工小明,在11月底的代码提交中引出一次线上事故,而在前10个月中小明表现都非常优秀。在这个情况下,小明这一年的绩效评估结果会怎么样?很不幸,估计不会太好。原因如下:1. 尽管小明之前表现非常优秀,但这次犯了错误。2. 尤为关键的是这个错误恰好在绩效评估之前,管理者记忆犹新。

前面我们列举了绩效管理的目标,以及传统按年进行绩效评估的缺陷。那么在敏捷软件开发中,如何进行绩效管理呢?

度量指标的分类

在谈及绩效管理度量指标之前,我先对度量指标做一个粗略的分类。度量指标可以分为:

  • 内部度量指标
  • 外部度量指标

内部度量指标

内部度量指标,指的是度量组织(或团队)内部的指标(从内部看)。举个例子,比如个人或者团队的代码行数,单元测试覆盖率,缺陷数等等。

内部度量指标主要用于提高组织(团队或个人)的效率。

外部度量指标

外部度量指标,指的是度量组织(或团队)外部表现的指标(从外部看)。举个例子,比如ROI,客户满意度,NPS等。

外部指标主要用于指导组织(团队或个人)的方向,从而组织盈利或获得成功。

敏捷软件开发的度量指标

选择度量指标的时候,有几个因素需要着重考虑:

  • 公司的目标是什么,这个度量指标和公司目标匹配吗?
  • 组织(或团队)的改进方向或重点是什么?
  • 这个目标的数据收集工作有多大?更新周期是多久?

另外,针对绩效管理度量,还有两个重要原则:

  1. 结果比过程重要
  2. 学习比失败重要

注意:在下一篇文章中,我会列出一些软件开发中常用的度量指标(经常也用于敏捷团队的),需要特别注意的是这只是一个度量指标清单,不要照本宣科全部采用(会累死的)。

待续

 

BoB Jiang敏捷新闻 – 2017年01月

2017年第一篇BoB Jiang敏捷新闻稿。
马上要春节啦,再次BoB提前预祝各位敏捷小伙伴,阖家欢乐,身体健康!
2017年开始,BoB Jiang敏捷新闻开始对外开放,征集敏捷相关新闻、观点、案例分析等稿子(包含但不限于以上类别)。如果您想成为BoB Jiang敏捷新闻编辑的一员,欢迎加我微信私聊。(有心人肯定可以找到我的微信哦)
内容大纲
  • 新闻
  • 社区
  • 荐书
  • 课程
新闻
—————————————-
2017年6月3日在越南岘港举办敏捷之旅全球大会,本次大会将会聚集全球各地2016敏捷之旅最佳话题。详情参考:http://conference.agile-world.com/
社区
—————————————-
2017年Agile1001(敏捷一千零一夜)有更多的玩法。想要加入我们,可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html
2月份Agile1001的活动如下:
2017年2月12日 北京 人脉构建 by 王泽一
2017年2月18日 上海 敏捷团队右脑训练工作坊 by 王伟
2017年2月18日 深圳 精益看板工作坊 by 李国柱
2017年2月25日 北京 精益创业(或待定) by 龚正
2017年2月25日 成都 一起来读书 by 张莹
荐书
—————————————-
《精要主义》这是我读过的最有共鸣的一本书。先说一下整本书的结构:
Explore 探索 – 区分出最重要的少数和不重要的多数
Eliminate 排除 – 敢于说“不”,排除不重要的事情
Execute 执行 – 让做重要的事情变成习惯,很容易的执行。
把书中一些共鸣点列举一下:
1. 抽离 – 为思考和探索留出时间。在现在移动互联网时间,每个人每天都非常忙,一点点闲暇时间也被碎片信息所充斥。在这个现状下,尤其需要注意留出时间进行独立思考。作者举出了几个例子(请参考书),我也说一下我个人的感受。冥想(坐享) – 每天有15分钟什么都不想什么都不做,静静的放空自己,注意感受自己的思绪变化。在李笑来老师的得到专栏也有很好的讨论。在最近一个月的练习后,明显我可以更好的认识到自己的情绪变化。
2. 勇气 – 优雅的说不的艺术。一直以来我认为自己是个烂好人,别人求助的事情90%都会答应。读到这一段之后给我巨大的冲击。原来说不有这么多方式,而且即使说不,也不会破坏关系。建议老好人仔细阅读这一章节。(优雅说不的六大原则)
课程 – Certified Scrum Master (CSM) 敏捷认证课程
—————————————-
2017年2月16日17日 成都 http://yihuode.io/activities/404
2017年3月23日24日 北京 http://yihuode.io/activities/419
2017年4月20日21日 深圳 http://yihuode.io/activities/436
2017年5月25日26日 北京 http://yihuode.io/activities/420
关于我
—————————————-
姜信宝 (Bob Jiang)
中国北方第一位CST(Certified Scrum Trainer)
资深敏捷教练、创新教练
旨在帮助企业改进工作方法以取得更好的商业价值
Certified LeSS Practitioner,《Scrum精髓》的译者
Agile1001 (敏捷一千零一夜)联合创始人
邮件: bob@bobjiang.com
微信: bob_jiang_xinbao
电话: 13910939018
如果您希望取消订阅此邮件,请回复主题为“退订”的邮件

我的2016-BoBJiang

我的2016是成长的一年,飞跃的一年,自己还是非常满意的。获得的证书如下:

  • CST (Certified Scrum Trainer) – 我是中国北方第一位CST
  • 北京邮电大学软件学院工程硕士 – 终于在截止日期之前完成了

既然2016是成长的一年,我想从四个角度来进行总结,即

今年听了大大小小10来个培训或大会,但其中只有如下几个很有收获:

  1. 自费听的2个工作坊(培训):Leading Agile Organization by Pete Benhrens, Problem Solving Leadership by Jerry Weinberg and Esther Derby
  2. 公司组织的培训:水平思考 by Sally老师
  3. 在线课程:敏捷教练修炼之道 by Lyssa Adkins
  4. 大会:AHA小会Global ScrumGathering Bengluru, Regional ScrumGathering Hangzhou

  • 线下分享10+。分享话题有《回顾工具箱》《设计思维体验工作坊》《提升团队研发效率1倍不是神话》《影响地图体验》。分享的大会有ToP100,TiD,PMI Congress2016,厦门技术峰会,怒马线下活动,Agile1001线下活动,Global ScrumGathering Bengluru等。
  • 线上分享10+。分享话题有《Scrum精髓》《精益看板》《敏捷领导力》《精益创业》《设计思维介绍》等
  • 值得一提的是,今年第一次用英语进行分享。还是颇有一些挑战。

  • 书籍:2016完整读过5本书,(有读书笔记)分别为《开放空间技术》《人人都能用英语》《重新定义工作》《把时间当做朋友》《即兴的智慧》另外还有一些零零散散的阅读记录,如《如何构建敏捷项目管理团队》《Scrum敏捷软件开发》《管理的未来》《给经理人的第一课》等
  • APP:最大的惊喜,发现了得到app,并订阅了《通往财富自由之路》专栏,借着这个平台发现李笑来老师很多的文字,如公众号,如免费书等等。

BoB Jiang敏捷新闻 – 2016年12月

本篇是2016年最后一篇BoB Jiang敏捷新闻稿。2016年8月份开始,每月我都会发布一篇新闻稿,里面包含新闻、社区、荐书以及课程四个部分。如果您对敏捷新闻稿有什么建议、想法或意见,都欢迎回复邮件联系我。
2017年开始,BoB Jiang敏捷新闻开始对外开放,征集敏捷相关新闻、观点、案例分析等稿子(包含但不限于以上类别)。如果您想成为BoB Jiang敏捷新闻编辑的一员,欢迎加我微信私聊。(有心人肯定可以找到我的微信哦)
内容大纲
  • 新闻
  • 社区
  • 荐书
  • 课程
新闻
—————————————-
敏捷学习指南-带你从入门到深入。11月我发表于CSDN极客头条的一篇文章,敏捷从入门到深入一条可能的路。
社区
—————————————-
敏捷之旅陆续在国内多个城市举办,大部分都已经举行过了。
敏捷之旅北京也在12月18日完美收官,2017年Agile1001(敏捷一千零一夜)有更多的玩法。想要加入我们,可以点击链接查看2017的课程内容。www.hdb.com/party/fcopb.html
2017年1月15日 在北京,一起体验视觉记录吧。http://www.hdb.com/party/pze3b.html
2017年1月8日 在上海,设计思维体验工作坊。 http://www.hdb.com/party/xor3b.html
荐书
—————————————-
《Scrum敏捷软件开发》作者Mike Cohn。本书是Scrum敏捷转型的宝典,值得反复阅读。每次阅读都能再次从中受到一些启发。最近又翻开了这本书,两个点很有感受:
1. ADAPT模型,即改变需要如何发生(不仅限于Scrum转型)
1.1 Awareness 意识。意识到需要改变,可以通过度量数据,沟通达到目的
1.2 Desire 渴望。告诉团队有更好的方法,创造紧迫感或者造势等方法可以帮助实现目的
1.3 Ability 能力。提供辅导、培训(可以参考下面的课程)或共享信息等工具
1.4 Promote 推广。讲述成功的故事,吸引注意力,勾引兴趣。让更多的团队愿意接受改变
1.5 Transfer 传递。Scrum这个框架如何传递给公司其他部门,而不仅仅是IT部门自己玩
2. 自组织团队的CDE
2.1 Container 容器。自组织团队的边界在哪里,找到合适的范围(即容器)
2.2 Differentiator 差异。团队的差异是什么,扩大或减小差异对团队的影响是什么
2.3 Exchange 交换。信息在团队内是如何流动的,怎么样最大化信息流动,知识传递
课程 – Certified Scrum Master (CSM) 敏捷认证课程
—————————————-
2017年1月12日13日 成都 http://yihuode.io/activities/404
2017年3月23日24日 北京 http://yihuode.io/activities/419
2017年5月25日26日 北京 http://yihuode.io/activities/420
关于我
—————————————-
姜信宝 (Bob Jiang)
中国北方第一位CST(Certified Scrum Trainer)
资深敏捷教练、创新教练
旨在帮助企业改进工作方法以取得更好的商业价值
Certified LeSS Practitioner,《Scrum精髓》的译者
Agile1001 (敏捷一千零一夜)联合创始人
邮件: bob@bobjiang.com
微信: bob_jiang_xinbao
电话: 13910939018
如果您希望取消订阅此邮件,请回复主题为“退订”的邮件

敏捷学习指南-带你从入门到深入

这是我11月发表在CSDN极客头条的文章。

什么是敏捷

敏捷(Agile)是一个全球性的运动,它正在改变我们的工作环境。敏捷这个词是2001年17位软件行业的大牛在一起讨论得出的(参见敏捷宣言),目前敏捷正在扩展到各行各业,而不是仅仅限于软件行。

敏捷到底是什么?我们看看下图(感谢Lynne Cazaly总结的40多种敏捷方法和框架):

图片描述

图1 40种敏捷方法和框架

上图所示,敏捷中有40多种方法和框架,超过70多种的具体实践,那么如何把这个概念介绍给他人呢?Cockburn博士(Alistair Cockburn)曾经是这么定义敏捷的:

敏捷是尽早频繁的交付商业价值。(Agile is to deliver business value early and frequently)

下面我们一起来看看,为什么我们要敏捷。

为什么要敏捷

了解敏捷之前,我们可以一起来看一下为什么我们要进行敏捷。敏捷可以帮助组织或公司来应对持续不断的变化,来应对这个VUCA(Volatile, Uncertain, Complex, Ambiguous)的世界。解决快速变化的唯一方法就是拥抱敏捷。由于软件变得越来越重要,敏捷也逐步变成企业转型的关键。

在敏捷的组织内, 自组织团队通过短期迭代(通常为1-3周)的方式快速交付客户价值。小团队都采用相同的节奏进行交付,因此大型的复杂产品开发也可以由多个小的自组织且端到端的特性团队来完成。敏捷是更聪明得工作,而不是更苦逼得工作。敏捷不是用更少的时间完成更多的工作,而是用更少的工作产生更多的客户价值。

敏捷入门

在我的培训课中,通常有学员问“ 一个人可不可以敏捷?” 我的回答是“必须可以”。下一个紧接着的问题就是“怎么做”? 回答这个问题之前,我们一起回顾下敏捷的基础:透明、检视和调整。根据这三个基础,我们逐一来看怎么做。

透明。 人类大脑的美妙之处在于思考,而不是记忆。你是否有过某件物品突然之间就是找不到了?你是否碰到过有个人的名字就在嘴边,说不出来了?这就是我们通常说的大脑短路,忽然想不起来了。那么对于这些需要记忆的信息,我们需要做的是把它写下来,存储到一个便于查找的地方。比如我常用的几个工具是:笔、本子、印象笔记。笔和本子记录平时的各种想法、学习笔记等,还有一个专用的本子记录行程,印象笔记记录不错的网页和图片。这些信息对我来讲都是透明可视化了,我清楚地记得它们的位置。

检视。检视指的是不仅要记录,还要不断回过来看一下。做了一些尝试,记录一些内容,回过头来看看,通常会冒出一些新想法。这些新的想法也可以补充到笔记上去。

调整。做到透明和检视还不足够,还需要不断调整。这个调整有一个重要的动作指的是反思。回顾反思之前我做过的事情,哪些地方做的非常不错,哪些地方还可以提高,从中学到了什么,以后我可以做出哪些改变。

一旦掌握了上述的三个基础,个人开始就变得敏捷了,也变得更加开放和包容了。

我们最常说的敏捷,指的是团队级别的敏捷。透明,把团队的进度公开可视化。检视,团队不断回顾检视潜在可交付的产品增量。调整,团队不断反思如何改进工作方法和工作流程

同理,组织或者企业层面的敏捷也是按照同样的思路进行。

敏捷基础

敏捷的学习可以参考日本合气道的修炼之道,守破离。在学习敏捷之前,可以先选择一种敏捷方法或框架,如Scrum。然后守破离。守,指的是完全遵守Scrum框架的规定,不去进行调整或定制。要的是一丝不苟的练习。这个阶段至少6-10个迭代。破,可以对Scrum进行调整(打破框架),这个必须是在团队进行了大量的练习之后。一次一个地方进行调整试验,然后总结。然后再调整再总结。离,指的是根据实际情况,采用适合当时情况的措施,做出合适的应对。这个时候已经不是Scrum,也不是极限编程这样的方法或框架。 而是心中时刻留存的是敏捷的精髓,即敏捷宣言。以及敏捷的基础,透明、检视、调整。

常见的敏捷方法和实践包含:Scrum极限编程看板方法以及持续集成

敏捷核心

敏捷核心的内容包含:敏捷宣言,以及敏捷原则,敏捷的心态(敏捷基础)和敏捷价值观。

敏捷进阶

敏捷入门之后,可以在这条路上继续前行。本部分一共包含三个方面:敏捷知识、教练知识、引导知识。上述每个方面的知识,从入门到精通至少需要七年时间(参见李笑来所著的《新生—七年就是一辈子》)。

专业知识:敏捷

图1所示的敏捷包罗万象,包含40多种方法,那么如何去学习敏捷专业知识是一个复杂的事情。建议可以从其中的1-2种方法或框架入手,如当前最流行的Scrum框架。Scrum入门可以参考官方提供的《Scrum指南》 ,想要全面学习Scrum,可以参考《Scrum精髓》。

学习的方法有很多种:如体验、观察,这些是基础的学习方法。举个例子,记得有一次去北戴河度假,有段时间流行自己蒸海鲜,我们买了一堆螃蟹回去。丈母娘自告奋勇帮忙洗海鲜,忽然我听到一声惨叫,哎哟哎哟。我赶忙跑过去看看发生了什么事情。原来丈母娘的大拇指被螃蟹给夹住了。仔细询问后得知,丈母娘把绑着螃蟹腿的皮筋解开了,想要放开洗。我相信丈母娘以后会非常小心螃蟹的钳子。这种学习的方式叫做体验,你亲身体验了就会记忆深刻。当时我老婆站在附近,她也看到这件事情。那么她也学到了要小心螃蟹钳子。这种学习叫做观察。对应到如何学习敏捷(具体说是Scrum),最好的方法是体验,在自己的团队中开始尝试采用Scrum。如果实在没有环境,也可以采用观察的方法。找一个正在采用Scrum的团队,去观察团队是怎么做的。

还有两种高级的学习方法是阅读和反思。阅读是拓展知识非常有效、非常快速的一种方式。世界上的事物有千千万万种,我们不会有那么多时间和精力一一进行体验。因此我们可以通过阅读优秀书籍来进行学习。拓宽自己的眼界和知识,这也是为什么敏捷当前包罗万象。另一种高级的学习方法是反思。曾子 曰:吾日三省吾身。每天都需要反思一下,那么反思怎么做,都需要反思什么。

对于个人反思,可以每天睡觉前花5-10分钟思考以下三个问题:今天我什么事情做得非常棒?今天有什么事情我可以做得更好?今天我学习了什么新的知识?

对于团队或组织的反思,可以通过定期(如每周、每 月)组织回顾会议来实现。组织一次回顾会议可以参考这个步骤:预设会议基调,收集数据,激发灵感,决定做什么,总结收尾。具体每个步骤中的环节,可以参考《敏捷回顾》。

专业知识:教练

什么是教练?专业教练作为一个长期伙伴,旨在帮助客户成为生活和事业上的赢家。教练帮助他们提升个人表现,提高生活质量。教练经过专业的训练,来聆听,观察,并按客户个人需求而定制Coaching 方式。他们激发客户自身寻求解决办法和对策的能力,因为他们相信客户是生来就富于创意与智慧的。教练的职责是提供支持,以增强客户已有的技能,资源和创造力——(摘自百度百科)。

为什么学习敏捷,还需要学习教练知识。让我们一起看下敏捷宣言中的“个体与互动高于流程与工具”。这里个体与互动,强调的就是人以及人与人之间的互动(即团队)。如何激发个人表现,改善个 人的生活与工作,对于这些教练可以有很大的帮助作用。针对具体的教练技术和流派,在本文就不一一详述,有兴趣的朋友可以网络搜索一下,或者参考ICF(International Coach Federa)官方网站

专业知识:引导(facilitation)

什么是引导?引导是指通过创造他人积极参与,形成活跃氛围,从而达到预期成果的过程。这种成果可能简单到学习一项新技能,也可能复杂到解决一个跨组织和部门的复杂问题。总之,引导的作用就在于积极引导他人主动参与的互动过程。

在团队的日程工作中,团队会议是最常见的活动。那么如何形成活跃氛围,如何帮助团队高效组织会议,如何能够达成预期,如何解决跨部门的复杂问题等等。这些问题都可以通过引导来进行有效的解决。如《敏捷回顾》 一书中,就提到了很多引导的技巧。学习引导还可以参考《引导》这本书。引导进阶可以参考《引导的秘诀》。

敏捷实施中常见问题

这个部分我将列出一些敏捷实施中非常常见的问题,可能你已遇到过,也可能还没有遇到。不过没关系,我们可以一起来研究探讨如何应对这些问题。

小提示:以下提到的几个常见问题的应对方案一般不限于一种,要根据不同的环境和组织进行相应的调整,以免对读者产生误导,本文暂不做解答。如果碰到类似问题的小伙伴想要了解的话,可以给我写邮件交流:bob@bobjiang.com。

  1. Sprint进行到一半的时候(比如两周的Sprint,过去了一周),总监要把团队中的一名骨干成员调走到另一个重要的项目。作为Scrum Master,碰到这样的情况,你会怎么办?请列出具体的解决方案以及原因。
  2. 每日站会上,团队成员A不关心其他人的内容(和其他人的任务没有交集),也不认为有必要关心。作为Scrum Master,你会怎么办?
  3. 连续3个Sprint团队都只完成了承诺的Product Backlog Item的一部分(即没有完成计划会上的承诺),作为ScrumMaster,出现这个情况,你会怎么办?

欢迎访问:CSDN敏捷知识库,全面系统展现敏捷各知识点及内容资源