-
三十了，许愿吧
转过年，就三十岁了。
（感叹的话全都不说了。三十岁的男人要沉稳内敛，嗯嗯。）
我想亲身经历一家重要企业的精益变迁，并且在其中扮演重要的角色。
我想把已有的技术磨练得更精熟，又学会新的技术做出新的东西。
我想变得更可靠更教人安心，同时更自信而不恐慌。
就是这样了。很简单的愿望。很大的愿望。
-
是的，我想要流程改进…
…只要“被改进”的不是我。
到底有多少人怀着这样的念头呢？
给某知名互联网企业做了一个草草的价值流分析。这家企业和同集团的几家姊妹企业最近都在热火朝天地搞敏捷。培训，项目试点，经验分享，宣讲推广，还打算要制定流程规范。一级一级把成果和经验报上去，领导都很支持。业务线的领导说，交付线的同学们多搞搞敏捷，交付能力强了，咱们公司就能更好地应对顾客们的需求了…
等等。这话为什么让我胃里一抽呢？
十分钟画出的价值流图告诉我们，一个用户需求从被客户服务部门收集到，直到成为一个新特性上线供用户使用，lead time总计2个月又20天（约合58个工作日），processtime约20个工作日。Muda在这个流程中占65%。
那么交付线到底浪费了多少呢？嗯，交付线的lead time共计17个工作日，process time共计10个工作日。
换句话说，就算这家公司得到了一根魔杖，只要魔杖一挥就能把用户需求变成可用的特性，他们也不可能在两个月内响应用户需求，如果业务线没有“被改进”的觉悟的话。
所有人都在讲流程改进。所有人都在讲敏捷讲精益。你真的准备好了吗？流程改进的结果，真的是你想要的吗？得到一个精益流程所需的决心和勇气，你已经有了吗？
-
用系统图分析一种常见现象
这是一个“舍本逐末”的系统基模。
上面的环路代表快速见效的症状解，它迅速解决问题症状，但只是暂时的。下面的环路包含了时间延滞，它代表较根本的解决方案，但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中，会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时，副作用常使问题更难以解决。
想要扭转舍本逐末的情势，需要增强治本的反应与减弱治标的反应。组织的特性常显示在如何处理舍本逐末情势的能力上。
增强治本的反应总是需要一个长期与共有的“愿景”。企业如果不能建立长期不断创新的愿景，那么暂时解决短期问题的策略将取得主控地位。
减弱治标的反应，需要诚实地说出那些“症状解”的真相。有时采用症状解有其必要性，但必须认清那只是为了纾缓痛苦症状的权宜之计，此时最容易忽略的是，一旦压力纾缓，就停止寻找根本的努力。
-
敏捷项目管理实践及其针对的问题
- Face-to-Face Team
- 团队成员对开发状态（进度、问题等）缺乏了解
- 低效沟通导致的步调不一致和延迟
- 个人工作不聚焦
- Standups
- 个人工作与团队目标偏离
- 因任务受阻而浪费时间
- 隐藏的、有可能影响项目交付的风险或问题
- Retrospectives
- 可以避免的、由于流程低效或缺乏支持造成的浪费和延迟
- Sustainable Pace
- 几种缺乏效率的团队工作方式：
- 任务跟踪不聚焦
- 任务量不饱满
- “冲刺”编码（降低质量要求）
- 任务分配过量
- 几种缺乏效率的团队工作方式：
- User Story Lifecycle
- 在各个阶段不同角色的工作不饱满
- 不灵活的计划
- 时间或工作量严重超出预期
- Collective Ownership
- 由于任务需求集中在某人“拥有”的区域而造成的开发延迟（“瓶颈”）
- 由于关键区域的“拥有者”缺勤而造成的交付风险（“巴士因素”）
- Face-to-Face Team
-
四个核心敏捷实践及其针对的问题
- Common Vision
- 各方涉众迭代地汇总观点，就项目的目标、约束和优先级达成共同认识
- 减少因对问题、方案和优先级的理解冲突而浪费的时间和开发资源
- Short Releases
- 在项目进行中频繁交付可工作的软件
- 减少在制品库存的浪费
- 降低在制软件不适合生产环境需要的风险
- Iterative Planning
- 项目计划根据进展中获得的信息迭代式制定
- 避免最后关头获知进度或预算超标
- 减少在低优先级功能上浪费投资
- Simplicity
- 尽量消除软件中的浪费、重复和复杂性
- 降低使用中软件的变化成本和风险（脆弱性）
- Common Vision
-
大团队的持续集成建设路径
- 状态：有缺陷的代码持续产出，软件最基本的功能无法保证
- 建立“缺陷发生时自动停线”的自働化机制
- 实施可视化管理：停线立即告警，作为最高优先级处理
- 解决基础质量问题：消除环境不稳定性，消除伪随机质量问题
- 提升团队基础能力：
- 采用令牌制提交，明确责任人，谁破坏谁修复
- 设立专人负责监控持续集成状态
- 对于不能快速解决的问题，预备有效的修改撤销机制，快速恢复生产，减少破坏的影响范围
- 状态：能得到可用基线，提交失败频率高
- 分层分级的配置管理和验证体系
- 验证提前：提交代码之前的准入构建
- 更严格的令牌制：以成功的准入构建报告申请令牌
- 状态：主线稳定可用，分支合入主线困难
- 标准化的分支持续集成环境
- 分支持续集成状态巡检，及时发现问题提供支持
- 帮助分支组培养持续集成专门人才
- 状态：持续集成稳定可用，需要持续提升
- 配置管理下的持续集成，解决了改进措施在大团队中复制的难题
- 迭代式改善的持续集成
- 从“贪多求快”、“一步到位”的建设思路转变，确立“小步走稳”的持续改进路线，将PDCA方法应用于大团队持续集成建设
-
自动化 vs. 自働化
什么是自动化？是让生产线自动运行起来的技术吗？
那顶多也就是个传送带技术。
《图解丰田生产方式》说，自働化，是在出现问题时让生产线自动停止。
自动停线的自働化，才能在现场、现物根据现实找到问题的根因，才能从源头上消除质量问题。只管自动运行不管自动停线的自动化，既无助于发现根因，又不能及时阻止不合格产品的生产，于是生产线末端的检验人员照样不能省。
建立真正的自働化，首先就要改变这个认识。全员意识到，自働化就意味着一旦缺陷发生立即停线，作为最高优先级处理。有了这样的觉悟才能继续前进。
意识之外，自働化的三个必要条件：
- 可视化。停线的同时以最直观的方式让所有人警觉，并作为最高优先级处理。
- 质量基础。如果设备经常发生异常故障，如果产品经常出现不明原因的质量问题，频繁的自动停线可能直接把生产线打倒。
- 能力基础。自动停线之后，团队是否具备快速发现问题、快速恢复生产的能力。
-
以后回答敏捷的问题…
要做两件事：
- 掐表。第一个问题回答完以后，估算整个交流时间还能回答多少个问题，然后请选优先级最高的问。
- 回答完一个问题之后，要询问：接下来在这个方面你打算采取什么措施？
没有时间盒、没有计划、没有优先级的交流，没有落实措施的讨论，就是漫议，就是在浪费大家的时间。
敏捷咨询本身首先就应该是敏捷的。
-
路宁推荐的精益书目
如是我闻…
《精益思想》是必读，其中提到的5个原则十分经典，比较“广泛适用”，但由于太抽象，现在很少有人提及这些原则。我个人认为弄透了这些原则会非常收益。
《金矿》以小说的行事介绍运用精益的全过程。应用的顺序，步骤，态度的转变都值得思考，非常难得。
《丰田汽车案例—精益制造的14项管理原则》我没看，但似乎是没有争议地被普遍推荐。
关于“丰田生产方式”的具体技术细节，有很多书可以参考，留意书名字就知道了。我感觉有时间一定要好好研究制造业的这些具体做法，还是很有启发性的。仅了解那些被无数人升华了好几层的各种“原则”没什么意思，还是要看看原滋原味的实做手法才过瘾。
《精益思想》的姐妹篇《改变世界的机器》和《精益解决方案》同样质量上乘，前者是一个调查报告，时间跨度大，资料翔实，对了解精益的由来，背景和应用概况很有帮助。后者有几个制造业之外的例子，非常生动。
《第五项修炼》介绍了系统思考方法，很像是精益背后的思考工具和理论支持。里面介绍了“系统循环图”，感觉是个不错的工具，一直想用用，还没落实到行动呢。《精益之旅》前半段介绍原则，总结的不错，后半段是一个故事，足够说明问题
就说这些了，还有像“图解丰田生产方式”，”丰田生产方式“（大爷乃一的），”丰田可视化管理方式“等，都可以帮助了解丰田生产方式的具体做法。
记得是《改变世界的机器》里面，提到了在销售，人事，研发，供应链等方面精益企业与众不同的做法和态度，比较精彩。提到财务方面的书比较少，好像是《精益企业》中有所涉及。
-
Dreamhost还是挺不方便的
想装个NewRelicRPM玩玩，结果，装不上…Dreamhost他不允许Rails应用在后台起进程…
于是，只好郁闷地继续在自己机器上玩…
难度Dreamhost就这么残忍么？
