本书主要分为几大部分：

• 教练基础，主要讲述如何开始敏捷教练之旅
• 敏捷当中的会议，哪些地方容易出错，以及如何改进
• 关注代码质量
• 倾听反馈

摘取部分想法来自于自我成长：

• 每月阅读一本书
• 开始写自己的博客
• 参与一个开源项目
• 每天在社区邮件列表中发一封信
• 在上班路上听有声读物
• 每月参加一次社区活动

下面是全书的脑图（英文）：

QCon北京2013大会
大会时间：2013年4月25-27日
大会地点：中国·北京 国际会议中心

社交篇

这次QCon大会上，碰到很多老朋友，也认识许多新朋友。听@Shining介绍uPerform是本届QCon的赞助商，首先想到Bill Li和王宇同学。另外QClub全国协调人@柴峰同学很健谈。认识了更多thoughtworks的高人，瑶瑶，徐八叉，刘海生等等等等。
休息期间去图灵展台，认识了大名鼎鼎的谢工，以及图灵的知名编辑小花
当然还有很多InfoQ的同学们，包括Charles, Kevin, 司巧蕾, Wendy, Jesse, Floyd等

演讲篇

《胜任管理》 组织的进化——单一目标的组织（举例：不用知道事情肮脏的背后，如吃鱼香肉丝，不用知道猪是怎么养的。

组织发展面临的障碍：

• 等级制度
• 疏离感
• 输血文化
• 成功背后的幽灵

标准化培训

• 入职培训
• 团队拓展
• 在线学习1

结对实践

• 文化技能导入
• 定制化学习曲线
• 榜样的力量

学习型组织（参考第五项修炼）

• 建立共同愿景
• 团队学习1
• 改变心智模型
• 自我超越

• 系统思考

  组织的重新思考：

• 成员，知识工作者

• 任务，知识传递
• 度量标准，知识影响力

游戏简介：
这个游戏将要求所有参与者站立完成。大家围成一个大圈，在一个共同的标准和规则下，在既定的时间里，完成抛球的动作，达成一定的目标。然后通过每个迭代的改进，提升团队协作的效率。 我们在以往的实践中，做过几十场不同规模的团队抛球游戏。本场，我们也将向最大规模发起挑战。团队成员将能收获，较大团队的协作和持续改进，是如何完成的。

抛球游戏，是一种越来越多地被Scrum培训师采用的敏捷游戏。通过这个游戏，你可以收获：

1. 通过迭代逐步提高工作效率
2. 领导力是如何产生的
3. 团队是如何学习-检视-适应
4. 回顾的力量（reflection）
5. 工作流（或节奏）

下面介绍游戏规则：

GTD是Get Things Done的缩写，意思是搞定。最早是由David Allen提出的。它追求的是“无压力的生活”，心如止水。

GTD分为两种方式组织：横向与纵向。

• 横向：事情的处理（Stuff）
• 纵向：事情的高度（link TBD）

GTD的理念：GTD的核心理念在于只有将你心中所想的所有的事情都写下来并且安排好下一步的计划，你才能够心无挂念，全力以赴地做好目前的工作，提高效率。而当你总是有些事萦绕在心头，悬而未决的时候，你要么就是会不时地想起它而影响现在的工作，要么就是会忘记了去做。而GTD通过将所有的这些事都罗列出来再进行分类，确定下一步的处理方法，将所有这些悬而未决之事都纳入我们可控制的一个管理体系中。

GTD的基本方法：GTD的具体做法可以分成收集、整理、组织、回顾与执行五个步骤。

收集：就是将你能够想到的所有的未尽事宜（GTD中称为stuff）统统罗列出来，放入inbox中，这个inbox既可以是用来放置各种实物的实际的文件夹或者篮子，也需要有用来记录各种事项的纸张或PDA。收集的关键在于把一切赶出你的大脑，记录下所有的工作 。

整理：将stuff放入inbox之后，就需要定期或不定期地进行整理，清空inbox。将这些stuff按是否可以付诸行动进行区分整理，对于不能付诸行动的内容，可以进一步分为参考资料、日后可能需要处理以及垃圾几类，而对可行动的内容再考虑是否可在两分钟内完成，如果可以则立即行动完成它，如果不行对下一步行动进行组织

组织：个人感觉组织是GTD中的最核心的步骤，组织主要分成对参考资料的组织与对下一步行动的组织。对参考资料的组织主要就是一个文档管理系统，而对下一步行动的组织则一般可分为：下一步行动清单，等待清单和未来/某天清单。
等待清单主要是记录那些委派他人去做的工作，未来/某天清单则是记录延迟处理且没有具体的完成日期的未来计划、电子等等。而下一步清单则是具体的下一步工作，而且如果一个项目涉及到多步骤的工作，那么需要将其细化成具体的工作。
GTD对下一步清单的处理与一般的to-do list最大的不同在于，它作了进一步的细化，比如按照地点（电脑旁、办公室、电话旁、加利、超市）分别记录只有在这些地方才可以执行的行动，而当你到这些地点后也就能够一目了然地知道应该做那些工作

回顾：回顾也是GTD中的一个重要步骤，一般需要每周进行回顾与检查，通过回顾及检查你的所有清单并进行更新，可以确保GTD系统的运作，而且在回顾的同时可能还需要进行未来一周的计划工作。

执行：现在你可以按照每份清单开始行动了，在具体行动中可能会需要根据所处的环境，时间的多少，精力情况以及重要性来选择清单以及清单上的事项来行动

有一位讲师正在给学生们上课，大家都认真地听着。寂静的教室里传出一个浑厚的声音：“各位认为这杯水有多重？”说着，讲师拿起一杯水。有人说二百克，也有人说三百克。“是的，它只有二百克。那么，你们可以将这杯水端在手中多久？”讲师又问。很多人都笑了：二百克而已，拿多久又会怎么样！

讲师没有笑，他接着说：“拿一分钟，各位一定觉得没问题；拿一个小时，可能觉得手酸；拿一天呢？一个星期呢？那可能得叫救护车了。”大家又笑了，不过这回是赞同的笑。

讲师继续说道：“其实这杯水的重量很轻，但是你拿得越久，就觉得越沉重。这如同把压力放在身上，不管压力是否很重，时间长了就会觉得越来越沉重而无法承担。我们必须做的是放下这杯水，休息一下后再拿起，只有这样我们才能拿得更久。所以，我们所承担的压力，应该在适当的时候放下，然后再重新拿起来，如此才可承担更久。”

说完，教室里一片掌声。

启示：

学会调整心态是取得成功的关键。文明的同时也带来不同的负效应，社会进步的同时也催生了沉重的压力。许多人不堪重负走向极端的屡见不鲜。这个时候，要学会释压。一直背负压力必然走不远。最好的释压方式就是调整心态，适当的时候放下负担，该放手时放手，该承担时承担，好好地休息一下，把心态调整到最佳，才能走得更远。

我最喜欢的一句话

成功的执行一项无意义的计划
是导致失败的致命原因
如果企业费尽心思开发出来的产品没人想要，
那么是否按时、按预算完成计划就无关紧要了。

精益创业使用来自丰田生产方式的精益思想来指导创业活动，避免在创业活动中的巨大浪费。

精益创业是一个关于“开发-测量-认知”的反馈循环，不断的开发，然后进行测试测量，得到一些认知，根据学习到的知识进行下一轮的开发。

精益创业首先有一个关于“价值的假设”，然后推出一个最小可行产品（MVP）进行假设的验证。

书里提到许多例子，比较典型的有两个：

1. 印度乡村洗衣服务
2. 美国最大的网上鞋店Zappos

价值假设得到验证后，下一步关于增长的假设需要得到很高的关注。书内提到传统的衡量指标（虚荣指标），有比较大的欺骗性，比如总用户数，总浏览量，总点击数。如果网站今天的总浏览量为2万，那么这些浏览量来自一个用户，还是2000个新用户呢？

关于增长假设，书中提到两个比较好的验证方法：

1. 同期群分析
2. 对比测试

在各种验证假设后，得到的报告、报表中，衡量指标要符合三个“可”的标准

• 可执行：指标简单易懂
• 可使用：指标具有指导意义
• 可审查：数据来源可信

KANBAN的基本原则如下（来自丰田生产方式）

1. Do not send defective products to the subsequent process
   有缺陷的产品不送往后工序
2. The subsequent process withdraws only what is needed
   后工序只有必要的时候，才向前工序领取必要数量的零部件
3. Produce only the exact quantity withdrawn by the subsequent process
   前工序应该只生产后工序领取的数量
4. Level the production
   平均化生产
5. KANBAN is a means of fine tuning
   KANBAN是微调的手段
6. Stabilize and rationalize the process
   使各工序稳定化与合理化

对应到软件开发中，如何使用KANBAN原则呢？

待续

关于教练可以提供给客户的价值有许多神秘和错误的猜想，本文以原文作者的亲身经历描述了为客户建立辉煌成功的五个方法：

问有力问题的小提示：下面有几个提示关于开始并掌握问有力问题的艺术。

1. 准备问题
2. 移除无力的问题
3. 预演
4. 仔细查看检查表
5. 应用
6. 体验询问的过程并改进

当问问题的时候，我们透露了范围。每个问题都有一个背景，有一个隐式的或者显式的范围。为什么问题的范围重要？范围确实很重要因为它可以使问题适应背景，它澄清了目的，从而给问题增加更多的能量或者分量。下面做三个测试。

1. 我们如何才能教组织里的每个人写出高质量代码？
2. 为什么你不把“代码质量”当做我们业务单元的积极行动呢？
3. 作为团队成员你是如何写出高质量代码，从而我们可以达到取悦客户的目的？

依赖于背景，问题的范围必须做出适当改变。否则，可能会导致令人震惊的体验。例如第一个和第二个问题不适合那些挣扎着确保项目质量代码的人。

在问题中也包含我们的假设。清晰的、有力的问题，假设也表露在外面。下面几个例子。

1. 我们可以做些什么来产生高质量代码吗？（假设团队中没人写过高质量代码）
2. 我们如何可以从其他项目团队学习关系编写单元测试与使用TDD？（假设你的项目中没人有相关经验）
3. 为什么不工作了？为什么崩溃了？
4. 你可以帮我推断这个情况吗？