名词。对单个领域专家的贬义词，指的是该专家只是该领域专家，对多方面的问题只能采取狭隘的方法。 这个词是来自于德语，Fach的意思是专家。单个领域的专家我们不会叫他“傻子（idiot）”，不过这里指的是这个专家在其他领域像傻子一样，而只能精通一个领域。 Definition of fachidiot Noun. A derogatory term for a one-track specialist who is an expert in his field, but takes a blinkered approach to multi-faceted problems. Additional Information The word originates from the German but there is no suitable translation into English. A “one-track specialist” is not quite right because you would not call someone like that an “idiot”. The “fach” comes from the German for “subject”. Example: “Despite being an expert in horticulture, the manager came across as something of a fachidiot when dealing with translation issues.

问题：最近有朋友咨询我，我们团队的每日站会，可不可以每周二、周四开？ 我的回答：不可以。 原因如下： 每日站会中，每个团队成员需要回答3个问题： 昨天我为团队达成Sprint目标做了什么 今天我准备如何帮助团队达成Sprint目标 有什么事情阻碍了我帮助团队达成Sprint目标 通过这3个问题，我们可以得到两个层面的信息： 团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；同时是否存在障碍 每天团队都会得到反馈，并可以根据得到的反馈做出调整 如果不是每天开站会，那么就可能（1）团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；（2）团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；（3）团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。 总之，每日站会，顾名思义是每天站着开的会议。如果不是这样，那么就不要叫每日站会。 如果您有不同意见或想法，欢迎和我交流沟通。扫我加微信哦~ 8月4日-8月5日Certified ScrumMaster (CSM中文认证课)，如果感兴趣也可以和我联系。

报名请点击链接 时间: 2016年8月4日 - 2016年8月5日 地点: 北京 价格：早鸟5600元，7月21日前有效；普通7000元 特别说明：京东员工、敏捷社区志愿者有特别折扣，详情联系讲师（邮件或微信） 以往学员是如何评价的 课程特色 在这次课程中，学员将从实际操作的层面上学习和掌握Scrum的运用技巧，学员将学会如何避免Scrum实施过程中的一些常见问题。Scrum很简单，但并非容易，讲师结合自己在企业内实施敏捷转型的实践经验和Scrum框架，通过案例与游戏介绍解释什么是Scrum以及为什么Scrum可以如此高效。课程中通过多个游戏，和穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。 内容全面、深入, 重在实际操作及运用囊括了大量项目论证过的经验 通过系列的练习和小组讨论，让学员在课后就能立即启动自己的Scrum 用Scrum的方式来讲Scrum框架 您将学到 什么样的项目更加适合于Scrum和敏捷开发 在Scrum和敏捷项目中如何控制风险 怎样组织产品Backlog，以及产品工作项的生命周期 如何能够保证您的项目有一个良好的开端 领导一个自组织的团队并不是一切都放手，如何能够激发团队自管理 您不仅收获一份Certified ScrumMaster证书，还将有： 1本Scrum实战培训手册 10+有启发的，对Scrum转型有帮助的视频 1份团队敏捷备忘录 Scrum联盟两年会员资格 PMI认可的14个PDU 培训大纲 Scrum的起源 Scrum概述 为什么用Scrum 敏捷宣言与原则 Scrum的价值 Scrum框架 Scrum角色及职责 产品负责人Product Owner Scrum Master 开发团队 Scrum活动 产品需求列表梳理Product backlog refinement Sprint计划会议 每日站会 Sprint审查会 Sprint回顾会 Scrum工件 Sprint Backlog 产品增量 产品需求列表Product backlog Scrum的误区 敏捷估算 Scrum实战演练 课程回顾总结 其他问题 可以给讲师写邮件（bobjiang@bobjiang.

从想法到实现，我一共花了2年2个月的时间，所以要给自己一些时间。2014年4月我想成为一名CST（Certified Scrum Trainer），2016年6月29日11点终于实现了。先给自己撒花~ 内容大纲 时间线 什么是CST 如何申请CST 基本要求 申请材料 认证流程 我的收获 时间线 2014年4月 - 有了申请CST的想法 2015年1月 - 提交申请材料 2015年4月 - TAC成员初次评审材料失败 2016年1月 - 再次提交申请材料 2016年3月 - TAC成员初次评审通过，通知面试 2016年4月 - 因为签证，错过奥兰多的面试 2016年6月29日 - 班加罗尔ScrumGathering，通过面试 什么是CST CST，即Certified Scrum Trainer，是Scrum联盟（https://www.scrumalliance.org）颁发的认证培训师。具体的认证路径如下图： 要成为一名CST，首先要拿到以下三个认证（CSPO、CSM、CSD）中的一个，然后需要申请成为CSP，有了CSP之后才能申请CST。 如何申请CST 如果英文好的同学，建议查看Scrum联盟网站关于CST申请的消息。 CST是我经历过最严格的一次认证经历，通过认证本身这个过程我自己也确实提高了很多。下面列出的要求是认证的最低要求，但绝对不是说你符合要求即可（如果只是达到最低要求，基本100%挂掉）。需要做的是按照这个要求制定自己的计划，一步一步往这个目标前进。 基本要求 对于Scrum概念、实践和原则有着深刻的知识和理解 持有有效的CSP认证 作为ScrumMaster、产品负责人、团队成员，拥有大量的在组织内实现Scrum的一手经验 和现有CST一起合作教过Scrum，或者独立教过Scrum（非认证），需要符合以下要求 最少教过100个学员 最少教过10个多天的ScrumMaster培训（多天指的是连续2天或以上） 如果想要培训CSPO课程，需要有CSPO认证 申请材料 具体申请材料要求，可以查看Scrum联盟网站。 申请人签名 Scrum经验文档（描述自己作为ScrumMaster、产品负责人、团队成员的Scrum经验）。CST希望是有一手Scrum经验的人，并且在该文档中要体现出自己的收获和学习是什么，以及对于Scrum的理解 个人声明。文档中描述为什么Scrum鼓舞你，并且是什么激励你把这个分享给其他人；另外还要清楚回答为什么你要成为CST 课程材料 如果材料不是英语，需要翻译成英语 培训材料可以是一起创建的，或者是公司创建的。为了更好的评估你的Scrum知识，请指出哪部分是你开发的，哪些属于你的。我们想要通过你的材料看到你的知识，你的故事。我们需要了解你知道什么（而不是你公司或你同事的共同知识） 材料可能包含ppt、讲义、手册、练习簿、学习指南、课程计划、课程大纲、课堂练习描述、小组练习、学习目标或者其他。（提示：尽可能的复现出你的课程实际情况） 提交的材料应该可以复现出课堂中学员的体验 Scrum联盟正在把学习目标向Scrum指南靠拢，因此提交的课程材料目标完全符合Scrum指南 如果材料中有非Scrum的元素，必须标识出来，这样评审可以准确评估你对于Scrum框架的理解 如果你采用“training from the back of the room”或者其他参与式培训方法，确保提供下述材料（至少提供两类）： 课堂的学习产出 课堂照片、白板照片 课件描述、大纲，以及课程计划 课堂练习或活动 小组讨论提示 游戏结果（反思） 如果想法不是原创的，确保指出来源。使用商标或版权材料时，给出明确的提示。 主要考察ScrumMaster课程材料。通过CSTs后也可以提交CSPO申请材料 课程材料映射：下载CSM课程学习目标（如果同时要教CSPO，也要填写CSPO课程学习目标），明确指出你的培训材料哪部分覆盖了哪一个学习目标 培训经验 申请人必须提供信息，可以说明至少10个多天ScrumMaster培训课程（最少100个学员参与）。培训课程可以是： 非认证ScrumMaster课程 和其他CST一起教的CSM课程。申请人应该交付至少50%的课程内容才能算1次。 多天培训课程指的是连续2天或以上的培训。 和CST共同培训指南： 以往的申请人说，共同培训是一段宝贵的师徒经验 共同培训理想的方式是，链接CST社区。如果通过邮件很难获得共同培训的机会，考虑参加全球ScrumGathering。尤其可以参加Gathering并且在教练诊所注册。 多名CST的推荐信非常关键。CST的推荐为申请人提供了关于Scrum知识和培训能力的反馈。 Scrum联盟不建议为共同培训的机会或推荐信付费。 如果你符合Scrum经验申请需求，也有自己的ScrumMaster课程材料，希望寻找CST社区的共同培训的机会，可以发信到 support@scrumalliance.

5月17日非常有幸和2位引导大师（来自澳大利亚的Tom和David）一起交流。从David那里我更进一步学习了焦点式对话ORID这个方法（参考资料：什么是ORID）。以前我也多次运用这个方法，也算小有心得，但是对于R(反应性问题)和I(诠释性)的问题，感觉总是问不好。而且有的时候干脆跳过反应性或诠释性问题。这次David给我一个很有力的说法： R反应性问题，就好像是最后决策背后的能量，是助推器，使我们更加有动力去产生最后的决策。 I诠释性问题，是主题与个人之间产生链接，以及可能是参与者之间产生链接。而这种链接可以为我们带来意想不到的收获。 如果你想和我交流ORID焦点式对话，欢迎扫一扫我的微信： 最后送大家一个小例子，用来解释为什么焦点式对话是很自然的。 在课堂上，David把胶带扔给明伟老师，以下为明伟老师的反应和解释： 明伟老师看到胶带飞过来了 （O，客观事实） 明伟老师很淡定，面带微笑（R，反应） 明伟老师评估了一下风险，根据自己的经验做了了如下判断（I，诠释） 明伟老师伸手接胶带（D，决策） David用了一个小小的例子，就解释了ORID是一个很自然的对话过程。非常棒的例子！

常常听到敏捷转型的团队提到，我们的一个迭代可以完成几个几个用户故事。那个故事怎么怎么样。那么什么是用户故事？用户故事就是软件需求吗？ 我们先来看一下什么是用户故事 什么是用户故事 用户故事指的是从用户的角度出发，来描述用户想要得到的功能。常见的格式为： 作为<某个用户>，我想要<功能>，以便于<实现某个价值> 用户故事需要采用日常用语或者用户听得懂的语言来描述，尤其注意避免使用晦涩的技术专用术语。 后来Ron Jefferies同学建议，好的用户故事符合3C原则：Card，Conversation，Confirmation；Jeff Patton同学，把这个3C继续扩充为5C（并总结为用户故事生命周期）：Card, Conversation, Confirmation, Construction, Consequence。 用户故事这个方法最开始的初衷是非常好的，希望技术人员（一般来说是研发人员）可以以用户的角度来思考问题。但在实际应用中，有些团队就会出现下面这样的例子： 作为一个系统的用户，我想要接口A，以便于和系统进行交互。 大家仔细体会，为什么这是一个反例？ 那么对于敏捷软件开发当中，需求是个什么东东，是不是都是用户故事呢？ 我的观点是，用户故事不是软件需求。 什么是软件需求 需求分析指的是在创建一个新的或改变一个系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。（摘自wikipedia） 从上面的定义中可以看出，软件需求的定义更加广泛，而不仅仅是从用户的角度考虑用户所需要的功能。并且用户故事也只是展现功能的一种形式。 软件需求可能包含（但不限于）：功能（可以用用户故事展现）、原型、探索、技术改进、缺陷等。 功能的展现形式可以有（但不限于）：用户故事、用例、关键词短语. 因此，不要把用户故事当作是需求，需求有更大的定义和更多的展现形式。而用户故事是一个相对较小的概念。 用户故事不等于软件需求。 在敏捷当中是如何管理需求呢，请继续往下看。 敏捷需求是如何呈现与管理 对于敏捷转型的组织来讲，需求是首先要考虑的事情，这是团队的起点（输入点）。因此敏捷需求是很重要的一步，但这个在Scrum当中并未有很多的提及。 Scrum中有产品列表（Product Backlog）以及条目（Item）来管理需求，产品列表是如何产生的，条目何时是就绪的，何时是完成的。这些都需要在实践中不断摸索。 如何建立产品列表 用户故事地图是一个创建产品列表很好的方式。这是因为产品列表是一维的，排序的，这样很难找出相互有业务关联的条目。通过用户故事地图这种方式，可以很好的组织需求条目。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。如下图： 如何把业务目标和需求条目进行关联 常常在平时的开发中，开发人员不清楚为什么要开发一个功能，或者是不了解背景，或者是不清楚业务目标。有一个非常有用的工具（影响地图）可以帮助团队。如果你的组织需要这样的工作坊，也可以单独和我联系（jiangxb@gmail.com）。例子如下图：

During teaching Scrum and coaching on Scrum, I summarized following working guide as a reference: Problem over Solution Note: The development team focus on how to build software, so normally development team focus on the solution. But the purpose for building software is to solve some specific problems, so we need to focus on the problem over focus on the solution. Because sometimes to solve problem we don’t need to build a feature, and we have an alternative solution.

本文是整理我的分享《Scrum精髓-之京东敏捷之旅》，这个演讲分别在敏捷之旅厦门、敏捷之旅福州、敏捷之旅天津以及光环国际敏捷组织转型大会上分享过。 这个分享主要包含2大部分： 案例分享 京东敏捷模型 案例分享主要讲了2个，一个是活动提报团队；另一个是途牛融合团队。 在活动提报团队中，团队没有关注功能场景，两次未能真正满足业务方的需求。后来团队进行敏捷转型，并且引入需求发起方到团队中，随时能搞响应需求变化并可以澄清需求以及验收。最终第三次较好的完成了业务方的需求。并且得到了业务方和老刘的高度认可。 第二个案例是途牛融合。前期采用用户故事地图进行版本规划，拆分成3个迭代。另外把所有接口和风险都列出来，每天更新。最后做到了60天完成两大上市公司的融合。并且8.18促销当天，总收入同期增长10倍！ 从在京东内部敏捷辅导的案例当中，我总结了如下的京东敏捷模型（当心：所有的模型都是错误的，但是有用的） 一个核心：以价值为核心 没有工具或实践的模型都是耍流氓！ 那么以价值为核心的实践就是产品待办列表（Product Backlog）。好的产品待办列表是ODDE的，参考我之前写的博客。 基本点1：透明 软件开发当中很多信息都是不透明的，而信任的基础又是透明。那么首当其中就是要把可以透明的信息都展示出来，这里我首推物理板子，如上图左边。如果是异地团队（不推荐搞异地团队），可以考虑使用电子板工具，如上图右边（京东自主研发的lessw）。 基本点2：迭代 迭代还有一层意思就是重复的做事情，那么重复做事情必须有一个限制。对于Scrum，这个限制就是时间盒。 基本点3：反馈 敏捷的核心不是快，而是反馈快，参考我的博客。针对反馈的实践，敏捷当中有很多的工具和实践。 每日站会 采用最多的是每日站会，每天团队凑在一起，回答3个问题。这里的关键点不是汇报工作，而是团队作为一个整体同步信息，为了达成迭代目标而努力。 评审会议，而不是演示会议，参看我之前的博客。 基本点4：教练 如果上面说的实践您还不会，或者在练习的过程中碰到问题怎么办，那么这个时候就需要有教练-即敏捷教练。不论是内部教练或者是外部教练，都对敏捷转型会有很大的帮助。 下面是这个模型的总结，希望京东敏捷模型对你也有所启发。