大团队的持续集成建设路径
November 29th, 2009
- 状态：有缺陷的代码持续产出，软件最基本的功能无法保证
- 建立“缺陷发生时自动停线”的自働化机制
- 实施可视化管理：停线立即告警，作为最高优先级处理
- 解决基础质量问题：消除环境不稳定性，消除伪随机质量问题
- 提升团队基础能力：
- 采用令牌制提交，明确责任人，谁破坏谁修复
- 设立专人负责监控持续集成状态
- 对于不能快速解决的问题，预备有效的修改撤销机制，快速恢复生产，减少破坏的影响范围
- 状态：能得到可用基线，提交失败频率高
- 分层分级的配置管理和验证体系
- 验证提前：提交代码之前的准入构建
- 更严格的令牌制：以成功的准入构建报告申请令牌
- 状态：主线稳定可用，分支合入主线困难
- 标准化的分支持续集成环境
- 分支持续集成状态巡检，及时发现问题提供支持
- 帮助分支组培养持续集成专门人才
- 状态：持续集成稳定可用，需要持续提升
- 配置管理下的持续集成，解决了改进措施在大团队中复制的难题
- 迭代式改善的持续集成
- 从“贪多求快”、“一步到位”的建设思路转变，确立“小步走稳”的持续改进路线，将PDCA方法应用于大团队持续集成建设
自动化 vs. 自働化
November 29th, 2009
什么是自动化？是让生产线自动运行起来的技术吗？
那顶多也就是个传送带技术。
《图解丰田生产方式》 说，自働化，是在出现问题时让生产线自动停止。
自动停线的自働化，才能在现场、现物根据现实找到问题的根因，才能从源头上消除质量问题。只管自动运行不管自动停线的自动化，既无助于发现根因，又不能及时阻止不合格产品的生产，于是生产线末端的检验人员照样不能省。
建立真正的自働化，首先就要改变这个认识。全员意识到，自働化就意味着一旦缺陷发生立即停线，作为最高优先级处理。有了这样的觉悟才能继续前进。
意识之外，自働化的三个必要条件：
- 可视化。停线的同时以最直观的方式让所有人警觉，并作为最高优先级处理。
- 质量基础。如果设备经常发生异常故障，如果产品经常出现不明原因的质量问题，频繁的自动停线可能直接把生产线打倒。
- 能力基础。自动停线之后，团队是否具备快速发现问题、快速恢复生产的能力。
以后回答敏捷的问题…
November 19th, 2009
要做两件事：
- 掐表。第一个问题回答完以后，估算整个交流时间还能回答多少个问题，然后请选优先级最高的问。
- 回答完一个问题之后，要询问：接下来在这个方面你打算采取什么措施？
没有时间盒、没有计划、没有优先级的交流，没有落实措施的讨论，就是漫议，就是在浪费大家的时间。
敏捷咨询本身首先就应该是敏捷的。
路宁推荐的精益书目
November 17th, 2009
如是我闻…
《精益思想》是必读，其中提到的5个原则十分经典，比较“广泛适用”，但由于太抽象，现在很少有人提及这些原则。我个人认为弄透了这些原则会非常收益。
《金矿》以小说的行事介绍运用精益的全过程。应用的顺序，步骤，态度的转变都值得思考，非常难得。
《丰田汽车案例—精益制造的14项管理原则》我没看，但似乎是没有争议地被普遍推荐。
关于“丰田生产方式”的具体技术细节，有很多书可以参考，留意书名字就知道了。我感觉有时间一定要好好研究制造业的这些具体做法，还是很有启发性的。仅了解那些被无数人升华了好几层的各种“原则”没什么意思，还是要看看原滋原味的实做手法才过瘾。
《精益思想》的姐妹篇《改变世界的机器》和《精益解决方案》同样质量上乘，前者是一个调查报告，时间跨度大，资料翔实，对了解精益的由来，背景和应用概况很有帮助。后者有几个制造业之外的例子，非常生动。
《第五项修炼》介绍了系统思考方法，很像是精益背后的思考工具和理论支持。里面介绍了“系统循环图”，感觉是个不错的工具，一直想用用，还没落实到行动呢。 《精益之旅》前半段介绍原则，总结的不错，后半段是一个故事，足够说明问题
就说这些了，还有像“图解丰田生产方式”，”丰田生产方式“（大爷乃一的），”丰田可视化管理方式“等，都可以帮助了解丰田生产方式的具体做法。
记得是《改变世界的机器》里面，提到了在销售，人事，研发，供应链等方面精益企业与众不同的做法和态度，比较精彩。提到财务方面的书比较少，好像是《精益企业》中有所涉及。
Dreamhost还是挺不方便的
November 16th, 2009
三人成众
November 13th, 2009
一个人是孤单的，就像“人”字，只能自己支撑自己。
两个人的团队，如果不是互相对立的话，就难免有一人比较强势。如同一个“从”字，主从关系往往确定下来就不易改变。
四个人或更多人的团队，就常会分裂成小帮派。
三个人的团队是个绝配。三人成“众”，既互相支撑，又互相平衡，均势来回变，难有某一人永远强势。一起出现，三人不显太多；分开行动，一人两人可以灵活配置。
而且争吵能得到有效控制。一旦两人出现争执，另一人便可客观评判，居中调停。而且这次的旁观者下次就可能成了争执的一方，这次的争执者下次又换了调停的角色。于是每个人在身涉争执时大可各执一端畅所欲言，因为信任旁观者已有准备平息战火。于是争执也常被带往健康的方向。
所以如果去陌生而紧张的环境工作，三个人的团队是很好的选择。
测试驱动咨询
November 9th, 2009
当别人求助你解决一个问题时，第一件要做的是什么？
不是挽起袖子解决问题。不是诊断症结在哪儿。甚至都不是问5个why。
首先要问的问题是：
- 如果这是一个问题，用什么数据能体现它？
- 如果问题被修复了，从这个数据上是否能反映？
然后，把度量放下去。每个度量项要有几个要素：
- 哪些数据？
- 如何得到数据？
- 以什么频率采集数据？
- 如何发布结果？
按照这几个要素制定一个跟踪度量方案。用这个方案先采集现有数据。根据现有数据定一个改进目标。
这就是你的──正在失败的──测试。先把测试放下去，然后再提任何改进措施。
Sponsor的价值所在
November 6th, 2009
今儿给麦罗打电话的片段摘录…
- 我：俺们SVN server装Windows上，用个32位Apache做前端，那玩意有2G内存限制…
- 麦：一，用Windows做SVN server。二，代码库很大。三，很多人同时访问。
- 我：对头～～
- 麦：你在XX公司？
知音啊～～我又内牛满面了～～介个就是Sponsor的价值亚～～
设计问题多于方法问题
November 2nd, 2009
比如说吧，产品和平台之间依赖好严重啊，产品还经常要修改平台的代码；特性组和支撑组之间耦合好紧密啊，支撑组的代码都得到特性组去验证和提交。敏捷怎么解决这些问题啊？还有啊，开发人员总是几个故事一起做，做出来的故事测试人员发现没法测。敏捷怎么解决这些问题啊？
还有啊，架构思想都没有传达到开发人员啊，都做乱掉了；持续集成工具的专家他不属于开发团队啊，出问题找他支持好麻烦啊；测试工具的专家…嗯，最近的一个离我们大概有一千公里吧。敏捷怎么解决这些问题啊？
这些不是方法问题，是设计问题。设计很简单。单一职责，DRY，OCP，依赖倒置，接口隔离，就这么些东西而已。但简单不等于容易。写代码的时候不会设计，划分模块的时候同样不会，划分产品的时候同样不会，管理组织机构的时候还是同样不会。一个软件组织不让员工学会写代码，其结果就是设计问题出现在所有地方。
还有个下半句：管理问题多于能力问题。
我们很想提高工程人员的技术能力啊，应该怎么让他们学习啊？我们这些实践影响的人太少啊，怎么快速复制到成千上万人啊？──想要事情做下去，不走样，就得去关注所有的细节。拍一个任务下去，你周五之前给我完成，我只看结果。完不成怎么样？时间过去了，能力还是没提升，问题还是没解决。这就是所谓粗放式管理。一层一层都说，行，我支持，大家去学习吧──你不去手把手的教着他，他除了变成蘑菇还能变成什么？
管理细节也很简单。代码的坏味道有没有重构？每个函数有没有测试？每次提交的注释是不是符合规范？但简单不等于容易。写代码的时候不会管理细节，做管理也同样不会。一个软件组织不让员工写好代码，其结果就是管理问题出现在所有地方。
持续不能集成
November 1st, 2009
持续集成只是信息源。持续集成的检验是在代码提交之后而非之前进行的，因此持续集成的作用只是使项目健康情况可视化。并且这种可视化必须建立在构建经常成功的前提下。因为软件本身的复杂性决定了只有“是否达到质量要求”能够被简单度量，而“达到（或不达到）质量要求的程度”无法被简单度量。所以，如果构建经常失败，持续集成所能提供的信息就只剩“项目一直不健康”──这个信息的价值很小，如果不是完全没有价值的话。
让持续集成保持经常成功，必须规范三件事：
- 提交代码之前必须更新
- 提交代码之前必须进行本地验证
- 线上构建失败时不得进行任何提交（或更新）
如果做不到这三件事，持续集成就可能降格化为持续不能集成：你知道项目有问题，但不知道问题出在哪儿，也不知道该如何解决这些问题。
为了避免这种降格化，在持续集成到位之后，需要用更多的手段确保三点规范得以落实：
- 代码库和持续集成分级
- 责任逐级下压
- 建立提交前本地构建基础设施
要言之：持续不能集成会使持续集成的价值降低到约等于0（甚至低于0）。要避免持续不能集成的发生，第一要严格规范，第二要提供技术手段使规范能够被落实。
