投资战略与敏捷转型
December 4th, 2011
和 上一篇博客 有关：恰好在读了《 竞争战略 》之后，又温习了一遍 成长-份额矩阵 ，然后就跟客户聊企业的敏捷转型。这时我终于清楚地意识到：敏捷引入的策略和应该与portfolio管理和投资战略紧密相关。
首先，狗是不需要什么敏捷转型的。当然也不好说得那么绝对，毕竟最起码减员增效可以让资产剥离的时候顺利一点。但是太多企业的问题不是减员增效，而是盲目追求规模舍不得把狗杀掉。这就是另一个话题了。
另外三个象限的敏捷转型策略非常有趣。效率，质量，用户。敏捷的三个关键词其实是不均等地对应在三类业务象限上的。
野猫（或者“问号”）的敏捷关键词是用户。份额小、成长快的野猫业务，最大的风险是根本就没人用。所以这时候要准确地抓住用户需求，提出强有力的价值声明，关注用户体验，以最小工作量抓住眼球并获得转化率。对于野猫业务，敏捷引入应该从 体验设计 入手，首先进行 快速项目启动 ，然后以迭代方式迅速交付并获得反馈。
明星的敏捷关键词是质量。份额大、成长快的明星业务，非常容易因为“Quick & Dirty”的开发方式而变成焦油坑甚至直接影响交付。这时候需要偿还技术债务、打好根基，才能承受不断加大的交付压力。对于明星业务，敏捷引入应该着重关注 持续交付 ，从持续集成和自动化测试入手，向下改进代码质量和架构质量，向后借助 DevOps 打通交付的最后一公里。
金牛的敏捷关键词是效率。份额大、成长缓慢的金牛业务，质量和交付风险并不高；同时因为规模大、涉及人员众多，些许效率提升就能带来明显的收益。所以金牛业务的敏捷引入思路应该是以稳为主、持续改进。通过 持续集成中心 等方式提升项目透明化程度，首先掌握现场状态、建立反馈机制，然后逐步改进、逐步提升人员能力。
结论：不同的业务类型需要不同的敏捷转型策略与实践。将投资战略与敏捷转型策略结合，有助于更有效地引入敏捷。
引论：所谓“全公司统一的敏捷流程”就是反敏捷。人和交互重于流程和工具。
了解你的客户
December 18th, 2010
为什么你在兴致勃勃地做着演讲，而你的客户不像你期望的那样？为什么他不断看表？为什么他盯着你却没有真正在看你？为什么他似乎另有心事？
你真的了解坐在你对面的这个人吗？你知道他到底关心什么吗？
（ All For One 似乎是一本好书。）
Lost + Found: Enthusiasm
September 18th, 2010
去了一趟澳大利亚。短短的几天时间里，见了Martin, Jim, Ola, Chris, Jez, Jason, Ines, Marina, Evan…一大堆牛人。在办公室跟一堆人聊天，跑到农场跟一堆人聊天，再跑到客户现场跟一堆人聊天…不知不觉间，连续出差一年中慢慢磨掉的热情，又回来了。
一个强大无匹的组织，开始面对内忧外患，于是他们想要改变。成千上万的人，把一个宏大的目标逐步分解成中期目标、短期目标和马上要做的事，然后开始一点点改变、一点点学习。除了所有的价值、意义，这本身就是一件如此有趣、如此令人好奇的事。而且，就在我面前，也有那样的成千上万人。看着一个个社会实验或成功或失败，这几乎可以纯粹是求知欲的问题。
回头看看，这一年学到了好多。尽管有很多无聊重复的事情，但是，还是学到了好多。再看得远一点，比起第一次去墨尔本时压根听不懂别人谈些什么，真是成长了不少呢。所以，还想学得更多，还想知道更多有趣的事。
（黄亮似乎也有同样的感受，所以 Test Everything 又回来了。只是，不知要到什么时候，我们才能不用这样隐晦的表述，把所有的故事原原本本地讲出来。）
作为管理工具的持续集成
September 3rd, 2010
有一个敏捷推行人，给她的团队设立了一个规则：每个函数不要超过30行。一开始，领导们都说，很好，很有道理。可是真的做起来，就发现遗留代码里有这样那样的特殊情况。紧跟着，开发人员也有了抱怨：我这里写32行又有什么损害呢？为什么一定要那么死板呢？于是，一个又一个的口子被打开。当然，你可以想象，有了越来越多的口子以后，“改善代码质量”也就成了纯理念──跟没有规则之前没什么区别。
我打算怎么做这件事呢？
- 把持续集成搭起来，只做编译。编译失败就红。红了就不能转测试，红了就必须马上修复，红了就是在阻塞整个团队的工作，红了就是最高优先级。让领导开始盯住持续集成。破坏构建就是和整个团队作对。
- 大家讨论一下，30行是不是一个合适的门限？如果不是，35行？40行？50行？行。我们就把门限定在50行。把静态检查放进持续集成。旧的代码我们既往不咎。就算现在有100个函数超过50行吧，没关系，我们容忍它。但是如果出现第101个长函数，就会让持续集成变红，要马上修复。
- 每次构建失败就是一个教育和学习的机会。一个人第一次写出长函数，我跟他一起重构；第二次写出长函数，我要看着他用我教的方法重构；第三次再写出长函数，那就要让领导来关心一下了。没有能力可以学，有了能力还破坏规则，说不过去了吧？
- 现在大家都学到怎么写更短小的函数了。偷偷把门限降低到45行试试？又多出来10个长函数。拉上几个开发者，我们来搞一次代码优化活动，把这10个长函数解决掉。于是大家又学到了更多的重构技巧。于是45行的门限变成了持续集成的要求。
- 两周搞一次代码优化学习会，降一次门限值。两个月以后，30行的标准就放在了持续集成里。如果有时间就去重构以前遗留的长函数，如果没时间就留着吧，至少大家已经不会写出新的长函数了。
先讲道理，再定规则，然后帮所有人提升能力以遵守规则，随着能力的提升逐渐拉高规则。30行的规则落实不下去？我就不信了。
把持续集成作为团队规则的自动、可视执行者，于是敏捷推行人就不必扮演那个凶恶的执法者，只需专心帮人排疑解难。持续集成把违规行为变成一个人与整个团队的对立，而不是一个人与另一个人的对立。
Migrating To A Decent SCM
September 1st, 2010
I know that lots of organizations are still using old-expensive-counterproductive configuration management systems (ClearCase, VSS, etc.). I understand the fear that prevents many of them from moving to a decent SCM (Subversion, Mercurial , etc.). I’ll try to tell a story about that kind of migration, which might alleviate the fear.
A huge company, with 40,000+ software developers, with 10+ years history using ClearCase, wants to migrate to Subversion, because of SVN’s encouragement to atomic commit and optimistic locking. The movement is still ongoing. Every single pace involves at least one delivery team, normally with 100+ programmers in it.
The movement must be as seamless as possible, because people are pushed to meet their next milestone. For a codebase sized over 4GB, we made the migration in a week:
- Monday
- Export the existing codebase and check it into SVN AS-IS—it’s time consuming so you have enough time for following items.
- Send mail to everyone to inform the migration plan, ask them to install SVN client if they haven’t.
- Make sure everyone can access new SVN repository.
- Tuesday
- Check out the codebase from SVN and build it, to make sure you are not breaking anything—that’s why you really should migrate AFTER you have a decent build script.
- Compose a shell script to synchronize from ClearCase local view to SVN working copy. Synchronize frequently and build every time.
- Wednesday
- Clean the codebase: legacy repositories often have lots of garbage (temp files, compiled binaries, etc.) checked in, it’s now a chance to do some clearance, delete and ignore them from SCM. Just don’t break the build.
- Install continuous integration instance for the codebase in SVN.
- Synchronize and build frequently. Ask people to fix build if it breaks.
- Thursday
- Send mail to everyone, ask them to commit any modifications by the end of day, and tell them “there’s an SVN training tomorrow morning”.
- Keep doing clearance. Synchronize and build frequently.
- Friday
- Disable write-access to ClearCase.
- Training: Configuration Management & SVN. People need to understand some SCM principles to make a better use of SVN—at least not to mess up the codebase with garbage again.
- At the same time, synchronize a last time, build, check in.
- Package your working copy and upload it to a shared directory: it’s much faster to copy and unzip, than checking out from the repository. Mail everyone about how to get a working copy and make first commit.
- Publish your CI to the team. It’s now the team’s CI.
That’s it. Now your team is on SVN.
有效访谈的技巧
August 30th, 2010
你是一个外来者，你想了解一个完全陌生的团队。最快的方式就是找到他们，和他们谈话，让他们告诉你。为了让谈话更有效，你会需要一些小技巧。
- 解除他们的戒心，尽量。戒心无非来自一个很简单的原因：如果说实话不会有好处、甚至会有坏处，那么人们就不会说实话。因此你要先告诉他们，你需要快速了解信息，不是为了任何考核，只是为了帮助他们改进──告诉他们，你会在未来几个月里跟他们一起改进。
- 话题明确。每场访谈开始之前，把你要谈的话题写在白板上，以及具体要了解哪些信息，以及计划用多长时间来谈。让进入房间的人在第一时间知道你要他干些什么，这样他就不会更紧张。并且在没话说的时候可以很快找回话题。
- 微笑。有很多人说过这事，可是真的有很多人没有做到。微笑，活泼一点，拿自己开个玩笑（例如嘲笑自己刚在白板上写下的字）。在访谈中你会必须制造紧张气氛（例如你会有意指出两个人对同一件事的不同描述），保持微笑，把它变成一件好玩的、和所有“人”对立的“事”。不要让任何一个受访者感到寂寞或者紧张，因为这时候你还不知道究竟谁才是值得信赖的人。
- 记下别人说的话。更多的人说过这事，可是我们真的做得都不好。不要一边跟人对话一边在记事本上写字，更不要用电脑做记录。这些行为会让你获得权威感，会让受访者感到不安──“他有代表权威的记事本/电脑，而我仿佛裸体”──甚至为了抵抗这种不安也拿出记事本来写字。但这些行为不会帮你得到更多有效的信息。在白板上做记录。把他们说的事情画下来。这会让受访者感到，你们在一起画一个作品。他们会告诉你，什么地方画得不对，还缺少了什么，这是你的记事本上永远不会出现的东西。
- 问他们有什么想告诉你的。当你问完了所有的问题，问他们：还有什么想告诉你的，有什么问题，有什么痛点。你在这里的原因是你要帮助这些人。这些人最关心的事不一定是你最高优先级的事，但一定不是你应该忽视的事。
- 最后，不要相信访谈。用眼睛去看。受访者一定会告诉你假话。有这样的觉悟之后，访谈才会真正是有效的。
个体与交互 重于 过程和工具
July 26th, 2010
曾经我认为，敏捷的各种实践，只要有了标准化的动作，加上一点点定制，加上PDCA/SDCA，就能做好。迈向敏捷之路，是可以唯一定义并且重复实施的。比如说持续集成，大师说 “在自己的计算机上启动一个自动化build”是重要的──我们把它叫做“本地构建”。做不好本地构建，提交构建失败率就会高，对持续集成的信心就会失去。这个问题，和它的解决方案，都是确定且可重复的。
可是这个团队让我吃惊了。他们一直没有真正意义上的本地构建。但他们真的相信持续集成──不仅仅是几个领导，是整个团队，真的相信：如果每天发现的小问题不能及时解决，那么到版本上线时一定会被客户骂得狗血淋头。他们不想被骂，他们也不想同一个战壕里的战友被骂，所以他们就把持续集成做好了。尽管没有真正意义上的本地构建，就靠着原始简单的代码评审，更认真的态度，他们就真的把持续集成做好了。
这个团队颠覆了一些正在我脑中渐渐成型的东西，让我想起了一些原本印象深刻但被渐渐遮掩起来的东西，比如敏捷宣言的第一条：个体与交互 重于 过程和工具。
面对巨大组织时强烈的无力感、无助感会让“敏捷推行人”们（包括我自己在内）不自觉地选择把自己的定位拔高──也许真是想帮助更多的人，也许只是想从残酷的现实中逃开，抑或两者兼而有之。但这些人不会做高层面的事情。于是离开低层面、离开具体事务的结果就是不知道该做什么，就是把敏捷推行简化为过程和工具的推行。
有一个敏捷推行人对我说，我负责几十个项目的改进，如果每次只到一个项目去做具体的事，对整体的帮助很小。我对她说，也许你救不了所有的鱼，但被你救的这一条鱼，它会在乎 ，它会得救。在反复思考如何拯救所有鱼的过程中，其实你什么也没有做，没有一条鱼真的得救。
敏捷的改变，最终是一个一个人的改变。过程和工具会帮助你。但如果把敏捷简化成过程和工具，你就在一步步远离敏捷，因为你已经违背了敏捷宣言的第一条原则。
不做小叮当
July 14th, 2010
ZD亲热地搂着我的肩膀说：“还是你有本事啊，这次才看到你的能力有多强。”我苦笑着说：“我的英名早晚要毁在你手上。”
他是我的客户，也是老乡，而且常常配合很默契。
第一次，二百多人的团队分散在两个城市五个办公地点。ZD对我说，那个产品，发货量巨大，是整个公司最赚钱的部门，客户遍布全球，要是把它搞定了，意义重大。（当时ZB在旁边热情澎湃，被我俩联手泼了一盆冷水。那是我第一次发现，和ZD配合有不需准备的默契。）我沉吟良久，说它真的风险太大，我真的不敢做。但最后我还是去了，因为一个不能让ZD知道的理由。
第二次，一支孤零零的团队正在被一个巨兽客户折磨得要死要活。ZD对我说，这次能让客户感受到我们的变化，要是把它搞定了，意义重大。我又沉吟良久，说它真的真的风险太大，我真的真的不敢做。但最后我还是去了，又是因为一个不能让ZD知道的理由。
我跟他说，其实只是运气好。他笑笑，不信，或者说是装着不信。
小熊说，每个问题解决者都有多拉A梦情结，而康夫每次痛扁技安之后灿烂的笑容便是对小叮当最好的褒奖，是他继续从口袋里掏出法宝的源动力。我不得不承认，挑战一下自己并且挑战成功（不论这成功的原因是什么）的感觉是很爽的。我想ZD一定也知道我的爽感，所以他笑而不语。
所以，尽管真的很想亲眼看到这个大雪球轰然滚下的最后一刻，尽管真的很嫉妒 小熊的博客 比我写得更有料并且更有文采，还是应该抽身了。让自己沉浸在小叮当帮助康夫破涕为笑的愉悦之中，这不是我想要的。
何况，ZD你懂的，我不能等到英名真的毁在你手上的那一天。
对象训练营：简介
July 1st, 2010
对象训练营是 ThoughtWorks 历史悠久的入门培训课程，而其中谈到的对象原则和实践历史就更悠久。面向对象的思想明显地分为两个阵营：
- Rational。强调建模，推崇UML和形式化方法。这些人最初使用ADA为军方开发软件，系统本身并不复杂。软件正确性非常重要，因此重视对设计的评审。
- Tektronics，一家电子设备测试工具制造商。强调示波器的可插拔性。使用新的编程语言Smalltalk，因为它的灵活性。这支团队中涌现了Ward Cunningham、Kent Beck、Sam Adams等敏捷世界的大师。使用Smalltalk，他们在设计和编码之间快速切换，这也是现在Agile的基本工作方式。
80年代中期Tektronics团队解散，Sam Adams加入KSC咨询公司，当时在IBM负责与KSC接口的Fred George从他那里学到了Tektronics的对象思想。后来Fred George加入ThoughtWorks，并开创了对象训练营。因此本课程是基于Tektronics的对象思想，而不是Rational的。
本课程采用苏格拉底式教学法，简单说就是学员自己教自己。我们会用问题来引导你，但不会手把手地教你正确答案。你会受阻，但这是好事。正如Fred Brooks所说：“好的判断来自经验，而经验来自糟糕的判断。”记住受阻的时刻，并从中学习，这些经验会成为未来良好判断的基础。
本课程至少3/4的时间会用来给学员自己动手练习编程。如果你喜欢编程，这些练习会很有趣。我们会针对练习中写出的代码展开讨论，所以每次讨论都会把某个pair的代码用投影展示出来供大家讨论。一开始也许你不好意思展示自己的代码，但是请大胆展示。被批评是最好的学习机会。
课程内容分为两大部分：（一）对象原则与敏捷实践，（二）设计模式。
《持续集成建设》引言
June 24th, 2010
软件开发的最后一英里
在任何软件开发过程中都有一个重要的部分：通过某种构建（build）流程，将已经编写好的源代码变成可用、能为客户创造价值的软件。尽管知道构建的重要性，但是我们仍然会经常因为构建中的各种问题而惊讶不已。曾有多少次，在所有人都认为“开发已经完成”之后，我们还要经历漫长而痛苦的编译、打包、联调、测试、上线过程？在代码都已经写好之后，我们还曾付出了多少个通宵的代价让软件真正可用？
编写源代码不是软件开发的全部。从源代码构建出可用的软件，这个过程也被称为“软件开发的最后一英里”：胜利似乎就在眼前，但各种潜藏的危机可能这段短短的路程变得艰难万分。
持续集成就是构建过程
构建之所以如此困难，是因为在绝大多数软件组织中，构建过程有以下几个特点：
- 它是一个神秘的、不可见的、只（模糊地）存在于少数人大脑中的过程
- 它是一个需要人工操作的、耗时费力的、容易出错的过程
- 它是一个偶尔为之的、缺乏练习的、充满未知风险的过程
为了减少“最后一英里”的浪费，让艰险的最后一英里成为坦途，我们需要将构建过程明晰化、自动化、频繁化。持续集成就是一个将构建过程明晰化、自动化、频繁化的实践。通过使用软件工具来实现自动化的构建过程、展示构建结果，原本虚无的构建过程就成为了一个实际存在的、可以重复进行的、可以被有效管理的实体。从这个意义上来说，持续集成就是构建过程本身：只有以持续集成的形式呈现的那部分构建过程，才是确定并可靠的；“最后一英里”中尚未被纳入持续集成的部分，仍然是不确定和有风险的。
