透明思考

Transparent Thoughts

  1. 敏捷之旅预告：双城记

    在第一个城市里，一支团队在开发某种电信交换机。他们距离客户很远，交付周期很长，跟硬件关系很多，技术栈很底层。这个团队经常在加班。

    而第二个城市的团队做的是业务软件。标准的J2EE架构，每个月都有版本上线，客户天天追着屁股骂他们。他们也经常在加班。

    两个团队都想解决自己的问题，他们选择了同一个药方：敏捷。没想到，当咨询师来到，两个团队所做的改进却大相径庭。

    两个团队又有一点相似之处：在迈出了第一步，解决了一些切肤之痛之后，他们没有停下脚步。他们都在思考，如何继续进步。在最初由咨询师指导的“猛改”之后，他们又分别做出了一些自己的改进。

    这就是我要讲的故事：双城记。

    （想听这个故事，请参加敏捷之旅杭州站。）

    •

  2. Lost + Found- Enthusiasm

    去了一趟澳大利亚。短短的几天时间里，见了Martin, Jim, Ola, Chris, Jez, Jason, Ines, Marina, Evan…一大堆牛人。在办公室跟一堆人聊天，跑到农场跟一堆人聊天，再跑到客户现场跟一堆人聊天…不知不觉间，连续出差一年中慢慢磨掉的热情，又回来了。

    一个强大无匹的组织，开始面对内忧外患，于是他们想要改变。成千上万的人，把一个宏大的目标逐步分解成中期目标、短期目标和马上要做的事，然后开始一点点改变、一点点学习。除了所有的价值、意义，这本身就是一件如此有趣、如此令人好奇的事。而且，就在我面前，也有那样的成千上万人。看着一个个社会实验或成功或失败，这几乎可以纯粹是求知欲的问题。

    回头看看，这一年学到了好多。尽管有很多无聊重复的事情，但是，还是学到了好多。再看得远一点，比起第一次去墨尔本时压根听不懂别人谈些什么，真是成长了不少呢。所以，还想学得更多，还想知道更多有趣的事。

    （黄亮似乎也有同样的感受，所以Test Everything又回来了。只是，不知要到什么时候，我们才能不用这样隐晦的表述，把所有的故事原原本本地讲出来。）

    •

  3. 贪婪与恐惧

    有个小姑娘对我说：“我们真的很想用TDD的方式来开发，可是我们的基础太差了，我们真的能做到那样吗？”

    人性的两大弱点：贪婪，和恐惧。亲眼看到了美好的可能性，于是迫不及待想要得到它，是为贪婪。一旦理想与现实抵牾，马上开始担心是否天堂遥不可及，在忧心忡忡中停止了前进，是为恐惧。

    不要贪婪。静下心来把远景细化成一个个可以实施的细小改进，把一件件小事落实做好。不要恐惧。不要停下自我改善与帮助别人的步伐，在看不到山顶的时候也不要踯躅不前。每天向上走一点，也许到不了天堂，一定会比现在好很多。

    （与WJ共勉）

    •

  4. 作为管理工具的持续集成

    有一个敏捷推行人，给她的团队设立了一个规则：每个函数不要超过30行。一开始，领导们都说，很好，很有道理。可是真的做起来，就发现遗留代码里有这样那样的特殊情况。紧跟着，开发人员也有了抱怨：我这里写32行又有什么损害呢？为什么一定要那么死板呢？于是，一个又一个的口子被打开。当然，你可以想象，有了越来越多的口子以后，“改善代码质量”也就成了纯理念──跟没有规则之前没什么区别。

    我打算怎么做这件事呢？

    • 把持续集成搭起来，只做编译。编译失败就红。红了就不能转测试，红了就必须马上修复，红了就是在阻塞整个团队的工作，红了就是最高优先级。让领导开始盯住持续集成。破坏构建就是和整个团队作对。
    • 大家讨论一下，30行是不是一个合适的门限？如果不是，35行？40行？50行？行。我们就把门限定在50行。把静态检查放进持续集成。旧的代码我们既往不咎。就算现在有100个函数超过50行吧，没关系，我们容忍它。但是如果出现第101个长函数，就会让持续集成变红，要马上修复。
    • 每次构建失败就是一个教育和学习的机会。一个人第一次写出长函数，我跟他一起重构；第二次写出长函数，我要看着他用我教的方法重构；第三次再写出长函数，那就要让领导来关心一下了。没有能力可以学，有了能力还破坏规则，说不过去了吧？
    • 现在大家都学到怎么写更短小的函数了。偷偷把门限降低到45行试试？又多出来10个长函数。拉上几个开发者，我们来搞一次代码优化活动，把这10个长函数解决掉。于是大家又学到了更多的重构技巧。于是45行的门限变成了持续集成的要求。
    • 两周搞一次代码优化学习会，降一次门限值。两个月以后，30行的标准就放在了持续集成里。如果有时间就去重构以前遗留的长函数，如果没时间就留着吧，至少大家已经不会写出新的长函数了。

    先讲道理，再定规则，然后帮所有人提升能力以遵守规则，随着能力的提升逐渐拉高规则。30行的规则落实不下去？我就不信了。

    把持续集成作为团队规则的自动、可视执行者，于是敏捷推行人就不必扮演那个凶恶的执法者，只需专心帮人排疑解难。持续集成把违规行为变成一个人与整个团队的对立，而不是一个人与另一个人的对立。

    •

  5. Migrating To A Decent SCM

    I know that lots of organizations are still using old-expensive-counterproductive configurationmanagementsystems (ClearCase,VSS, etc.). I understand the fear that prevents many ofthem frommoving to a decentSCM(Subversion,Mercurial, etc.). I’ll try to tell a story about that kind of migration, which might alleviate thefear.

    A huge company, with 40,000+ software developers, with 10+ years history using ClearCase, wants tomigrate toSubversion, because ofSVN’s encouragement to atomic commit andoptimisticlocking. The movement is still ongoing. Every single pace involves at least one delivery team,normally with100+ programmers in it.

    The movement must be as seamless as possible, because people are pushed to meet their next milestone.For acodebase sized over 4GB, we made the migration in a week:

    • Monday
      • Export the existing codebase and check it intoSVN AS-IS—it’stime consuming so you have enough time for following items.
      • Send mail to everyone to inform the migration plan, ask them to installSVNclientif they haven’t.
      • Make sure everyone can access newSVNrepository.
    • Tuesday
      • Check out the codebase fromSVNand build it, to make sure you are not breaking anything—that’s why youreally shouldmigrateAFTERyou have a decent build script.
      • Compose a shell script to synchronize from ClearCase local view toSVNworking copy. Synchronize frequently and build every time.
    • Wednesday
      • Clean the codebase: legacy repositories often have lots of garbage (temp files, compiledbinaries,etc.) checked in, it’s now a chance to do some clearance, delete and ignore themfromSCM. Just don’t break the build.
      • Installcontinuous integrationinstance for the codebase inSVN.
      • 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 tellthem “there’sanSVNtraining tomorrow morning”.
      • Keep doing clearance. Synchronize and build frequently.
    • Friday
      • Disable write-access to ClearCase.
      • Training: Configuration Management &SVN. People need tounderstandsomeSCMprinciples to make a better use ofSVN—at least not tomess up thecodebase 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 tocopy andunzip, than checking out from the repository. Mail everyone about how to get a workingcopy and makefirst commit.
      • Publish your CI to the team. It’s now the team’s CI.

    That’s it. Now your team is onSVN.

    •

  6. 有效访谈的技巧

    你是一个外来者，你想了解一个完全陌生的团队。最快的方式就是找到他们，和他们谈话，让他们告诉你。为了让谈话更有效，你会需要一些小技巧。

    • 解除他们的戒心，尽量。戒心无非来自一个很简单的原因：如果说实话不会有好处、甚至会有坏处，那么人们就不会说实话。因此你要先告诉他们，你需要快速了解信息，不是为了任何考核，只是为了帮助他们改进──告诉他们，你会在未来几个月里跟他们一起改进。
    • 话题明确。每场访谈开始之前，把你要谈的话题写在白板上，以及具体要了解哪些信息，以及计划用多长时间来谈。让进入房间的人在第一时间知道你要他干些什么，这样他就不会更紧张。并且在没话说的时候可以很快找回话题。
    • 微笑。有很多人说过这事，可是真的有很多人没有做到。微笑，活泼一点，拿自己开个玩笑（例如嘲笑自己刚在白板上写下的字）。在访谈中你会必须制造紧张气氛（例如你会有意指出两个人对同一件事的不同描述），保持微笑，把它变成一件好玩的、和所有“人”对立的“事”。不要让任何一个受访者感到寂寞或者紧张，因为这时候你还不知道究竟谁才是值得信赖的人。
    • 记下别人说的话。更多的人说过这事，可是我们真的做得都不好。不要一边跟人对话一边在记事本上写字，更不要用电脑做记录。这些行为会让你获得权威感，会让受访者感到不安──“他有代表权威的记事本/电脑，而我仿佛裸体”──甚至为了抵抗这种不安也拿出记事本来写字。但这些行为不会帮你得到更多有效的信息。在白板上做记录。把他们说的事情画下来。这会让受访者感到，你们在一起画一个作品。他们会告诉你，什么地方画得不对，还缺少了什么，这是你的记事本上永远不会出现的东西。
    • 问他们有什么想告诉你的。当你问完了所有的问题，问他们：还有什么想告诉你的，有什么问题，有什么痛点。你在这里的原因是你要帮助这些人。这些人最关心的事不一定是你最高优先级的事，但一定不是你应该忽视的事。
    • 最后，不要相信访谈。用眼睛去看。受访者一定会告诉你假话。有这样的觉悟之后，访谈才会真正是有效的。

    •

  7. 把事情做完

    跟一个小朋友结对。拿在手上的是一张叫做“高级搜索”的故事。小朋友说，功能已经做好了，今天的目标是给它加上WatiN的功能测试。

    于是打开页面，搜索一把，呃…高级搜索的四个条件输入框，有两个填错了东西。小朋友不好意思地说，后台的逻辑都做好了，HTML还差一点点。因为昨天晚上要聚餐，所以就留下了。

    改好HTML，再试一试，呃…正好是刚才没弄好的两个条件输入框，如果组合起来使用就会出错，啥也搜不出来了。仔细往里面一看，原来这两个条件的组合是比较奇妙滴…需要修改整个搜索算法，还需要自己实现一个“集合的交集”（stupidC#…）总而言之，用了大半天时间，才把“高级搜索”真正做完…咻～可以开始写测试了。

    记得某人曾经告诉我，H司某产品的代码，有40%是在大家都以为“差不多做完了”的连调测试阶段写进去的。（给小朋友讲这个故事，似乎小朋友不是很有感觉，sigh～～）

    所以，做一件事就做完，做到可以给客户验收的程度，然后再开始下一件事。自以为90%完成的东西，通常还需要再花一倍时间才能真正做完。（昨天胡凯再次验证了这一理论的正确性。）

    •

  8. 敏捷中国2010大幕将启，讲师招募正在进行

    在连续举办四届敏捷中国大会以后，ThoughtWorks将以“敏捷十年”为主题在今年10月份举办第五届敏捷中国大会，目前国际知名讲师如敏捷宣言创始人Martin Fowler和James Grenning、精益方法专家Mary Poppendieck和TomPoppendieck，均确认参会并演讲。本次大会的亮点之一是组委会将采取开放、透明的方式，面向全球的敏捷实践者征集话题和招募讲师；大会的报名工作也已启动，现在报名享有多种优惠。

    如果从2001年2月份敏捷宣言面世那天开始计算，敏捷已经走过了近10个年头。在这10年的发展过程中，敏捷的分支和外延不断扩大，比如Scrum、Crystal、XP、精益，包括仅今年新出现的看板等均快速发展，在不同的行业和领域帮助企业提高生产效率。虽然敏捷在国内的实施并不如国外那么普及和先进，但是像华为、中兴等大型电信企业，如上海贝尔、赛门铁克等软件企业也已经开始了自己的实践。这次第五届敏捷中国大会的主题即是“敏捷十年”，希望通过回顾过去十年间软件开发行业发生的变化，敏捷的诞生和发展，“全面呈现敏捷方法在中国的推广历程和实施经验”。

    如前所述，今年敏捷中国2010的亮点之一即是从“业务敏捷、实践与新技术、领导力与组织和敏捷工具”等方面，面向全球公开招募讲师和征集话题：

    只要您有过敏捷（开发）实践，或者深入思考过敏捷，或者持续关注过，或者有其他独到观点，都可以报名成为本届敏捷中国大会的讲师。此外，敏捷爱好者还可以通过提交自己感兴趣的话题参与到本届敏捷大会中。主办方将通过大会组委会，统一审核话题及备选讲师，通过公开、公正、透明的组织方式，鼓励全球敏捷爱好者积极参与，共同创建敏捷实践经验分享平台。近年来，国内越来越多的公司已不再仅仅是关注，而是开始有了更多的创新敏捷实践，在本次大会，我们将遴选超过20位讲师分享他们在应用敏捷实践过程中的经验和教训，通过实际案例与参会人员交流在各种典型的真实软件组织和项目中采用敏捷方法带来的实际效果。

    •

  9. 个体与交互 重于 过程和工具

    曾经我认为，敏捷的各种实践，只要有了标准化的动作，加上一点点定制，加上PDCA/SDCA，就能做好。迈向敏捷之路，是可以唯一定义并且重复实施的。比如说持续集成，大师说“在自己的计算机上启动一个自动化build”是重要的──我们把它叫做“本地构建”。做不好本地构建，提交构建失败率就会高，对持续集成的信心就会失去。这个问题，和它的解决方案，都是确定且可重复的。

    可是这个团队让我吃惊了。他们一直没有真正意义上的本地构建。但他们真的相信持续集成──不仅仅是几个领导，是整个团队，真的相信：如果每天发现的小问题不能及时解决，那么到版本上线时一定会被客户骂得狗血淋头。他们不想被骂，他们也不想同一个战壕里的战友被骂，所以他们就把持续集成做好了。尽管没有真正意义上的本地构建，就靠着原始简单的代码评审，更认真的态度，他们就真的把持续集成做好了。

    这个团队颠覆了一些正在我脑中渐渐成型的东西，让我想起了一些原本印象深刻但被渐渐遮掩起来的东西，比如敏捷宣言的第一条：个体与交互重于过程和工具。

    面对巨大组织时强烈的无力感、无助感会让“敏捷推行人”们（包括我自己在内）不自觉地选择把自己的定位拔高──也许真是想帮助更多的人，也许只是想从残酷的现实中逃开，抑或两者兼而有之。但这些人不会做高层面的事情。于是离开低层面、离开具体事务的结果就是不知道该做什么，就是把敏捷推行简化为过程和工具的推行。

    有一个敏捷推行人对我说，我负责几十个项目的改进，如果每次只到一个项目去做具体的事，对整体的帮助很小。我对她说，也许你救不了所有的鱼，但被你救的这一条鱼，它会在乎，它会得救。在反复思考如何拯救所有鱼的过程中，其实你什么也没有做，没有一条鱼真的得救。

    敏捷的改变，最终是一个一个人的改变。过程和工具会帮助你。但如果把敏捷简化成过程和工具，你就在一步步远离敏捷，因为你已经违背了敏捷宣言的第一条原则。

    •

  10. 不做小叮当

    ZD亲热地搂着我的肩膀说：“还是你有本事啊，这次才看到你的能力有多强。”我苦笑着说：“我的英名早晚要毁在你手上。”

    他是我的客户，也是老乡，而且常常配合很默契。

    第一次，二百多人的团队分散在两个城市五个办公地点。ZD对我说，那个产品，发货量巨大，是整个公司最赚钱的部门，客户遍布全球，要是把它搞定了，意义重大。（当时ZB在旁边热情澎湃，被我俩联手泼了一盆冷水。那是我第一次发现，和ZD配合有不需准备的默契。）我沉吟良久，说它真的风险太大，我真的不敢做。但最后我还是去了，因为一个不能让ZD知道的理由。

    第二次，一支孤零零的团队正在被一个巨兽客户折磨得要死要活。ZD对我说，这次能让客户感受到我们的变化，要是把它搞定了，意义重大。我又沉吟良久，说它真的真的风险太大，我真的真的不敢做。但最后我还是去了，又是因为一个不能让ZD知道的理由。

    我跟他说，其实只是运气好。他笑笑，不信，或者说是装着不信。

    小熊说，每个问题解决者都有多拉A梦情结，而康夫每次痛扁技安之后灿烂的笑容便是对小叮当最好的褒奖，是他继续从口袋里掏出法宝的源动力。我不得不承认，挑战一下自己并且挑战成功（不论这成功的原因是什么）的感觉是很爽的。我想ZD一定也知道我的爽感，所以他笑而不语。

    所以，尽管真的很想亲眼看到这个大雪球轰然滚下的最后一刻，尽管真的很嫉妒小熊的博客比我写得更有料并且更有文采，还是应该抽身了。让自己沉浸在小叮当帮助康夫破涕为笑的愉悦之中，这不是我想要的。

    何况，ZD你懂的，我不能等到英名真的毁在你手上的那一天。

    •