1，在最初设计时，如何尽量保证向后兼容？（这里不提倡过度设计噢，我们是搞敏捷的，哈哈）

2，如果API发生了改变，该怎么通知已有实现？

对于第一个问题，答案相对而言简单一些：支持必要的，但是最少的东西，而且层次不要太多。为什么？用下面的xml，举个例子来说

<person>

  <name>phoenix</name>

  <job>softerware developer</job>

  <company>ThoughtWorks</company>

</person>

第一层，指的是这个xml具体针对什么，第二层有三个属性，分别是name，job和company，这是一个嵌套层次很好的，而且也没有包含过多的信息。但是如果我们在一开始再加上address属性（假设它并非必要），那么如果客户构建了一个客户端也的确包含了address属性，那么在下一个版本的API中，你把这个属性去掉了。问题是不是出现了？客户的软件无法工作了。反过来，如果最开始的版本不包含address，但是有客户强烈要求下一个版本要支持，那么怎么办？简单！在下一个版本加上就好了，对于已有的客户端，多一行冗余数据而已，也不会导致客户的软件无法工作。好了，这个问题解决了，那么，什么是嵌套层次不要太多。举个反例

<person>

  <name>phoenix</name>

  <job>softerware developer</job>

  <company>

    <name>ThoughtWorks</name>

    <locations type="array">

      <city>beijing</city>

      <city>san francisco</city>

    </locations>

    <products>

      <product>

        <name>mingle</name>

      </product>

      <product>

        <name>cruise</name>

      </product>

      <product>

        <name>twist</name>

      </product>

    </products>

  </company>

</person>

这叫层次太多！一个company里，包含了太多的嵌套信息，其中location还算说的过去（因为只是一个简单的数组），但是products里包含了子对象就不对了，这就是第三层对象了，具体的解决方案可以利用url来替换掉。世界终于清静啦！

可是我还不能清静，因为要回答第二个问题：API改变了，该怎么通知已有实现？这是一个很头疼的问题，如果能避免回答我绝对会避免，可惜，不能！通常有两种解决方案，但目的都是为了让客户的软件失效（我知道，我知道，这会让客户抓狂，可是我们也没辙啊！所以还是能不动，则不动，打死也不动，打不死嘛......就按如下办）a，使用带有版本号的API URL（这是现在最经常使用的一种方法），例如api/v2/projects/members.xml前面的api不说也明白，v2就是version 2版本2的意思，如果更换了，就变v3，客户的软件不能用了，也就知道了；b，利用HTTP header 里的ACCEPT来解决（别说你写了这么多年程序，连HTTP有HEAD都不知道啊！会被鄙视的！），ACCEPT可以设置接受的文件，你可以将版本信息放在里面。技术细节不多说了，给个链接，供大家参考 http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ 其实我是比较赞成这种方式的，比较优雅，但缺点就是它还不是标准，对方的程序员也可能不知道HTTP有HEAD，所以做起来，对人家可能会有点复杂，这里就不再多说了。

总之昵～～，小初（想必盯我博客很久的人，也都知道我姓甚名谁了，以后我就用真名了）的技术博客在沉寂了，这么久之后，又回来了（我胡XX又回来啦！哈哈），有太多东西要写了，以后会陆续带给大家的，多谢捧场！

PS:为啥Blogbus不支持<pre>标签呢，让我的xml这么丑的出现在博客里？惭愧呀！

Agile Adoption Patterns: A Roadmap to Organizational Success，这本书是讲述如何从非敏捷过程平滑的迁移到敏捷过程，挺喜欢这本书并决定翻译它的主要原因，是它里面不仅仅介绍了敏捷实践方法，更一语道破了软件开发中的关键两点：一、学习是瓶颈；二、交流和人是主要的。

现在的进度是，三个人大概翻译了一小半，作为组织者，最近整合大家的手稿，发现许多翻译英文文献中常见的问题。值得总结一下：

1、太多的“你”，“你的”，“你们”，“他们”等等。英语的语法有主、谓、宾，例如”So you are interested in Agile development. Why? Chances are, you want to improve your software development process“，每句都一个you，第二句还有一个your如果中文照着翻译，就变成了”为什么你对敏捷开发感兴趣？可能你想改进你的软件开发过程。“。从头到尾读一下中文的句子，你会发现，别扭。可是又说不出来在哪里，那么换成这样如何？”为什么对敏捷开发感兴趣？想改进你的软件开发过程？“，感觉通顺多了吧？我去掉了两个”你“，这才是大家说话的方法

2、词语不统一。这种情况在多人合译的时候，尤其普遍。我的小组会共享一个Google文档，里面是我们的词汇表，记录了我们遇到的关键词，定期碰头统一词汇

3、中文的精炼性。中文比英语精炼，我们平时说话，很少一气儿说很长的句子。而英语不是，句子的从句一串串。这个时候，我们就要学会断句。其实翻译主要是意译，如果觉得长句实在别扭，将整句读懂，撇开原作，用你的语言写出来，你会发现其实就是这么回事

4、这就引出了断句的问题。你都意译了，那断句和标点符号，就自然按照我们的习惯来了，我和我的朋友们在翻译的初期，生怕翻译错了，所以尽量按照原文走，句子都不敢改。其实这是错误的，这本书讲敏捷，敏捷依靠学习，学习依靠犯错误，因为人类的学习就是从犯错误成长，哪有人第一次写程序就能达到完美的？恐怕连第一个int都要想半天，查查书才知道。翻译一个道理，大胆翻译，犯错了有别人审查呢（当然这不表示你不负责任的乱翻）

5、漏翻。这就不用多说了，漏翻是不好的。有的时候遇到困难，千万不要空过去，标记个颜色，过几天再回头看看。如果空过去，很可能造成漏翻

6、中文的连贯性。有的时候，我们要想翻译的更”像“中文（哈哈，姑且用”像“来形容吧）。就需要将一些句子连起来，”如果 就“，”不但 而且“，”不是 而是“等等，这些连词要好好使用

很久没写Blog了，要努力呀

    mkdir git-usage（创建项目目录）
    cd git-usage（进入项目目录）
   git init（Git初始化）
   touch README（创建一个README文件）
    git add README（增加该文件到索引）
    git commit -m 'first commit'（本地提交）
    git remote add origin git@github.com:phoenixtoday/git-usage.git（增加远程服务器代码库地址）
    git push origin master（将本地代码提交到远程服务器上）

我所在的项目小组自从使用Git后，发现Git提供的种种特性大大提高了我们的开发效率，在认识Git前我们无法想象一个版本控制工具可以让开发任务切换变得如此自然流畅。所以我强烈推荐大家使用Git，你付出的学习绝对物有所值

  InfoQ 上的书评链接在这里 http://www.infoq.com/cn/news/2008/10/agile-adoption-patterns-br

个人认为，除了翻译中所说的那么多适用情况，其实这它还非常适合拿去给别的企业做敏捷指导的时候使用，倒是本从传统软件开发向敏捷过度的好书

摘要

正文

在AmrElssamadisy最近的一本书《敏捷模式──指向成功的路标》 中，他使用了一种概念框架，用这个框架把具体应用环境和敏捷策略一一对应。他没有建议人人都使用一系列相同的实践方法，而是针对公司所想达到的目标，帮助 你找出哪些实践方法是最适合的。这些实践方法不但会引领你走上敏捷的道路，而且会将迁移过程的花费，以及所出现的失望情绪降至最低。

成功实施敏捷开发方法，对于一个企业而言，将会获益匪浅。敏捷过程提供更为精确的项目评估；在项目正在进行的同时也能给予更好的控制（提供更有用的功能， 而不只是需求文档上所要求的）；产生更高质量和更易于维护的软件产品；以及提高开发团队的士气和信心以及彼此之间的信任。不幸的是，正如我们许多人在敏捷 开发者社区里所了解到的，从传统的软件开发过程迁移到敏捷软件开发过程非常困难。针对具体的企业环境，找到合适的敏捷方法并进行实践，是一件很让人头疼的 任务。因此，许多企业在转换过程中经历了很多困惑和失望，而且许多企业在发现敏捷开发方法的益处之前，就放弃尝试了。

Elssamadisy在书中提供了一些行之有效的方法，可以帮助你避开在实施敏捷中的种种陷阱。举例来说，尝试“大跃进”式的迁移是很常见的错 误，而作者为你提供了一种逐步进行、迭代采纳敏捷开发方法的计划。他鼓励使用敏捷的方式来实施敏捷：在（希望是）正确的方向上小步前进，利用短期回馈来收 集信息，用于调整方案和确定下一步的计划。同时，作者会帮你达到投资回报率最大化，他提供的技巧可以找出对组织最重要的商业价值，并且告诉你如何选择一开 始采取的实践组合，以强化这些价值。

如果你对敏捷有所了解，而且希望知道如何在真正的项目中卓有成效地实施敏捷，这本书就是你的不二之选。如果你非常愿意帮助采用传统软件开发方法的企业转而实施敏捷开发，那么这本书非常适合放在你的书架上。

上下文驱动的实施方式

该书的前两部分（第一部分：关于软件开发的想法；第二部分：实施敏捷的艺术）是全书的核心。

第一部分介绍了两个可供敏捷指导者采纳的指导原则：

• 原则1：学习是瓶颈。
  对于给定的流程和任务，如果不知道如何实施，要找到可以加快学习速度的途径。Elssamadisy主张使用敏捷实践者普遍采用的一种方法─周期性得信息回馈 ：
  

  1）设立目标 2）采取有助于达成目标的行动 3）将行动结果与目标进行比较 4）调整行动并回到步骤2
  学习的过程发生在步骤3，并在步骤4中得以应用。

  Elssamadisy同时强调了沟通对于强化学习效果的重要性，个体之间的信息传播，可有效地使他们融入软件开发过程。

• 原则2：个体敏捷性
  Elssamadisy借用了Chris Avery的“责任过程模型”， 以帮助读者在组织变化的过程中，保留富有成效的想法。该部分提出的建议包括：如何避免常见的陷阱，包括盲目指责、妄下结论、自怨自艾、羞愧难当，以及自感 无助而没有主控权的状况。为了产生（并且保持住）责任感，必须创建“思想上为自己负责的状态。用行动解决我们不喜欢的东西。这就是达到个体敏捷性的起点。 ”

该书的第二部分是我最喜欢的。它阐述敏捷实践的方式，是我不曾在其他书中看到的。它明确描绘了各种各样的“业务价值”（就是诸如“缩减生产时间”和“提高 质量”这样的目标），这些价值及其目标可以利用敏捷方法达成。如此描述方式，可以帮助读者在采纳敏捷时，照顾到组织的客观环境：首先，确定对于组织最重要 的业务价值；然后，根据上述的目标来应用敏捷实践，从而提升业务价值。

Elssamadisy同样描述了一些经常碰到的“坏味道”，利用敏捷方法可以有效的去除它们。（一般来说，坏味道比业务价值更易于发现。因此，从企业目前的坏味道开始，确定采用哪种敏捷实践，通常是一种相对简单的途径。）

进一步地，Elssamadisy解释了各种敏捷方法的联系。很多时候，如果不首先实施某种敏捷方法，那么很多基于它的敏捷方法就很难实施下去。针对特定的商业价值和坏味道，Elassamadisy提出了一个草图，用于排序和分组对应的敏捷实践。

这种以上下文驱动来实施敏捷的方式，是敏捷出版物中早就应该出现的，我非常高兴地看到它成为本书的核心。由于体验过许多艰难的过渡经历，我可以断言：以基于上下文的、迭代的方式实施敏捷会大行其道，尤其适合于大型组织机构。

敏捷模式

敏捷模式的章节几乎包含了敏捷领域中所有的模式。它们被分成五个群组：

• 目标和周期：
  两个基本的模式构成了许多敏捷实践的基础。
• 信息反馈实践：
  迭代、启动会议、待办事项列表、规划扑克、站立会议、完成状态、演示、回顾、时常发布、“联合驻扎”团队、自组织团队、跨职能团队、客户作为团队成员、唤醒式文档、用户故事、用例、和信息辐射器。
• 技术实践：
  自动化测试、测试后行开发、测试先行开发、重构、持续集成、简单设计、功能测试、代码集体所有制、结对编程。
• 辅助实践：
  指导、加入社区、阅读周期、研讨会、教室式培训。
• 模式集群：
  迭代集群、沟通集群、演化的设计、测试驱动开发、测试驱动需求。

辅助实践也包含于其中，是非常令人高兴的。从本质上来讲，它们不是敏捷实践，而是帮助学习新知识的方法。但是，如果忽视了这些实践，将会使学习举步维艰。

每个模式都包含一些有用的工具,有助于判断这个模式的实践是否适合于你的敏捷实施计划。这些工具包括：对当前模式所提升的业务价值的解释，特定模式 适用环境的介绍，和对于某些模式试图解决的阻力的深入说明。仔细阅读每个模式的上述内容，读者可以确定在自己所处的环境中，实施特定的模式会有多少价值。

拿“演示”模式为例，列举一些帮助你判定该模式是否“合身”的内容：

•  
  • 将需求和设计用文档记录是可以的，但是不足以提供信心，让组织相信应用可以满足他们的需要。
  • 通过增强项目透明度，并且提供定期演示的流程，可以增强信心。
  • 可工作的软件会给投资者树立信心，让他们看到不断推进的、卓有成效的工作成果。
  • “我们完成了需求和设计的编写和复查，这就表示完成了30%的工作量”，类似的片面完成度统计是错误的。开发者们一向过于乐观。
  • 完成可工作的软件所付出的努力，还包括在软件开发的后续阶段减少许多瑕疵。
  • 越早发现缺陷，修复付出的代价越小。
  • 查找和修复缺陷是一个学习的过程，而学习是软件开发过程的瓶颈。
  • 一些早先设想的解决方案并不总是我们真正需要的。有时候虽然软件开发完成并通过测试，而且是完全按照需求完成的，但不能解决真正的问题。
业务价值：
“演示”增加了项目对于干系人的透明度，让客户评估具体的系统，这也增加了产品的实用性，同时对迭代也是支持。迭代可以直接提升业务价值，而演示在这方面起到了二次影响。

上下文：
你处在一个开发团队中，此团队施行迭代开发，投资者在开发团队之外，但对项目的进度感兴趣。

阻力：

接下来，关于模式的章节介绍了如何帮助你有效实施敏捷方法，同时避免很多实践者曾落入的陷阱：

因此：
当前模式的描述。该模式如何解决已知上下文环境下的种种阻力。

采纳方法：
步骤，顺序，一些实施当前模式的建议。

但是：
采用当前模式可能产生的消极结果。

变种：
该模式的变种，不同于“因此”部分的描述，同样能成功实施。

引用：
深入阅读资料。

这些部分用精炼的语句总结了许多敏捷社区诞生的智慧，并且与实际问题丝丝相扣。如果你正在进行某种实践的尝试，但是并未体会到它提供的任何价值，那么这些部分可以帮助你进行调整，以从实践中获得更多的价值。

我非常喜欢“但是”部分。很多常见的敏捷实践都非常容易出错，而且经常很难找到有关这些错误的描述。阅读这一部分的内容，新的敏捷实践团队就可以设置切合 实际的目标（不是一切都能顺利推进，实施敏捷实践时有很多歧途），这部分内容还能给新的团队以警示，确保他们不走弯路。大多数情况下，“但是”部分会包含 很多建议，告诉你要是走错了路该如何扭转局势。由于许多敏捷实践都曾在这些情况下出了问题，能看到相关内容实在是读者的一大福音。

实例研究

该书的第三部分，研究了两个应用敏捷实践的真实案例。有关敏捷的出版物中，常会描述一种“完全敏捷”的团队，这样的团队与缓慢向敏捷迁移的团队大相径庭。很多倡导敏捷的人都是通过看书学习的，可他们却很难像书中描述的一样马上达到收效，也因此而遭受打击。

敏捷在真正实施时，并不是一帆风顺的，能够读这些真实的情况使人耳目一新。现实世界中，尤其在大的企业，改变个人和组织的习惯是一个长久、艰难的过 程。事情不会一帆风顺，但是只要假以时日，那些持之以恒的个人和团队总会获益匪浅。这两个敏捷案例清晰刻画了目前的现实情况。帮助组织机构向敏捷迈进的过 程是漫长而又艰难的。相信别人也曾遇到类似的问题，这会让你摆脱疑虑，从而看到自己正在取得卓有成效的改进。

结论

这本书并不适用于所有人。我不会将它推荐给完全不了解敏捷的人。Elssamadisy认为，本书适合对常用的敏捷实践和原则有所了解的读者。所以 初学者可能会发现这本书在某些方面缺乏细节描述。我同样不会给资深的敏捷教练推荐这本书；他们很可能对本书的绝大部分内容烂熟于心了。

不过，如果你已经阅读了大量的书籍，并且对敏捷软件开发充满好奇，却不知道从哪里着手，那么这本书对你再合适不过了。如果你对敏捷实践有一些基本的 了解，但对于自己能否成为团队中的敏捷专家没有信心，这本书同样适用于你。如果你身在一个敏捷团队中，已经实施的敏捷实践对你来说似乎没有产生预期的好 处，你也可以好好读一读这本书。

注意：这本书同样可以通过Safari在线书店获得。

关于作者

Ryan Cooper是一位敏捷软件开发者和教练。他是Ryan Cooper咨询公司的创立者。在他的家乡Halifax，他还是敏捷用户小组的创建人之一。他的博客可以通过www.onagile.com访问。

将欲歙之，必故张之；将欲弱之，必故强之；将欲废之，必故兴之；将欲夺之，必故与之。是谓微明。柔弱胜刚强。鱼不可脱于渊，国之利器不可以示人。

大意：

想要让它缩小，就一定先要让它扩张；想要使它削弱，就一定要使它增强；想要灭掉它，就一定要振兴它；想要剥夺它，就一定要给予它。这叫做隐藏意图。柔软的战胜刚直的，弱小的战胜强大的。鱼不可离开深渊，国家的锐利武器不可以在别人面前显示。

之所以对老子这段话特别有感触，是在其中的一句“将欲弱之，必故强之”的逆过来应用“将欲强之，必故弱之”。意思是你要增强它，就先要削弱它。

最近有幸与一位无论是公司还是世界范围都堪称顶级的开发大师结对编程了两天，获益匪浅。其实主要的收获不在具体技术细节，而在解决问题的方式。因为Mingle 接近2.1版本的Release 了，所以最近有些工作是在做性能调优。我和这位大师第一天所做的工作就是调整Card 的属性编辑性能。之前也与团队里面的一些成员进行过部分模块的性能调优。而这位大师做了一件与众不同的事情，让这句“将欲强之，必故弱之”强烈的撞击了我的脑袋。以至于这几天细细回顾起来，还觉得很有味道。大师在进行性能调优之前，将Mingle底层的JRuby Runtime 实例调整为一个，并且将所有的后台无关任务全部删掉。这也就使得，Mingle在每个请求下，只运行在一个线程中，而且功能不完善，速度甚至可能会因此变得缓慢，大大的“弱”化了Mingle。性能调优，本意在强化Mingle，为什么先要这样的弱化它呢？

开始的时候，我很不解的看着大师。后来大师给我仔细的解释了这样的好处：首先，所有的请求都会在一个线程中处理，那么你看到的东西是机器真的一个接一个的处理问题，很容易一眼看出最耗时的地方，虽然可能比实际的情况稍慢，但却一针见血；其次，去掉后台任务，的确让Mingle少了许多功能，这种性能调优的数据，跟实际会有些出入，可是后台任务的运行，经常会打印出一些日志，干扰了性能调优的日志文件，使你不容易发现问题，虽然跟实际的数据有些出入，但最慢的地方依然最慢，你优化了它，真实的数据也就得到了优化。也就是这样的弱化，是为了增强Mingle 未来的性能！

大师出手，不一样就是不一样！回来后，越揣摩越有味道！朱雀服了！朱雀服了！

 “将欲强之，必故弱之”，什么时候才可以修炼到这种地步呢？朱雀服了！

工作已来快六个月了，这半年生活丰富多彩，也做了许多事情。嗯，我该冷静冷静，回头看看。

半年来收获最为丰硕的是加入Mingle 的四个月。也是我接触RoR 的四个月，真的很感谢小组的朋友们，包括PC，晓哥，还有QianQian。他们不但让我熟悉了RoR，更能从如何写出好的代码方面上给我提供了许多帮助。所以最近的一个月，我会逐步将一些心得总结出来，回头看看是为了将来走得更远

在程序方面，还有最近在研究的Python 和PyGame，这要感谢我的TWU 朋友Matty 和Sanjay，他们一个多月前拉我加入一个叫PyWeek 的游戏编程竞赛，我们一起做了一个叫strlen 的游戏，我也贡献了不少代码噢，哇哈哈。这是我们放在Google Code 上的链接 strlen，你们想玩的话，可以去下载来玩玩噢，这是游戏截图

写游戏，我可是非常感兴趣的，所以以后也会将如何用Python 写游戏的过程，以及如何写出好的游戏代码的心得写出来

嗯，最近没事的时候还在研究战国和秦国的历史，春秋战国时代是中国文化大爆发的时代，音乐、文学、机关（工匠学）各个方面的人才辈出，只可惜汉代以后，废百家独尊儒家，使得许多值得保留的东西逐渐销声匿迹了。这是中国与西方不同的地方，西方文艺复兴后，科学和艺术大爆炸，从此强盛起来。我对这段历史一直很感兴趣，所以最近研究研究，打算重拾《史记》，再好好研读下正史。之后，也会总结总结的

最后啦，自然就是最近在学习的钢琴了。现在可以弹一些简单的练习曲了，希望年底会有大得提高吧

总结看似回头，实际上会让你跑得更快更远

  ThoughtWorks University 取经第二记

老师给我们准备了，TDD（Test Driven Development测试驱动开发）、结对开发、面向对象编程、测试与Mock、重构、自动化测试、持续集成等课程大餐。通过学习这些知识和技术，使所有学员可谓真真正正窥见了软件开发的流程，为以后在工作中大战拳脚打下了扎实的基础。即使是针对这些具体的技术培训，与国内大学所使用的以讲为主的授课方式完全相反，ThoughtWorks 采用让学员主动参与，随时提问，动手实践，及时总结等方式，争取让每次课程的内容被消化在课堂上。我们培训的地点就是公司租用旁边一家五星级酒店的会议 厅，整个大厅非常宽敞，学员们可以随时更换自己的位置，老师们平时使用投影仪和白板进行授课，如果需要他们会坐在学员旁边亲手指导，学员在实践过程中有了 问题，也可以立即跑到老师跟前询问解决方案，这样的环境非常便于学员之间、学员与老师之间的交流。例如在培训测试驱动开发的时候，老师并没有立即告诉我们 什么是测试驱动开发，而是让我们分成四个小组自己讨论二十分钟，每个小组在大厅的一面拥有一个白板，讨论结束后每个小组选派一个代表，根据白板上的记录向 所有学员和老师介绍你们小组理念中的测试驱动开发是什么，如下面的照片所展示，Kunal正在向全体同学介绍他们小组的观点，而所有其他的学员随时可以提出质疑，老师也可以纠正一些错误的观点。经过小组讨论的环节后，老师会对大家所阐述的各种观点进行查漏补缺和总结，通常总结的行为方式也是多种多样的，有可能直接用大白纸写出来然后贴在墙上，也有可能用思维图的方式画在白板上等等，这些方式都增强了我们收集内容的可视性也使讨论过程更高效。最后，老师再现了一个用测试驱动开发的完整实例，反复的强掉了测试驱动开发中设计大于测试的理念──即用测试书写你的思想，用代码实现该思想，而不仅仅只是一种测试开发方法的原理。这种让学员积极参与和进行演讲的教学方式，使得所有人对教学的内容都有了自己的理解，并深深地印在了脑海中。

其实对于ThoughtWorks，结对并不仅仅是应用在编程中，我们几乎做什么事情都结对，老师们结对讲课，学员们结对演讲，结对研究新技术，结对做课后作业，当然还有著名的结对编程了。结对的方式促使我们更频繁的沟通，更高效的知识分享，这 也是为什么我在上文中使用了结对开发而不是结对编程这个词的原因了。很有趣的事情是，老师们在上课时给我们传授结对思想的时候，让我们讨论的主题是结对的 好处和坏处。当被问到结对有什么坏处的时候，学员们怎么想都想不出来，没想到身为资深开发者的老师Khali大声地说到：“结对编程非常的累，因为你总是 全神贯注，而且总是有人盯着你，你必须工作呀。每天结对完之后，我都累得不想动了，当然结对的时候还是很有趣的。”对于这样的诚恳的答案所有的学员都爽朗 的笑了起来。回国后在ThoughtWorks项目管理产品Mingle团队的实际工作，让我体验到了结对的种种好处，业务分析员结对给我介绍软件的各种 功能，让我很快的了解到我们要做什么。资深的开发者跟我结对编程，保证项目进度的同时，也教给我许多编写代码的知识和技巧，更值得一提的是让我学会了他们 遇到问题的思维方式和解决问题的处理方法，这如果靠一个人独自摸索，真的不知道要花多长时间。直到工作几个月后，才真正理解到结对给团队带来的巨大好处， 当然每天也的确很累。

面向对象编程、测试与Mock、重构都是敏捷开发方法中所涉及的具体内容。ThoughtWorks University的老师通过两个小故事的开发让我们真的体会到了为什么以及什么时候使用与之对应的技术。老师们用一个关于飞机场的开发素材让我们了解 到面向对象编程中良好的封装性、单一职责原则、Liskov 替换原则（LSP）、递归算法、Strategy设计模式等开发知识。另外一个关于停车场的开发故事，让我们了解到了Mock对象在测试中的使用、重构的 必要性和艺术、Composite设计模式等知识点。拿飞机场故事为例，老师们在课堂开始的时候会给我们描述完整故事的一个小部分，然后每次给每个结对 （Pair）十分钟的理解需求和发问时间，五分钟的设计时间，十五分钟的开发时间；在开发的过程中要灵活的使用测试驱动开发、结对编程和重构的各个技巧； 在每个开发周期之后，如果没有任何一个结对完成了功能，则进行下一个十五分钟的开发周期，否则就会请一个结对上台展示他们的代码，在展示的过程中首先运行 测试保证功能全部完成，然后由该结对的成员讲述他们的实现思路和具体方法，可以随时发问和提出更好的方案，最后老师会进行总结并展示自己编写的代码以供大 家仔细分析。还有一点在培训开发方法的时候非常值得注意，其实对ThoughtWorks有过接触的朋友通常对ThoughtWorks的开发人员有一点 印象非常深刻，就是他们是一群使用开发工具尤为流畅的群体，他们不但可以熟练的运用各种开发工具，更能够飞快的使用工具的快捷键进行代码的编写。其实我们 在实现这些开发素材的时候，老师专门给我们培训过相关工具的快捷键，并且把最常见的快捷键书写在大白纸挂在我们的头顶，我们只要抬头便看得见，真正在开发 的过程中我们也会很努力的使用这些快捷键，很快得就可以灵活运用了。使用快捷键可以极大的提高开发速度，而且它更有助于开发者保持开发思路，如果你使用快 捷键非常熟练，往往在开发的过程中，不需要思考就可以实现几个视图、类的切换，否则使用鼠标时为了寻找按钮的那段停顿期，往往会让你的思路受到干扰，这也 可能是为什么那么多ThoughtWorker为快捷键乐此不疲的原因之一吧。

自动化测试、持续集成是敏捷开发技术中的重中之重。在ThoughtWorks University的培训课程中我们会学习，利用JUnit编写单元测试，利用Selenium进行功能性测试，利用Ant编写运行自动化测试的脚本，利用Subversion进行代码的持续集成，使用Cruise（或Cruise Control）作为自动化构建的工具等课程。老师给我们传授这些知识的的 最佳方法也就是让我们实际在开发过程中演练这些技术和工具。其实这些课程展现了在ThoughtWorks的真实工作流程：我们在测试驱动开发的过程中通 常会使用测试框架（JUnit）先编写测试，在开发完一个简单的功能后，会运行测试脚本（Ant），在本地运行所有的测试以确保编写的代码没有对别的功能 有所破坏；然后会用版本控制工具 （Subversion）将代码提交到代码库中；代码库中还包括测试人员编写的Selenium测试脚本；这时自动化构建工具（Cruise）就会开始自 动运行所有的测试，如果失败会给团队亮出红灯，表示软件处于不可用的状态，这时团队的成员就会集中精力来解决错误，自动构建工具还可以自动生成可运行的软 件以供客户试用。总之，代码库中的软件始终要处于可运行的状态，这在某种程度上也保证了用户可以直接试用软件，从而提出有价值的回馈信息。在 ThoughtWorks中国分公司有很多关于持续集成的小故事，其中最有趣的是同事李晓告诉我的关于一个下午听那首经典的“Only You”的故事：李晓根据构建的情况开发出了一个构建结果自动提醒的语音程序，如果构建失败就会播放指定的歌曲和最后提交代码的开发者的名字，有一次某人 提交了一段代码使构建失败了，结果始终找不到错误的来源地，整整一个下午办公室都激荡着这首著名的歌曲和某人的大名，据他所说那个时候该团队空前的一致集 中精力找错误。在ThoughtWorks中跟这些很有创意的同事们一起工作，总是会有新的惊喜和收获。

最后的测试──项目评估

前五周的知识积累，使所有学员都迫不及待的希望在某个项目上灵活运用一下，这就是最后一周的实战内容──一个公司内部使用的项目，这 个项目完全由学员自行开发，老师们扮演客户的角色，开发结束后会直接供公司内部使用或者由别的团队接管继续开发。在紧张的一周开发过程中，所有学员每天九 点到下午三点是实际的开发过程，下午三点到五点是向客户展示，询问意见，以及对当天团队情况进行总结和信息回馈的过程。每天学员中都会有人扮演 IM（Iteration Manager）负责管理开发的具体事宜，首席BA（Business Analyst业务分析员）负责所有BA事宜的决断，首席DEV（开发人员）管理开发团队，首席QA（测试人员）调空测试人员的任务。各个不同的领导者角 色每天都会在不同的学员中进行轮换，以满足绝大多数愿意尝试管理角色的学员都有机会尝试。整整一周的评估，真正地体验了什么叫“魔鬼客户”的难缠程度，也 许老师们的目的就是让我们体验一下大强度、高压力、多任务的工作环境。第一天，意料中的混乱，有人把未经测试的代码提交到代码库中去了，所以构建库对我们 展示了一整天晚霞般红通通的笑脸，在当天的展示阶段，我们战战兢兢的向脸上阴云密布的客户展示了惟一一个能拿得出手的开发功能。不过当天之后的总结和信息 反馈阶段，学员们一起努力提出了很多有效地解决方案，之后的每一天都会有很大的改观，最后我们成功的提交了七个完全复合客户需求的功能，老师们对我们的表 现也非常的满意。终于，我们成功的毕业了！！！

总结

其 实还有许多有趣的故事还记忆犹新，比如为了驱散每日中午的困顿，大家会把各个国家的游戏集合起来，每天中午都一起玩一个，我们称这种活动为“振奋精神”； 每天下课后都会有学员自己主持的技术介绍演讲，学员可自愿参加，切身体会一下当前又新又优秀的各种技术，从而更好地面对自己即将到来的工作。就这样思维活 跃的人走在了一起，迎面遇到的每一个困难都去努力解决，大家团结在一起体验了一次软件开发的盛宴，最后告别终究还是会来临，不过美好的记忆和所学的知识却 永远的伴随左右。仅以此文献给我ThoughtWorks University的各位好友，同时也希望本文对各位读者能有所启迪。

movie link

 The story is kind of old, but one thing interested me. The whole story is telling the man wanna figure out who he is and who he wanna be. This is similar with one story put on www.kaixin001.com by one of my friends who is a ThoughtWorker, too. That story is telling about one business man tried to change one fisher's life. Both of the stories ask me one question:"Who are you? Who you wanna be?"

 I think I'm lucky, I have my plan, and I exactly know what I wanna be. But some people can't, especially those young people(sorry, I'm young, too) , they just lost their destination. Their lives are not what they want, they work because they need to. This maybe not only happenning in China, also in other countries

 If you are not happy, and you don't know why you should live in this way, So you may find what you wanna be. Ask yourself, nobody can answer instead of you. But only one thing more, don't lose your confidence

 everyday is a new day close to your dream

 OK, too much philosophy. That's not my style, to be honest

这篇文章可能与程序员上的略有不同，因为后来L MM 帮我改得更好了，不过这是我的Blog 所以贴出来的自然是原文

在有些人的眼中，ThoughtWorks是一群拿着卡片到处贴，到处走的奇怪人群组成的软件咨询公司。其实为什么使用卡片作为理解用户需求的主要机载体， 在我去TWU之前也很疑惑。后来，在一堂介绍如何使用卡片理解需求的课程中，终于了解到原来其中包含了这么多奥妙。首先卡片很小，这就迫使业务分析员不能 将太多的内容放在同一张卡中，由于一个迭代周期通常是两到三周，需要给用户展示一些能用的系统功能出来，这样就会引起整个团队思考许多有价值的问题，什么 是最紧要的？什么是系统的核心？我们要用多长时间来完成这些卡片上的内容？第一个迭代周期能完成多少卡片？我们的团队开发速度是多少？等等。其次，卡片在 卡片墙上是可移动的，因此它很灵活，就如下图所示，可以将卡片放置在不同的队列中，通常我们用“在分析中”、“在开发中”、“在测试中”、“结束”等一些 状态表示卡片所处的不同状态。这样，当所有团对人员，需要了解当前项目的进度状况时，只要站到卡片墙前，就可以一目了然，如果处理不同卡片的小组需要彼此 沟通，在卡片墙上，可以用最快的速度找到相应的人员，甚至，当你有疑惑的时候，卡片可以拿下来仔细研究，只要记得最后放回去就好。卡片的最后一个优点就是 对当前项目进行评估，举一个简单的例子，当一个团队的开发状态是绝大多数的卡片都集中在“在开发”的队列中，就表示当前开发团队处于业务分析员和测试人员 无事可干，但是开发人员又过于繁忙的不健康状态。什么原因导致的呢？可能是开发速度过慢或者是业务分析员写的卡片粒度过大，导致开发人员无法及时的完成。 由此，当我们站到一个团队的卡片墙之前，我们看到的不仅仅是一些简单的卡片，更是整个开发团队的开发状态的展示。一张张小小的卡片却包含了如此多的内容， 这真的是我们始料不及的。当然卡片并不是完美无缺的，对分布式团队开发就是卡片墙的致命弱点，但这些问题在ThoughtWorks的Mingle软件中 都得到了很好的解决，卡片对我们来说更是一种以用户为中心，以团队沟通为中心的开发思想，而不仅仅是一种开发方法。

针 对眼前的需求，小步前进，不做过多的设计，也是敏捷软件开发的核心思想之一。ThoughtWorks University通过一个早上的摆积木课程（Lego Game）让我们充分的理解了过多设计的弊病。这次课程的整体任务是创造未来物种，类似于造电话课程，同样分为三个迭代周期，有一位老师作为客户伴随着我 们进行开发。这一次，老师们一下给了我们许多点数不同的需求，每个需求对应一张卡，每张卡上有不同的分数表示这张卡的难度，每次迭代有五分钟的讨论，需要 确定这次迭代都要完成哪些功能，有十分钟的设计，还有十五分钟的开发过程，每次迭代后大家要讨论哪些做得好，哪些做得不好的地方。第一次的迭代往往是犯错 误最多的地方，我所在的小组向客户许诺了总共加起来十分的卡片，在设计过程中又做了许多不必要的假想，过多的专注于给未来的需求留下余地，而将自己开发的 过程束缚住。最后仅仅搭起来了动物的头和身体，可是客户要求的是一个完整的动物，所以第一次迭代我们只有零分，客户非常的失望。ThoughtWorks 就是这样，通过学员的犯错误，让我们自己体会，然后通过讨论，让我们自己总结出具体的方法，老师们则是在旁边指引，这样的感受怎么能不深刻呢？经过讨论， 我们制订了自己的方针：少许诺，少设计，好好做核心模块。就这样，最后我们创造出了未来的一个物种（还有它的孩子）。

迭代的过程也是ThoughtWorks进行敏捷过程培训的一个重要方面。还是继续我们的游戏旅程吧：这一次老师让我们分成三个小组，分别从培训大厅的一端 将气球搬运到另一端，每一组有两个人负责装运，两个人负责撑袋子，一个人负责搬运，哪一组能在最短的时间内，将最多的气球从一个口袋中运到另一侧的口袋中 就算胜利，如果过程中任何气球掉在路途中，则不可拾取。第一次的规则是只能运一次，整个过程给人的感觉就是搬运的人花了很多的时间，承担了过多的责任，而 其他的四名队员起不到任何的作用，只能边喊边焦心的等待。第二次的规则几乎与第一次一样，但搬运人可以多次的运输。结果第二次，我们不但出色的运输了所有 的气球，而且还比第一次所花的时间更少。玩完游戏的讨论过程中，我们逐渐的明白了，第一次运输就好比传统的瀑布式开发，开发人员承担了许多的压力，缺少沟 通和其他人员必要的帮助，闭门造车造出来的东西，往往并不是客户心目中想要的东西；而第二次运输就好比多次迭代的开发过程，开发人员得到更多的信息回馈以 及业务分析员和测试人员的帮助，因此能够开发出更好的软件产品。就这样，我们不但理解了迭代开发的原理，更通过亲身的体验明白了这样做是行之有效的。