亲历者说:敏捷?我被洗脑了吗?

几年之前我还是个野生程序员的时候,对“敏捷”这个词是有些抗拒的。那时候,要么是没有想法、懒得去理会,要么就是主观上拒绝:

肯定又是些无所事事的人弄出来的无聊概念,帮他们自己刷存在感的东西!

敏捷,就是那些咨询公司弄出来给别人洗脑的嘛,那些理念太空,根本无法落地!

那些一大堆概念都是些什么鬼?条条框框太多了,运作起来太麻烦了!

不用敏捷,我们现在不也挺好的吗?敏捷跟我有什么关系?

但后来我却选择加入了 ThoughtWorks,这个传说中的敏捷大本营,一方面因为很多出名的书都是 ThoughtWorks 的人出的,另一方面也想亲入虎穴一探究竟。而如今,历经敏捷项目的洗礼,我已经成为专职的一线咨询师,为众多大型企业提供敏捷转型过程中的技术指导。

他们

在一些朋友看来,我自从换了工作,就开始在群里转发一些敏捷相关的文章,发表一些感言。在转发这些内容的时候,我经常用到的叙事口吻是“他们”。

他们的代码真的写了好多测试。

有时候要开一整天的会,我真不知道他们是怎么撑下来的!

感觉跟着他们一起做测试驱动开发好像没那么难。

这段时间里,我让自己成为一个“警惕的观察者”。不管是主观上的警觉,还是故意在外人面前将自己打造成这样的一个形象。深怕在我还没有觉察到的时候就已经被敏捷洗脑了;同时也希望在曾经的好友面前以尽量理性、中立和客观(理中客)的形象示人:不过,这不妨碍在他们看来,我已经被洗脑了。

后来我了解到,这如同学习新知识过程“守破离”中“守”的阶段。“守”的过程既是获取新认知的过程,也是与过去的认知做比较和更新的过程。观察现象——对比质疑——私下学习——拨开疑云,大体就是这样的不段重复,在不断了解新实践的过程中,也同步去认识它、理解它。

渐渐地,一系列疑问得以解答,使得最终我接纳了敏捷开发思想,并认为它是适用于现代开发团队中的工作方法。

疑问

在过去我呆过的团队中,一直有两个无法解答的问题。那时作为技术经理,我经常被别人问到的问题,也是我自己无法用经验回答的问题。

  • 做完这个功能,你估计需要多少时间?
  • 为什么大家在办公室显得很安静、气氛有点压抑?

在成功学的洗脑课程中,有一句被强调最多的话:“失败一定有原因,而成功一定有方法!”那么,我们过去回答不了的上面这些问题,以及由它们导致的管理上的难题,其根本原因又是什么呢?获得管理上成功的方法又是什么呢?我带着这两个问题离开了之前深度参与的创业项目。与朋友分享了要探索新征程的想法之后,他真诚地邀请我加入他的创意,并希望由我来带领团队一起续写新的故事。我猛然间发现,其实虽然之前在团队里担任所谓技术经理的职位,但我真正给团队带来的帮助似乎更多的只是一个有经验的工程师给新手的指导。那时候,第三个疑问产生了:

  • 如何去做好一个团队带头人?应该安排团队成员每天做什么?

这些疑问不得到解答,我就如同掉下井底的青蛙,虽然能听见外面世界的声音,却只能看到井口大小的世界。

答疑

加入新团队后不久,这些疑问就完全得到了解答。第一个要实现的需求就是一个“明星”功能,集成第三方系统的调查问卷。团队很快组织了需求计划会议,并细致地过了一遍第一期要完成的目标,实现这个目标要包含的业务范围,而具体又包含哪些步骤(用户故事)。

  • 目标:发出问卷链接,并将数据收回来。
  • 范围:选取模板、发送链接、收回数据、发送提醒邮件
  • 步骤:
    1.  管理员在外部系统中创建好模板(不需要开发)
    
    1. 用户可在 XX 页面中使用选项来选择问卷模板(系统自动将外部系统中的模板名字同步到本地系统)
    2. 用户可在 YY 页面中使用链接发送调查表单,客户收到包含链接的邮件
    3. 系统自动将外部系统中收到的数据同步到本地系统中以供使用
    4. 如果没收到提交数据,系统自动在7天后自动发出提醒邮件,客户再收到一封包含链接的邮件

接着开发人员和测试人员对还不够详尽的细节提出问题,讨论获得一致,一起对各个步骤大致估计所需时间。每个用户故事并不确定由谁来做,而是大家一起就其中的细节进行讨论,并就所需时间形成一致:有的人说需要 3 天,有的人觉得 2 天就够了。他们会叙述自己的想法,并最终达成共识。

这项活动,以及之后的迭代过程中,基于这个会议的开发过程解答了我第一个疑问。

他们有一个角色叫 BA,会写一个个的用户故事来描述需求,一两天就可以完成一个故事。明确的前提条件和验收标准(从哪里开始做,做到哪里为止),让开发工作变得有节奏感,需求不清楚的时候随时就这个需求的范围进行讨论。

相比于拿别的产品做个演示,甩一句“就照这个做”,然后就天天催进度、做出来之后又说不对劲的产品经理,有一个专门负责业务、随时可以叫过来讨论的 BA 让开发人员感到倍感轻松。

江湖上传言说敏捷不需要文档,原来是谬误。敏捷并没有说不需要文档,只是说认为团队成员之间的沟通协作比详尽的文档更重要。所以,用户故事仍然是会包含必要的描述内容的。要写清楚为什么要做这项功能,以及验收标准等。

团队一起估计时间的过程,不光可以消除特定人估计时的无助感,更重要的是它让所有人都了解用户故事的细节,在后续开发中谁都可以参与开发。

相对较小的用户故事,估计起来要比一整个功能(比如对整个调查问卷功能进行估计)估计起来靠谱得多。即使有特定的用户故事估计不准确,其影响范围也是可控的。

把所有故事的估计时间相加,即为整个功能所需要花费的时间。

估计只是帮助做计划的一种方法,在后续开发过程中,如果发现比当初估计的要复杂,或者简单,需要与 BA、PM 等角色一起更新这个估计值,从而帮助团队及时完善一开始制定的迭代计划(如果必要,可以加入一些,或者减去一些,或者修改一些)。

这样,我发现开发团队的时间原来是需要管理的,而管理时间这件事其实也需要花些心思才能做好。这时候,如果你问我某项功能需要多久做好?我会告诉你,让我来拆分一下功能,粗略估计就成为了可能。

而后面的其他疑问也很快得到了解答。关于团队气氛,如果一个团队里每个成员都在闷头做自己的工作,独自面对自己的交付压力和技术挑战,成员之间互相帮不上忙,他们的气氛一定不会太好。而如果所有人通力配合工作在相同的功能上,一起理解消化业务,一起解决技术问题,共同做技术决策,并分担解决缺陷(BUG)的责任和压力,那么团队的气氛怎么会不好呢?

最后一个问题,关于团队。

团队里大家的角色是如何分配的,规模又应该多大?团队之间应该如何配合?这就不难回答了。典型的业务功能团队,以及后来出现的微服务团队,都很好的诠释了团队结构和规模问题。有一个论述产品设计和组织结构关系的康威定律,值得我们深入思考。团队带头人?我突然反应过来,一定要有这个角色么?如果大家都能很好地运作了,那其实这个所谓带头人的作用是很淡化的,这也就是所谓的自组织团队了。如果一定要一个带头人,那他的职责一定是确保这样一种自组织的机制在团队中持续地运作下去。

所以,我被洗脑了吗?

也许你可以这样认为。

作者我现在是接受了敏捷思想的,其中还有一些工具和方法,我还在持续学习过程中。不过,“洗脑”这个词本身其实具有一定的预设立场,它是那些质疑者的说法。

那么,重新回到问题本身。敏捷是什么呢?它会将人们洗脑吗?

敏捷不是什么宗教,它只是一种生产软件的思路,一种倡议。它倡议,通过加强团队成员间的交流协作,尽快交付高质量、有价值的软件,让团队以良好的响应性来拥抱软件的变化。为了符合这种思路,它一般又会有一些典型的实践方式。我们可以说哪些实践是由敏捷方法所推荐的,因此是“敏捷的”;而哪些实践是不推荐的,因此是“不够敏捷的”。但不会说哪种是好的,哪种是不好的。

比如,敏捷的:

  • 自主提交代码,尽早集成
  • 自动化一切,包括环境初始化
  • 代码由团队共享,随时重构和优化

不敏捷的:

  • 逐次代码提交都需要他人审查并批准的管控
  • 手动部署生产环境
  • 不让他人修改自己编写的代码

但这些“不敏捷”的条目,基于团队具体情况,可能实际操作起来更可行,就可以根据目前的阶段去施行,并向着更敏捷的方向去持续改进。类似地还有,敏捷不会说团队一定要开站会,站会一定要在早上开等等……相反,如果要求团队一定要做某件事,其实它与敏捷思想是背道而弛的。我们应该遵循敏捷理念去对实践进行改良,以适应团队实际情况。

事实上,“敏捷”一词来源于英语 Agile,这一英文词汇也类似于中文中的形容词“敏捷”一词,其适应性相当广泛。人们往往用它来形容业务的灵活性,思路的开放性等。因此对于敏捷来说,并不存在什么洗脑不洗脑的说法。它只是一种风格,一种态度。只要你运用这种思路和风格去让团队协作越来越好,开发出来的软件的质量越来越好,那就是敏捷的。敏捷中典型的具体实践方法有 Scrum)、XP 和 Lean 等。此外,近年被广为谈论的 DevOps,也已经成为了敏捷软件方法的典型实践。


更多精彩洞见,请关注微信公众号:思特沃克

Share

培育数字化文化的7个原则

[摘要]

谈到数字化和敏捷转型,缺乏“文化土壤” 通常是一道巨大的难关。什么样的 “土壤” 能够孕育 “敏捷” 的价值观,帮助企业落地数字化的战略? 如何改变人的思维?文化是可培育的吗?文化是可衡量的吗?


Peter Drucker once said,“Culture eats strategy for breakfast.”

彼得·杜拉克曾言:“转型之挑战,不在战略,而在于文化之不达”。谈到数字化和敏捷转型,缺乏“文化土壤” 通常是一道巨大的难关。什么样的 “土壤” 能够孕育 “敏捷” 的价值观,帮助企业落地数字化的战略? 如何取得怀疑者、后进者的支持?如何改变人的思维?这些问题都是我经常听到的疑问。

“文化土壤” 的养成,是一项积极倡导简单,躬行践履不易的事。实际落地比逻辑理论困难的多。所以,我这篇文章只是想抛砖引玉,大家可以尽情评论。

文化很重要,但是大多数公司不在文化上花时间

一项有来自340家机构的1700名参加者的研究显示,60% 的人认为缺乏文化土壤是推行数字化转型的主要壁垒。典型的现象是:

领导层觉得他们在推行数字化,但是员工并不认为他们的企业文化是“数字化”的。

中层领导认为他们权力不够,推行不了文化转型。

员工不知道组织的数字化愿景是什么;即使这个愿景真的存在,也没有人跟他们沟通过数字化愿景。

总之,领导层和员工的看法完全对立。同年,另一项研究调查了欧洲的450名主管和董事会成员,发现只有20%的人按照要求花时间管理、改善数字化。对立实在很严重。

诚然,如果适配的文化土壤是成功的重要因素,我们就需要齐心协力来营造。实际上,像海尔这样的巨头,企业中有一个专门负责建立与推广文化的部门。也许你会说这是政治宣传,或者洗脑。但宣传、实践文化十分重要;持续宣扬正确的价值、正确的行为也是很重要的。

什么是数字化文化?

根据艾德佳·沙因的理论,“组织文化是一种隐形假设,一种在行为和态度中得到加强的行为观念,它是潜在的、共有的、但又是潜意识层面的”。

组织可能会拥护某些指导着行为的价值和原则。组织中一个人的行为很可能取决于他/她的同事是否能接受。同时,特别在大型组织中,不是只有一种文化,而是有很多种文化或亚文化。

数字化、敏捷的文化就是支持数字化创新、持续支持敏捷工作方式的文化,它包括:

  1. 以客户为中心,而不是闭门造车:能察觉并满足顾客的需要,而不是怎么省事怎么来;愿意为顾客克服障碍。打造尽善尽美的客户价值,并持续提升。
  2. 鼓励合作:同事们相互合作,寻找解决方案;鼓励 “人人发问,人人贡献”——无所谓职位高低,职能差异,每个人都应得到尊重。
  3. 拥抱反馈,拥抱学习:组织应该兼收并蓄,广泛收纳意见;不断学习,尝试新的商业模型、管理模型等等;个体的经验能够通过分享,为整个组织所习得。
  4. 赞赏出色的表现和突破:组织内充满斗志,很有激情;勇于质疑现状,永远追求进步。

对于数字化和敏捷文化,或许你有不同的认识。我说的并不是全部,你也可以自行补充。实际上,每个组织都要花时间寻找自己的敏捷文化,而且全体参与进来,而不是只有领导层。

如何培育数字化文化?

如何将敏捷文化移植到自己的文化土壤从而催生数字化?这是一个价值千金的问题。我认为有以下几个原则:

1. 文化有可以让人前仆后继、死而后已的内涵

为什么要有文化?我为什么而活着?我为什么要有斗志?

文化(还有战略、创新等)是成就伟业的工具——但伟业不是靠孤军奋战,而是靠整个组织齐心协力才能取得的。这关乎愿景和使命。组织中的每个个体都需要明白,自己该如何为组织的目标贡献力量。这个战略和文化的对齐需要时间,也需要技巧才能完全融合。战略是你设立的优先问题,而文化是背后支持的管理系统。在现实中,战略和文化是不可分离的。他们相互依存,相互补充。如果配合良好,就能顺利运作;否则,就会互相掣肘。

2. 文化反应在预算、绩效管理和奖励系统上

这句话已经广为流传,“衡量什么,得到什么;投资什么,获得什么;奖励什么,加强什么”。

You get what you measure. You get what you invest in. You reinforce what you rewards.

所以,好好看一看你的关键绩效指标(KPI),好好看一看你的奖励机制。如果你不理解员工的某种行为,那就应该去找到驱使了这种行为的管治方法或政策,而且持续了一段时间,以至于它与公司文化融为一体了。因此,你可能需要重设关键绩效指标,更照顾顾客而不是利益相关者。我也强烈建议你仔细分析你们的财务会计体系和系统。你评估各个项目和作业的方法是否正确?你评估绩效的方法是否合适?

3. 文化是双向的,甚至是多向的

被定义出来的制度,不能算是文化。员工不仅仅是文化的被动接收者,他们正在积极地塑造组织文化。如果你希望员工和管理者接受数字化和敏捷化,为他们做点什么吧。让他们能够更轻松地工作。我们经常发现管理让做好工作变得更困难了。作为领导层,你可以为员工做点什么?这不仅是胡萝卜加大棒那一套。很多时候,你需要支持他们做想做的事情,辅导他们,帮他们跨越障碍,帮他们跟合适的人建立联系。需要特别注意的是:领导和领导层的行为能直接塑造企业的文化。如果,员工没有发挥他们的潜能,领导也必须反省一下。

4. 组织的不同层次有不同的文化

组织中的职员级别不同,职责也不同。举个例子,产品研发队会合作创造新产品,或者改善产品。因此,团队中每个人都在读相同的材料,见相同的客户。管理团队会开会探讨其他问题,他们面对不同的挑战,他们也可能说不同的话。结果就是,很可能这些圈子至少会有些许的不同,他们说话、行动和思考的方式都是如此。因此,在不同级别设立文化沟通的桥梁、仔细倾听、积极支持就变得十分重要了。你需要为负责改变的职员播种、提供工具、赋权,让他们能够跨越级别工作。不同的级别需要不同的背景和技巧。

5. 文化需要时间和空间发芽

现有的文化不是一天之内形成的,因此改变它也不是一天的功夫。改变需要时间和空间。为同一目标工作的团队提供一个共享的空间,如一个会议室,以便团队成员能在固定的时间见面、合作,从而从感觉上营造出一个共同进退的氛围。为来自不同团队的成员提供合作机会,比如说,“四个五”方案——就是给五个不同部门的五个人五星期(全职或者兼职)创造有用的东西。它可以是原型、调查研究或者其他。你可以给他们500或5000美元作为奖励或者投资。领导应该思考如何创建协作机制和机会。

6. 培养文化不是一次性的

企业需要有一套自己的节奏和仪式。敏捷模型,比如Scrum方法,能找到让人们共事的场合。经常回顾能让人们提出问题,解决问题,互相鼓励。大模型敏捷是在一个专用的大房间里设计活动,交流公司意图,收集意见。合弄制(Holacracy)提供空间让职员提出不满,表达冲突。再次强调,领导和管理层的行为会直接影响企业和团队的文化。你鼓励什么行为,你有什么作风,就会引起相关的文化风气。

7. 文化会自动演变

文化的本质就是它会自己演变,但是我们希望演变的方向正确。所以,提供分享正面的故事的空间。庆祝成功。提供讨论禁忌和大家都忽略的问题的机会。解决这些问题。我们都知道,坏消息和丑闻传得比好消息快得多。所以我们要主动传播好消息。

如何衡量数字化文化?

文化是无形的,那么有没有办法来衡量文化?当然有办法,而且还很简单。

当然,我们并非为了衡量文化而衡量文化。我们衡量文化是为了检验它对数字化和敏捷转型的效果和贡献。如果你有支持数字化和敏捷的文化,你就已经有了数字化和敏捷的文化。这样,你就可以用净推荐值(NPS)或者客户费力度(CES)两种量表衡量文化了,如下所示:

  • NPS量表——你会不会因为这个组织拥有支持数字化和敏捷转型项目的文化而向朋友推荐它? 从1到10选择可能度。
  • CES量表——这个企业的文化多大程度上让我感到推行数字化项目、应用敏捷工作方式很容易(不费力)? 用非常困难、困难、中立、容易、非常容易等回答。

你可以用很简单的问卷,或者用已有的、可接受的某种情绪分析工具衡量。请注意在大型组织中,应该用数字化的方式收集回应。我推荐使用某种意义构建工具(Sense Making,一种信息收集研究方法,强调使用时序与中立提问访谈技巧)。Cynefin框架经常被用于区分简单、复杂、很复杂和混乱(无秩序)的环境,不过个人而言,我觉得这种方法让意义构建更有趣也更有用。

至此,但愿我的以上观点对你在 “培育企业数字化文化土壤” 的思考有所启示。企业文化的沉淀,不能靠某一个人,它需要不同的人与人之间的化学反应。所以,你需要一个长期的“催化剂”团队。在一些组织中,会去找外部的“敏捷导师”来做催化剂。实际上,我个人认为HR能承担这个职责最好——毕竟,HR是积极参与绩效管理过程的人。但如果HR对于这类具体工作不感冒,就需要敏捷导师来做了,成为数字化和敏捷商业伙伴

我讨论了文化的很多方面。你的企业文化是数字化转型的阻碍吗?从始至终都会是牵绊吗?还是数字化转型能从你的企业文化中汲取营养,获得支持?请记住:其实,文化是你培养出来的。

不过,倡导远不如践行有效。只有一起共事,才有共通目标,同在一条船上,亲身参与某件事,我们才能改变,才能成熟,才能更好地为我们的顾客和集体服务。带上兄弟们,一起行动吧!


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

人人都是生活的敏捷教练

ThoughtWorker们天天生活在敏捷的工作环境中,拥抱着敏捷的价值观,做着敏捷的项目,执行着敏捷的方法论,敏捷的拆卡写卡,敏捷的编码测试,敏捷的迭代,每天在公司、在客户现场都不亦乐乎。如同每一个新人入职一样,从参加各种各样的培训学习敏捷,到慢慢应用到项目中去,再到一定阶段就开始有创造性的自制敏捷实践,这正好是日本剑道学习的步骤——“守破离”啊!

科普下守破离:

  1. “守”:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界。
  2. “破”:基础熟练后,试着突破原有规范让自己得到更高层次的进化。
  3. “离”:在更高层次得到新的认识并总结,自创新招数另辟出新境界。

为应对客户不同的要求和不同的领导风格,大家一定创造出了很多独特的敏捷实践,有的跟瀑布完美结合,有的半敏捷半反敏捷,反正我们听过各种项目的吐槽和经验分享,很是有趣。今天想分享的是在工作之外如何应用敏捷实践,正如《敏捷团队的办公室设计》中所言,希望人人都可以做生活的敏捷教练。

家里的物理墙

去过很多同事家玩耍,发现都有物理墙,以我家为例,有了娃以后事物繁多,比如打疫苗、体检之类时间节点特别明确的事件,还有比如预约了装空调、修暖气、预定了机票要出去旅行等,生活如此纷繁复杂,要安排的事情太多了,又不想错过美好,那么物理墙真是一个很好的办法,把墙建在客厅很醒目的地方,让全家人都能及时看到要做的事情、正在做的事情和已经搞定的事情,并且要有owner,这也是治理家里超级懒惰女士/先生和拖延症患者的绝好办法,“诶,你看你看,我的事都done了,你的咋都在to do里啊?”

图1: 我的2016物理墙

装修与结婚

我司最近好像到了一个适婚的时候,突然很多人买房子装修结婚,事情一多不免焦头烂额,其实把这装修啊结婚啊当做项目来做就会容易很多,比如管理装修就可以整一个看板,把每个步骤都当做一个故事卡,这个故事卡有一定的点数,比如装开关得2个点,室内门从测量到安装得30个点。有些故事卡之间还可能有依赖关系,比如瓷砖贴好了才能量橱柜,比如墙刷好了才能铺木地板。有些故事卡可以分stream并行,有的只能串行。这么看来,管理装修就是管理一个项目,

下图是我的好姐们自家装修的trello看板,两人很明显是两种风格,第一个姐们是过程控制型的,第二个姐们是epic管理型的。

图2:姐们的装修trello看板

图3:姐们的trello装修看板

生孩子

我司最近除了适婚人群激增外,也到了一个生娃高峰,办公室里不少准妈妈,这可能也是一家公司的人口结构慢慢走向成熟的标志之一吧,怀孕生娃是每个家庭特别重要的时期,根据医院产检的要求、根据体重和胎儿的监测,可以以周为一个迭代,大概经过40个迭代就可以顺利release了,以同事宝宝的deliver为例,以周为一个迭代,写一张卡,卡上标注周数、需要做的检查,妈咪每天的体重,身体状况,宝宝的估重,需要补的维生素钙等信息,这样很容易一目了然的监测妈咪的身体状况和宝宝的情况,也能更好的安排去医院检查、预约B超抽血之类的事情。

图4:宝宝deliver全40迭代

养孩子

带小朋友也可以用到很多敏捷的办法,比如监测小婴儿的饮食量、尿不湿的重量、睡眠状况等,都可以很好的帮助家长去调整小朋友的作息和生活规律。

图5:家宝睡眠追踪

像项目中的开发velocity,这是baby的一周睡眠时间,因为周四带出去吃饭high的比较晚,过于兴奋,睡得少。

下面是同事邱俊涛为自家心心宝贝做的换尿布和睡眠时间记录(图表绘制方式可参考《一张漂亮的可视化图表背后》),不断迭代,和宝宝一起适应新世界,换尿布的时间越来越规律平均。

图6:邱俊涛家宝换尿布图谱

图7:邱俊涛家宝睡眠图谱

重构

作为一个非技术型BA,我对重构这事仅限于每天听到devs说太冗余了、要重构、要抽象、要组件化等这种浅薄的认知。第一次发现重构就在身边,是CTO徐昊手工制吉他,原来吉他有那么多细小的步骤,原来手工吉他不能够被量产是因为太多步骤和环节中人工干预的成分过重,导致了结果不能标准化,徐昊在很多步骤中像对待代码一样开启了重构模式,把很多环节组件化,这样加快了手工制作的速度和整个琴的质量。其实生活中很多小事都可以组件化,都可以重构,比如洗衣服的流程,脑补一下现在放荡不羁的年轻人可能是衣服乱丢,然后有一天发现没衣服穿了,统统丢进洗衣服洗完晾晒,要的时候在一件一件收下来穿。那么重构下洗衣服的流程,洗衣机旁边放一个脏衣篮,这样家里就相对整洁些,定期洗衣服,洗好晾晒后,把蒸汽熨斗也放在洗衣服旁边,顺手就熨烫好了,收起挂起,这样的暖男/暖妹,快来给我司妹子/汉子们来一打!

大家不妨回家观察下自己或父母的生活小事,处处都可以进行重构,进行优化,改动一点点,生活质量提高一大截!

家庭Retro

中国传统家庭很难开口讲出“你这样做不对”,“对不起”,“我爱你”之类的直白表达,尤其面对比较传统的家长或者很大男子主义的家庭成员,虽说家不是一个讲理的地方,但各位敏捷教练也可以试试用自己的facilitate技巧化解各种危机。家庭retro就是个不错的方法,定期在家庭成员之间进行retro,可以贴纸条,也可以大家吐槽倾诉,专人记录,但一定要可视化出来,让大家记得自己刚说过的事实,才能找到最终的解决方案。比如婆媳关系,婆婆觉得自己都是为了儿子好,媳妇觉得自己很委屈,让双方一起倾诉下,或者默默的写sticker上,贴起来,由男主来完成整个retro,帮助家庭解决问题,发现每个人的出发点和闪光点,最终找到大家各自的分工和职责,不可越界,不互相干涉等等。

新的一年已经过去了三分之一,想必每个人在年初时都做过展望与总结,新年已经到来,想必每个人都会做一下自我的2017总结和2018展望,不妨试试敏捷的方法,也为整个家庭做一次总结和规划,把那些年不好意思说出的话讲出来,把那些不愿意面对的矛盾和神情都收拾出来。该迭代的迭代,该重构的重构,该retro的retro,敏捷一点点,做生活的敏捷教练。


更多精彩洞见,请关注微信公众号:思特沃克

Share

敏捷在中国这十五年

题记:2002年3月,《程序员》杂志发表了《极限编程》技术专题。以此为标记,敏捷进入中国已经十六年了。这篇文章是熊节去年为《程序员》写的年终回顾文章,发表于《程序员》2018年第1期。

时至岁末,各种年度调查报告渐次登台。其中我注意到云栖社区发布的《2017开发者调查报告》中有一项数据:45.6%软件开发者所在的组织采用了敏捷软件开发方法,在各种开发方法学中位居第一。这个数字又让我联想起,CSDN在年初发布的《2016年度中国软件开发者白皮书》中提到,64%的受访企业采用了敏捷项目管理工具。虽然之前也曾经看到某些调查声称“98%的企业计划采用Scrum”,但我对于这些调查的采样范围一向存疑。云栖社区与CSDN的这两个报告,在我看来客观而坚实地明确了敏捷在当今IT行业的主流地位。

作为站在传统企业数字化前沿的咨询师,来自各个行业甲方的动向也给我同样的感知。在电信行业,浙江移动大张旗鼓地开展敏捷转型与DevOps体系建设,并与咨询师结对公开演讲,介绍自己的转型经验。在金融行业,渣打银行的敏捷转型已经进行数年,汇丰银行以敏捷理念构建他们位于西安的研发中心,招商银行的CIO陈坤德在金融科技峰会中正面提出“银行必须敏捷化”,新成立的民营互联网银行更是从诞生第一天就把短迭代、自动化、持续交付等敏捷实践植入在基因深处。在汽车行业,7月发布的《汽车销售管理办法》打破了传统4S店对销售渠道的垄断,乘用车主机厂纷纷上马在线营销或销售系统,欲与已在地平线露头的汽车电商一争高下,短迭代、微服务、持续交付同样是他们在数字化渠道建设中的主题词。在航空行业,海航集团旗下的科技集团把自己转型成PaaS云供应商,组织文化、工作方式全面对标互联网企业,敏捷岛、看板、信息可视化等硬件设施已经成为研发团队标配。看着各行业头部企业的动向,我感到现在已经可以放心地说:敏捷,已然成为不可逆转的时代大潮。

这股大潮在中国最初的涓滴潜流,大约要追溯到十五年前。2001、2002年,彼此互不相识的几组人,几乎不约而同地向中文世界引进与敏捷相关的资料。《程序员》杂志在2001年12月专栏介绍重构、2002年3月专栏介绍极限编程,是中文出版物中有案可查的最早的先行者。同在2002年,北京软件过程改进组织(PKSPIN)的成员唐东铭向人民邮电出版社推荐了Kent Beck的《解析极限编程》,后来这一套《极限编程丛书》于2002年10月出版。到2003年,《软件研发》杂志的创刊号大篇幅介绍敏捷方法,《重构》、《敏捷软件开发》、《自适应软件开发》等一系列重量级著作引进。今日的风起云涌,即肇始于当年的青萍之末。

饶有趣味的是,唐东铭本人在后来的职业生涯中一直没有机会亲身经历一个敏捷的项目。他的经历,映出了行业的发展历程。敏捷所强调的快速迭代、持续交付,对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言,是太过超前了。时至2006年,在第十届国际软件博览会上,Martin Fowler做了关于敏捷方法的主题演讲,台下报以他的是困惑的眼神与尴尬的沉默。语言固然是尚未全面与国际接轨的中国软件业理解Fowler演讲的阻碍之一,更大的鸿沟还是在于观念与意识。对于其时的行业环境与技术环境而言,每两周一次迭代、每次迭代发布上线给用户使用,既不可能、也不必要。中国的IT业还没有做好迎接敏捷的准备。

决定性的转机发生在2008年前后。通信市场的争夺日趋白热化,4G相关产品的研发已经从原来先有规范后有产品,变成了规范产品同步进行,并且运营商也开始要求越来越多的定制功能。这种竞争态势,使各家大厂把应对需求变化、缩短交付周期放上了研发能力的优先级。从2005年底,诺基亚在杭州的研发中心已经开始试点敏捷,并把试点的成果带到了2006年与西门子合资的新公司里。2008年,诺西多条产品线开始大面积推广敏捷。同在2008年,爱立信也在大范围实施敏捷,将传统的功能团队转变为特性团队,用Scrum方法运作项目,并引入了持续集成实践。华为在印度的团队于2006年小规模试点敏捷,总部得知这一经验后于2007年开启一系列试点项目,并于2009年开始全面推广,特性团队、双周迭代、故事墙、持续集成等实践切实落到了基层。2010年落成的华为南京、上海两个新基地,都大量采用开放式办公区、敏捷岛的格局。在BAT气候大成之前,通信大厂是中国技术人才的重要源泉,这几家公司培养出的大量优秀敏捷教练与持续集成专家,为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

互联网大厂的敏捷起步也并非一帆风顺。2009年,百度把握住谷歌退出中国市场的机遇,全面对标谷歌,包括工程师的工作方式。从单一主干开发模式切入,百度大幅提高了研发过程中的自动化程度,把产品发布周期从几个月一次缩短到了每周一次发布。迟至2012年,腾讯某些产品还只能做到两三个月发布一次,通过模块解耦、提升自动化水平、拆分特性团队、持续集成等实践,得以逐步缩短发布周期,达到了每天能发布两个可用版本的水平。

不过互联网大厂毕竟身处在时代大潮的前沿,时刻接触海量用户真实的行为反馈,以及每一点转化率提升带来的直接经济效益,使他们有直接的动力不断缩短发布周期。大野耐一强调的“湖水与岩石”理论在他们这里得到了淋漓尽致的发挥:发布周期从几个月缩短到一两周,可以靠组织和管理的改变;从一两周缩短到一两天、甚至一天发布若干次,必然要靠技术和平台的积累。BAT自不待言,美团作为二线互联网大厂,也把技术视为自身核心竞争力。对技术人员的尊重不仅体现在管理技术双线并行的职业路径上,也体现在开放、平等、追求卓越的文化氛围上。对技术的重视带来的反哺,则是平台实力的大幅提升。借由高效的数字平台赋能,领先的互联网团队已经超越了“敏捷”的范畴,开发人员无需刻意考虑敏捷的实践,眼前的数据和背后的平台已经驱动着他们自然地按照极短的发布周期不断演进产品。

当互联网大厂以这样的高节奏从线上往线下席卷而来,各个行业的CIO们纷纷上马敏捷,看起来更像是在BAT收割之前的末路狂奔。已经被驱动起来的金融、汽车、零售行业,在一波与时间赛跑的敏捷浪潮究竟会剩下几家欢喜几家愁?有着大市场基数和高利润空间的教育行业,最近连续曝出令人不安的丑闻,这是否会成为政策放松管制、互联网竞争大举涌入的契机?医药行业树欲静而风不止,近有医药改革两票制全面触动流通环节即有利益、阿里健康倒逼医院改革,远处还有政府依托腾讯建设国家级医疗人工智能平台的愿景,医药行业的数字化、互联网化转型何时会进入快车道?航空行业谋求用数字化拉升资产效率,从民航维修、机场运营,到顾客体验、航线收益,再到搭建云生态平台,对未知场景、未知需求的快速感知和响应能力何时会排上航空业IT的优先级?这些可能都是我们在未来一两年内就会看到答案的事。

作为中国敏捷十五年发展历程的亲历者与推动者,透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程,我看到了整个中国IT行业、乃至中国经济发展的缩影。今天敏捷成为最为广泛采纳的软件开发方法,背后折射出的是IT在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。过去十五年,来自美国的敏捷软件开发方法指导了中国的IT行业;未来,中国的IT行业需要什么方法来指导,这个问题可能要靠我们自己来回答了。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

从汽车贴膜看专业团队

前几天去给新车贴膜,体验了一把什么叫“专业团队的专业服务”。

听老板说这家店刚开张两个月,但是团队并不是新组建的,而是已经在一起配合了很久。这从后来的整个过程,也看得出来。整个过程我几乎一直站在旁边,虽然被冻得够呛,也被老板怀疑我是在监工,说了好几次让我放心,绝对做到令我满意。但我其实是在观察,或者说是在学习,因为我觉得他们同样作为一只专业服务团队,比我们更敏捷,也更精益。

在制品限制(WIP Limited)

汽车美容这种工作,由于存在场地限制,天然就满足精益中的WIP Limited。像我这次来的这家汽车美容店,只有三个工作台,也就形成了最自然的WIP Limited。就算是有再多的活,再多的车需要贴膜装饰,也只能排在外边,整个团队最多也只能工作在三台车上。

这种天然的WIP Limited存在,也限制了大家并行工作的最大车数。那为了获取更大的利润,也就是为更多的车服务。大家的关注点自然而然的就落在如何以最快的速度完成每一台车的贴膜装饰过程,也就是我们常说的单件流和Lead Time。

自组织全功能团队

(自组织全功能团队)

为了尽量缩短每一辆车从开始装饰到完成交车的整个过程,也就是缩短单个车的Lead Time,我观察到整个团队是在以一种几乎完美的方式协同工作。

首先,所有的工作被高度并行化。例如我的车最多的时候有四个人在同时施工,一个人在缝真皮方向盘套,一个负责贴车左侧窗户的膜,一个负责贴车右侧的膜,一个负责贴前后挡风的膜。

其次,大家并没有清晰的角色划分,缝方向盘套的人在完成了手头的工作后,立刻自觉的加入到贴膜的工作之中;而两侧的膜贴完后,两名工人立刻开始帮车打蜡和做内饰清洁;整个过程自然而连贯,完全自组织,不需要人安排和督促。

所有人都掌握了缝方向盘套、贴膜、打蜡、内饰清洗的工作技能,并没有严格的角色分工,很难说清楚谁是贴膜师,谁是打蜡师,他们每个人都像一个专业的全栈工程师。你也很难说清楚整个过程的流程,是先做贴膜,还是先做内饰清洁,整个过程已经被高度优化过,环环相扣,环环相融,无论是时间还是材料的浪费都被降到了最低。

Leader VS Manager

不用担心,这不是发生了意外,而是在做“新车去异味”项目。而这个一头扎进充满烟雾车厢的人就是这家店的老板。是的,他还是我上面提到的四名“工人”之一,分别完成了缝方向盘套,新车除味和右侧的贴膜工作。

在我的眼里,他就是一个称职的Leader。凡事冲在前面,以身作则,勇于承担一些困难甚至危险的工作。而不是坐在舒服温暖的办公室里指点江山。有了这样的老板,这样的Leader,员工们自然也干的格外起劲。而对于作为客户的我,自然也对这样的团队平添了一份信任和钦佩。

质量内建

关注Lead Time并不代表做的越快越好,更不意味着忽略质量,毕竟残次品也是一种常见的浪费。这不,在我的车几乎贴膜完成的时候,工人在做复检过程中发现左后窗户的贴膜有了一个小气泡。

老板在亲自检查、确认无法修复的前提下,二话不说直接将已经贴好的膜撕掉,重新亲自上阵贴了一个新的给我。整个过程迅速而敏捷,还保持了较高的质量和水准。

总结

一个小时之后,我的车焕然一新。

不得不佩服这样一只专业的团队和那个令人钦佩的老板。他们的技术是那样的全面而专业,整个团队的协作是那样的高效而自制。

而回顾整个过程,让我对于自己的团队有了很多反思,对于精益软件开发中的很多概念也有了更深刻的理解和认同。


更多精彩内容,请关注微信公众号:软件乌托邦

Share