投资战略与敏捷转型
December 4th, 2011
和 上一篇博客 有关：恰好在读了《 竞争战略 》之后，又温习了一遍 成长-份额矩阵 ，然后就跟客户聊企业的敏捷转型。这时我终于清楚地意识到：敏捷引入的策略和应该与portfolio管理和投资战略紧密相关。
首先，狗是不需要什么敏捷转型的。当然也不好说得那么绝对，毕竟最起码减员增效可以让资产剥离的时候顺利一点。但是太多企业的问题不是减员增效，而是盲目追求规模舍不得把狗杀掉。这就是另一个话题了。
另外三个象限的敏捷转型策略非常有趣。效率，质量，用户。敏捷的三个关键词其实是不均等地对应在三类业务象限上的。
野猫（或者“问号”）的敏捷关键词是用户。份额小、成长快的野猫业务，最大的风险是根本就没人用。所以这时候要准确地抓住用户需求，提出强有力的价值声明，关注用户体验，以最小工作量抓住眼球并获得转化率。对于野猫业务，敏捷引入应该从 体验设计 入手，首先进行 快速项目启动 ，然后以迭代方式迅速交付并获得反馈。
明星的敏捷关键词是质量。份额大、成长快的明星业务，非常容易因为“Quick & Dirty”的开发方式而变成焦油坑甚至直接影响交付。这时候需要偿还技术债务、打好根基，才能承受不断加大的交付压力。对于明星业务，敏捷引入应该着重关注 持续交付 ，从持续集成和自动化测试入手，向下改进代码质量和架构质量，向后借助 DevOps 打通交付的最后一公里。
金牛的敏捷关键词是效率。份额大、成长缓慢的金牛业务，质量和交付风险并不高；同时因为规模大、涉及人员众多，些许效率提升就能带来明显的收益。所以金牛业务的敏捷引入思路应该是以稳为主、持续改进。通过 持续集成中心 等方式提升项目透明化程度，首先掌握现场状态、建立反馈机制，然后逐步改进、逐步提升人员能力。
结论：不同的业务类型需要不同的敏捷转型策略与实践。将投资战略与敏捷转型策略结合，有助于更有效地引入敏捷。
引论：所谓“全公司统一的敏捷流程”就是反敏捷。人和交互重于流程和工具。
精益管理者的成长（二）
November 7th, 2011
持续改善，尊重员工。持续进步，员工参与。如果只是看到了桌子左腿的重要性，而忽略了右腿的话，桌子就站不住脚了。
改善活动的四种类型：（1）通过将问题可视化来应对日常的问题；（2）为特定的问题，以标准化的形式组织跨职能的研讨会；（3）质量小组，定期地把团队内的工人们组织在一起，在主管和专家的帮助下解决一些具体的问题；（4）工人的个人提案建议。
认识到做所有四种类型改善的关键，不仅在于现场观察，团队合作也同样重要。一个人无法独自做改善。团队合作，既包括不同职能部门一起工作，也要求不同层级的人一起工作。
我们的关注点一直是“潜力”水平，而不是“平均”水平。这种关注使正常化运作显得更加重要。我们不是仅仅让一个流程运转，而且是要花时间弄清楚，如果能持续地以最佳状态运行，它所能达到的潜在效果。作为管理者，如果你开始问自己，是否每一秒都让自己的流程最佳运转，而不是差不多就行了，那么你自然就会关注工人是如何工作的。
如果“北极星”是明确的，我们可以以此为参照发现自己的错误。我们是否在做计划上的事情？现在做的是否足够取得成果？这样做的好处在于，如果你能让员工专注于明确的目标，迟早会赢得他们的信任，所有的事情都会迎刃而解。
每次有人提出一个新问题，都要用“谢谢”来回应。种一棵树需要几百年，然而砍一棵树却只需要几个小时。所以彼此的信任要持续不断地努力。我们需要反复倾听，强迫自己要严肃认真地对待每个人的问题，弄明白这些问题并且寻求解决之道。无论是工人还是邻居，只要有人告诉你存在的问题，你就应该对他说“谢谢”。
给产品制定一个计划，然后给每个人都制定一个计划。第一，让每个人知道他们应该做什么，并且和他们一起解决问题。第二，表扬那些值得表扬的。第三，让他们提前对改变有所了解。第四，充分利用每个人的能力。培养人需要花时间，但这就是管理最终全部的内容。你必须单独对待每个人，并且认真对待他们的问题。没有两个人会用相同的方法，体会相同的事情。
机器是用来帮助工人更好地工作。只有人才能改进自己的生产率。不是流程在驾驭人，是人在驾驭流程。精益流程是执行流程的人不断实施改善的结果。为了做到这一点，必须创造充满着改善精神的工作环境。我们将会分享收益。相互信任！
在推广精益的过程中，会经历一些神奇的时刻。- 第一个时刻：管理人员和工人们在改善研讨会里讨论如何改善生产线。
- 第二个时刻：生产线管理人员自发地定期改善。
- 第三个时刻：把所学到的改善知识应用在新的流程种，工程师会因为所学到的知识而改变产品设计，使得现有的生产线更加高效。
- 第四个时刻：改善导致产品本身的重新设计。
生产产品之前先培养员工，这样一来，就可以设计出在客户看来比竞争对手更加优秀的产品，并且应用更加精益的生产方式降低成本，令竞争对手望尘莫及。这才是持久的竞争优势。
Bug Driven Development
November 4th, 2011
周六一起开会的时候，徐昊说起这样一种开发方式：当我拿到需求，如果我一行代码都不写就交给测试人员去测，测出一个bug我再写一段代码来fix它。我说：真正的测试驱动开发啊。徐昊说：这叫Bug驱动开发。
我当时以为他说笑呢。直到今天突然我弄明白了他说的什么意思。然后我就发现自己有多笨。
首先，Bug驱动开发是一种需求分解的方法。当无能的BA拿着一个一句话需求说“这个需求就是这么大没办法再分得更小了”，请使用Bug驱动开发，测试人员说出来的第一个bug就是一个story：它必定相当独立，它必定有价值，它必定比原来的整个大需求要小，并且它必定可测试。
然后我很激动地给徐昊发了个短信，然后他告诉我，其实这个方法的学名叫 Feature Injection ，是价值拉动思想的具现化。然后我又发现原来这篇新闻是我的sponsee翻译的⋯⋯为自己的笨和无知挠墙⋯⋯
显然，为了真正做到Bug驱动开发，我们需要快速、可重复的反馈机制，也就是说：持续集成，自动化测试。这是拉动出来的改善需求。
顺便我今天又想到了一个检验交付流程的度量指标：往代码里随便乱改一行，改变系统的行为但是不破坏编译，提交它。好了，现在系统里有一个bug，你需要多长时间才能把它抓出来？我把这个度量指标叫做“Bug寿命”（Bug Life Time，BLT）——感谢 Praveen 对这个名字的贡献。
一个理想的交付流程，BLT应该无限趋近0：第一，你应该不能提交这样的代码，因为本地构建会抓住这个bug；第二，提交后持续集成应该会抓住这个bug，并且持续集成的反馈越快越好。
以“BLT趋于0”作为目标进行改善，第一你有清晰的方向，第二你可以很容易地度量改善的效果，第三这个目标是如此简单而又如此困难以至于你永远找不到理由停止改善。这就是Bug驱动改善，一个相当有效的改善活动。
精益管理者的成长（一）
November 3rd, 2011
（读《 金矿II 》的一些快速笔记。）
首先，你得问自己两个关键的问题：- 我们的产品或者服务能自始至终满足客户的需求吗？
- 工人能解决自身的问题，并持续地保持下去吗？
丰田生产方式的三大模块：支柱之一，自働化；支柱之二，JIT；两个支柱都是为了一个目标：所有人参与改善。标准化工作和改善就像一枚硬币的两面。安灯系统，还有JIT灯，都不过是一些技术而已，它们最根本的目的是理清基本的生产问题。这些工具对解决实际问题的作用，就好比用望远镜来阻止流星雨，用显微镜来消除病毒一样。工具的作用无非就是，严谨地把“正常”操作中的问题凸显突出。
现场观察是一门管理技术，这门技术分为四个部分：第一，假设进行验证，培养判断能力；第二，在就解决方案展开争论之前，让人们对问题本身达成共识；第三，在实施过程中定期进行检查；第四，通过让员工参与进来，赋予他们更多的权力。
可视管理的建立需要回答四个关键问题：（1）是否每个人都能看到这里现在是正常还是不正常？（2）是否每个人都能看到自己应该采用的标准方法？（3）是否每个人都能看到在这里工作的工人明确他们的主要问题是什么？（4）是否每个人都能看到他在做什么？
管理工厂交杂着救火和改善的情况。通常，工厂总经理花80%的时间四处救火，花20%的时间改善。而真正的窍门是颠倒这个比例。如果你花了大部分精力致力于改善，你会有越来越少的火灾需要救，而且火还会越来越少。
To be continued…
Why Is 100% Test Coverage Easier To Achieve?
April 17th, 2011
Some say that “it’s little valuable to achieve test coverage over 80%” (or 60% in some cases). From the perspective of quality assurance, maybe it’s true. However, from a lean perspective, 100% test coverage could be even easier to achieve than 80% (and much easier than 60%). Sounds weird? I’ll explain.
The most common argument against “100% coverage” is “Do we really need test trivial methods such as getter/setter?” But it’s a bad question. What really matters is not “do we really need test them”, but “do we really need write them”. I saw programmers wrote (or even generated) getter/setters without test just because doing so is cheap. But these small pieces of code are waste: not only because you need maintain them, but also because they (potentially) break design principles such as Law of Demeter . Creating trivial methods without test-driven is over production. It’s MUDA .
And the tolerance of code-without-test causes MURA (meaning irregular, uneven or inconsistent). Lower the bar of test coverage to 80% (or even 60%), and you’ll end up to solve code-without-test in a bigger batch. It requires more consideration and effort every time you doing it, and this effort is not split into every story (or even better, every commit) evenly. You’ll need a concentrated hour (or worse, half day) to write tests for code committed a few days ago.
And as we all know, MUDA and MURA causes MURI (overburden, unreasonableness or absurdity). When it comes to the last day before your release and suddenly test coverage drops under the bar, how possible can you get a concentrated hour to fix it? Isn’t it annoying to be requested writing some test to fix broken continuous integration when you are ready to pack your laptop and go home at 6PM? Are you going to do some serious code review before typing in yet another non-sense test case and commit it?
Allowing MUDA to accumulate causes MURA. MURA plus delivery pressure causes MURI. MURI stops you from improving code quality and causes more MUDA. The lower the bar, the worse the case. You can break the chain by eliminating every piece of code-without-test continuously. Test-driven every piece of code.
Bottom line: although it might be little valuable to tighter test coverage restriction from 80% to 100% from a quality assurance point of view, doing so makes your life easier (instead of harder). So, why not doing it?
Show-off Too
February 28th, 2011
我也会画～～
A3报告的基本结构
January 10th, 2011
读《建设全功能团队》后感
December 4th, 2010
胡凯在InfoQ发表了 两篇 文章 。读后，简单的感想是：追求卓越的团队，就得所有人会做所有事。
所有人都得会编程。所谓编程，是指在离散的数字世界中输入信息量以建模连续的真实世界之某一局部方面的智力活动。如果不会编程，如何知道用户的价值应该怎样以数字方式建模？如果不会编程，如何知道数字模型的哪些部分可能存在潜在错误？不会编程的人做不好软件需求，也做不好测试。
所有人都得会测试。所谓测试，是指提前发现和消除用户可能在真实使用中发现的软件缺陷的智力活动。如果不站在最终用户、最终生产环境的角度思考，“质量内建”从何谈起？不会做测试的人做不好软件需求，也做不好软件开发。
当然，常见的角色还有需求和管理。不过，“所有人都要了解需求”是敏捷软件开发中的老生常谈。而管理，私以为它就是一种浪费。如果团队每个人都会编程、会测试、会跟客户沟通需求，我们真的需要项目经理吗？
其中最难的部分是“所有人都得会编程”。因此每个追求卓越的软件企业招聘和人才培养以及每个追求卓越的软件从业者的个人成长都应该将编程能力作为一个重点。
以上。
精益生产的六大要素
November 14th, 2010
工作场所安全、有序、极为整洁。
产品按照客户需求即时生产。
六个西格玛质量标准融入产品和生产过程中。
被授权的车间小组有权做出重大决策。
可视化管理跟踪业绩，公司的一切均让员工了解。
坚持不懈地追求完美。
多能工化的算术表述
November 4th, 2010
（本文系剽窃 胡凯 的点子。写出来一是因为有趣，二是为了刺激胡凯赶快写好他的文章。）
假设一个功能点的开发需要1人天、测试需要0.5人天。一支3个开发人员和1个测试人员构成的团队一周能交付多少个功能点？
答案是8个。因为第一天还没有功能点被开发出来，测试人员没的测。后来虽然开发了很多，但没有测，不能交付。
现在想象另一支团队：还是4个人，不过4个都是开发人员，并且开发人员都能够并且愿意做测试工作（通常不是一个很离谱的假设）。这支团队一周能交付多少个功能点？
具体的动态规划有点复杂，总之是接近 4×5/1.5 ，十多个。比有专职测试的团队交付得多。你真的相信“专业分工能提高效率”吗？
更有趣的是，如果这支团队只有3个开发人员，没有那位测试人员，但开发人员都能够并且愿意做测试工作。这支团队一周能交付多少个功能点？
答案大概是9或者10。多加一个专职测试，反而不如没有这个人交付得多。你真的相信“专业分工能提高效率”吗？
更详细的计算以及“为什么”和“如何能做到”的答案，敬请期待胡凯的文章。（我写完这个有趣的部分就没兴趣再写下去了。）
