敏捷之旅介绍 Agiletour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国，由帕特里斯·佩蒂特发起。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。 2020 各地敏捷之旅时间 11.22 北京敏捷之旅 11.28 郑州敏捷之旅 11.29 长春敏捷之旅 11.29 深圳敏捷之旅 12.5 大连敏捷之旅 12.6 沈阳敏捷之旅 12.13 上海敏捷之旅 [12.13 天津敏捷之旅]() [12.27 广州敏捷之旅]() 英文官方网站 敏捷之旅英文官方网站 招募 如果你想为敏捷在中国的推广贡献自己的力量，可以联系 bob@bobjiang.com 如果你想举办所在城市的敏捷之旅，欢迎在下面的issue留言。 - 申请举办敏捷之旅2020 提交举办信息（已经确定举办，尚未列在上面） - 申请举办敏捷之旅2020 目标 敏捷之旅的主要目标是： 大量交流敏捷 我们的主要任务是在整个十月和十二月的几个月里，以我们的行为进行一次“大众交流”。我们希望在有受众的任何地方进行交流，以吸引更多对我们新的专业方法的关注 分享我们对敏捷的看法 由于敏捷不断发展，我们希望向新视野开放，同时也为敏捷社区贡献我们的理解，解释和想法 联邦制 鼓励世界各地在敏捷领域中发挥领导作用，同时与敏捷文化和自我组织保持一致 支持 协助我们的同事和当地企业采用敏捷 总而言之，AgileTour敏捷之旅的任务是突出世界各地的领导组织并创建敏捷领导者，并协助大众传播敏捷的好处及其对世界专业人士的影响。因此，AgileTour敏捷之旅旨在帮助所有的组织和企业，这些组织和企业将以敏捷方法论为基础和使命。 以往活动的总结

Scrum指南 更少的规范性 多年以来，《Scrum指南》变得更具规范性（Prescriptive）。2020版旨在通过删除或软化说明性语言，将其恢复为最低限度的框架。 例如： 删除了每日Scrum问题， 软化了围绕PBI属性的语言， 软化了Sprint待办事项围绕回顾会的语言的条目 缩短了取消Sprint的部分等。 一个团队专注于一个产品 一个团队专注于一个产品的目的是消除团队内独立团队的概念，这会导致产品负责人（PO）和开发团队之间的“代理”或“我们和他们“的行为。现在只有一个Scrum团队专注于同一个团队目标，具有三组不同的职责：PO，SM和开发人员。 产品目标的介绍 2020版的《Scrum指南》引入了产品目标的概念，为Scrum团队向更大的有价值的目标迈进提供了重点。每个Sprint都应使产品更接近整体产品目标。 冲刺目标，完成的定义和产品目标的目录 之前的《Scrum指南》描述了Sprint目标和完成的定义，但并没有真正给它们提供身份。它们不完全是工件，而是有些附属于工件。除了2020版对产品目标提供了更清晰的说明。现在，每个工件中都包含对它们的“承诺”。 对于产品待办事项列表（Product Backlog），是产品目标； Sprint待办事项列表（Sprint Backlog）则有Sprint目标， 增量（Increment）则有完成的定义（现在不带引号）。 它们的存在是为了带来透明并专注于每个工件的进度。 自我管理超越自我组织 self-managing over self-orgainzing 之前的《Scrum指南》将开发团队称为自组织，团队选择和谁一起工作以及如何完成工作。 2020版本则更着重于Scrum团队，强调了自我管理的Scrum团队，团队选择和谁一起工作、如何做以及做什么。 三个Sprint计划的主题 除了“什么”和“如何”的Sprint计划主题外，2020的《Scrum指南》还强调了第三个主题“为什么”，指的是冲刺目标（Sprint Goal）。 全面简化语言，扩大受众范围 2020版本的《Scrum指南》着重于消除冗余和复杂的陈述，以及消除了余下的对IT工作的任何推断（例如测试，系统，设计，需求等）。现在，《 Scrum指南》不到13页。 加入社区？ 加入社区参与讨论？ 欢迎报名我的线上课程 - Scrum敏捷精髓

定义 什么是用户故事 用户故事是一种敏捷的实践，帮助开发团队从写需求的视角切换到与客户交谈需求的视角。敏捷用户故事中会有1-2句话简要描述需求，更重要的是基于这几句话的一系列交谈。 用户故事是从最终用户（或客户）的视角出发，对于他们有价值的特性的简单描述。通常是如下的格式： 作为 <某类用户>， 我想要<达成某个目标> 由于 <某个原因> 什么是任务 a: a usually assigned piece of work often to be finished within a certain time b: something hard or unpleasant that has to be done 任务的定义，来自于 韦氏词典 任务，通常是一定时间内要完成的、已分配的工作 任务，必须要做的，较困难的（令人不愉快的）的事情 这里的任务是通用的定义，在敏捷工作环境中，任务指的是团队为了完成用户故事而拆分更加细粒度的、功能模块的工作。 用户故事和任务的相同点 用户故事和任务都是开发团队必须参与的 用户故事和任务都是为了完成特性（feature）和产品的 用户故事和任务，通常都是较难的、必须完成的工作 用户故事和任务，通常都有截止日期（时间）的要求 用户故事和任务的不同点 用户故事就像裤子，而任务就像内裤 用户故事通常是解释特性的why，而任务通常是实现特性的how 用户故事是面向用户（或客户）的，而任务是面向团队的 用户故事通常是产品负责人（或客户）关注的，而任务通常是开发团队关注的 （注：开发团队也需要关注用户故事） 用户故事通常是以用户的语言进行描述（通俗易懂），而任务通常偏向于技术语言描述（如用python实现某个算法） 社区的回复 需求的价值版本描述和需求的BA-编程行为拆解？ – 悟空 用户故事用户能听懂，可以参与。任务是团队自己能理解的功能做拆解。用户故事可以是一个mvp，任务可能只是故事的一个部分，不完整。 – Bruce Wang 任务是用户故事拆分后的子项，有指定的执行者 – 嘿，愉快的人儿啊 用户故事是需求点描述。任务是拆分出来的，用以实现用户故事的条目，任务指导开发团队实施具体的工作。– Fiona W.

敏捷公开课 如果下面的课程计划中没有找到合适的时间和地点，还可以填写表格（表达课程兴趣，足够的人数即可单独联络开课） CSM 课程计划 成都 2020年10月31日 - 11月01日 | 我要报名 线上 2020年11月07日 - 11月08日 线上 2020年11月14日 - 11月15日 | 我要报名 深圳 2020年12月05日 - 12月06日 | 我要报名 CSPO 课程计划 敏捷教练训练营 上海 2020年12月17日 - 12月20日 课程介绍 CSM课程 敏捷教练训练营

为什么要办敏捷教练训练营 自从2016年我开始讲CSM课程以来，总会有学员问拿到CSM证书以后可以做什么，后面如何晋级？ 其实证书本身有什么用呢，这个是值得打个问号的。 虽然证书不代表任何内容，证书也不一定有用。但是获得证书的过程，以及共同学习的同学这是一笔很好的回报。 在获得证书的过程中，可以了解到自己的知识有哪些欠缺的地方，可以梳理出知识结构，还可以学习到正宗的Scrum知识。 不论你是否持有CSM证书、PMI-ACP证书或者其他敏捷证书，是否有想过下一步该往哪里去呢？ 敏捷教练训练营就是为了给这样的实践者，提供一个晋级的可能性，晋级的可能方向。 在今年（2020）早些时候，我找到Lucy和Lance两位大神，协商我们是否可以一起开发一个课程。目的是为了提高敏捷教练的能力，从而可以让他们能更好的服务于组织和公司。（最初的目的是为了现有的CSP服务，实际上我们不想限制于这个群体，只要是有经验的敏捷教练，都欢迎来参加。） 欢迎各位CSM,CSPO,CSP,PMI-ACP,DOP等等证书持有者，也欢迎各位实践者参与到我们的训练营中来。 敏捷教练训练营包含什么 这个训练营中包含什么内容？ 以自我认知和自我成长为基础，重点提升讲授（Teaching）、辅导（Mentoring）、教练（Coaching）、引导（Facilitating）能力。 我要报名 想要了解更多信息

作者：辛光烁 在艾威的课程班报名了scrum master的培训课程后，我花了一段时间认真的重新将老师的网络课程以及scrum指南回顾学习了一次，以下是我对scrum master的一些感受。 我个人是从事传统汽车行业的，对于传统的汽车开发/甚至是传统的汽车软件开发模式，一般遵循的是瀑布模型，从分析，设计，开发，测试，所有阶段是分开的，当我们结束分析后再去进行设计，设计做好后在做开发，等等。这种模式属于传统和经典模式，在汽车行业中至今仍然在使用。一些车载软件的娱乐系统更新换代的周期在几年以上，在长周期背景下，将每一步做好也可以节省成本。 但是在软件开发中我意识到，如果开发软件的同时也有大量的需求的更改，那么存在两周情况，意识退回去重做，造成延误，二是不能响应市场的需求，这两者在基于互联网开发的背景下是致命缺陷。版本迭代周期过长，没有办法满足用户需求上的变化。于是我想学习一下敏捷开发是如何解决问题的。 通过学习，我自己的认识是，在敏捷中为了解决需求的变化，可以将分析，设计，开发和测试通过不同用户故事的条件下组成不同的开发周期，组成不同的条目，如果要增加需求，那么只需要增加相应的用户条目，由PO进行确认并排序优先级，或者相反的删除需求，对于整体项目的损耗就降低了很多。同时在开发的同时，也有机会对趋势重新进行分析，这样开发的产品永远都可以跟上市场的节奏，可以实现敏捷开发。 在多种敏捷开发的模式中，Scrum是一种敏捷开发的方式，它的特点是：灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。 对于scrum的使用流程，在每一个Scrum开始的时候，需要进行sprint计划会，确定这个Sprint要做的事产品待办列表，随后大家开始执行。在每天开始时，进行每日站会。在这一个周期结束的时候，一般是2-4周后，开sprint审查会议，审查会议之后要开一个回顾会议.以上步骤完成后，再开始下一次的Sprint。 对于scrum中的角色分类，核心团队包括产品负责人、Scrum教练和开发团队。猪队中，最重要的角色就是产品负责人，因为这个项目失败的话，他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责，他只对这个团队是否合理的使用Scrum负责。 对于scrum的框架，包括产品待办列表，要不断的把已知的所有需求记录到这里面来，sprint计划会是对这个Sprint进行规划的会议。它的主要的目标就是从产品待办列表里面选择一些任务，放到Sprint待办列表中。Daily Scrum是一个用于同步进度的会议。会议形式是每日站会来进行昨天做事情，今天做的事情以及遇到挑战的总结。Sprint审查会是一个用于Sprint总结的会议。会议形式会演示产品增量，目的是把之前做的Sprint新功能给大家进行演示。Sprint 回顾会是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。 但同时，在使用scrum的过程中也需要一些注意的方面，包括Scrum绝对不能代替传统软件开发方法，Scrum适合十人左右的团队，Scrum的一个Sprint时间为2周–4周，Scrum需要一个强有力的团队等等。虽然scrum可以实现敏捷开发，但针对传统汽车行业的项目也要确定是否团队适合Scrum应用，外界的需求变化是否会很多多，这是决定使用Scrum的出发点。如果决定了使用scrum，在确定团队，相应的scrum master，找到合适的工具，比如每日看板。 欢迎报名我的线上课程 - Scrum敏捷精髓

超越指责（Beyond Blaming） ©1996年 Jean McLendon 和 Gerald M.Weinberg ，www.satir.org和www.geraldmweinberg.com 英格兰虽然目前处于非常繁荣的状态，但仍表现出民族衰败的一些症状。向英国人提出任何原则或任何手段，无论多么令人钦佩，您都会发现，英国人的全部努力都是针对于发现困难，缺陷或不可能的地方。如果您对他说剥土豆的机器，他会说这是不可能的。如果在他眼前将马铃薯剥皮，他会宣布马铃薯无用，因为它不会切成菠萝。将相同的原理或同一台机器展示给美国人或我们的一个殖民者，您会发现他的脑海全是在寻找该原理的一些新应用，以及对该仪器的一些新用途。” – 查尔斯-巴贝奇（Charles Babbage），1852年 早在1852年，查尔斯-巴贝奇（Charles Babbage）就能看到衰败的症状，并从中推断出未来的表现。通过这样做，他完美地描述了指责的沟通风格，这种风格出现在”衰败”的组织中，无论是国家还是软件工程组织。什么是”指责的沟通方式”？为什么在系统开发中如此重要？【指责的沟通方式，也严重影响着家庭关系】 什么是一致性？ 一致性是一个概念，它描述了内部和外部之间协调一致的人类体验 – 思想和感觉（内部），所说的话及如何说（外部）。 为了在世界上实现一致性的运作，您需要考虑三个普遍因素：自我（内部世界），他人（直接外部世界）和上下文（事物、结构、过程、法律和文化，更大的外部世界）。 自我：您必须考虑自己的需求和能力。假设您是一位不信任任何人的判断的经理，因此您尝试参加每次技术会议。这样做可能会使您的所有可用时间都超负荷，从而无法执行管理工作，或者在任何情况下都无法做出真正的技术贡献。（或者如果你是一位不信任儿子的父母，每次和儿子沟通的时候都是持有怀疑否定的心态，那么沟通就会非常吃力。） 他人：您必须考虑其他人的需求和能力。例如，如果您是一位程序员，编写可读代码的时候拒绝打扰，那么对代码的测试和维护将是一个巨大的负担，因为这是不可能。 上下文： 您必须考虑操作环境的实际情况。 例如，如果您是一位经理，坚持使用不再具有处理任务能力的旧设计，那么不管每个人的工作多么辛苦，您的项目都可能注定要失败。 或者，如果您是一家初创公司的经理，并且花了很多钱，好像该公司拥有10亿美元的现金余额，那么您的组织可能在软件产品投入市场之前就已经倒闭了。 一致性是最基本的诚信，因此对项目及其中的每个人都具有巨大的价值。没有诚信，我们就无法建立信任。没有信任，我们不会感到安全；没有安全，我们很难做到一致性。因此，一致性可以在一个强大的增强回路中强化一致性，从而提高按时、在预算范围内构建高质量产品的机会。 相反地，同一循环会导致不一致，从而加剧不一致。如果一个项目被允许走下坡路，信息的完整性（integrity）就会被破坏。很快，人们都不可能知道真正发生了什么。这样的项目总是失败的，而当它们失败时，总是发现它们保存着两套”书”（这里的“书”指的是信息）。他们的外部形象与他们的内部形象不一致，所以项目死了。更糟糕的是，可能永远活着 – 活死人（the living dead）。 如果一致性对于项目成功是如此重要，那么为什么不是所有项目都一致呢？原因之一是一致性是有代价的。另一个是，一致性通常会带来风险。风险的水平在某种程度上取决于所显示的一致性程度（心理或情感）。 精神上的一致 在美国，相对容易地表达我们的思想而无需过多地承担责任 – 言论自由是该国赖以建立的基础。即使这样，”大声说出来”也可能要付出代价。例如，与同事或当权者在错误的时间发生分歧，可以使我们迅速走上隔离、谴责、减少机会和微妙的关门之路。因此，我们都知道了对在哪里和对谁说的话要小心的重要性。说错话会引起激烈的辩论，然后是关于谁对谁错以及谁好谁坏的声明。到那时，我们已经基本失去了增进理解和有效沟通的可能性。 情感上的一致性 在我们的文化中，情感主要用于体育赛事、庆祝活动、葬礼、临近死亡的经历，深刻感受的精神体验主要体现于战斗以及与亲密的他人之间的交流（可能是小孩或老人）。我们甚至对自己的感觉也会有很多感觉（感觉的感觉），其中最强烈的感觉与羞辱和尴尬有关。感觉是个人的，并且贴近我们的内心，在那里我们温柔而脆弱。难怪我们所有人都变得如此娴熟地​​否认自己的感情，这必然使我们不一致。 假设您是一个开发人员，害怕您无法兑现承诺，从而无法交付产品。您试图告诉您的经理您的恐惧，但是他毫不犹豫地告诉您，如果您不表现出更多的信心会怎样。”你为什么这么消极？你不是团队的一员吗？” 保护自己免受此类负面反应的一种方法是生活在自己的头脑中。也许您会说：”这只是一个估算；我不同意它，”这意味着您不会受到伤害，因为您已经与自己保持足够的距离，可以抵御可能暗示拒绝的任何事物。但是，尽管您否认对经理的恐惧感，但还是感觉到了，被压扁了。您可以背弃自己的想法，但始终保持自己的立场。而且，当然您一直是不一致的。 当您分享自己的感受时，您的内心被暴露在外在世界中 – 暴露在其他元素中。当您害怕并表达恐惧，同时又要考虑他人（您的经理）和上下文（项目）时，您就变得与众不同。您在这里遇到的关键问题是：”我可以分享自己的想法并且仍然可以控制吗？” 如果您的项目环境受到指责，那么如果您说实话，就有可能取消您的控制权 – 因此，对您的想法撒谎的诱惑会增加。这就是为什么责怪文化会导致”双重后果”，也就是导致失败的原因。 什么是指责？ 在一致性的组织中，您的经理问：”您的项目进展怎么样？” 您会回答：”恐怕我不会按时完成了。” 这开始了一个解决问题的讨论，你们两个都在其中制定了新的计划，以使项目重回正轨。但是，在指责的组织中，您的经理可能会告诉您，只有劣等人缺乏信心。在这种情况下，解决问题将被避免指责所取代。 从作者的角度来看，一致性的交互作用不是很大。人们只是明智地采取行动，互相体贴，完成工作并享受所做的事情。这种行为可能不如肥皂剧一般的场面，您的经理发脾气而你在角落里哭泣，但这绝对是一个好的项目。 并不是说指责文化会以一种戏剧性的，指责的方式进行每一次互动。在通常情况下，应遵循一致性的应对方法，但如果情况总是很普遍，我们就不需要管理人员。当自尊心低落时，它们会以更加明显的、不协调的典型应对方式表现出来：指责，安抚，过分合理的爱或恨，无所作为。我们不能在简短的文章中解决所有这些问题，因此让我们讨论指责，也许是应对方式中最常见、最直接的破坏方式。 在压力下，人们往往会失去平衡，这三个基本要素可能会被忽略，从而导致一种典型的不一致的应对方式。例如，当人们不考虑他人时，他们就会陷入指责状态。这是您在软件组织中可能会看到的典型的指责行为（斜体字会以这种说话方式强调 – 因为句子中的多个强调字是指责的语言符号）： 经理，因为程序员迟到了一次会议：”您*总是*迟到。您*永远不会*对*他人*表示*任何*考虑。” 为什么这不一致呢？如果经理真的感觉到并认为程序员总是迟到并且不考虑周到，那么她是否就这么同意呢？是的，但这不是这位经理所说的。她没有说：”给我的印象是你总是迟到我的会议。” 取而代之的是，她把迟到的感觉说成是科学事实，从不提供程序员可能会有不同印象的可能性。她在会议中总结了经验，就好像这些经验必定适用于所有会议一样，从来没有考虑过她的经验可能不是唯一重要的经验。 如果经理真的感觉到并认为程序员总是迟到并且考虑不周全，她可能会说：”我认为您总是迟到，而且我觉得您没有考虑过我和其他人。这也是你的看法吗？” （并省略强调的单词。）甚至更好的管理风格是使程序员有机会在进行解释之前提供不同的看法。至少，这可以防止在以下情况下的尴尬： 经理，因为程序员迟到了一次会议：”在我看来，您总是很晚。这也是你的看法吗？” 程序员：”是的，我对此感到难过。我总是迟到的原因是，我必须为死于白血病的9岁儿子献血，而他们唯一的一次捐赠就是在这次会议之前。” 经理：”对你儿子感到抱歉。我不知道 让我们找出一个新的会议时间表，这样您就不必迟到了。” 更笼统地说，它考虑到除了该经理之外，还有其他考虑因素。例如，程序员可能有来自与客户的会议，即与经理会议重叠的定期安排的会议。 但是，如果程序员真的总是迟到而又没有合理的解释怎么办？经理不是有权指责程序员吗？并非如此，因为这种情况与权利无关，而与完成项目有关。为此，使用非指责的对抗与不可接受行为有关的事实，可以最有效地解决该问题。通过前述的指责，管理者使沟通保持清晰和开放，从而最大程度地提高了程序员接收预期消息的机会。而且，收到预期的消息会最大程度地解决问题（尽管不能保证）。

团队的问题 团队进展得怎么样？ 实际上并不太好；团队遇到了不少问题。比如…… 比如冲刺计划（sprint planning）之前梳理工作；冲刺评审（sprint review）的时候获得有用的客户反馈；团队都同意一个有意义的DoD（完成的定义）【这些问题的原因是什么呢？】 因为现在是新冠疫情，我们都是在远程工作…… 作者评论 不要认为你的团队目前像世界上大多数人一样远程办公为借口，认为保持团队合作是平淡无奇的。在这种没人能见面的时代，保持并进一步发展敏捷团队的团队精神比以往任何时候都更为重要。有了合适的在线工具，例如Miro，Zoom，Slack，Teams，Skype或其他工具，这变得可能了。但是，拥有正确的在线工具仅是答案的一半。练习“远程的团结”是另一半。 实现此目的的方法包括：在工作时间内不断开放所有团队成员的交流渠道，以模拟他们坐在一起；安排频繁的虚拟游戏会议以增强团队合作精神并一起玩乐；以及与特定同事计划在线聊天，以保持这些宝贵的临时讨论和交流机会。因此，如果您是Scrum Master或敏捷教练，现在是时候真正踏上第一步，因此即使在这些困难时期，您也可以帮助您的团队成长。 译者评论 疫情大前提下，团队合作变得更难。原来是远程团队还好，原来在办公室的团队，大家都不得不进行远程协作。这对于传统行业更为挑战。所以选择一个（套）好的工具是大前提，其次需要更多的设计团队沟通环节。因为原来团队合作，很多是发生在办公室，潜移默化（悄悄）的。而现在的团队合作，需要提前设计好固定的沟通时间、固定的沟通方式、固定的沟通渠道等等。 最后问一句，你的团队还好吗？ 读者评论 对于今天的漫画，你有什么想说的呢？ 原文链接