技术雷达的安全实践

安全事故

2014年乌云网发布了某旅行网站(以下简称X网站)的安全支付漏洞,X网站因长时间打开支付服务调试接口,导致用户信用卡信息面临泄露风险;在针对其进行进一步的扫描后,乌云发现X网站的分站源代码可打包下载,其数据库配置和支付接口因此被直接泄露。

(图片来自:http://t.cn/Rt7siGq)

在X网站所泄漏的数据中,最引人关注的当属信用卡的CVV码。由于大量国外网站可以直接通过CVV码进行支付验证,用户直接面临盗刷的风险;X网站的行为也公然违反了《银联卡收单机构账户信息安全管理标准》:

各收单机构系统只能存储用于交易清分、差错处理所必需的最基本的账户信息,不得存储银行卡磁道信息、卡片验证码、个人标识代码(PIN)及卡片有效期。

混用测试环境与产品环境、明文记录用户敏感数据、违反相关技术标准、公网暴露数据库密码。X网站的安全事故对很多企业的IT部门都是警示,它提醒我们,随着互联网的发展,软件安全和信息安全不再是安装防火墙所能保障的,它需要企业从软件开发的第一分钟就开始关注安全并积极采取行动,把软件安全内建到研发过程中。

技术雷达的安全概念

技术雷达是ThoughtWorks的定期发表物,它包含了ThoughtWorks对于前沿技术和实践的观察与理解,是软件工程实践的风向标之一,在2016年4月期技术雷达中,与安全相关的技术与实践有13项,占到总数的13%(采用2项,实验5项,评估6项),从软件开发生命周期的角度去观察这十三项安全实践:

  • 分析阶段:1项
  • 开发阶段:8项
  • 测试阶段:2项
  • 运维阶段:2项

通过这个趋势我们可以观察到,软件的安全问题已经不仅仅存在于开发结束后,对于安全的管理已经开始贯穿软件开发的全生命周期,内建安全正在成为一种趋势。

如何理解安全实践

仅仅在项目启动的时候提出安全的要求,在项目结束前做渗透测试和审查,在现有的技术环境中已经不够了,X网站就是很好的反例。那么是不是越安全越好?

(图片来自:http://t.cn/R6Kkcag)

安全措施应该被看作是“必要的浪费”,关键是与商业目标做好平衡,我们认为其中的关键是安全问题从出现在代码/配置里到被发现之间的时间,即MTTD时间(Mean-Time-to-Detect),IT所追求的目标是将MTTD降到一个比较合理的水平, 且达到这一目标的成本是能够被开发团队所接受的。

基于这一理念,我们可以在软件开发流程的各个阶段内,在MTTD目标的牵引下,充分引入各种实践、工具、流程制度等等,不管表现形式是什么, 核心的目标都是在成本的限制下降低MTTD时间,我们看看从需求分析、开发、测试、运维几个阶段的角度入手,有哪些关于安全的工具、实践可以采用。

需求分析阶段

威胁建模,其主要目标是分析系统可能遭受的潜在攻击、识别出风险并制定应对措施。威胁建模提供了一系列技术,可以帮助团队在开发阶段就能够对潜在威胁进行识别和分类,其主要分为三步:

  • 解构应用:庖丁解牛般的解构软件,比如网络、用户数据存储、其它数据、应用层等,分析攻击者可能对哪些信息感兴趣以及他们最可能的侵入方式。
  • 分析风险:对于上述风险,在参考了攻击的可能性、损失和成本因素后,进行优先级排序。
  • 决定对策:对于高优先级的风险在软件开发的不同阶段采取不同的措施进行防范。

当然威胁建模只是安全战略的一部分,当它和其他技术(如建立跨团队的安全专家,采取自动化安全扫描器)结合使用时,威胁建模才可以真正减轻企业面临的安全风险。

开发阶段

Let’s Encrypt,早些年SSL Labs公布的2010年互联网SSL调查报告(PDF)指出超过半数的Web服务器没能正确使用证书,主要的问题有证书不被浏览器信任、证书和域名不匹配、证书过期、证书信任链没有正确配置、使用已知有缺陷的协议和算法等。而且证书过期后的续签和泄漏后的吊销仍需进行繁琐的人工操作。Let’s Encrypt就是为了解决这个痛点而诞生。它基于自动证书管理环境(Automated Certificate Management Environment),至少做到了两件事:免费发放证书自动化更新证书

(图片来自:http://t.cn/R6CoUXB)

Let’s Encrypt由ISRG(Internet Security Research Group,互联网安全研究小组)提供服务并得到了Mozilla、Cisco、Akamai、Electronic Frontier Foundation和Chrome等众多公司和机构的支持。从2015年12月开始,Let’s Encrypt项目从封闭测试阶段转向公开测试阶段,也就是说用户不再需要收到邀请才能使用它了,这促使安全和隐私向前进了一大步。

OWASP Dependency Check,堡垒最容易从内部攻破,现代软件开发少不了用到第三方的库和插件,这些库是否安全呢?OWASP Dependency-check就是一款自动识别Java和.Net项目中所使用的第三方库中是否有已知安全问题的软件,通过第三方插件,它也支持Ruby, Node.js, Python和C/C++。

HSTS,新的HTTP头,可以用于强制要求浏览器与系统之间采取HTTPS通信,目前新版浏览器都支持这一头文件,Internet Explorer从Windows10技术预览版开始支持。

iFrames for sandboxing,HTML5标准的一部分,在<iframe>标签中插入了sandbox属性,开发团队可以建立一种新的开发实践。通过将第三方的组件放到iframe里,并且使用iframe的sandbox属性,只给iframe开放最小的权限,避免第三方的组件访问主页面的信息(比如DOM)。

Content Security Policies,新的HTTP头,CSP的目的是减少跨站脚本攻击。比如通过指定Content-Security-Policy的default-src属性为‘self’,强制要求只能使用本站资源,避免恶意脚本在payload中加入恶意代码,下载和上传信息。CSP需要浏览器的支持。

(图片来自:http://t.cn/R69APfE)

Gitrob,用于检测是否有员工不小心把某些敏感信息放到了Github公开库里。目前Gitrob只支持Github的组织级帐号,并只能扫描最近一次提交。

HashiCorp Vault,微服务架构需要管理大量服务器和各种密钥(秘钥、API key、证书),“如何安全管理这些信息”逐渐成为项目的一大挑战。之前通过文件或者环境变量存储机密信息的方式已经变得难以控制。HashiCorp Vault就是用于解决这一问题的,它可以作为开发的一个最佳实践采用。

Repsheet,一个类似于防火墙的工具,下一代安全防护产品(作为第三方库,在应用的源代码里使用)。可以分析和可视化来自黑客的攻击流量,使之只对正常流量放行。

测试阶段

OWASP Application Security Verification Standard ProjectASVS是一个针对应用程序安全性的检查清单,目前包括了22篇实践,比如《不要在敏捷开发中忘记黑客用户》,官方认为它可以作为:

  • 清单:用于开发人员自查。
  • 原则:作为安全人员和开发人员的桥梁。
  • 采购标准:用于企业采购软件时进行技术打分的标准。

Sleepy Puppy,Netflix出品的一个用于追踪、分析、 管理跨站脚本攻击的工具, 测试人员也可以利用这个工具进行跨站脚本攻击的测试。

运维阶段

Linux security modules,一个框架,可以支持多种不同的安全框架

Deflect,对抗分布式、拒绝服务攻击的服务

2017技术雷达

互联网企业所采用业务模式往往是“以隐私换服务”,这间接促成了庞大的隐私黑产、伤害了个人的权益。2017年的技术雷达也体现了业界在隐私问题上的思考。本期雷达上,身份数据欧洲托管从“评估”进阶为了“尝试”,差分隐私开始进入雷达。

差分隐私,从源头抓起

在2016年的WWDC大会上,苹果宣布自己加入了AI大战,同时宣布了不会走Facebook和谷歌的道路,在对于用户数据的收集上采取了差分隐私技术,简单来说,差分隐私是通过算法对个体用户数据添加噪音,让任何人都不能凭此追踪到具体的某一名用户,但又可以允许机构成批分析数据以获得大规模的整体趋势。其目标是在保护用户身份和数据详情的同时,仍能提炼出一些基本信息用于机器学习。

差分隐私的实施也将影响软件架构,比如(部分)计算将重新回到本地(而非云端),(夜间)批量处理可能成为移动端的最佳实践。

身份数据托管,减少干预

由于互联网企业拥有的数据越来越多,政府也在通过各种渠道渗透互联网公司,试图获取数据的控制权,棱镜门所暴露的政府文件让全球都意识到了这个问题。而欧洲是对于PII数据管控最为严格、立法最为完善的区域。比如:

在这样的监管下,Amazon这样的巨头也不得不推出相关服务,以响应这样的监管措施。

在可行的情况下,尽量考虑通过欧洲的数据中心进行托管是进一步减少干扰、增强隐私的方法。


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

Share

数字消费者与传统行业互联网转型

面对换商经济的冲击,从前几年尝鲜感受电子商务,到最近不得不为之,传统企业正在发生着变化,它们认识到消费者的生活方式已经彻底改变,数字化、智能化和社交化已经成为新常态,这迫使传统企业开始寻求打通线上和线下多渠道的途径。埃森哲2013年中国零售商全渠道零售能力调查显示,63%的传统零售商已开展多渠道零售,78%的单一渠道零售商正计划向多渠道转变。受调查企业中61%已拥有独立官方网,超过半数 (52%)已在第三方平台开设了网店。

数字体验业已成为消费体验不可或缺的重要组成 ,越来越多的企业也意识到了提升数字体验的重要性,从我们的观察来看, 围绕用户体验的提升建设企业分析数据的能力,打通线上和线下的体验是传统行业互联网转型的一大类方向。

用户数字体验,新方向

提到用户数字体验的提升,常见的误区是把用户数字体验简单的看成视觉设计而没有意识到用户数字体验的改进是系统工程,从实施的角度看,它往往被划分为快速启动、体验设计和实施三个阶段。快速启动关注愿景,着力于帮助相关人之间对未来产品的愿景达成一致,然后规划并设计产品最核心的用户体验, 包括完整的信息架构、信息及交互设计。在设计的过程中,往往采用各种原型工具来辅助交流,让相关人减少误解,尽快达成一致。

有信是微信在国内最大的竞争对手,设计团队和相关负责人在快速启动中从企业用户场景和业务模式入手,识别出了“舍不得挂断电话的异地情侣”的场景,从这一点出发,设计团队利用纸质原型、互动原型、低保真原型、高保真原型对需求进行了充分的发掘以及交流,从在相关人之间达成了对业务模式和设计的共识。

Screen+Shot+2014-12-23+a

体验设计关注设计本身。体验设计主要回答三个问题,用户看什么内容? 用户怎么找到这些内容?用户消费内容时的感受如何? 看什么内容是内容策略,设计团队往往需要从业务上下文出发对现有内容进行梳理。“怎么找到这些内容”是产品的信息架构,需要应用交互设计原则对产品的核心交互行为进行系统性的设计,这这个过程中,往往会利用用户的真实行为数据来辅助设计,让整体设计更容易落地。“感受”是视觉设计,即通常意义上的做“漂亮”,设计团队往往结合企业现有品牌和视觉标视对产品进行定位和设计。

实施关注的是验证和演进。产品在使用中往往有很多意想不到的地方,这需要通过真实数据不断验证,对设计进行调整打磨。买房网 是面向中国富人销售澳洲房产的项目, 设计师在初期设计了 澳洲行政区域图 ,用户可以通过点击区域来完成相应的搜索,令人吃惊的是 这一特性 上线后使用度为零。在回访中,设计师发现用户不知道这个图是可以交互,这说明设计过于复杂,需要进行调整。

用户常见的行为是在网上对商品进行比对、挑选、购买,再通过实体店享受产品和服务,数字 体验的改进必须同时考虑线下和线上。诺德斯特龙((Nordstrom)是美国一家高档连锁百货店,它 推出了一个 具有交互功能的显示屏 科技产品,一眼看去就像镜子但镜面可以交互,顾客可以在试穿衣服的同时浏览不同的尺码、颜色、款式甚至是产品评价,就像网购一样,不过优于网购的地方是:顾客可以随时召唤店员把想要购买的衣物拿过来让他们试穿。而不是试完一件衣服后脱下,又换上自己的衣服走回销售区去找挑选。 充分利用传感器和数字技术增强用户在物理世界的体验是线上、线下体验整合的新趋势。

9209426C-6213-4113-9E32-

创新,没有最好,只有更好

创新,则是着眼于尚未满足的体验。尼尔森提出了创新的三步:第一步,找出的尚未得到满足的需求,思考怎样才能实现;第二步,通过一种进化的测试-改进程序,不断地改善这些概念,进而完善依据这些概念而推出的产品;第三步,上市推广。

在实践中,我们发现寻找“尚未满足的需求”有两个关键路径,首先要学会与用户合作创新,Woolworth是澳洲最大的超市,客户对付款时排队久抱怨极大,Woolworth想通过手机应用让用户可以随时扫码付费,提高用户体验。设计团队采取了在超市现场与用户共同研发的方法,在几天内他们就发现这个计划行不通,大量客户不习惯提篮子所以腾不出手来使用设备扫码。同时,团队发现了一个“尚未满足的需求”:帮助客户决定晚餐吃什么? 并最快找齐食材,满足这个需求会大大提升购物体验和销售收入。

Screen+Shot+2014-12-25+a

学会与IT合作创新是另一个关键途径, 当今IT的角色绝不仅仅是支持业务,企业应当建设IT与业务融合的能力。内部创新日是帮助市场与 技术结合形成草根创新的行之有效的方法。 市场和IT部门自由组队围绕某主题进行头脑风暴,产生创新想法;团队2天内利用各种快速开发技术产出产品原型;通过创新市场 共同向市场部门 推销产品,寻找内部投资; 最终实现产品化。澳洲最大的房产门户正是通过这一套方法孵化数十个新产品。

尼尔森所提到的可演进的测试-改进程序是 不断试错、快速小步骤改进产品的能力。这种快速、高效、灵活的向用户交付新功能的原则和技术实践被称为持续交付。通过实现自动化的构建、部署和测试过程,并改进开发人员、测试人员、运维人员之间的协作,交付团队可以在几小时(甚至几分钟)内发布软件变更,从而得以不断收集数据判断软件的功能是否被用户接受,继而作出相应的改进。

围绕企业的核心竞争优势,寻找差异化,利用IT进行创新是我们观察到的另一大类企业互联网转型的方向。

着眼未来

马云和王健林打赌未来电商能不能超过零售的50%,雷军和董明珠以10亿豪赌小米在五年后能否超过格力。随着阿里巴巴的上市和小米的突飞猛进,让人颇有传统行业江河日下的 感觉。但其实风生水起的数字消费不过占了整个零售市场9% ,传统企业还大有潜力可挖。

着眼于中产阶级的消费升级。更更有趣的购物体验将吸引中产阶级回到传统渠道。电影是个很好的例子,在Youku, iQiyi们25元包月看电影的冲击下,中国全年电影票房依然保持着27.51%的高速增长,电影院提供的已经不仅仅是电影本身,而是周末全家出行,从吃到娱乐的全套服务和体验。

着眼于大规模定制化。定制化意味着差异化,从差异化出发, 传统企业可以避开目前数字渠道的劣势,以及充分利用生产的强项。 定制与大规模经常是一对天然的反义词,而最近然声名鹊起的红领西装,就用规模工业生产满足了个性化需求。定制西服往往就意味着手工量体、手工打版、制作毛坯等,一条小型定制生产线一天产量一般在五套左右,而让红领每天可以生产1200套西服。红领充分的利用了企业现有数据和计算机辅助设计大大提高了效率,而用户则被粘在了红领的终端上。在其它企业饱受高库存煎熬时,红领今年以来却实现了生产、销售、利润指标150%以上的同比增长。

着眼于未上网的消费者。在中国还有超过7亿没有使用互联网的消费者,有些是因为年龄的原因难以掌握新技术,有些是因为教育的原因,相比于互联网,传统企业的营销网络可以在不同的区域采取不同的策略,更容易去服务这个群体。

着眼于服务。劳斯莱斯在飞机引擎中安装了上百个传感器,引擎工作过程中任何的微小细节, 如振动, 压力, 温度, 速度等,都会通过卫星传送到进行数据分析的计算机中。通过利用这些数据,劳斯莱斯可以预测引擎的问题,根据航班的安排,可以在飞行目的地机场安排备货及时维修。这样,劳斯莱斯把自己从提供硬件重新定位为提供服务,从而获得更高的利润和粘性。

Share

建设全功能团队——实践篇

上篇文章中我们一起回顾了分工历史,对于技术团队影响以及建设全功能团队的必要性 ,在实践篇中我将详细分享一些实践以及我们团队的经验数据。

吃自己的狗粮

当开发人员坐在测试工作站前,你将会诧异于多少开发人员因为繁琐的步骤而不会安装/升级自己参与制作的软件,多少人认为自己设计的复杂配置是荒唐的。在很多情况下,这都不是安装、配置的问题,而是设计问题,将开发和测试过程分离而把痛苦转嫁给了另一个团体(测试、用服、用户),开发人员丧失了亲身使用软件的机会,进而无法发现问题的存在。暴露并修正这些问题,是将开发人员和测试人员进行轮换的主要价值之一。从我们的经验数据看,开发人员可以在一周内掌握大多数的测试技巧,个人的建议是从经验丰富的开发人员开始轮换,一方面他们更能认识到测试的必要性,便于交流,也便于形成表率。另一方面丰富的经验更容易帮助他们察觉到问题的存在。其它的一些要点是:

  • 一对一的充分交流,让开发人员认识到进行测试工作的价值和目的。
  • 引导开发对痛点进行思考、改进。改变测试简单、重复的工作面貌,要对开发人员形成挑战。
  • 一周轮换2天持续数周或连续轮换2星期为宜。

睁开眼睛看大象

开发人员习惯于正确性驱动,然而正确的返回结果却不一定是必须的,有时甚至是一种浪费。我们项目所需要处理形如1001的期货时间戳,10代表2010年,01代表一月份。开发人员自然想到了如何区分1910年、2010年、2110年的问题。于是复杂的内部表达被设计出来,用于推断正确年份。这是必须的么?如果我们能了解到客户最大的压力在于半年后项目能否成功上线、替换掉现有无人能够维护的应用,而不是100年后才可能出现的问题,我们是否能在类似的技术决策中,做出更聪明的选择呢?帮助开发/测试角色获取更多的信息,让他们了解到制定需求的上下文,而不仅仅是需求是什么;让他们从更高的层面认清各个故事之间的关联,能够分辨可以给客户带来最大价值的任务,这是将开发角色/测试角色与分析角色对换的主要价值。一些要点是:

  • 在进行分析工作前,开发人员需要完成多个模块的开发,而测试人员最好完成开发轮岗,否则收效甚微。
  • 分析工作可以兼职进行,我们认为比较有效的方法是每天下午花40分钟让开发/测试人员在教练的带领有重点的分析一、两个故事。
  • 重点放在提供一套思考框架帮助新手梳理分析思路,我们发现一个有效的方法是结对工作、独立思考、演讲并点评。(参见结对工作,不止与结对一节)

根据我们的经验,两周全程跟踪式的结对分析足够帮助新手初步掌握分析思路,教练可以考虑逐渐减少在新手思考过程中的侵入,再经过大概2个月的练习,新手基本可以独立工作。

和客户对话

在进行过分析角色的轮换后,可以进一步利用需求管理作为主线让团队成员参与到客户交流中,慢慢削弱项目经理的客户联系人角色,其主要价值在于:

  • 提升交流质量,一线人员常常比项目经理更了解产品。
  • 展示开发人员的能力,增强客户信心。
  • 弱化项目经理在客户眼中的重要性,为未来平滑的取代项目管理者,减少开销作准备。
  • 帮助技术人员掌握交流技巧、提升团队能力。

个人建议是:

  • 从例行的功能展示会(showcase)开始,让每个成员练习从客户的角度进行思考(客户想看什么?),锻炼语言能力,消除与客户交流的恐惧感,并且让客户熟悉开发团队的每个成员,习惯开发团队的交流方式。
  • 由多人分别准备客户进行电话会议中需要讨论的议题,每人深入思考的一、两个问题,通过充分思考弥补经验、技巧上的不足。
  • 结对完成发给客户的邮件,让另一双眼睛检查有没有把该说的问题点到,表达方式、方法是否得当。
  • 提供一套与客户交流的思考框架,并在与客户的交流中不断强化它。我们采用的框架是“客户,交付,流程,员工”,团队成员在思考问题时,首先从这四个点出发再逐层展开。

这项练习需要贯穿项目始终,对于团队成员无差别的进行,我们的经验数据是经过5个月左右的练习,项目经理就不需要出现在与客户的例行电话交流中了。

写程序,我行么?

测试人员普遍编程技术能力欠缺,同时有常常对编程这一未知的经验产生恐惧。从经验看,如果测试人员不能编写、维护自动化测试,测试工作将很快成为交付瓶颈。通过编程,让测试人员掌握技术,避免瓶颈的出现是测试到开发角色转换的主要价值。我们所采取的步骤是:

  • 与测试人员结对完成简单的编码任务,不断树立信心。在这个团队中,我们从设计与实现自动测试框架开始,亲手设计的框架让测试人员更有能力来编写、维护测试,同时增强了编程的信心。
  • 在测试人员消除了编程恐惧、具备编程基础后,安排测试人员与开发人员结对进行功能开发。

在这个过程中,必须首先要帮助测试人员正视编写程序的必要性以及消除恐惧,同时针对每天的工作内容留一些家庭作业效果也非常好。必须承认的事实是即便在完成轮换后,测试人员较开发人员还有一定距离,然而我们得到了一个意外的收获:进行过轮换后,再讨论需求时,测试人员越来越熟练的使用开发术语与团队交流,越来越多得参与讨论,甚至主导讨论,她开始直接引用核心组件的设计思想来推导测试用例,不断质疑和挑战开发人员,极大的提升了交流的效率和功能实现的质量。从经验数据看,大致需要3个月的时间测试人员可以达到在辅导下完成功能的程度。

订最后一颗纽扣

前端开发有其独特的知识领域,但这并不意味着任何界面工作都要由前端开发工程师来完成。前后端的分离增加了开发过程中的瓶颈以及人员认知领域中”Unknown Unknown”的区域,降低了找到更优解决方案的可能性。前端开发能力的培养特别适合在全团队中无差别的展开:让后端开发人员进行前端开发可以减少瓶颈,积累知识,构造“T”型知识区。测试人员需要测试界面,所以了解界面是如何工作,可以帮助她们设计出更高质量的用例,对于需求分析人员来说,高保真原型可以用作高效的交流工具。一个有效的方法是全面铺开,引入专家,重点培养,我们所采取的步骤是:

  • 要求全团队在业余时间完成一组界面练习,在全团队普及Html, Css和Javascript知识。
  • 引入界面开发专家重点培养一名有兴趣进行界面开发的团队成员,对系统的界面结对进行改进,优化。
  • 在界面开发专家的带领下,全员重新完成之前的界面练习,专家每天用一个小时讲解对应的前端技术并点评作业。

从全面普及知识到引入界面专家再到培养出新人,总共花费3周时间。值得一提的是,在整个过程中,由于之前团队建设的铺垫,其它成员有能力完全分担工作,团队重点培养的开发人员可以不受任何干扰,全职投入到前端开发中,最大程度的利用了界面开发专家的价值,提升了学习效果。

上同一艘船

项目经理是和技术领袖是作为现场管理者存在的,他们必须能够理解现场,能够通过现场的痕迹找到团队的不足和改进方向。那么,没有什么比卷起袖子参与到一线的工作中更能帮助这些角色理解现场。形成对产品质量和进度的亲身体验。理解现场,有效的管理现场而不是管理数据,是这些角色轮换到开发,测试或者分析工作的主要价值所在。现场管理人员常常有太多的职责,既要对内负责也得对外负责,一个自然而然的问题是:”没有时间投入一线工作“。我认为现场管理人员的工作主要是两个部分:首先是职位责所赋予的管理性事务,譬如状态的汇报,客户的管理等;其次是能力所赋予的工作,作为团队中最有经验的成员,他们需要参与到需求分析、架构设计、决策的制定、培训等活动中。基层管理者应当有意识的主动的卸下身上的工作职责,完成到一线角色的转换,从另一个角度看,这个过程就是整个团队能力提升的过程,个人经验是:

  • 对职位责所赋予的工作,首先做到对团队的状态、开发的进度等尽量的做到自动化、透明化、可视化,让所有人都能获得这些信息,其次通过知识传递,把不涉及敏感内容的工作下放,重点培养一两名团队成员参与管理。
  • 对能力所赋予的工作,一是针对团队急需提升的能力组织培训,二是通过结对工作(参见结对工作,不止于结对)传递知识,提升能力,让团队习惯于自行决策,有意识的逐步弱化自己在团队中的重要程度。

我们的经验数据是大约需要4个星期,新人可以在指导下正确的进行管理实践(正确的做事),这已经可以保证基层管理角色参与一线工作的时间;而让新人具备辨别团队目前需要什么帮助(作正确的事),进一步将原有的管理角色基本弱化为开发角色,则需要6个月左右的引导和练习。

结对工作,不止于结对

我完全认可结对工作在知识传递、提升工作正确性方面的作用。我们几乎结对作所有的事情,某种程度上结对工作成为一种文化,成为了思维惯性和一种必然。长期的结对工作让我发现目前的结对方式对于培养新人还不够友好,这里,新人所指代的是广义的新人概念,不仅仅指毕业生,刚刚从事测试工作的开发达人也算是测试新人。目前结对方式的的缺点在于:

  • 培养了思维惰性,心理上依赖于别人的带领。
  • 无法从失败中学习。有经验的人常常会跳过很多陷阱,新人的工作经历全是各种成功,一旦独立工作就被这些陷阱打的措不及防。
  • 只见树木不见森林。譬如在TDD的过程中,新手可以看到一个个的方法是如何被设计的,如何从测试中被驱动出来,但很难从他的搭档那里学会如何想到要设计这些方法?从下向上驱动还是从上向下,各有什么分别?为什么这个方法要被放在这个类,而不是那个?

我认为结对工作其中一个被忽略的要点在于让新人在可控的状态下经历失败,获取经验,并且在工作中学会思考问题的方式(如何发现问题?从何处着手?怎么在不同的方案中取舍?从哪里开从哪里开始分析?),而不仅仅是思考问题本身(写什么测试?如何让测试通过?)。从我的观察看,培养新人比较有效的途径是从全程结对工作开始,通过对细节的指导让新人了解工作的主要方式和职责,进行必要的知识贮备,学会如何正确的做事。接下来应当让新人逐渐学会什么是正确的事情。我们的做法是:

  1. 新人接到任务后,自行思考。
  2. 在白板上写下完成任务的主要步骤
  3. 向教练讲解主要思路和考虑点,教练通过提问引导他(输入特殊字符会怎样?)
  4. 自行完善方案
  5. 和教练一起确认方案
  6. 教练对整个思考过程进行点评,告诉新人这类问题的思考要点

整个过程大致耗时半个小时,这种方式的优点是新人对方案非常了解,执行起来不容易跑偏;有机会在可控范围内犯错,成长更快; 新人可以通过不断的练习有能力通过多个任务逐渐总结出一套思维方式。教练利用这种方法可以通过代码检视和有选择的结对(譬如针对任务中的难度部分结对)同时帮助多人,更有效率。

结局

在咨询的过程中,我见过太多的团队把目标放在交付上,寄希望于工具、外部力量,期望快速的解决问题,往往对小步前进不够耐心,不关心团队的成员。在我们这个 90%以上成员没有.Net经验,50%是毕业生的团队中,那些微不足道的改进,一点点的提升,最终造就了这个9个月中没有一天加班,几乎没有缺陷,提前交付的项目,客户甚至愿意为他们的满意额外支付3万美金作为奖励。我把全篇总结为一句话:把项目目标放在人员能力提升,让项目成功成为能力提升的副产物。

本文转自:http://www.infoq.com/cn/articles/hk-build-full-function-team-practice

Share

如何建设全功能团队

简介

团队的开发人员撇开需求沉浸在想象中的“完美”程序中;测试人员迷茫的点击着按钮试图搞明白这到底是个什么功能;设计师造出了没有尽头的楼梯,更糟的是,客户爱上了这个设计;团队领导四处救火,力有不逮。种种迹象表明,我们得打破分工带来的壁垒,建设全功能团队——大多数人能完成大多数种类工作的团队。

在一次闲聊中,女友的母亲说起实习大夫必须轮岗一年才会进行分科学习,我质疑道:“对于致力于心脏病治疗的医生来说,他岂不是在不相干的学习上浪费了一年时间么?”,她母亲笑着说:“不这么做,你怎么确信病人的确患有心脏病呢?”。不知道为什么,我眼前突然浮现出这样的场景?测试人员在怯生生的询问:“这是一个缺陷么(而不是操作系统/浏览器的限制)?”。

亚当与大头针工厂

亚当·斯密于1973年在描述大头针工厂的专业化生产时提出了社会分工的好处:提高熟练程度、减少任务切换时的开销、便于机器的应用。我们似乎可以非常自然得推导出重复设计、重复编码、重复测试可以增加相应岗位员工技术熟练度,提升效率,并由此提升企业的盈利能力。

然而市场的不断变化让重复生产的美梦不在,切换任务变得越来越频繁。IT公司不是大头针工厂,知识工作者毕竟有别与体力劳动者,在劳动主体发生变化的过程中有两件事情的差异被放大了:一是局部优化与整体优化的差异,二是正确的做事与做作正确的事情的差异。

有一道数学题,假设每个开发人员每天可以完成一个功能,测试人员每天可以测试2个功能,团队由3名开发人员和1名测试人员组成,那么一周内通过测试的功能最多为多少个?

大多数人的第一反应是5(天)x2(功能/天)=10功能,下面的表格会告诉你,由于负载不均衡,测试人员在周一没有功能可测,团队其实无法在一周内交付10个功能。

周一 周二 周三 周四 周五 总计
开发人员 3功能 3功能 3功能 3功能 3功能 15个功能
测试人员 0功能 2功能 2功能 2功能 2功能 8个功能

(表一) 那么我们改变一下条件,假设团队中有4个开发人员,并且开发人员可以参与测试,结果会怎样呢?

周一 周二 周三 周四 周五 总计
开发人员 4功能 4功能 3功能 2功能 0功能 13个功能
测试人员 0功能 0功能 2功能 4功能 8功能 14个功能

(表二) 我们最终能够交付13点,产量提高了60%, 如果我们只留下三名全能人员:

周一 周二 周三 周四 周五 总计
开发人员 3功能 3功能 3功能 1功能 0功能 10个功能
测试人员 0功能 0功能 0功能 4功能 6功能 10个功能

(表三) 居然比3个开发人员和1个测试的人员组合还多交付两个功能! 我们当然有理由质疑第二题的假设:“开发人员可以胜任测试人员的职位”。又或者继续讨论迭代二的数据变化。

我对此的回答是:

  • 第一,以我的观察来看开发人员之所以不进行测试工作,不是能力不允许,而是主观上认为测试工作是简单、重复而枯燥的,不愿意做。客观上开发人员们比较贵也更难于培养,组织层面不允许这样的“浪费”。 对测试工作的偏见客观上促成了大量不具备技术能力的人选择测试工程师作为职业,而技能不足则一步导致了测试工作倾向于简单重复。测试人员在很大程度上无法判断什么是正确的事情(作正确的事),从而更倾向于熟练的按照脚本进行操作(正确的做事)。
  • 第二,我的关注点不在交付8点还是10点,我希望这个例子能够引发大家对于均衡生产的思考。 软件的需求和实现可以被细化,但它毕竟不是大头针,需求和实现间往往呈现出关联与依赖,换言之,局部效率的增加无法直接转换为整体效率的增加。而整体效率的优化往往依赖于均衡生产(参考表三),即消除生产的波峰(过度生产)和波谷(生产不足),避免任务时松时紧,松时生产力浪费(周一时专职测试人员),临时加班加点,粗制滥造。 我倾向于认为亚当·斯密对劳动分工论述的假设是:需求稳定,简单生产。对于IT领域来讲,这些假设还成立么?

拧螺丝的卓别林

不难发现,对分工以及个体效率的迷信正在深刻的影响着IT领域。分工的端倪在招聘时就已经显现,即便对于差异不大的毕业生们,雇主也会根据其极有限的技能,用不同的标准进行测试(Java, .Net, PHP等),并在入职后将其冠以前端工程师、后端工程师、测试工程师、技术支持工程师等不同的头衔,甚至可能在其可见的职业生涯中专门负责某个文件的维护。

整体效率的优化要求IT团队消除技能壁垒,培养多面手,根据计划的变动,弹性调整任务,达到各角色和流程之间的平衡。对于IT企业来说,变化从招聘时就必须开始。找到拥有学习热情、学习能力、学习习惯的人变成了当务之急,员工是否掌握了某种算法、语言或者工具应当从准入条件降格为对于其学习能力和热情的一种(不是唯一一种)证明。

整体效率的优化要求员工必须持续学习、成长,兴趣无疑是成长的催化剂,然而丧失意义的工作却在不断扼杀人的兴趣。丹·艾瑞里在怪诞行为学里著述到: 劳动者与他自己的生产活动、劳动目标以及生产过程相分离。这就使工作成为非自发性的活动,因此劳动者就无法对劳动产生认同或者领略到劳动的意义,而缺少了意义,专业人员可能觉得自己好像电影《摩登时代》中查理·卓别林扮演的角色,一切都由工厂的齿轮控制,他们根本不会有全心全意工作的愿望 。 如果员工成长是必须的,那么,帮助员工认识到工作的全貌也是必须的。角色轮换是一个很好的解决方案。在项目内部通过角色互换,不限角色的结对工作,加强不同角色、不同模块间的知识传递,打破技术壁垒,帮助员工从不同视角理解项目,锻炼技能,进而增加团队均衡生产的能力。

在我看来,进行角色轮换的最大阻碍在于编程能力的普遍缺乏,大多数的测试、需求分析工作(鉴于大多数团队所处的地位,需求分析师实在言过其实,更精确的名字是需求整理师),迭代管理,简单的客户交流,学习曲线都非常低,任何成员都可以在师傅的带领下迅速掌握工作要点,然而编写程序却是个例外,即便对于基础良好的新人,在经验丰富的导师带领下,也需要2个月左右才可能写出比较体面的单元测试、较为面向对象的程序。在分工的体制下,用别的角色轮换开发人员几乎是个死局。

非常奇怪,IT领域如此的看重抽象能力和逻辑分析能力,可为佐证的是层出不穷的建模语言、模式、领域模型、架构。然而最能训练抽象能力和分析能力的一项活动,却仅仅有选择性的开展,这是不是意味着我们认为IT项目可以在大多数人无法(也没有能力)达成共识的情况下顺利展开并成功交付呢?在我看来,编写程序不仅仅是一项技能,一种思考方式,还承担着构造IT团队成员间共同经验区、提高交流效率的目的。

一个值得从其它行业借鉴的经验是首先展开基础素质培养,再进入领域培养专业素养,换言之,避免过早的分工,所有新人从编程开始职业生涯,在公司的体制层面促成每个新人都能经历力所能及的所有角色。在具有了一定的基本素质后,在员工对工作内容和自身兴趣有了充分的了解后,根据个人意愿进入领域发展专业技能,兴趣将成为员工成长的内在动力,而良好的基本素质将使员工有能力在专业岗位上施展自己的想法。 同时公司应当鼓励员工跨界工作,《应用Selenium和Ruby进行面向领域的Web测试》的作者是拥有卓越能力的开发人员,他曾经进行了相当长时间的测试工作,在其它人抱怨自动化界面测试难于维护时,他优秀的抽象能力、分析能力已经帮他提炼出测试模式,识别出缺陷,找到了优雅高效的工作方式并诞生了这篇优秀的文章。丹·艾瑞所言于我心有戚戚焉。

知行合一

我们曾在团队中进行了建设全功能团队的初步实践,在分享具体实践前,我希望下面的总结性数据能帮助你获得一些背景知识。 项目处理的是期货交易领域,使用的技术栈是C#, ASP.NET MVC。团队主要由八名开发人员以及两名测试人员组成(其中一名测试人员在项目中期加入),其中四位是毕业生,三位具备工作经验,但刚刚加入Thoughtworks,只有一位开发人员具备.Net开发经验。 下面是全部35周的燃尽图,黑色实线代表项目的范围,绿色实线代表开发完成的速度,蓝色实线代表测试完成的速度,每周为一个迭代。 image0 在这张图的大部分区域内,蓝色和绿色是重叠或者非常接近的,这意味着团队每迭代开发完成的功能恰好与测试人员的处理能力对齐。一方面,这归功于测试人员自行实现的自动化测试框架对效率的提升,另一方面,开发人员参与测试也起到了平衡开发和测试速度的作用。 让我们截取开发过程的一部分,观察每个迭代的速度,在下面这样图中,横轴代表第几个迭代,纵轴代表每迭代完成的功能点数。 image1 从项目经理的角度看,团队的交付速度很稳定,从15周开始直到项目的结束,我们都可以放心的使用12点每周的经验数据进行估算、计划工作。事实上团队在后期所处理的工作种类越来越多,包括了正常的开发任务、公式转换、性能调优、验收测试、支持等。在这种情况下,每个人都具备跨角色、跨模块工作的能力,才保证了可持续的交付节奏。 在这篇文章中我们一起回顾了分工历史,对于技术团队影响以及建设全功能团队的必要性 ,在下一篇文章中我将详细分享一些实践以及经验数据。

Share