ThoughtWorks读书雷达方法学篇-张逸

标签: 转载文章 | 发表时间:2013-08-31 22:15 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
原文: http://agiledon.github.io/blog/2013/08/06/methodologies-of-reading-radar/

方法学(Methodology)看似与开发技能无关,常为程序员忽略。忽略意味着未曾察觉,却不等于它的无关紧要。我们每时每刻呼吸的空气同样会被我们忽略,但空气不重要么?不要等到我们开始戴上口罩,每日关心PM 2.5指数时,方才察觉原来空气的质量已经积重难返了。在我们的读书雷达中,方法学象限囊括的书籍多与开发过程相关。如果说开发技能是程序员修炼过程中必须加强的显式的力,则开发过程的这些思想与实践,就是隐藏的推手。你若不动,它会推你前行,然而缓慢;若你后退,则推动的阻力就大,暗流汹涌。只有自愿向前,这种助力才能如鱼得水,使你能够优游地前行。

软件开发说通了,不是技术问题,而是人的问题。

由于我们所处的领域,敏捷方法才是我们的擅长,因而在这个象限中,我们推荐的书籍主要与敏捷相关。首先推荐的是一本祖师级的经典大作,Kent Beck的Extreme Programming Explained《解析极限编程》。一切关于极限编程的思想、原则与实践,都能追本溯源到本书,寻找到这些内容的出处。如果你从未曾了解或接触过XP,通过本书,可以给你最正确的引导;若你已经在项目中运用了XP,却又心存疑虑,阅读本书一定能为你答疑解惑。

相较于《解析极限编程》更偏重理论,Henrik Kniberg的著作Scrum and XP from the Trenches《硝烟中的Scrum和XP》会带给你不同的感受。我们喜欢它的短小,简单,实用,书的气质分外地符合敏捷的精神。该书是Henrik Kniberg真实项目经验的提炼,讲述了成功敏捷团队的工作过程,没有理论、没有引用、没有脚注、没有废话。它可以作为基础实践的入门指南,帮助团队正确实施Scrum与XP——但不能模仿。你需要了解自己所处的环境,进而对具体实践做出取舍,创造出属于自己的过程。

如今,精益思想已经被许多不同的行业所广泛采用,该思想在软件行业的影响尤为显著。现代化的软件开发思想和实践方法,早就开始从精益思想里学习和借鉴,包括迭代开发,质量内建,一人多技,一岗多能,全功能团队,看板管理,持续改善等等。精益思想背后的想法可以追溯到上个世纪40年代后期,丰田公司的一群工程师发现了在连续流动中进行少量生产的方法,这种方法可以像传统的大量生产者批量生产大量产品的方法一样有效率。对于初次接触精益思想的读者来说,这种”少量生产和批量生产一样有效率”的思想,未免有些反直觉和难以理解,因为我们从小接触到的观念就是”只有大批量生产才是有效率的“。Freddy Balle等人的著作The Golden Mine《金矿》就是为初次接触精益思想的读者准备的。本书采用小说的形式,描述了一家濒临破产的企业如何采用精益的方式,扭亏为盈,让人读起来非常轻松有趣。

在我们推荐的初学读物中,基本上覆盖了XP、Scrum与精益等主流的敏捷软件开发方法与思想。但是,我们还单独挑出了Mike Cohn的著作User Stories Applied《用户故事与敏捷方法》。因为—— 需求的重要性无论怎么强调都不为过,只有真正理解了用户需求,才能谈得上软件开发的成功。软件的需求说明不一定要是冷冰冰的,也未必需要庞大复杂的方法理论。用户故事对需求的描述更为柔和,预留了讨论和想象的空间,又能借助此作为项目评估的依据,需求分析和确认的基础。本书是描述用户故事的经典之作,几乎涵盖了编写用户故事的方方面面,同时又结合了敏捷开发思想的精髓,以加深你对敏捷开发的理解。

若要更上一层楼,我们还需要进一步了解更多的实践方法,当然,也包括理论的升华。许多方法大都源于实践,然而若无更高抽象层次的思想体系,则方法仅能作用于一事一物,场景一变,就只能偃息旗鼓了。正如你看一花的开放与衰败,并不能知春来与秋逝;只有把握内在的自然运行规律,四季的变换才可以被知悉。因而就精益思想而言,我想,阅读《金矿》不过是让你有了登堂入室的资格,若要走得更深,吃得更透, 更好的阅读选择还是James P. Womack等人的经典之作Lean Thinking《精益思想》。该书阐述了精益思想的五大基本原则,并阐明了一些用于所有行业,并能创造永久价值的简单而有效之原理。同时,为了更好地说明这些原理,并阐释该如何应用它们,给出了大量包括应用步骤和从大企业到小企业的应用实例。本书的视角非常的高远,它将精益思想传播到了产品生产的整个价值流,关注于精益企业的打造。这种精益思想的全局观,可以让我们跳出软件行业的狭窄领域,观察更加广阔的天地。

Paul Duvall等人的Continuous Integration《持续集成》和Jez Humble的《持续交付》,加上Martin Fowler的Continuous Integration,可以看做是软件构建的三部曲。你以为持续集成亦然达到了目标,可是距离交付又还差了最后一公里。然而,没有持续集成,所谓持续交付又成了一句空话。便宜的阅读方法是快速浏览Martin Fowler的这篇文章后,直接步入Jez Humble建造的持续交付殿堂。这个殿堂没有售票员拦着你查看你手持的行程票;但是,在跨入这扇门之前,先去敲开Paul那扇门,会让你的步伐走得更坦然。持续集成和持续交付到底有多重要?在我连续经历了具有持续集成与持续交付能力的项目后,要让我再回到以前的项目开发状态,我会以为自己被遣送到软件宇宙的太初,一片混沌。

我们的读书雷达面向程序员,可是我们仍然毫不犹豫地推荐了诸多与测试相关的著作。这一认识完全符合精益的“一人多技”原则。团队成员一起战斗,程序员对测试说:“我把后背交给你!”然后,义无反顾地冲上前去战斗。可你冲得越猛越快越发的犀利,后背的测试就越撑不住。换言之,你理解为你支撑后背的测试人员吗?当团队需要你的测试技能时,你能挺身而出吗? 阅读Lisa Crispin的Agile Testing《敏捷软件测试》,可以让你切换到测试视角,观察我们该如何在敏捷项目中执行测试行为以保障软件的质量。作者在测试领域浸淫了丰富的项目经验,因而能够完整全面地勾勒出敏捷测试的全景,且又能深入到测试的细节,可谓敏捷测试的集大成者。因此,Robert Martin推荐本书,认为它“实用、智慧、反对教条。本书意义重大,每一位软件专业人员都应该阅读”。

James A. Whittaker等撰写的著作How Google Tests Software揭秘了作为本世纪最成功的软件企业之一的Google,是如何应对和处理软件测试的复杂性的。Google通过对自身软件特征的定位,自我演化出一种非同寻常的测试文化。这种特立独行并非刻意为之,而是从工程实用性的角度量体裁衣。Google的测试开发工程师(SET)角色正是这种工程实用文化的凸显。Google的高级工程总监Patrick Copeland认为:“最好的办法是让测试人员有能力把测试作为产品的真实的功能写到代码库里,测试作为产品的一个功能应该和真实用户可以看到的其他功能一模一样。”这种测试工程文化未必能够照搬照学,但其中内涵的一些测试策略与原则,仍旧值得我们学习和借鉴。

如果是在5年或者8年之前,我们推荐阅读Matt Stephens与Doug Rosenberg的著作Extreme Programming Refactored《重构极限编程》,是希望读者能够冷静地思考极限编程,不为各种吹捧而着迷。然而,时至今日,那种膨胀以及夸大地吹捧已经烟消云散,使得我们多数人已经能够正确地对待敏捷方法,对待极限编程。那么,为何我们还要推荐本书?这是因为,我们希望转动一下极限编程的水晶球,观察它不同的棱面,即便是面对暮色折射出的幽暗光芒,同样有其诱人之处。反面地或者说批判地审视极限编程,并不会彻底的否定极限编程推崇的实践与原则,只是予我们以警示,要求我们结合具体场景因地制宜,因人而异地推行这些敏捷实践。本书只不过是完整地拉开了极限编程的帷幕,让我们不只看到了舞台上的精美表演,也看到了角落一隅可能存在的混乱与无序。

工程师其实并不擅长用文字去描述自己所思所想,因此何谈准确描述客户的需求?我们喜欢事实说话,数字说话,因为它不会撒谎,不会虚饰,因而不会误解。 这正是Specification By Example《实例化需求》的出发点。该书是作者Gojko Adzic从大量工程项目得来的经验,基于大量的业内研究提炼出来的知识总结。这种实例化需求的方式既能清晰地表述需求,消除客户、需求分析师、开发人员与测试人员在沟通中可能产生的理解分歧;又极为融洽地支持开发人员进行有效地测试驱动,帮助测试人员条理清晰地完成对需求功能的验收和测试。实例化需求不仅仅是一种方法,更是一种对软件开发方法学的革命,我如此认为。

注:本文由张逸与刘龙军共同完成。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [thoughtworks 读书 雷达] 推荐:

ThoughtWorks读书雷达-编码实践篇

- - 简单文本
期望通过四分之一的读书雷达图就能将与编码实践有关的优秀书籍一网打尽,自然是不现实的打算. 因此,我们希望就我们的侧重点来推荐书籍. 对于编码实践而言,我们共同认为培养良好的编码习惯,编写整洁简单而又合理的代码,是一名好程序员的基本要求. 因此,这里我们更强调与程序员基本编码技能相关的知识. 我们并没有给出与算法直接有关的书籍,虽然我们认为算法知识同样属于编码实践的范畴,虽然我们认为诸如《计算机程序设计的艺术》、《编程珠玑》、《算法导论》之类的书籍同样很重要很优秀;然而,我们取舍再三,仍然将它们划出了读书雷达的范围.

ThoughtWorks读书雷达方法学篇-张逸

- - 人月神话的BLOG
原文: http://agiledon.github.io/blog/2013/08/06/methodologies-of-reading-radar/. 方法学(Methodology)看似与开发技能无关,常为程序员忽略. 忽略意味着未曾察觉,却不等于它的无关紧要. 我们每时每刻呼吸的空气同样会被我们忽略,但空气不重要么.

2013年的技术趋势 — ThoughtWorks技术雷达阅读笔记

- - I am Hu Kai
边界正在变的更加模糊,传统上办公室是工作发生的地方,我们需要内部网络来登陆邮件系统,访问公司的知识库,利用电话会议系统和处于世界各地的同事交流. 随着移动设备的普及,网络速度的提升以及越来越多的内部系统被迁移到同时提供外部访问的云平台上,工作正在从办公室扩展到生活的每一处,在出租车上,我们用手机阅读和回复邮件;在机场,我们使用Goto Meeting来和各地的同事举行电话会议;在客户现场,我们用手机访问Jive.

再见ThoughtWorks!

- lnsoso - Happy Hacking
最近的几个月时间里我的工作和生活都发生了较大的变化:因为家庭原因,我离开了生活了六年之久的北京,来到了上海和妻子团聚;同时,我也因此而离开了 ThoughtWorks ,加入了设计软件公司 Autodesk. 回首过去的几年时间,我能很清晰地感觉到自己对软件开发的认识不断地发生着有趣的变化:. 眼中只有C#/.NET/Windows,“外面"的世界.

聊聊ThoughtWorks面试

- - 梦想风暴
最近有几篇关于科技公司面试的新闻,这篇格外受瞩目,因为竟然有公司力压Google,成了面试最难的公司,而这个公司居然是ThoughtWorks. 这个结果真的让我有些惊讶,作为一个面试过许多人的ThoughtWorker,我之前还真没想过我们的面试到底有多难. 既然有人关心ThoughtWorks面试,我就不妨在此分享一下我的“面经”.

如何快速读Paper – ThoughtWorks洞见

- -
去哪里找paper之后,大家问我的问题就常常变成了:. 如何快速阅读一篇paper并准确的提取其中有用的信息. 在本文中,我将试图为大家简要解答这个问题,争取告诉大家如何在短时间内通过阅读文献的方式了解一个新的领域. 阅读一篇paper通常见的目的有四种:. 面对一个新的领域,我要快速把握这个领域的研究方向和state-of-the-art方法,来给自己或者团队设计一个大致的技术方案.

再谈敏捷和ThoughtWorks中国咨询师

- lishali - 酷壳 - CoolShell.cn
之所以用了“再”,是因为之前的两篇文章——. 我在《那些炒作过度的技术和概念》中批评了ThoughtWorks中国咨询师的咨询方法是以一种接近于教条、炒作、洗脑和电视购物的方法(虽然我心底觉得有时候有时候更像传销),当然,批评是没有意义的,所以我也给了中国ThoughtWorks那些年轻的咨询师们一些我认为有建设性的建议.

Serverless实战:打造个人阅读追踪系统 – ThoughtWorks洞见

- -
阅读习惯和个人知识管理体系. 进入互联网时代,知识的获取成本变得前所未有的低廉,但是无论再好的知识,若是没有对个人产生价值的话,那也只不过是一种信息噪音而已. 我在《个人知识管理:知识的三种形态》这篇文章中使用“材料 -> 资料 -> 知识”这样的路径来诠释信息的流通,如何方便快捷并且有效地收集材料,再将其整理转化为有价值的个人知识体系结构,在这个信息极度碎片化的时代变得尤为重要.

微服务分布式一致性模式 – ThoughtWorks洞见

- -
微服务拆分后遇到的一个麻烦是分布后的一致性问题. 单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心. 当把业务系统拆分到不同进程时,就遇到了技术性一致性问题. 这带来了纠结,我们希望有一颗银弹,一把解决问题. 但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择.

用DDD指导微服务拆分 - ThoughtWorks洞见

- -
对于服务拆分的逻辑来说,是先设计高内聚低耦合的领域模型,再实现相应的分布式系统. 服务的划分有一些基本的方法和原则,通过这些方法能让微服务划分更有操作性. 最终在微服务落地实施时也能按图索骥,无论是对遗留系统改造还是全新系统的架构都能游刃有余. 开发者在刚开始尝试实现自己的微服务架构时,往往会产生一系列问题 :.