理想与现实

题目的由来

这个题目是怎么来的呢?我在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

敏捷不是形容词!

阅读《技术人创业攻略》一书中,作者对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  期待交流~