人人都是生活的敏捷教练

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

企业竞争力的双引擎:数字化与敏捷

[摘要]

企业的成功既需要数字化也需要敏捷化。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷化是天生一对,不能只选其中一个。数字化、敏捷化如何评估?如何才能更加数字化、敏捷化?

人类的进化进入了一个新阶段。科技已成为我们日常生活中不可缺少的一部分, 大部分人离开科技就无法生活。不仅如此,我们对科技的需求还在日渐增长。你能想象一整天不用Wi-Fi、Facebook、Instagram、谷歌或智能手机吗? 对大多数人来说,这肯定难以忍受吧。 我们需要来自各种网站、应用的即时回应。亚马逊、京东等公司已用“翌日送货”乃至“一小时内送货”(只要送货地址在范围之内)这样的服务宠坏了我们。我们需要吸引眼球、容易使用的界面,想我们所想、专为我们而创造的服务。

现在每一个公司都在寻求数字化转型。图1显示了2017年1月至本文写成期间,谷歌搜索“数字化转型”的趋势。很明显,大家对这个话题的兴趣在上涨。

图 1 谷歌搜索“数字化转型”(英文)的趋势

虽然技术是数字化中必不可少的一部分,但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结:敏捷。要适应客户不断变化的需求,就要保持敏捷。

图2显示了2017年1月至本文写成期间,谷歌搜索“敏捷转型”的趋势。可见,“敏捷转型”和“数字化转型”的搜索趋势都是在2014年开始上升的。

图2 谷歌搜索“敏捷转型”的趋势

数字化转型和敏捷转型有很强的关联。举例来说,亚马逊是数字化企业的领头羊,它本来只是一个电子商务网站,但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东,而是不断投资于创新,创造更好的客户服务。它是为客户而存在的。同时,亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数,以及他著名的“两个披萨”高效团队原则,都是在谈敏捷。

企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说,根本不能只选其中一个。

“数字化”和“敏捷”是动态的、没有终点的比赛

想要数字化转型的企业往往一开始就问什么是“数字化”。虽然对它的定义众说纷纭,但在一些方面存在共识——比如,“数字化是关乎客户的”。数字化的目的是改进客户体验,让他们在达成自己的目标时投入更少。你对客户的服务越好,来找你的客户就越多,这就是真理。

但是,数字化没有一个黄金准则。有一个手机应用,不一定就是数字化公司。其他公司也有他们的数字应用,但并没有因此领先。不过如果你的数字应用很烂,那你就不能算是数字化公司。“数字化”的最低标准是有的,但没有最高标准。

企业和科技都在不断进步,数字化企业的最低标准也在不断提升。不断会有公司打破常规,抬高标准。今日的巨头很可能明日就辉煌不再,如博德斯、柯达等等。企业也是有半衰期的,平均寿命是18年。如果五年来你的公司还在同一个行业,做同样的事情,方法完全不变,就要特别小心了——你需要“颠覆自己”,不然就会被他人颠覆。

沃伦·巴菲特在2015年警告大家小心企业衰退的三要素,告诫波克夏下一任CEO必须与傲慢、官僚主义和自满作战。即使是波克夏这样一家收入超过了新西兰GDP的公司,也要小心谨慎,更不用说其他公司了。对付这致命的“三要素”的方法是公开、透明、激情,这也都是敏捷的基础价值观。

“数字化”(Digital)是个形容词,不是名词。你不能指望数字化有个标准,静态不变。这是一场动态变化的、没有终点的比赛,赛道上有很多竞争者。你需要以竞争对手为基准,来自我衡量。你能做的,只是比他们“更加数字化”。

同理,敏捷也不是个名词,没有最敏捷,只有更敏捷。在这个数字化时代,更数字化、更敏捷的企业才是赢家,也只有赢家才可以生存。

那么,到底是什么需要更数字化、更敏捷?

如果数字化和敏捷的都是形容词,它们形容的名词是什么?这个问题很重要,因为它定义了数字化转型的大框架。在这个框架下,需要找到数字化最少、最不敏捷的地方,让它们更加数字化,更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。

图3 数字化、敏捷化的领域

那么,是什么构成了组织?组织运作的部分都是什么?它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力(见图3)。

渠道——渠道是组织与客户互动的渠道。渠道可以完全是数字化的,也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户,我想与企业中那些了解组织也了解我,同时可以提供优质、迅速服务的人互动;我不想跟不同的人,还有讨厌的聊天机器人不断花时间去解释我的需求;我希望立即得到我想要的服务;我费的力气越少,我的感受就越好;不要让我费劲去想、花时间去等。

职能部门——组织中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户,有些可能在后台做不同的工作,有些可能负责管理与合规等等。不管怎样,他们的工作可以更加数字化、更加敏捷。他们的流程如何?采用什么步骤?可不可以省略或者自动化?有没有其他更简洁的方法达到同样效果?职能部门之间的合作能不能改进?职能部门能不能合并或重组,以精简流向客户的价值流?能不能给职能部门更大的权力去更好地服务客户?

合作伙伴——在全球化的今天,没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系?是一方需要不断与另一方协商、再协商才能达成合作的关系,还是互利共赢的关系?合作伙伴能否很容易地纳入其中?信息可以顺畅地跨组织分享,还是有很多交流摩擦?沟通不畅、合作不佳,相关的职能部门就需要花时间等待,最终损害的是客户体验。

员工——有满意的员工才有满意的顾客。工作环境如何?工作环境是促进学习和分享,还是加剧孤立?员工需要每时每刻坐在桌前,还是可以在任何地方工作?举例来说,工作现在越来越移动化,员工可能不在桌前,而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音,提高员工参与度吧!考虑提供一个能为不同工作需要,提供不同合作空间的数字化职场吧!

技术——这点可能让人惊讶,不过技术管理及操作自身就需要数字化和敏捷。很多时候,信息技术被认为是要花钱的,我们会抱怨为什么一个系统要投入那么多人力,一个改动要花那么长时间。但是,如果我们相信科技是业务成长之源,那就在源头多投资吧:投资工具,也投资相应的人才,使用最新的技术。让你的IT系统成为“持续成长”的系统,而不是“老旧”的、衰退不能用的系统。顺便一提,英语里“老旧”一词是个多义词,它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”,那么,制定更新换代的计划——考虑一下DevOps(开发与运营一体化)模型,或者云端,或者微服务,或者敏捷与持续交付吧。

领导力——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者,而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗?雇员愿意提供信息吗?各层领导都愿意倾听吗?不论个人还是组织本身,都在持续学习吗?牢记沃伦·巴菲特的告诫,时刻警惕:傲慢、官僚主义和自满。

你有多数字化,多敏捷?

如上所述,数字化和敏捷是形容词。它们没有静态的定义,而是相对的概念。没有人能说一家公司满足了一组固定的条件,就是一家数字化公司。因此,不要问“我们是不是数字化”,而要问“跟竞争对手或以前相比,我们的企业数字化程度更高了吗?”。另外,数字化包含很多层面,你的企业可能在一个领域非常数字化,但另一个领域却做得不够。这种情况也不能长久。比如说,渠道十分数字化,但员工和技术的数字化成都非常低,就不明智。对于敏捷,道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。

在这里,我提出了一些衡量数字化和敏捷程度的评估方法,因为这是与时间、与对手赛跑,所以是相对评估。你可以有一些绝对的评估方法,不过即便如此,它们也是在相对场景下才合理。图4展示了这套评估方法。

图4 衡量数字化和敏捷的程度

我想强调这些评估方法只是为引出讨论而提出。当然没有适用于所有组织、所有领域(也就是前面讨论过的渠道、组织单位、合作伙伴等等)的一套标准评估方法。不同的组织和领域,侧重会有不同。因此,我提供的只供参考。

制定一套评估方法的时候,弄清楚你的目标对象非常重要。对渠道,评估对象是客户。一个企业更加数字化(或更加无缝等等),它的转化率就会更高。对职能部门,可以用订单、交货单等等作为评估对象。对员工,评估对象就是员工自己,人才招聘、员工发展才是最重要的。

另外,我的评估没有考虑“方法”,也就是说我并不关心你在使用什么技术。你如何做好顾客工作,达成效果才是最重要的。

这个数字化评估框架,原型是基于电商平台制定的。如果你有一家电商平台,而它比其他电商平台更数字化,我会期望你有更高的客户转化率,更低的客户投入,更高的交付履行速度,更高的推荐精准率,以及更高的客户推荐率。

评估敏捷化程度,我用的是同样的准则。评估的对象主要是变化:对变化的反应有多灵敏,变化后质量有多好,发货速度有多快,团队结构应对变化的速度和效率如何,以及学习速度有多快。

重申一下,我要强调这些评估方法只是为了引出讨论。你需要根据你的组织和领域进行调整。

如何更数字化、更敏捷

渠道,职能部门,外部合作伙伴,员工,科技,还有领导力等领域都可以变得更加数字化、更加敏捷化。虽然每个领域都有细微的差别和独特之处,数字化和敏捷化的方法是相似的,思维也是相似的。我总结了这些不同的方法帮助你变得更加数字化、更加敏捷化(见图五)。这是数字化者和敏捷者的职业工具。

图5 变得更加数字化、更敏捷的方法

先谈谈更加数字化的方法。当然这仅仅是个简介。

首先,利用数据。不要猜测,猜测会带来不必要的风险。你的设计和决策都必须基于相关的、无偏见的数据。设计在线或离线系统时,思考可以获取或收集数据的方法,当然不能侵犯客户隐私。思考在渠道、产品和服务中可以嵌入哪种智能来减少客户投入。

第二,设计思维是研发新产品和新功能时常用的。设计思维是与客户共情,了解需求以及反复改进可行的解决方案,永远追求客户认可。这与传统意义上“我什么都知道”的象牙塔思维的设计是不同的。不断收集数据、信息反馈,设计也持续迭代、改进。

第三,思考你怎样能利用科技民主化。不要限制顾客的操作,相反,向顾客和合作伙伴开放技术,让技术成为顾客的工具箱,顾客可以自行组合工具自助服务,满足需求。这包括开放应用程序接口,公开成果或提供其他自助服务的功能。这就是赋权,给客户赋权。

第四,反思你的价值主张。你还能向客户提供什么?你能更好地在客户和合作伙伴之间建立连接吗?你能重新包装你的产品,或者和合作伙伴的产品重新组合?这就是改变商业模式,它常常需要组织结构的变革。

最后,寻找将你的产品变成平台的机会。利用效应帮助客户放大商业生态系圈。这当然并不容易,需要清晰的价值主张、投资和市场,才能跨越引爆点。需要精心策划,才能保证生态系圈中有一个健康的网络平衡。

踏上数字化之旅,首先你需要变得更敏捷。没有敏捷就不能开始,这就是为什么我们经常看到新企业在做老企业想做却做不到的事情。老企业被官僚主义和自满绊住了。数字化在于改进商业科技的硬件和软件,但是敏捷在于改变员工和领导的心性。

敏捷之路开始于谦虚和勇气,在于承认我们不是什么都知道,而且我们愿意不断学习和适应。学习需要如饥似渴,对现有的所有智慧进行消化。学习也在于不断验证假设和猜想,不断调整,寻找可行的方法。

与敏捷很相似的是精益系统思维。分析整个价值流,去除浪费和瓶颈,或许还要重新设计价值流。精益系统思维常常和设计思维一起使用,但是前者更着重于后台合作,后者更着重于客户触点。

有了科技民主化,权力就会被下放。权力不再集中,相反,决策权会交给前线——创新最多的组织边缘。这对于很多组织来说,需要进行引导和赋权。过去,决策是由几个大人物掌握的,但是现在由很多小人物做决定,为顾客提供更好的服务。

引入颠覆性商业模式,需要改变组织和团队结构。这合乎情理,因为每一个商业模式都有相关联的组织结构。这是现实生活中的康威定律。不过商业模式在变,组织结构也在变。在企业结构方面没有万用灵药。组织结构是动态的,让自治的团队发挥才智满足客户需求,比让你的员工在循规蹈矩恪守工作流程要好得多。

如果数字化平台可以利用客户及其社交群体的网络效应,利用员工的网络效应也是一种创新。提供让不同职位的人合作的机会,这会让你的员工更好地了解公司,也能发掘更好的工作方法。这也能创造更强的归属感,而归属感正是传统企业中缺乏的。

为什么你不够数字化?

最后说一句,苹果公司推出iPhone的时候,诺基亚在研发上花的钱是苹果的九倍。钱和资源并不是关键。除了科技方面投资不善,我怀疑(并无证据)诺基亚当时有潜藏的傲慢、官僚主义和自满。如同每个个人一样,其实就是那句再普通不过的俗语:“骄傲使人落后。”

如果组织中存在某种显而易见的问题,鼓足勇气提出来吧。这个世界不需要假的数字化、纯粹的口舌之劳、或用来装饰门面的数字化。你需要有勇气,坚持,看到问题的核心。问题经常出在人心,也就是为什么敏捷需要先行于数字化,而勇气需要先行于敏捷。

所以,抛弃旧方法,系统地开启数字化的工作,在走向数字化和敏捷的进程中也要运用数字化和敏捷。有了这份勇气,你会得到丰厚回报的。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


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

Share

敏捷团队需要专职QA么?

敏捷QA对职业发展的担忧

最近和组内的QA聊起以后的职业发展,发现一个有意思的事情,有说想转BA的,有说想转开发的,有说想转型作PM的,还有想以后往咨询方向发展的。很少有说想在团队里面继续作QA的。QA这个角色难道就这么没有吸引力么?为什么都想转型或者自己出去单干呢?和组里几个QA聊了之后,发现主要因素在于对QA职业发展的担忧,觉得敏捷团队对专职QA的需求并不大。

记得我刚工作的时候还是有独立测试团队的,那个时候分工很明确,我就负责windows mobile(现在叫windows phone)上应用的自动化测试,我的这个职位叫做SDET,说通俗点就是自动化测试工程师。我们这个团队大概有10人,测试完毕后将结果汇报给测试经理。由于产品复杂,需要大量的测试工程师以保证产品能顺利发布。随着更多功能的加入,测试团队的人数也在增加,这段时间是QA最有价值感的时候,产品的发布最终都由你来把关,你可以根据兴趣来选择以后做一个性能测试或者安全测试工程师等等,有明确的发展路线。

但现在越来越多的公司选择了敏捷转型,适应变化和快速交付可工作的软件成为了团队的关注点。从开发和用户的角度看,他们会很乐意接受这个变化,客户可以不断看到新功能,开发可以把精力从繁琐的文档和流程上释放出来,发挥想象和创意来提供更好的解决方案。可对于QA来说,敏捷带来了什么好处呢?之前定期有一个可测的稳定版本,详细的需求文档就是我们参考的对象。现在要对一个不断变化着的对象来进行验证,也没有一大段时间来设计自动化框架。我们怎么来保证质量呢?

敏捷QA的测试职责

在敏捷的团队中,质量是由团队所有人来保证的,我刚开始听到这句话就像听到敏捷宣言一样,知道这有道理,但具体怎么做呢?如果质量是团队的责任,那么专职的QA干什么呢?

首先我们来看在敏捷团队经常用来保证测试用例达到平衡状态的测试金字塔,简单来说我们可以把更多的测试放在单元和服务级别,因为这些用例更易维护和执行,运行效率也更高,可以参照Martin FowlerTestPyramid

在这个框架下,很容易让人产生这样的误解。

1. 开发负责单元测试,不需要QA参与

跟组里的开发讨论过“是否需要QA参与到审查单元测试覆盖率”的问题,开发通常会觉得用处不大,因为有专门的工具比如:Cobertura, Jacoco, Istanbul等。这些工具的检查范围通常包括

  • 行覆盖率(line coverage):是否每一行都执行了?
  • 函数覆盖率(function coverage):是否每个函数都调用了?
  • 分支覆盖率(branch coverage):是否每个if代码块都执行了?
  • 语句覆盖率(statement coverage):是否每个语句都执行了?

而QA的检查可以弥补单纯的代码级别的覆盖。比如异常处理和边界值的情况,代码级别的覆盖会检查语句是否执行了,但是不能检查这段逻辑是不是写了。下面列举出几种常用的检查方法:

  • 等价类:把程序的输入域(所有可能的输入数据)划分成若干部分,然后从每个部分中选取少数有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中其他值。
  • 边界值:边界值分析法是对等价类划分的补充,它是对输入或输出的边界值进行测试的一种测试方法。我们这里所指的“边界值”是相对于“输入等价类”和“输出等价类”而言的,稍高于其边界或低于其边界的一些特殊情况。
  • 决策表:在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作,判定表很适合于处理这类问题。
  • 因果图:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

有的QA会发现这些通常是用在黑盒测试里的方法,其实把这些覆盖尽可能的在单元或者服务级别来实现是一种既有效率,结果反馈又快,又可以直接作为回归测试的一种很好的途径。

在项目的实践中我们可以看到QA参与到单元测试的审查有以下好处:

  1. QA可以审查单元测试的覆盖率,来调整单元测试以及后续接口测试和回归测试的覆盖率。之前做的项目都是开发独自写单元测试和接口测试,QA也独自写自动化回归测试,后来发现有很多的重复覆盖,这也是种浪费。如果能结对来做单元测试,是种更高效的方式。
  2. QA可以更清楚代码对各个模块的影响,这样可以有针对性的设计回归测试,比如之前项目有个小的改动,QA没能在很短的时间进行回归测试,导致产品发布后遇到了问题。有人会说自动化覆盖所有回归测试不就行了么?理论上是这样的,但现实中有很多限制,只能通过手动验证来完成回归测试。这种情况下,精确定位回归测试的范围变得尤为重要了。
  3. QA对系统构架、开发语言能有一个学习的过程,这有利于自动化回归测试的搭建。

2. 开发更适合设计自动化测试框架和接口测试,因为他们写代码更有效率

如果说自动化测试和接口测试的目的是比谁写代码的效率更高,那么的确这些事情应该由开发去做,但是作为QA,参与其中的作用在于分析需求以及从客户的角度来设计用例。

敏捷团队越来越多的应用行为驱动开发(BDD)来覆盖基于服务和UI的测试。

1、QA会和PO,BA,DEV,UX一起合作,分析软件的需求,然后将这些需求写成用户故事。开发者负责填充这些故事的内容,测试者负责检验这些故事的结果。通常,会使用一个故事的模板来对故事进行描述。

故事的模板:

  • As a 角色
  • I want 特征
  • so that 利益

比如:

As a mobile App user

I want to recharge the Mobile phone number with credit card

so that I can have fee to give a call

2、每一个story有可能会有不同的场景,可以用下面的模板来描述在什么环境下发生了什么事情,结果如何。

  • Given [上下文]
  • And [更多的上下文]
  • When [事件]
  • Then [结果]
  • And

比如:

Scenario: Recharge with Credit card successfully

Given I logged into the Mobile App

When I go to Recharge page

Then I can see the recharge option listed

And I can see the Mobile phone number input box listed

When I input the phone number

And I select the recharge option as “Credit card”

And I input the Credit card number

And I click the Recharge Button

Then I can see the “Recharge successfully” message shows

3、QA会和DEV一起合作来实现这些story的自动化测试,常用的工具:

  • Cucumber (Ruby framework)
  • SpecFlow (.NET framework)
  • Behave (Python framework)
  • JBehave (Java framework)
  • JBehave Web (Java framework with Selenium integration)
  • Lettuce (Python framework)
  • Concordion (Java framework)

3. 开发交互进行基于UI的测试就行了,不需要专门的QA进行测试

如果说基于UI的测试就是执行测试用例,那么的确不需要专职QA来做,但是在敏捷的团队中基于UI的测试大部分是以探索性测试来完成的。怎么设计好的探索性测试用例才是专职QA的价值所在。

有人说探索性测试就是手动测试,有的说是随机测试,有的说就是把自己当用户来使用软件的测试。

什么是探索性测试?下面是wikipedia上面的定义:

Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1984,[1] defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

看完这个解释更迷惑了,探索性测试到底是什么东西?

举个简单的例子,我们聚餐的时候有时候会玩猜数字的游戏,主持会写下一个数字,大家轮流猜,主持会提示大了或者小了。那么下一个人会根据这个提示来继续猜,直到有人猜中这个数字。这其实就是探索测试的原理,每次都会根据之前的结果来设计下次的数字,那个被猜数字就是defect,每一次猜测都是测试用例。如果你想用最少的次数来猜中这个数字,就需要有高效的方法,探索测试也是如此。

敏捷QA存在的价值

以上简单的描述了在敏捷团队中,QA在测试中的职责:

  • 审查单元测试的覆盖率
  • 和开发结对搭建基于服务和UI的测试
  • 探索性测试

其实QA还有很多面向客户的职责,比如需求澄清以及产品演示,会在后续的文章去讨论。

随着敏捷的项目越来越多,对QA的需求不是越来越少,而是越来越高,QA需要像一个好的家庭主妇一样,能里能外,在团队内部能更好的平衡测试设计,在外部能更好的体现产品价值。在一个快速变化的时代,在持续快速交付的情况下保证质量是一件很困难的事情,解决这个问题就是QA存在的价值。


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

Share