[转] ThoughtWorks读书雷达-方法学篇

   方法学（Methodology）看似与开发技能无关，常为程序员忽略。忽略意味着未曾察觉，却不等于它的无关紧要。我们每时每刻呼吸的空气同样会被我们忽略，但空气不重要么？不要等到我们开始戴上口罩，每日关心PM2.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从大量工程项目得来的经验，基于大量的业内研究提炼出来的知识总结。这种实例化需求的方式既能清晰地表述需求，消除客户、需求分析师、开发人员与测试人员在沟通中可能产生的理解分歧；又极为融洽地支持开发人员进行有效地测试驱动，帮助测试人员条理清晰地完成对需求功能的验收和测试。实例化需求不仅仅是一种方法，更是一种对软件开发方法学的革命，我如此认为。

转载小记: 在看《JUnit in Action》时,看到了Martin Fowler(《重构:改变既有代码的质量》的原作者)的个人博客的网站，然后看到了ThoughtWorks(Martin现在工作的公司)以及其新浪微博的链接,然后不知怎么的就看到了这篇文件。

粗粗一看，文章的措词以及作者表达思想都极佳，相比较之下,我的写的文字就如同干草一般，平庸而干涩。觉得很值得PM2.5的我学习。于是乎，我就用转载的方式将其收藏起来(收藏癖犯了)，供自己以后查阅。看到这篇文件所在的网址后,我好奇,github也可以写文章的啊,好吧，PM2.5的我长见识了。

原文链接: http://agiledon.github.io/blog/2013/05/13/architecture-and-design-of-reading-radar/