为什么你的Scrum会失败?(二)

前文说了Scrum三种角色的错误姿势,现在来说一下四个会议。注意是乱序,先看showcase。

Sprint评审会议/Demo/Showcase

如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意、或收集到了反馈等。这都不够,且不说客户满不满意本就不应是评审会议追求的东西,就是收集到了反馈,都不够。

那如何评价评审会议的效果? 唯一的评价标准是, 会后有没有对product backlog做出调整

如果每次showcase完product backlog都没发生变化,那恭喜我们,我们的计划和预见能力很完美,完全可以按瀑布的方式工作,没必要迭代交付了。客户或stakeholder需要了解, 他们对showcase负有给出反馈的责任和义务,找对真正关心产品或项目的人来参加showcase。

但往往团队倾向于show好的一面,直接点就是掩饰问题,这是本末倒置,会后皆大欢喜就是失败的会议,会后没有调整product backlog也是失败的会议。

Sprint计划会议: 实际上应该是分开的两个会

很多团队都会抱怨Sprint计划会议的冗长和低效。抛开开会的技巧不谈,根本原因在于Scrum把两个不同目的,需要不同参会角色的会议融为一体了。在它的官方指南里明确说了计划会议有两个topic: what 和 how。

IPM

对于what,即下个sprint要做什么,某种程度上是不需要开发团队参与的。PO应该根据stakholder的输入,从业务优先级上选出下个sprint的backlog。这个过程可称之为IPM, iteration planning meeting,应该在本sprint开始前进行,也就是推荐在上个sprint的末尾进行,开发团队的参与是可选的,PO完全可以一个人搞定或者跟业务方的stakeholder来商定, 具体如何取决于PO。

  • 你说还没估算呢,PO怎么知道要选多少? PO可以根据之前Sprint完成的story个数,多选几张,比如多出个20%的量。
  • 你说开发团队不参与的话,可能漏掉一些技术依赖项。我们还有下个会呢,开发团队有机会给出反馈。

说到底,估算和技术方面的依赖,不是决定优先级的很重要的因素,仅供优先级参考而已。

IPM结束后,PO手里有了一小堆下个Sprint要做的功能,可能比开发团队正常能完成的量多了一点。这堆功能将作为下个会议的输入,可以微调。

IKM

下个会议称之为IKM, iteration kickoff meeting,在本Sprint开始时进行,主要目的是PO和开发团队对这个Sprint的目标进行交互解释、答疑、达成共识。开发团队对优先级,验收条件的任何疑问都可以提出来,PO来解释或调整任务。对what没有疑问之后可以开始估算,如果你非要估算的话。估的时候就按优先级估,估到累积的工作量达到团队的capacity为止。

IKM的解释,答疑和共识,依然是what,而不是how。对于how,开发团队自组织讨论就可以了,不需要PO参与。开发团队也完全可以在领到任务开始做的那一刹那,由领到任务的一对pair自己讨论how就可以。

总结一下就是 PO自己搞定planning,PO和团队一起kick off,团队自己搞定how。IPM不占开发团队时间,IKM 2个小时足够,其它的讨论分散在开发过程中

每日站会: 关注接力棒, 而不是运动员

站会到最后是最流于形式的会议,没有之一。原因很多,而一个比较普遍的原因是大部分站会关注在了错误的点上,引不起团队成员共鸣。这个错误的点就是关注每个人都干了啥,今天要干啥。站会对于团队成员就成了一项考核,考核你工作量饱不饱满。每个人挖空心思表明自己没闲着,说完自己的就完事,也不管别人的。

那么站会正确的关注点是什么? 进度,障碍,新知,及是否要进行调整。关注接力棒,而不是运动员

每日站会是进度报告会吗? 你可能会说不是。我只能说: 当然是了! 开完会对当前进度是什么样子都不知道,这会也太浪费时间了,甭管是半小时还是仅有10分钟。 (你说我们有其它方式了解进度,站会关注在其它方面,那是另外一回事)

站会首先是进度报告会,区别在于是向谁报告,报告的目的是什么。站会是向整个团队报告进度,目的是寻求帮助,提供新知,为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步,负责Check和提出Action。Check时检查点不在谁闲着谁没闲着,而在于过去这一天有哪些新的信息会影响到任务交付。

评价站会效果的唯一方式是,会后有没有根据会上的信息做出相应调整。不排除不需要调整的情况,但很少。换句话说,如果你站会后没有调整,那你的站会是极有可能没什么效果的。

Sprint回顾会议

没什么可说的。只要回顾会议有效果,其它问题再大都是小问题。当回顾会议没有效果的时候,问题就大了去了。其它问题都可以在技巧层面针对问题本身改进。但回顾会议没效果的话,改进回顾会议本身是没有用的。

评价一项活动,不是看它过程,甚至不是看它结果,要看它对其它事务的影响。站会/回顾/评审会议,都涉及调整。开完会没什么调整, 会就白开了。

Share

为什么你的Scrum会失败?(一)

Scrum失败的原因有很多,很普遍的一个是:忽视其众多前提而仅仅把现在的基层开发组织按照Scrum要求的那三种角色改了一下,就算是上马了。很快Scrum也就像它的音译那样,变成死马了,仅留一身马皮。我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不奏效的。

角色一, PO: PO的任职资格

在我所见过的Scrum团队中, 绝大部分PO是不具备PO的资格的。不是说能力,而是资格。PO从职责上讲拥有Product Backlog,负责决定哪些功能进、哪些功能不进、优先级是什么。换句话说:PO负责产品的方向。Product Owner这个词从字面上也赋予了PO这种职责,但与这种职责相伴的是对应的资格,是必须有资格能够负责产品的方向,你才能负责产品的方向。那么通常都是什么样的人有资格负责产品的方向呢?

  • 如果你是一个定制化开发项目、企业应用,毫无疑问,客户才有资格负责产品的方向
  • 如果你是一个产品项目,面向多个潜在客户,那么你们组织里面谁对产品的成败负首要责任,谁就是PO。

换句话讲, PO通常是资方而不是劳方的人,PO要么是给项目提供资金的人, 要么是他的代言人。通常出钱的人是老板,很忙,在大的组织里不太可能直接出任PO,但他必须把他的职责代理给某个人,而这个人是要对产品的成败负责的,出了事之后他要负主要责任。

如果PO不需要对产品的成败负首要/主要责任,那么他/她关于Backlog的范围和优先级的决定是不可信任的,不是说他/她这个人不可信任,人可能是好人,找你借钱你也愿意借给他/她,但由于他/她不需要负责,他/她的决定是没有权威性的。

在我见过的运行的比较好的Scrum团队中,担任PO的人都满足上面的任职资格,包括客户本人,包括从头到尾负责一个产品很多年的人等。而运行的不好的Scrum团队中,PO通常由原先开发团队中的业务分析师担任,仅具备一定的业务能力,而没有商业上的资格和权威。

角色二, Scrum Master: Scrum Master的悖论

在我所见过的Scrum团队中,绝大部分Scrum Master是没有认识到自己的使命的。Scrum Master的使命就是把自己做没,不是做媒,是做没。

Scrum Master这个角色深深反映了Scrum内在的不一致性。我们只需考虑这么一个问题:如何评价Scrum Master的工作成果? 如何证明一个人是合格的Scrum Master? 你会发现如果Scrum Master做的好, 他会把自己的大部分工作做没,变得越来越轻松。因为Scrum Master按照定义,从根本上来说就是一个教练的角色,教会团队自组织、教育PO、教育开发团队、教育组织里其它Stakeholder。评价教练的唯一标准就是被教授的人不再需要他/她了。

也就是长久来看,Scrum运行的好的话,对Scrum Master的需求会越来越少,这个职位甚至不再需要专职的人了,而这在Scrum的教义中是不推荐的。有的团队Scrum Master是兼职的,平时还有一部分开发的职责,不知道是不是认识到这一点之后未雨绸缪…

然而如果Scrum Master认识不到这一点的话,对团队的破坏将是巨大的。他/她会不由自主的为自己找事做,无形中破坏了团队的自组织。所谓自组织其实很简单,就是不去干预。如果团队在众多内部关于流程/活动/角色/职责等事情上需要Scrum Master的干预,则离自组织还很远。

那为什么球队永远都需要一位教练? 答案很简单,因为球队教练的职责是赢球,而不是教会球员自组织。如果他通过让球员在场上自组织来赢球,那球队确实对他的依赖会减少。

角色三, 开发团队: 开发团队自组织的假象

在我所见过的Scrum团队中,不是自组织,而是没组织。原先的Project Manager/Business Analyst/Developer/Tester的职责随风而去,现在统一称Team Member了。每个人在新的组织方式中无所适从,而Scrum Master经验不足、机械的、一厢情愿的抹平角色的差异,导致工作分配/领取出现众多状况,影响进度。

那么我们来回答一下这个问题:在Scrum的开发团队中, 还有PM/BA/Dev/Tester等分工吗?

答案是, 可以有。

什么,这难道不是在Scrum教义中被明文禁止的吗?

Scrum确实禁止了,但谁让它又开了个”自组织”的口子呢?如果团队自组织起来,开了个讨论会,觉得这个Sprint,谁谁谁,你去负责跟PO接口,搞清楚需求细节;谁谁谁,帮忙把CI环境弄稳定点;谁谁谁,把上个Sprint的功能没来及测的再测一下, 剩下的人都去做开发…这个会开完之后, 团队在这段时间内有了明确的分工甚至角色,只要团队觉得合适,团队觉得这样是在当前约束下完成工作最合适的方法,又有何不可呢?

本文原文来源于>>>>http://liguanglei.name/blogs/2015/05/04/why-your-scrum-failed/?from=timeline&isappinstalled=0

Share

浅薄的欢腾与自欺的流量

本文于2014年8月20日首发于《钛媒体》和《商业价值》,题为《“冰桶挑战”全民娱乐的两大败笔》

273060803370

互联网使一切正在成为可能,泼冰水在一夜之间如约而至;公益行业前所未有地感受到科技大佬们集体狂欢式的热情也在一夜之间成为现实。可是,在我们沾沾自喜于社交网络产品带来的病毒式传播速度, 或是以博取“点击量”享受数字带来的成绩时,速度或数量带来的躁动与欢呼蒙蔽了哪些更重要的信息?当慈善公益遇到科技娱乐时代,如何正确地快乐公益?如果公益行业未来有幸卷入了重构和消费,并如同其他传统行业一般被颠覆,我们是不是应该停下来首先反思那些贪婪、暴富、冒险或是挥霍的病态现象如何在公益行业或者公益事件中停止蔓延?继续聚焦“冰桶挑战”中国行,也希望此文能为任何参与过和跃跃欲试的参与者带来新的思考。

当我们在商业社会初学了讲故事的皮毛,却不知公益更需要引人入胜的故事时,鼓吹营销获得成功的本末倒置的思维又一次在“冰桶挑战赛”上演。公益不需要过度的娱乐、浅薄的关注和喧哗的吵闹,它需要朴素的内心和严肃的思考。

败笔一:善因传播与营销的尴尬错位

中国科技新贵们领衔挑战,目前已有数十位企业界和娱乐界名人先后通过不同的方式积极参与——无论是大佬们赠送粉丝各类产品所使用的传统营销手段,还是挑战时不忘以无下限的笑话“挑战”明星美女湿身脱衣的玩笑,这一切不过再次迎合了中国互联网的主流——低价体验、过度娱乐以及得屌丝者得天下的心态。

反观美国科技巨头们的挑战录影,无论软植了Surface产品的盖茨还是拿斯诺登开点玩笑的贝索斯,无一例外地在传递”冰水“精神中,严肃并真诚地讲述了”ASL”群体的故事、筹款进展以及接受冰桶挑战的驱动原因 ——公益先行,娱乐次之。

娱乐不是问题,豪掷千金甚至拒绝捐赠都有道理,“冰桶挑战赛“的中国变形记的病”毒“也不在于娱乐和土豪,而在于病态和盲从的无趣,人的价值和精神的力量却被稀释在一桶桶冰水中,”冰桶“、”泼水“、”明星“、”美女“、”湿身“成了主角,而原本最重要的善因却成为道具,变得无足轻重;希望狂欢过后,所有人能记住中国罕见病30余种共计1000万人次,其中成骨不全症(即“瓷娃娃”)在中国的10万名患者,记住他们的样子。中国针对罕见病无救助措施,2008年成立得“瓷娃娃罕见病中心”依靠自己的努力在四年间也仅仅救助了80多名患者。

严肃与玩笑的尺度在公益慈善看来是那么的苛刻?——是的,没错!肤浅的关注、过度娱乐的心态玩公益得到释放的只有大众扭曲公益的心理,“湿身”大佬们不过低价做了一次娱乐明星,圈子自high,看客玩闹。

败笔二: ”钱“和”冰水“掩饰了瓷娃娃的真实

截稿为止,瓷娃娃罕见病关爱中心在三天狂欢中共计收到106万捐赠(其中包括100万王思聪的个人一次性捐赠,以及小米公司董事长雷军的1万元捐赠等)。ASD组织通过一次“ALS冰桶挑战”筹款活动即获得了超过组织去年募款总额四倍的成功,在广泛赢得社会关注之时筹款活动大获成功,那么“冰水挑战赛”的中国行在捐赠数量无疑又是一次败笔。

所以有人疑惑了,王思聪替1万位粉丝一次性买单,雷军不但泼了冰水还捐了价值几部小米手机的善款,

难道还不够表率作用?名人们泼水也好,娱乐也罢,起码“瓷娃娃”当作一个流行词被无数粉丝记住,但是这种强烈对比的背后问题出在哪里?

阿里巴巴员工海外遭遇车祸,一夜之间便筹满200万元善款——这是众少成多,积小致钜的力量;冰桶挑战赛在美国致使一夜之间获得百万筹款,恐怕也是遵守了“100美金”的约定和那激发出无数人心底的柔软。百万捐赠起步或是一万起价的娱乐游戏,有多少粉丝可以平起平坐?除了泼冰水,屌丝们就只剩下围观的待遇。更何况,如果只关注捐赠数额,而忽视资金能否最佳使用、如何使用等问题,我们也不会得出“捐钱令穷人生活更加悲凉”的结论。

真正的领导者或是成功者,如何激励粉丝、客户或是小额捐赠人的支付行为?如何鼓励其全心投入共同的舞台应对挑战?原因很简单——别人买单并不是因为你做了什么,而是为什么做?如果用全心投入做产品的心态”玩“公益,而不是把公益成为”植入“而非”自知“品,也不会上演泼水登头条,瓷娃娃成为附庸的闹剧。

如果你仍未被说服,我们再来估算一些数字。若以一般水桶10升水的容积以及北京目前自来水单价5元/立方计算,一桶不加冰的水价格约为0.05元,若不产生任何浪费,106万的捐助额可以消化2100万桶水,而并未包含公益机构以及活动组织方投入的人力等成本。虽然未能准确统计因此次活动产生的用水量,如果用微博重本话题“5亿”次阅读量和“56万“ 条评论的数字做不合理假设,恐怕用水量的支出已完胜捐款总额。

社会投资与商业投资有一个共通处则是产生财务回报,暂且不将截止到目前的社会影响分析,仅从目前账面看,我们这个本应具有公益使命的“冰桶挑战赛”实则演变成为一次全民泼水大联欢和一次流于追求流量的表层“成功”传播案例。

一次本应娱乐与严肃参半的筹款公益活动俨然成为娱乐公益的真人版大片实属令人无奈。我们不妨引用科特勒在其所著的《营销革命3.0》中描述的——”3.0营销时代应用更为全面的眼光看待顾客,把他们视为具有多维性,受价值驱动的人群,甚至是企业潜在的合作者。” 言外之意,技术是手段,内容是根本,价值是关键。当今企业的正确的做法是必须开发出能够激发和反映消费者价值观的产品、服务和公司文化。技术与商业生态的背后是“人”,为用户提供便捷、有价值、甚至极富教育意义的成功产品才是现代成功之道——其最终落脚点是通过输送价值观令科技带来人类的变革。

莫非公益不是落脚点在“人”和“人的内心”?企业家的爱心传递难道只是“水桶”和“5元钱”的传播而不是公益组织的价值观传播?一边是瓷娃娃,另一边是粉丝(更为广泛的捐赠者),又曾有哪些人从他们的角度思考过如何赢取此次筹款的成功?

重“量”不重“质的传播是虚无的,只有“钱”没有“心”的打动是失败的善因营销,用独具一格的表演来掩饰内心的空虚更是毫无生命力可言。当深知庸众的麻木可悲,思辨、挑剔或批判才能翻新土壤,中国公益本来就是缺乏信念的认同、价值观的一致,却从来不乏成功的投机者。

Share

在约束与机会中权衡

在我看来,经济学应该是当代人人都应该掌握的基础知识,现推荐一本《斯坦福极简经济学:如何果断地权衡利益得失》,比之前那本《经济学的思维方式》更容易入门。

经济学的三个基本问题是:

1. 社会应该生产什么?
2. 应该如何生产?
3. 谁来消费所生产的东西?

比较有启发性的内容包括:

做自己最适合的事,就有更好的生产力:在经济学教科书里,我们称之为比较优势。前段时间和几个创业的朋友聚会,发现创业起步者,尤其是靠项目盈利者,有一个最大的误区就在于复制客户或上游链条企业的模式,不少行业级的大企业也正在步入同样的误区:比如设备商做运营商的事,运营商做电商的事,电商做社交的事——这本质上都变成了服务商涉足自己客户的领域,同时又要求客户买单。

这也可以理解为,中国社会依然没有很好地理解分工合作,依然没有从农业经济模式到商业经济模式发展上进行思维的转变。

在任何情况下都必须有所取舍:公平只是一个相对的词汇,企业会说,如果有更高的产品价格,他们有办法扩大生产,创造更多的就业机会;而消费者会说,他们的收入已经无法负担当下的产品价格了。管制,包括价格管制和最低工资限制,都会掩盖成本,但以最低工资为例,如果在此标准下,企业会不愿意雇佣一批技能非常低下的工人,造成了这批人的失业,但却有90%的工人因最低工资标准而在收入上受益,那政策倾向后者就是一个相对公平的取舍。

人一生积累财富的关键是什么?发现周围许多上了30岁的朋友依然处于“储蓄—消费”偏好的阶段,非常缺乏投资的眼光。记得刚毕业时身边的“高帅富”同学已经在投资土地(而非房市)了,现在更发现越早有投资经验,就越容易真正扩大财富。

在财富积累这个层面,关键是懂得利用复利——如果储蓄是为了大额消费,无疑是损失了更高的利益收入。在投资上,无论是个人投资、企业投资,投资人的风险承担能力是最关键的因素;另外一点是自己能用多少时间来投资。

主张绝对的零污染是不可能的:几十年来,高速发展中的国家如中国,环境问题非常敏感。在经济学中我们称之为“外部性”(Externality),指在直接的买家与卖家之外,有第三方直接受到这笔交易的影响。

外部性可能是正面或负面的。例如:你的邻居正在举办宴会,找来一个很吵的乐团,邻居快乐地享受音乐,乐团也开心地表演。至于你,身为局外人,可能会有两种反应:如果你喜欢这种音乐,那很棒,你可以享受一场免费的音乐会;如果不喜欢,那就不妙了,你只好忍受(或是报警)。无论是哪种情况,你的邻居和乐团之间的交易,都没有考虑到你。

染污是负外部性(Negative externality)最重要的例子。在不受约束的市场交易中,厂商只注意生产商品的私人成本,至于社会成本,是不用支付的生产成本,因此厂商不会将其纳入考虑范围。如果倒垃圾不必花一毛钱,厂商可能会制造很多垃圾;但如果必须付钱处理垃圾,那厂商自然会想办法减少垃圾。

不过问题来了,这个社会成本也好,额外增加的处理成本也好,最终都会转嫁到消费者头上。当我们享受着便宜的工业制品时,却没有考虑到,它的便宜是建立在某些方面未支付成本上面而已——比如说靠破坏不发达地区地理环境为代价的便宜的水电,比如说靠制造空气与水高污染的廉价合成化工用品塑料,等等。

什么样的收入不均程度算合理?这依然是一个可能被“公平”掩盖的问题,许多人关注公平,但人的背景、智力、知识与努力程度,本身就不是不公平的;大多数情况下,收入是被个人的产出结果衡量的。所以更好的问题是:目前的收入不均的程度是否合理?

另一个非常容易被“公平”掩盖的问题是流动性。收入分配只是一个静态分析,它告诉你在某个时间点,人们处于某个收入水平,但并未告诉你他们的发展趋势:向上、向下或是稳定发展。对收入分配的持续动态追踪,被目前大部分政府忽略了,但我们可以通过一些事例,观察到中国大部分上代务农的低收入人群的子女,都在向城市准中产阶层转变。比如说,有篇文章叫做《我奋斗了18年,终于和你一起坐在星巴克喝咖啡》,现在又有新一篇文章叫做《我奋斗了18年,不是为了和你一起坐在星巴克喝咖啡》……

穷国可能追赶上富国吗?这是一个开放式问题,但可以肯定的是,穷国的高速增长离不开低成本获得富国现有的技术与发明。关键点在于富国是否能继续保持在技术和效率上的领先,穷国是否能降低技术升级对富国的依赖。

政府的钱怎么花?对政府的财政政策来说,具有自发性或权衡性两种。

权衡性财政政策的第三个困难,在于政治的本质。自从经济大萧条和凯恩斯的著作问世以来,很多经济政策制定者都要求政府制定反经济周期的财政政策,亦即在经济差时花钱,在经济好时节俭。但政治上很难这么做,为什么?想象经济飞快增长的情况,税金像洪水般涌入,经济学家说:“不要花掉这些钱!要累积非常大的盈余,削减支出并提高税收。”这是一个很好的反经济周期政策,但它在政治上不容易获得认同。当经济萎缩且资金吃紧时,经济学家说:“这是大肆挥霍的良机,我们知道收不到税金了,管它呢,花吧!”但很多公民和政治人物会说,如果人们都在不景气时勒紧裤带过日子,那么政府也应该这么做。在经济好时节制政府支出,经济差时扩大支出,这种敏锐的洞察力不是一般政治人物能有的智慧。

其实权衡性措施在过去的农业经济中不难看到:丰收年,地主或政府管理者会存储大量粮食在粮仓,在欠收的年份,使用粮仓中的粮食向受到损失的地区发放救助。而货币的需求供给弹性却远远高于粮食,这也是权衡性政策难以操作的原因。

未来全球经济面临的危险:能源短缺和环境危机。在上面提到,工业化生产其实是以能源高消耗和忽略环境成本为代价的,一旦能源和环境的阈值达到,当前经济的长期增长就会面临危机。

现在越发认识到,人类社会最主要的矛盾就在于内部的竞争。当一部分人的技术发展起来时,他们需要竞争获取其它人的市场来使自己获得更大的利益;当市场竞争结束后,原本落后地区的人在成本上和原产地竞争;大量生产技术的转移,又会引发新一轮的技术发展竞争。人类的智力、知识、工具甚至语言的多样性,都远远超越了造物主在自然创造的复杂度,自然的简单性与漫长的修复周期,又反过来制约着人类的欲望与想象力。

经济学告诉你的,就是在约束与机会中果断地权衡自我的利益得失。

本文原文:http://www.justinablog.com/archives/1671

Share

DevOps中文名: 开发自运维

谜面

在实践和推广 DevOps 的过程中, 当对着客户吐出 DevOps 这个词之后, 收获的往往不是大腿一拍热泪盈眶, 而是一脸困惑欲言又止想问又没问的场景. 在一番解释后, 到团队中落地的时候, 往往又单独拉几个人出来, 划了个圈说这是一个 DevOps Team. 这类做法背离 DevOps 的初衷. 背后的原因很多, 但一个浅显却影响深远的原因往往被忽略, 就是 DevOps 这个名字本身.

DevOps 目前并没有中文翻译, 对于中国人来讲, 即使直觉的望文生义也无法产生. 当几番了解知道是” Development” 和” Operations” 的拼接之后, 对应的中文是”开发运维”, 依然一头雾水不明所以. 而由于” 开发”和”运维”目前是常见的两种角色, 两个团队, 而 DevOps 需要新的技能和工具, 因此把 DevOps 作为一种新的角色, 成立一个新的团队, 就自然而然了.

开发自运维

语言的边界就是思想的边界. 一个精确表达概念的词汇将阻止误解的产生. TDD 也好, Pair Programming也好, 虽然实践本身争议不断, 但其含义却少有误解. DevOps 对于英语母语的人来说或许精确表达了它的意思, 但对于中国的开发团队来说, 带来的只有困惑.

开发自运维” 是我推荐的 DevOps 中文翻译. 它依然没有反映全部的含义, 甚至暗示着不再需要运维团队, 但它至少从字面上就阻止一件事: 成立专门的 DevOps 团队. 想想吧, 把几个人弄出来, 说你们是”开发自运维”团队, 这从语义上就说不通啊. “开发自运维”从字面上就意味着运维是开发团队内置的责任, 这也符合 DevOps 运动的初衷.

历史即未来

在高度不确定性的产品创新中, 对市场的响应速度越来越快, 开发自运维是一个趋势, 可以缩短交付时间和对反馈的修复时间. 这种趋势的前一波浪潮, 则是”开发自测试”/“开发自设计“, 而下一波运动则极有可能是”设计自开发”.

”开发自测试”已经接近成功而即将成为过去式, 可最初也曾经面对”开发”和”测试”天然是两个团队这种概念而阻力重重. 并没有一个像 DevTest 这样的运动来指导开发和测试的融合, 而是敏捷推行的”全功能团队”帮了忙. 而最终的结果是并不会取消测试这种活动, 甚至依然有专职的测试人员, 但相当一部分测试活动被”开发人员自测”涵盖了. 对照历史, 我们有理由相信, “开发自运维”并不会取消运维这种活动, 甚至依然会有专门的运维人员, 但相当一部分运维工作, 将被”开发自运维”涵盖.

“开发自设计”几乎从未引起过困惑和质疑. 事实上无论是 PC 时代还是 Mobile 时代, 大量软件都是个人能力的结晶. 这里面的制约因素是开发能力而非设计能力. 即使对企业应用开发, 架构师, 交互设计师等也都算作开发团队成员.

而”设计自开发”则已初露端倪. “心声”是一款帮助听障患者与他人沟通的 iOS App, 由 ThoughtWorks 设计师朱晨独自设计并开发. 随着对市场响应速度的追求, 对不确定性快速验证的追求, 设计师们发起了”Lean UX” 等工作方式, 而对开发工具的掌握, 将极大提高其产品设计和验证效率. 开发工具及平台朝着简单易用的方向发展, 也会助设计师们一臂之力.

Share