禅意的对谈
April 27th, 2010
领导：大师你看，我们公司多久能达到敏捷的状态呢？
大师：五年。
领导：大师有所不知，我们公司执行力很强，只要我一句话下去，所有人都会照办。
大师：哦，那么十年吧。
（如有雷同，纯属巧合。请勿对号入座，谢绝跨省追捕。）
去了QCon，又回来了
April 25th, 2010
去QCon做了个演讲，把 演说之禅 里学到的东西试用了一把。据说，效果还不错。
每次讲真实的故事，就会觉得，讲得有劲，似乎别人听得也有劲。
问我，在研究什么呢？没有在研究什么。研究人算是研究吗？Fearless Change 是个挺好的典范。
与人斗其乐无穷，也有术与道之分。一件件实践着的时候，常常归纳模式，确保原则没有变。那就不会误入歧途了吧。
又回到实践的战场了。进取中的常自反省，很好。
《持续集成》第二版译出
April 18th, 2010
《持续集成》第二版的中译本 。感谢雷镇的奉献。
如是我闻，一开始，我将已集成的源代码复制一份到本地计算机。这可以通过从源码管理系统的 mainline 上 check out 一份源代码做到。现在我拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。
一旦完成了修改，我就会在自己的计算机上启动一个自动化 build。
当我 build 成功后，我就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过 mainline。这时我需要首先把别人的修改更新到我的工作拷贝中，再重新做 build。如果别人的代码和我的有冲突，就会在编译或测试的过程中引起错误。我有责任改正这些问题，并重复这一过程，直到我的工作拷贝能通过 build 并和 mainline 的代码同步。
一旦我本地的代码能通过 build，并和 mainline 同步，我就可以把我的修改提交到源码仓库。
然而，提交完代码不表示就完事大吉了。我们还要做一遍集成 build，这次在集成计算机上并要基于 mainline 的代码。只有这次 build 成功了，我的修改才算告一段落。
无畏·勇气
April 17th, 2010
做360度评价。发现别人对我的认知和我的自我认知之间，差别最大的是“fearless”这项。
原来那么多人认为我”always fearless”，还有”like challenge”。 天知道我有多胆小。风险只会让我焦虑并加重颈椎病症状。
风说，要勇敢，至少装作勇敢的样子，很少有人能看出两者的差别。（知人论世就是，你不仅要知道大家都认为他很勇敢，还要知道他其实只是装作勇敢的样子。）
Deliberative和Context的特质，使你面对风险时思考它的前因后果。对它认识得更多，也就更容易去承受它。所以让你看起来无畏。可能这不是无畏（不害怕），而是勇气（害怕也敢于去做）。郭晓如是说。
也许知道自己胆子小，就会认真去计算一个uncertainty的成本和收益；反而成天嘴上喊着“敢于尝新”的某些人，面对风险总以“要想清楚”做借口。这么一来，岂不是比我更胆小了么。
原来勇气是一种与知识、与经验、与计算有关的东西。嗯，符合敏捷价值观。
持续集成不是敏捷的基础
April 10th, 2010
它就是敏捷本身。或者说得更大一点，持续集成就是软件交付本身。
持续集成反映交付形态。这句话实际上是肖鹏说的。实际上是肖鹏很久前说过然后李丰用了很长时间理解了然后再说出来然后我听了一耳朵然后又用了很长时间理解然后再说出来的。持续集成是什么样，不是由持续集成负责人设计的，而是由软件交付形态决定的。
所以持续集成反映交付团队的一切现状和问题。分层分级的持续集成，说明团队与团队之间的沟通成本高。层级之间以二进制还是源代码集成，代表团队之间的依赖层面和交付形式。测试用例失败时构建不失败，说明交付团队没有可依赖的质量标准。构建的频率，代表团队关注质量的频率。每日构建，说明质量没有内建在生产流程中，全靠“守门人”把关。
没有持续集成，说明交付流程是混乱不清晰随机的。
（推论：关于“敏捷是不是必须有持续集成”的讨论再也不想听到，因为持续集成不是敏捷的组成部分，它就是敏捷本身。连交付流程都没有还提什么敏不敏捷的，没有意思。）
