投资战略与敏捷转型
December 4th, 2011
和 上一篇博客 有关：恰好在读了《 竞争战略 》之后，又温习了一遍 成长-份额矩阵 ，然后就跟客户聊企业的敏捷转型。这时我终于清楚地意识到：敏捷引入的策略和应该与portfolio管理和投资战略紧密相关。
首先，狗是不需要什么敏捷转型的。当然也不好说得那么绝对，毕竟最起码减员增效可以让资产剥离的时候顺利一点。但是太多企业的问题不是减员增效，而是盲目追求规模舍不得把狗杀掉。这就是另一个话题了。
另外三个象限的敏捷转型策略非常有趣。效率，质量，用户。敏捷的三个关键词其实是不均等地对应在三类业务象限上的。
野猫（或者“问号”）的敏捷关键词是用户。份额小、成长快的野猫业务，最大的风险是根本就没人用。所以这时候要准确地抓住用户需求，提出强有力的价值声明，关注用户体验，以最小工作量抓住眼球并获得转化率。对于野猫业务，敏捷引入应该从 体验设计 入手，首先进行 快速项目启动 ，然后以迭代方式迅速交付并获得反馈。
明星的敏捷关键词是质量。份额大、成长快的明星业务，非常容易因为“Quick & Dirty”的开发方式而变成焦油坑甚至直接影响交付。这时候需要偿还技术债务、打好根基，才能承受不断加大的交付压力。对于明星业务，敏捷引入应该着重关注 持续交付 ，从持续集成和自动化测试入手，向下改进代码质量和架构质量，向后借助 DevOps 打通交付的最后一公里。
金牛的敏捷关键词是效率。份额大、成长缓慢的金牛业务，质量和交付风险并不高；同时因为规模大、涉及人员众多，些许效率提升就能带来明显的收益。所以金牛业务的敏捷引入思路应该是以稳为主、持续改进。通过 持续集成中心 等方式提升项目透明化程度，首先掌握现场状态、建立反馈机制，然后逐步改进、逐步提升人员能力。
结论：不同的业务类型需要不同的敏捷转型策略与实践。将投资战略与敏捷转型策略结合，有助于更有效地引入敏捷。
引论：所谓“全公司统一的敏捷流程”就是反敏捷。人和交互重于流程和工具。
复杂度的指数曲线，以及敏捷原则的根本
August 2nd, 2011
想象我正在往一个已有的代码库中添加新的功能。假如我一次只添加一个小修改，这个小修改是如此简单以至于它只有两种状态——写完代码之后只要看一看，我要么是改对了要么是改错了；如果改错了，我就用另一种方式来修改，后者一定是正确的。
如果我一次不是添加一个小修改，而是添加两个，然后把两个修改放在一起来验证。这时可能的状态就有四种：一种正确的，以及三种不同的出错方式。
如果我再贪心一点（或者是因为某些客观条件的约束），一次添加三个小修改然后再验证。这时可能的状态就成了八种：一种正确的，以及七种不同的出错方式。
所以这就是复杂度和变量个数之间的关系：C=(V的N次方)，其中C为“复杂度”，V为“单个变量可能的取值个数”，N为“变量个数”。所以复杂度随变量个数的增加而指数上升。所以几个简单的问题可以分别解决、而合并成一个复杂的大问题就根本无法解决，因为整个问题的复杂度不是做加法而是做乘方。
所以聪明的程序员知道要小步快跑。所以一次只做一件事、做好提交等build通过了再开始下一件。所以要频繁地跟其他人的修改集成。所以不要同时开多个story卡来做。所以不要讲什么“反正这些都是我的工作怎么做都是一样的”。所以不要讲什么“小心翼翼地重构太麻烦了不如一步就改过去多省事”。因为软件开发的工作量不是要敲多少次键盘，而是要处理多少复杂度。把渐进式的修改变成大步伐的修改，会增加工作量，而不是取巧。
所以越是痛苦的事越要频繁做直到它不再痛苦。所以要让反馈周期缩短再缩短。不光是为了练习和得到信息，更是为了降低需要处理的问题的复杂度，使普通人也可以处理——从这个意义上来说，再次向所有不采用敏捷方法的程序员致敬，为他们所能处理的超大复杂度。
Show-off Too
February 28th, 2011
我也会画～～
敏捷之旅预告：双城记
October 14th, 2010
在第一个城市里，一支团队在开发某种电信交换机。他们距离客户很远，交付周期很长，跟硬件关系很多，技术栈很底层。这个团队经常在加班。
而第二个城市的团队做的是业务软件。标准的J2EE架构，每个月都有版本上线，客户天天追着屁股骂他们。他们也经常在加班。
两个团队都想解决自己的问题，他们选择了同一个药方：敏捷。没想到，当咨询师来到，两个团队所做的改进却大相径庭。
两个团队又有一点相似之处：在迈出了第一步，解决了一些切肤之痛之后，他们没有停下脚步。他们都在思考，如何继续进步。在最初由咨询师指导的“猛改”之后，他们又分别做出了一些自己的改进。
这就是我要讲的故事：双城记。
（想听这个故事，请参加 敏捷之旅杭州站 。）
作为管理工具的持续集成
September 3rd, 2010
有一个敏捷推行人，给她的团队设立了一个规则：每个函数不要超过30行。一开始，领导们都说，很好，很有道理。可是真的做起来，就发现遗留代码里有这样那样的特殊情况。紧跟着，开发人员也有了抱怨：我这里写32行又有什么损害呢？为什么一定要那么死板呢？于是，一个又一个的口子被打开。当然，你可以想象，有了越来越多的口子以后，“改善代码质量”也就成了纯理念──跟没有规则之前没什么区别。
我打算怎么做这件事呢？
- 把持续集成搭起来，只做编译。编译失败就红。红了就不能转测试，红了就必须马上修复，红了就是在阻塞整个团队的工作，红了就是最高优先级。让领导开始盯住持续集成。破坏构建就是和整个团队作对。
- 大家讨论一下，30行是不是一个合适的门限？如果不是，35行？40行？50行？行。我们就把门限定在50行。把静态检查放进持续集成。旧的代码我们既往不咎。就算现在有100个函数超过50行吧，没关系，我们容忍它。但是如果出现第101个长函数，就会让持续集成变红，要马上修复。
- 每次构建失败就是一个教育和学习的机会。一个人第一次写出长函数，我跟他一起重构；第二次写出长函数，我要看着他用我教的方法重构；第三次再写出长函数，那就要让领导来关心一下了。没有能力可以学，有了能力还破坏规则，说不过去了吧？
- 现在大家都学到怎么写更短小的函数了。偷偷把门限降低到45行试试？又多出来10个长函数。拉上几个开发者，我们来搞一次代码优化活动，把这10个长函数解决掉。于是大家又学到了更多的重构技巧。于是45行的门限变成了持续集成的要求。
- 两周搞一次代码优化学习会，降一次门限值。两个月以后，30行的标准就放在了持续集成里。如果有时间就去重构以前遗留的长函数，如果没时间就留着吧，至少大家已经不会写出新的长函数了。
先讲道理，再定规则，然后帮所有人提升能力以遵守规则，随着能力的提升逐渐拉高规则。30行的规则落实不下去？我就不信了。
把持续集成作为团队规则的自动、可视执行者，于是敏捷推行人就不必扮演那个凶恶的执法者，只需专心帮人排疑解难。持续集成把违规行为变成一个人与整个团队的对立，而不是一个人与另一个人的对立。
敏捷中国2010大幕将启，讲师招募正在进行
August 5th, 2010
在连续举办四届敏捷中国大会以后，ThoughtWorks将以“敏捷十年”为主题在今年10月份举办第五届敏捷中国大会，目前国际知名讲师如敏捷宣言创始人Martin Fowler和James Grenning、精益方法专家Mary Poppendieck和Tom Poppendieck，均确认参会并演讲。本次大会的亮点之一是组委会将采取开放、透明的方式，面向全球的敏捷实践者征集话题和招募讲师；大会的报名工作也已启动，现在报名享有多种优惠。
如果从2001年2月份敏捷宣言面世那天开始计算，敏捷已经走过了近10个年头。在这10年的发展过程中，敏捷的分支和外延不断扩大，比如Scrum、Crystal、XP、精益，包括仅今年新出现的看板等均快速发展，在不同的行业和领域帮助企业提高生产效率。虽然敏捷在国内的实施并不如国外那么普及和先进，但是像华为、中兴等大型电信企业，如上海贝尔、赛门铁克等软件企业也已经开始了自己的实践。这次第五届敏捷中国大会的主题即是“敏捷十年”，希望通过回顾过去十年间软件开发行业发生的变化，敏捷的诞生和发展，“全面呈现敏捷方法在中国的推广历程和实施经验”。
如前所述，今年敏捷中国2010的亮点之一即是从“业务敏捷、实践与新技术、领导力与组织和敏捷工具”等方面，面向全球公开招募讲师和征集话题：
只要您有过敏捷（开发）实践，或者深入思考过敏捷，或者持续关注过，或者有其他独到观点，都可以报名成为本届敏捷中国大会的讲师。此外，敏捷爱好者还可以通过提交自己感兴趣的话题参与到本届敏捷大会中。主办方将通过大会组委会，统一审核话题及备选讲师，通过公开、公正、透明的组织方式，鼓励全球敏捷爱好者积极参与，共同创建敏捷实践经验分享平台。近年来，国内越来越多的公司已不再仅仅是关注，而是开始有了更多的创新敏捷实践，在本次大会，我们将遴选超过20位讲师分享他们在应用敏捷实践过程中的经验和教训，通过实际案例与参会人员交流在各种典型的真实软件组织和项目中采用敏捷方法带来的实际效果。
个体与交互 重于 过程和工具
July 26th, 2010
曾经我认为，敏捷的各种实践，只要有了标准化的动作，加上一点点定制，加上PDCA/SDCA，就能做好。迈向敏捷之路，是可以唯一定义并且重复实施的。比如说持续集成，大师说 “在自己的计算机上启动一个自动化build”是重要的──我们把它叫做“本地构建”。做不好本地构建，提交构建失败率就会高，对持续集成的信心就会失去。这个问题，和它的解决方案，都是确定且可重复的。
可是这个团队让我吃惊了。他们一直没有真正意义上的本地构建。但他们真的相信持续集成──不仅仅是几个领导，是整个团队，真的相信：如果每天发现的小问题不能及时解决，那么到版本上线时一定会被客户骂得狗血淋头。他们不想被骂，他们也不想同一个战壕里的战友被骂，所以他们就把持续集成做好了。尽管没有真正意义上的本地构建，就靠着原始简单的代码评审，更认真的态度，他们就真的把持续集成做好了。
这个团队颠覆了一些正在我脑中渐渐成型的东西，让我想起了一些原本印象深刻但被渐渐遮掩起来的东西，比如敏捷宣言的第一条：个体与交互 重于 过程和工具。
面对巨大组织时强烈的无力感、无助感会让“敏捷推行人”们（包括我自己在内）不自觉地选择把自己的定位拔高──也许真是想帮助更多的人，也许只是想从残酷的现实中逃开，抑或两者兼而有之。但这些人不会做高层面的事情。于是离开低层面、离开具体事务的结果就是不知道该做什么，就是把敏捷推行简化为过程和工具的推行。
有一个敏捷推行人对我说，我负责几十个项目的改进，如果每次只到一个项目去做具体的事，对整体的帮助很小。我对她说，也许你救不了所有的鱼，但被你救的这一条鱼，它会在乎 ，它会得救。在反复思考如何拯救所有鱼的过程中，其实你什么也没有做，没有一条鱼真的得救。
敏捷的改变，最终是一个一个人的改变。过程和工具会帮助你。但如果把敏捷简化成过程和工具，你就在一步步远离敏捷，因为你已经违背了敏捷宣言的第一条原则。
持续集成铁的纪律是怎样炼成的
June 29th, 2010
持续集成问题说到底是人的问题
有一种常见的观点认为：持续集成是一系列技术问题；只要安装配置了适当的持续集成工具，解决了某些构建、测试自动化的技术问题，持续集成建设就能顺利开展。但实际上，持续集成建设中很少出现高难度的、超出团队本身能力范围的技术问题，涉及的工具也大多通用。持续集成建设中遭遇的一些典型难题，归根结底都不是技术问题，而是人的问题：
- 构建失败率高：背后的原因是开发人员质量意识不足，习惯把质量保证的责任全部丢给测试人员
- 构建修复难：背后的原因是开发人员在本地开发机无法重复构建过程，难以定位问题
- 在失败构建上继续提交代码：背后的原因是构建结果不够公开、受重视不足
持续集成建设就是提升团队质量能力的过程
建设一个运转良好的持续集成体系的过程，就是在培养每个团队成员重视质量的意识，就是在帮助团队发现交付“最后一英里”潜藏的问题、并督促团队解决这些问题。为了保持项目的健康，需要整个团队的努力：
- 加强对质量的关注，代码经过必要的自检再提交
- 制定简明严格的提交纪律，构建失败及时修复
- 用构建监视器显示持续集成状态，使项目健康情况公开可视
- 为开发人员提供本地构建能力，以方便自检和问题定位
《持续集成建设》引言
June 24th, 2010
软件开发的最后一英里
在任何软件开发过程中都有一个重要的部分：通过某种构建（build）流程，将已经编写好的源代码变成可用、能为客户创造价值的软件。尽管知道构建的重要性，但是我们仍然会经常因为构建中的各种问题而惊讶不已。曾有多少次，在所有人都认为“开发已经完成”之后，我们还要经历漫长而痛苦的编译、打包、联调、测试、上线过程？在代码都已经写好之后，我们还曾付出了多少个通宵的代价让软件真正可用？
编写源代码不是软件开发的全部。从源代码构建出可用的软件，这个过程也被称为“软件开发的最后一英里”：胜利似乎就在眼前，但各种潜藏的危机可能这段短短的路程变得艰难万分。
持续集成就是构建过程
构建之所以如此困难，是因为在绝大多数软件组织中，构建过程有以下几个特点：
- 它是一个神秘的、不可见的、只（模糊地）存在于少数人大脑中的过程
- 它是一个需要人工操作的、耗时费力的、容易出错的过程
- 它是一个偶尔为之的、缺乏练习的、充满未知风险的过程
为了减少“最后一英里”的浪费，让艰险的最后一英里成为坦途，我们需要将构建过程明晰化、自动化、频繁化。持续集成就是一个将构建过程明晰化、自动化、频繁化的实践。通过使用软件工具来实现自动化的构建过程、展示构建结果，原本虚无的构建过程就成为了一个实际存在的、可以重复进行的、可以被有效管理的实体。从这个意义上来说，持续集成就是构建过程本身：只有以持续集成的形式呈现的那部分构建过程，才是确定并可靠的；“最后一英里”中尚未被纳入持续集成的部分，仍然是不确定和有风险的。
团队空间
June 18th, 2010
Martin Fowler说 ，一个好的团队空间，要有大面的墙作为 信息辐射器 ，团队要围着大桌坐以保持眼神接触，要有自然光线和看到外面景色的落地大窗。
ThoughtWorks北京的办公室，Martin Fowler认为是一个好的团队空间。
这个空间又如何？除了缺少自然光，也是个不错的团队空间。
