2015.5 技术雷达 | 语言和框架篇

2015-5 语言&框架

自从我们上一次在技术雷达中提到 Nancy (nancyfx.org) 之后,它已然成为了我们在项目上的默认选择。围绕着小而垂直切片的架构和微服务需要的仅仅是这样轻量级的部署选项和不拘小节的工具。

前端 Javascript 框架持续喷井所带来的一个好处是,时不时一个新的主意出现的时候,会引起我们的思考。React.js 是一个 UI/View 框架,在这个框架中,Javascript 函数在一个响应式的数据流中生成 HTML。我们已经见到几个小的项目成功的使用了 React.js,开发人员也被其干净的易组合的组件化方式所吸引。

Spring Boot (projects.spring.io/spring-boot) 能够让独立的基于 Spring 的应用。它非常适合启动新的微服务并且易于部署。它也通过更少的样板代码从而降低了数据访问Hibernate 映射所带来的痛苦。Spring Boot 简化了基于 Spring 的 Java 服务,这是我们所喜欢的,然而同时,我们也学会了一定要对很多依赖保持谨慎。毕竟,潜伏在表面之下的依然是 Spring。

虽然并不是所有的体验都是正面的,AngularJS 依然在 ThoughtWorks 的项目中被广泛的使用着。我们依然建议团队评估单页 Javascript 应用所带来的额外复杂度对于满足需求而言,是不是真的有必要。我们也推荐评估一些其他类似的框架,在这一版的雷达中我们提出 Ember.js,它在 ThoughtWorks 内部也逐渐变得流行。Ember 被人称道的是,它对于惯例胜于配置非常固执己见,并且有着响应迅速的核心开发团队,其性能不错并且有一套基于 ember-cli 的构建工具。

在众多 JavaScript 框架中,我们要强调 Flight.js(flightjs.github.io),Flight 是个用于构建组件的轻量级框架。它没有通过太多“神奇”的东西来为 DOM 节点添加行为。它的事件驱动和基于组件的特点,促使开发人员写出低耦合的代码。这也使得测试单个组件相对容易。然而,当组件需要彼此交互的时候还是需要格外注意。Flight.js 对测试的支持很少,并且容易卷入事件漩涡。 继承与组合,我们喜欢组合,与之类似,我们非常喜欢 Flight.js 用混入的方式处理行为。

经过一些我们在真实世界中的经验,Swift(developer.apple.com/swift)仍然表现出非常好的前景。有些问题,如过长的编译时间,已经得到了解决。然而,持续的语言的变化会导致额外的开发工作,并使得构建你自己老版本的软件非常繁琐。测试和重构也依然痛苦。总之,虽然如此,在为苹果生态圈开发新项目的时候你还是应该考虑使用 Swift。

 

点击这里可以下载最新中文版本PDF

Share

You are not your job

agile-standup

受到光磊的系列文章——《Scrum:死马?》的启发,我也来谈谈Scrum中的元素之一——站会。


还记得经典Scrum站会上我们要问的三个问题吗?

  • 我昨天做了什么?
  • 我今天打算做什么?
  • 我遇到了什么障碍?

在初次接触Scrum的团队中,一般都会让团队成员去遵守“Scrum教义”中的做法,其中就包括了在站会上依次回答这三个问题。
一般我们会看到这样的情景:
张三说:我昨天把这个故事的代码写完了,今天打算自测一下,没遇到什么障碍。
李四说:我昨天被叫走解决某个紧急故障了,今天打算继续这个故事,遇到的障碍就是最近打断比较多。
……

如此往复,基本上几周之后,站会就变成一个人兴趣索然地说,其他人目光游离地听;不低头玩手机都已经算是给面子的了。

德鲁克在《卓有成效的管理者》中曾经写到过:

“在组织的内部,不会有成果出现,一切成果都存在于组织之外。举例来说,企业机构的成果,是通过顾客产生的,企业付出的成本和努力,必须通过顾客购买其产品或服务,才能转变为收入和利润。”

“在组织内部所发生的,只有人工和成本。”

这个说法不论在组织的任何层级都是奏效的:从企业的角度,只有不断创造价值去缩小人类理想和现实之间的鸿沟的公司才能做到基业长青;从团队的角度,只有持续对组织有所贡献的团队才算是高绩效团队。

同样,作为个体,只有你的劳动真正被别人承认并消费,你所做的事情才算得上是卓有成效。

只不过在历史上作为体力劳动者,员工的劳动基本上等同于创造的价值,因为他们创造的是有形的产品,不论是搬的砖、制造的零件还是放牧的羊群。而在今天作为知识工作者的代表,IT项目和从业者产出的都是无形的知识、创意或者信息,而这些无形的东西在被别人消费或者影响到别人之前,都不能产生任何价值。

所以我们回头检视一下刚才提到的三个问题,是不是能够从这个角度来提升一下我们站会的效率呢?我们能不能从外部的影响来重新考虑如何回答这三个问题呢?

  • 我昨天做的事情,对我们的项目产生了什么样的影响?今天谁可以来消费我昨天的工作成果?
  • 我今天打算做的事情,可能会使用谁的知识或者信息?
  • 我遇到的障碍会不会是我们项目中潜在的一个风险?

作为知识工作者,不光考虑自己所做的事情本身,多去考虑自己做的事情对于自己的伙伴、团队所造成的影响,就走上了“卓有成效”之路。

Share

为什么你的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