结对编程的好处

1. 程序员与编程存在密不可分的关系，为什么让他如此厌恶

编程，有些人喜欢，有些人讨厌，有些人从未尝试过，还有一些人每天都在使用。

讽刺的是，要让程序员在结对编程感到更加的舒服，我们需要在工作结束，或者在番茄钟间歇的时候，多多交流，相互反馈。但程序员大多数沉默少言，并且很内向，他们之间的反馈和交流非常的不容易。

简而言之，整个事情都不容易。

结对编程优势不可能被否认，是有据可查的。但结对编程存在的问题却很少被提到，但这些也非常重要。

郑重声明，我是一个结对编程的践行者。对于我来说，和很多人一样，我们都会对挑战所带来的收益进行评估，判断是否值得自己去付出努力。但是我也相信，和其它的挑战一样，当你准备好，知道你自己应该做什么的时候，事情就会变得很容易。

我们经常谈论各种各样的挑战，我们可以使用我们的智慧来找到解决办法。我们可以从中获得好处并减少问题带来的挑战。举个例子，我们并不需要对每一个任务都进行结对编程，我们可以间歇性的执行结对编程，更好地适合你团队的现状。

2. xp是什么

xp

极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效 XP的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。

目录

第三方的身份的事故发生过对方规范化和规范
黑屏警告
反盗版“黑屏”举措
XP的核心思想
XP的十二种方法
四个核心价值
带给我们的变化
极限编程的有效实践
展开
编辑本段
第三方的身份的事故发生过对方规范化和规范

xp
编辑本段
黑屏警告

微软中国正式宣布 xp黑屏警告，将从2008年10月20日起同时推出两个重要更新，使用XP专业版盗版系统与OfficeXPe2003、Office2007盗版软件的用户将分别遭遇电脑“黑屏”与“提醒标记”等警告。
被称为Windows正版增值计划通知和Office正版增值计划通知的这两个项目均是可选择式的服务。用户可以通过微软更新站点或自动跟新选择下载安装、经过验证过程后了解自己使用的WindowsXP或Office产品是否为正版并获得了相应的授权。
微软方面透露，验证通过的用户直接使用WindowsXP或Office程序即可。对于因不同原因未通过验证的用户，将收到相应的系统通知。如：产品未激活或使用试用版下的“未激活验证失败”；因同步超时等原因引起的“验证无法完成”；或“非正版验证失败”。
XP
xp如果WindowsXP用户没有通过正版验证，将会体验到：用户开机进入后，桌面背景变为纯黑色，用户可以重新设置桌面背景，但是每隔60分钟，桌面背景将重新变回黑色；会看到一个登录中断的对话框，并在屏幕的右下角会出现一个永久通知和持续提醒的对话框显示“您可能是软件盗版的受害者”等提示信息。
如果Office用户没有通过正版验证，用户体验将分为三个阶段：验证失败后的第1-14天内，客户将在每天首次打开Office软件和此后2小时分别收到一次对话框提醒；从验证失败后的第15天开始，提示信息将告知用户如不采取行动，将在14天后，Office软件被添加视觉标记；客户在收到这些对话框通知30天后，Office软件的Word、Excel，PowerPoint和Outlook程序的菜单栏中将被添加视觉标记。
微软方面认为，这两项计划是旨在帮助中国用户甄别电脑中安装的微软Windows操作系统和Office应用软件是否是获得授权的正版软件，从而帮助那些在不知情的情况下安装和使用了盗版软件的用户免受侵害。
XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National BankFord Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。
编辑本段
反盗版“黑屏”举措

xp微软中国正式宣布，将从2008年10月20日起同时推出两个重要更新，使用XP专业版盗版系统与OfficeXP、Office2003、Office2007盗版软件的用户将分别遭遇电脑“黑屏”与“提醒标记”等警告。
XP
新闻发布后即引起了网友的极大反应。截止18：00，已有4万名网友通过搜狐新闻的调查表达了自己的意见，其中22.7%的网友反对“黑屏”，认为微软此举太过分了。而66%的网友则坚称要将盗版使用到底。
支持微软的网友只占7.8%。
不少坚称继续使用盗版。“不是不想用正版，而是太贵了。”类似该网友，希望微软继续降价的网友也不在少数。
XP-概述
同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。
XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。
XP
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了用户开发程序的传统思维方式。下面用户将介绍它带给我们那些改变。
xpXP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。
编辑本段
XP的核心思想

从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。
编辑本段
XP的十二种方法

规划策略(The Planning Game)；
结对编程(Pair programming)
测试(Testing)
重构(Refractoring)
xp简单设计(Simple Design)
代码集体所有权(Collective Code Ownership)
持续集成(Continuous Integration)
现场客户(On-site Customer)
小型发布（Small Release）
每周40小时工作制（40-hour Week）
编码规范（Code Standards）
系统隐喻（System Metaphor）
编辑本段
四个核心价值

极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。
XP
XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专着叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。
XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。
编辑本段
带给我们的变化

通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗？XP认为事实并非如此。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说：“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。
另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。
一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。
XP开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为用户的客户不能明白用户的源代码并不意味着用户可以不努力去管理代码的质量。
五、用户什么时候用XP
XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，
XP
这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。
XP方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。用户应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。
XP方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。
另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。
在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。
编辑本段
极限编程的有效实践

完整团队
XP
XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显着的图表以及其他一些显示他们进度的东西。
计划游戏
计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
客户测试
作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
测试驱动开发
编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
改进设计
随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。
持续集成
团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。
集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
编码标准
系统中所有的代码看起来就好像是被单独一人编写的。
隐喻
将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
编辑本段
程序

：
XP，是英文Experience（体验）的缩写, 自从微软发布windows XP后,成为软件流行命名概念。
Windows XP原来的代号是Whistler。Windows XP的外部版本是2002，内部版本是5.1，正式版的Build是2600。 微软最初发行了两个版本：专业版(Windows XP Professional)和家庭版(Windows XP Home Edition)。
2001年10月，Windows XP问世了，这个版本在Windows 2000基础上开发。微软此次为Windows XP造势的规模相当大，XP（eXPerience）这个词随之深入人心，越来越多的软件公司为了搭这个顺风车，不管相干不相干都为自己的软件名字后面加一个XP，甚至连AMD的0.13微米Athlon也“非常巧合”地命名为Athlon XP，不过AMD对XP的解释是eXtreme Performance。
编辑本段
停售

美国微软公司从2007年6月30日起，停止向零售商和几家主要电脑生产商销售视窗xp操作系统。
据美国媒体30日报道，微软今后将不再向戴尔、惠普等主要电脑生产商提供视窗xp操作系统，但这些厂商库存的装有xp系统的电脑仍将继续销售。从这些商家购买新电脑的消费者，如果仍想安装xp，也只能先接受Vista操作系统，然后再合法地将操作系统“降级”至xp。
不过微软宣布，到2008年1月之前，该公司仍将允许一些家庭经营的电脑商店等小型零售商销售xp操作系统。此外，微软仍会销售一款针对超低价个人电脑的XP系统。
XP操作系统上市至今已有8年。Vista是微软继xp系统之后推出的最新版视窗操作系统，于2007年1月30日面向普通消费者发售。但一些消费者认为，Vista系统对硬件配置的要求太高。另外，2008-2009适逢“上网本”开始快速发展。“上网本”即目前日趋成为笔记本电脑中的主流的一类个人终端，搭载有无线网卡，方便随时随地登录互联网，这类电脑的配置普遍较低，价格便宜，适合对于移动网络要求比较高而对硬件配置要求并不高的用户。Windows xp显然是这类电脑的首选。迫于上述原因，2009年4月16日：微软决定延长国内xp主流支持服务。
编辑本段
疾病

XP也是着色性干皮病（xroderma pigmentosa）的缩写。着色性干皮病是一种发生在暴露部位的色素变化，萎缩，角化及癌变的遗传性疾病，属常染色体隐性遗传病。在某些家族中，显示性联遗传。表现暴露部位发生针头至1mm以上大小的淡暗棕色斑和皮肤干燥，日晒后可发生急性晒伤样或较持久的红斑，雀斑可相互融合成不规则的色素沉着斑。也可发生角化棘皮瘤，可自行消退，疣状角化可发生恶变。避免日晒，不宜室外工作。可用2－5%二氧化钛霜外用，肿瘤及早切除。
编辑本段
口语

在如今网络终于丰富多彩的时候，XP在一些不愿说脏字的人嘴里就代替了牛X。
基督Χριστοs 的首两位简写 ，罗马皇帝君士坦丁大帝曾在梦中梦到基督，醒来后便让手下正准备出征的战士在盾牌上刻上XP，即基督之意。后来君士坦丁使基督教获得了前所未有的地方，让基督教真正的与政治统治结合了起来。
编辑本段
eXtreme programming

XP（Extreme Programming），它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。
经验值
在某些单机游戏与网络游戏中，XP就是EXP的简称，指的是经验值。

3. 国内为何很少有人做结对编程呢是确实不好还是属于中国特色

结对的代码质量应该高于单干，单干的效率可能高于结对。对于一个没有敏捷基因，看重效率大于质量的团队来说，结对的投入产出比太低，采用传统方式也就理所当然。

4. 为什么要Code Review

Code Review是我们项目成功的最有力的武器。下面我先谈下我理解并实施的Code Review.

1. Code review的层次。
最基础的，也是所有人都会想到到的，就是编码规范，类，方法命名什么的，还有代码格式...这些是程序员的基本功底，默认选项；多年前领导要我搞个编码规范，我说大家都熟知的规范就已经很好了啊；当然公司内部也需要这方面的规范，比如项目如何命名，包如何命名等这些。
更高一层次的，也是说的比较少的，是代码的质量。前面能保证代码写的好看，大家看了都还顺眼，但并不能保证代码的可工作性，合理性，健壮性，可维护性。我们需要可以解决问题的代码；我们需要最合理（最是相对的）的代码；我们不希望破坏现有的架构搞特殊处理，如果架构本身不适应，那就可控制的重构；我们不希望有个工作很好的功能被破坏。

2. Code Review的好处
第一，最少有两个人对同一段代码深刻理解，并且认同。如果不能做到敏捷要求的“结对编程”的味道，我们就打个折执行吧。这一点从公司正常运营上，也是有好处的。
第二，开发人员可以放心的把自己的创造性发挥出来，因为他知道他有个坚强的后盾，绝不会等到QA发现不可饶恕的错误，然后经理过来骂你一顿。
第三，开发人员都会尽全力写最好的代码；软件开发人员都是要"face"的，不想当时就被别人找到缺陷，尤其是你身边的同事。再也不会只顾今天，不管明天会怎样；对软件的可维护性更加尽心。
第四，极大的提高软件质量，以及可维护性。当然这要求Review人员的责任心，以及专业精神。如果是维护性项目，经验也是相当重要的。

3. Code Review的重要性
至此，其重要性以已经不言而喻了。个人认为某种程度上其重要性以及你改超过Unit Test.

4. Code Review不好实施的原因
Code Review如此重要，但是据我接触的人跟公司来看，真正认真执行的并不多。其原因无非：
ü 项目时间紧，时间跟人员都不充足；如果是这种情况，建议招点人，项目计划制定的更合理些。
ü 重视程度不够；开发人员都觉得自己很牛，代码不需要给别人Review。其实问题往往就是由于过分的自信造成的，需要公司高层多做宣导，并形成制度，强力执行。等过一段时间，大家都会体验到其中的好处的。
ü 执行起来比较麻烦。这是大问题。如果你让开发人员觉得做Code Review是件很容易的事，并且收益大于付出，大家就愿意做了。我们Team大致经历过三个阶段。
第一阶段，按制定的流程，开发人员把修改的代码用邮件发给Review者，并说明改了什么，对系统那些功能有影响。然后负责Review的人Copy到Eclipse，对比CVS, 看代码的改动是否合理。然后再邮件通知合格，或不合格，并说明原因(口头或书面)。
第二阶段，开发人员都觉得这样太繁琐，费事费力；于是我们开发了个Eclipse插件，帮助开发人员对自动生成代码改动细节的邮件，并把改动的代码自动放到指定的公用文件夹中。如此一来开发人员生成一个Code Review的请求，就是分分钟的事情了(右键，写点什么，完成)就好了。
第三阶段，开发人员现在很Happy了，但是Review的人觉得还是有点麻烦，要Copy,要写邮件。于是我们把插件又改进了下，Review的人也可以在Eclipse上一键把代码进来；然后提供了一个Web Console供头头看我们Code Review的情况。

5. 什么是结对编程

结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。
在结对编程中，观察员同时考虑工作的战略性方向，提出改进的意见，或将来可能出现的问题以便处理。这样使得驾驶者可以集中全部注意力在完成当前任务的“战术”方面。观察员当作安全网和指南。结对编程对开发程序有很多好处。比如增加纪律性，写出更好的代码等。
结对编程是极端编程的组成部分。

6. 什么是pair programming

结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。

1995年，Larry Constantine在他的专栏中第一次提到了在他在P. J. Plaugherís software company, Whitesmiths, Ltd观察到一个现象：Collaborative Programming（合作编程）。

1996年，Kent Beck，Ward Cunningham 和Ron Jeffries一起提出了Extreme Programming（XP），其中吸收了Collaborative Programming，并称为Pair Programming。

同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体现出来。

7. 为什么软件开发方法论让你觉得糟糕

围绕软件开发实践和方法论，总有很多教条式的口水仗。阶段式（phase-gate）方法能够有效管理软件开发过程的风险，还是说只是风险管理中的花哨噱头？TDD真的能够促生出高品质软件？结对编程是代码评审的有效替代抑或只是增加了商议沟通代价？我想说，虽然缺乏证据判断这些论调的谬处，但有两条常用的法则能够帮助我们选择好的实践，同时，提升我们所提供软件的价值：划小开发周期以及提升反馈效率。
Michael Feathers给出了以下观点：
我认为，我们最终还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，要是人人都可以替代（随便找个人都能顶上），那该有多好呀？但事实并非如些。
问题是，我们怎样才能找到有（合适）技能的开发者？IT界从未很好地定义个体生产率，从这点来看，那么，要找到合适技能的开发者就是个很难解决的问题。代码行数（Lines of code） – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭，这并不是一个好的方法。而度量工作小时数则是鼓励（个人）英雄式举动 – 经验表明，“英雄们”通常就是导致项目延期的人，依赖“英雄”往往是一开始就采取的不该采取的冒险行动，长时间工作导致人变得鲁钝，并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式，招聘好的人才，是一门（招聘）艺术，而非（招聘）工程。
心理学家至少对这个问题进行了研究：为什么IT业的技能很难被掌握和度量？Daniel Kahneman说（Thinking Fast and Slow），掌握技能有两个基本条件：一个环境足够规律以便可预测；有机会通过长时间实践来学习掌握这些规律。
但是典型的软件项目往往是没有规律及可预测环境的。项目成功的唯一正确度量就是：最终的结果通过整个生命周期里的实施达到了预期目标吗？ 很难知道什么关键活动导致了项目成功和失败，很少有人能够通过旧有或现有的项目获得答案。几乎不可能判定哪些决策导致了成功或失败（在人工智能领域，这叫作信度分配问题）。
这些因素造成了IT专业人员很难掌握引导产品和服务走向成功所需的能力。然而，开发者掌握能帮助他们更高效地达到目标的技巧，将使他们更有动力 – 通常称之为“开发完成”，尽可能快的、不考虑是否功能被集成以及生产就绪。类似的场景也常出现在其他功能性实施领域。
实际的软件项目是复杂的，没有规律可循，这会导致另一个问题 – 为了证明某种技术、实践和方法论是实际有效而收集相关数据是极度困难的，几乎不可能在脱离收集环境的情况下归纳出这些数据。
在Laurent Bossavit的好书《The Leprechauns of Software Engineering》中， 他抨击了软件开发的一些惯式，比如“成本变化”（或“缺陷成本”）“曲线”，这些惯式是许多其它的软件开发方法论知识基础，称开发人员生产率的变化是一个数量级（参照确定性金字塔原理）。Laurent Bossavit说明了相关依据 – 很多人依赖从计算机科学专业学生进行的非正式试验或是从无法被有效控制的项目中收集小量数据。这些研究组织的给出的论调基础往往是不健全的，数据缺乏分析，而且，最过分的是调查结果普遍远远超出了他们的适用领域。
因此，不太可能轻易下论断敏捷开发实践就比瀑布模式之流合适，反之亦然。“方法大师”的见解其实也没太大指导意义，就像Kahneman说的，“人们在想法方面的信心，并非是有效行事可倚重的因素…当评估专家的想法，即使在有规律可循的情况下，你也一定要想清楚是否有合适时机可以引入其想法的可能性”。就像Ben Butler-Cole指出的（why software development methodologies rock），引入一种新方法往往会带来一些影响。
你可能会认为当我们决定怎样运作一个团队时，我们就陷入了被动。但细想一下为什么软件开发无章可循？为什么在这个环境里很难进行一些试验以及获取技能？什么实践和决定会导致成功或失败？其中的根原因就是：环境是无规律的，做出变更与理解变更带来的结果之间的反馈过程太长了。这里的“变更”一词是指广义上的需求变更、方法变更、开发实践变更、商业计划变更、代码或配置变更等等。
还是有一些办法帮助缩短周期的，比如当我们应用精益软件开发思想 – 一个很重要的方法。缩短开发周期在大型产品开发中是很重要的：在Bret Victor的精彩视频Inventing on Principle中提到，“如此多的创新被发现，只要你真正理解了你在做什么，你就能发现任何事物”。
但对我而言就是这样的：我们几乎不可能实践持续改进、学会怎样使团队或个人变得更好、掌握成功创建大型产品与服务所需的技能。除非我们聚焦于尽可能使反馈间隔时间缩短，以便实际洞察其间关联，以及辨别原因和影响。
事实上，从想法到反馈的周期尽可能短的好处是如此明显和重要，应该把其作为商业模式中要遵循的一个重要原则。如果你纠结于要把你的产品创建成一个用户安装式的软件还是SaaS模式（Software-as-a-Service，软件运营服务模式，软件即服务），这时的想法会自然而然地推动你强烈考虑SaaS模式（有感而发）。如果你要重建你的系统（包含硬件），应该考虑怎样尽快实现原型（how you can get prototypes out as quickly as possible），以及模块化硬件和软件，以便你可以快速和独立地整合。3D printing（三维打印成型技术）技术看起来在这方面有着巨大的用武之地，因为它可以满足软件开发应用实践朝硬件系统（原型呈现）的演进。如果你想如愿以偿地缩短周期，或多或少按多功能型团队（cross-functional teams）方式运作是需要的。
软件方法论，即使雇用一群牛人并让他们自我组织，也是糟糕的，因为他们时常搞得“cargo-cult”（货物崇拜，敏捷开发里的知名小故事，形而上）：我们在做stand-ups（每日站立会议），我们有优先顺序的backlog（优先待办事务），我们甚至看在老天的份上实践了continuous integration（持续集成）。
我们的到头来的结果为什么还这么差呢？因为你忘了最重要的事情：建立一个学习能力和适应能力都很好的组织。

8. 学习少儿编程，对孩子升学有帮助吗

有用。
学习编程对孩子的帮助很大，可以归纳为以下10点：
（1）强化孩子的逻辑思维能力。
编写程序最重要的是如何把大问题不断分割成小问题。
编程中孩子要思考如何把代码合理地安排在整个程序中，让程序流畅地处理输入、演算、输出，这个过程对孩子分析事物的逻辑性有极大的帮助。
（2）培养孩子的专注力和细心度。
在编写程序的过程中，排错是无法敷衍了事的，这个过程能有效改正孩子马虎行事的毛病，避免当个“差不多”先生。
（3）提高孩子的耐心。
编写游戏和玩游戏的很大区别在于编写游戏可以很好的锻炼孩子延迟满足感的能力，提高耐心，从编写游戏，到玩游戏，是需要经历一个比较长的过程。同时学会编写游戏的小朋友，会在游戏过程中融入更多的思考，游戏视角会有明显变化。
（4）增加孩子的抽象思考能力。
学习程序就是为了跟计算机沟通。这意味着孩子在学习的过程中需要一种化具体为抽象的能力，让程序能够按照孩子想象的方式运行，这是集思广益的过程。让孩子发挥无限想象并动手实践，让不懂得思考的电脑也能了解与表达抽象的事物。
（5）提升孩子整理信息、融会贯通的能力。
程序是一堆电脑指令的组合，程序中的基本指令就像是汉字，写成可重复利用的方法或对象就像是成语。最终要完成项目，就必须融会贯通、学以致用，确保程序在执行中不会出现不可预期的错误。
（6）提升孩子国际性的沟通能力和竞争力。
编程语言已然成为一种重要的沟通工具，不但可以跟电脑沟通，还可以跟所有运用电脑的人沟通，这将会是他们面对国际和未来竞争的核心能力。
（7）让孩子学会团队合作和共同学习。
在适当的教学课程设计下，学写程序就像玩游戏闯关一样，同学彼此讨论破关攻略。结对编程，你不会，我教你；我卡关，你帮忙；我设计，你闯关。同时，在互动中增进情谊，学习如何利用团队的力量解决问题。比起老师在讲台上单方面的讲课，同学之间的探讨更容易提高学习效率。
（8）训练孩子的空间思考能力。
在编程中控制游戏人物的过程是训练空间思考能力的一个很棒的方式。仿佛孩子自己在高低起伏中身陷迷宫，在闯关角色中置身于编程世界，在游戏中学习，明白方向感和立体的空间架构。
（9）增进孩子解决问题的能力。
面对一道道关卡的挑战，孩子会不断思考如何利用学到的知识、程序达到闯关的目的。一旦养成这样的习惯，在碰到生活中或其他课业问题时，自然也会试着自己解决。父母只要给予适当的工具和提示，让孩子自己动手、动脑去完成。
（10）Learn to code，code to learn。
学习编程，训练编程的思考方式，父母再也不用逼着孩子学习数学，因为当他要完成按钮、人物、得分、方向的同时必然需要用到许多数学的技巧，让孩子在编程的同时自主学习。另外，还可以提高孩子的英文能力，编程让接触英文成为自然而然的事情。其他的科目（如音乐、艺术、文学等）一样可以运用在编程的过程中，也就是我们所说的code to learn。