三十了，许愿吧
December 31st, 2009
转过年，就三十岁了。
（感叹的话全都不说了。三十岁的男人要沉稳内敛，嗯嗯。）
我想亲身经历一家重要企业的精益变迁，并且在其中扮演重要的角色。
我想把已有的技术磨练得更精熟，又学会新的技术做出新的东西。
我想变得更可靠更教人安心，同时更自信而不恐慌。
就是这样了。很简单的愿望。很大的愿望。
是的，我想要流程改进…
December 20th, 2009
…只要“被改进”的不是我。
到底有多少人怀着这样的念头呢？
给某知名互联网企业做了一个草草的价值流分析。这家企业和同集团的几家姊妹企业最近都在热火朝天地搞敏捷。培训，项目试点，经验分享，宣讲推广，还打算要制定流程规范。一级一级把成果和经验报上去，领导都很支持。业务线的领导说，交付线的同学们多搞搞敏捷，交付能力强了，咱们公司就能更好地应对顾客们的需求了…
等等。这话为什么让我胃里一抽呢？
十分钟画出的价值流图告诉我们，一个用户需求从被客户服务部门收集到，直到成为一个新特性上线供用户使用，lead time总计2个月又20天（约合58个工作日），process time约20个工作日。Muda在这个流程中占65%。
那么交付线到底浪费了多少呢？嗯，交付线的lead time共计17个工作日，process time共计10个工作日。
换句话说，就算这家公司得到了一根魔杖，只要魔杖一挥就能把用户需求变成可用的特性，他们也不可能在两个月内响应用户需求，如果业务线没有“被改进”的觉悟的话。
所有人都在讲流程改进。所有人都在讲敏捷讲精益。你真的准备好了吗？流程改进的结果，真的是你想要的吗？得到一个精益流程所需的决心和勇气，你已经有了吗？
用系统图分析一种常见现象
December 11th, 2009
这是一个“舍本逐末”的系统基模。
上面的环路代表快速见效的症状解，它迅速解决问题症状，但只是暂时的。下面的环路包含了时间延滞，它代表较根本的解决方案，但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中，会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时，副作用常使问题更难以解决。想要扭转舍本逐末的情势，需要增强治本的反应与减弱治标的反应。组织的特性常显示在如何处理舍本逐末情势的能力上。
增强治本的反应总是需要一个长期与共有的“愿景”。企业如果不能建立长期不断创新的愿景，那么暂时解决短期问题的策略将取得主控地位。
减弱治标的反应，需要诚实地说出那些“症状解”的真相。有时采用症状解有其必要性，但必须认清那只是为了纾缓痛苦症状的权宜之计，此时最容易忽略的是，一旦压力纾缓，就停止寻找根本的努力。
敏捷项目管理实践及其针对的问题
December 10th, 2009
- Face-to-Face Team
- 团队成员对开发状态（进度、问题等）缺乏了解
- 低效沟通导致的步调不一致和延迟
- 个人工作不聚焦
- Standups
- 个人工作与团队目标偏离
- 因任务受阻而浪费时间
- 隐藏的、有可能影响项目交付的风险或问题
- Retrospectives
- 可以避免的、由于流程低效或缺乏支持造成的浪费和延迟
- Sustainable Pace
- 几种缺乏效率的团队工作方式：
- 任务跟踪不聚焦
- 任务量不饱满
- “冲刺”编码（降低质量要求）
- 任务分配过量
- 几种缺乏效率的团队工作方式：
- User Story Lifecycle
- 在各个阶段不同角色的工作不饱满
- 不灵活的计划
- 时间或工作量严重超出预期
- Collective Ownership
- 由于任务需求集中在某人“拥有”的区域而造成的开发延迟（“瓶颈”）
- 由于关键区域的“拥有者”缺勤而造成的交付风险（“ 巴士因素 ”）
四个核心敏捷实践及其针对的问题
December 6th, 2009
- Common Vision
- 各方涉众迭代地汇总观点，就项目的目标、约束和优先级达成共同认识
- 减少因对问题、方案和优先级的理解冲突而浪费的时间和开发资源
- Short Releases
- 在项目进行中频繁交付可工作的软件
- 减少在制品库存的浪费
- 降低在制软件不适合生产环境需要的风险
- Iterative Planning
- 项目计划根据进展中获得的信息迭代式制定
- 避免最后关头获知进度或预算超标
- 减少在低优先级功能上浪费投资
- Simplicity
- 尽量消除软件中的浪费、重复和复杂性
- 降低使用中软件的变化成本和风险（脆弱性）
