敏捷之旅介绍 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敏捷之旅旨在帮助所有的组织和企业，这些组织和企业将以敏捷方法论为基础和使命。
以往活动的总结
11月24日，星期天，北京的天气晴朗但北风嗖嗖，温度已经到了零下5度。 顶着5级大风，乘着欢快的地铁，我按时赶到了位于白石桥的新世纪日航大酒店。
今天我有一个话题（工作坊），便签公司。即如何用便签来体验规模化敏捷。 如果想要了解更多关于工作坊，可以扫下面的二维码。 今年敏捷之旅最大的收获是参加了开放空间中的一场即兴表演 即兴表演中，我积极参与其中，乐得其所。 整体1个小时的时间中，娜娜同学（引导者）表现的相当出色，成功地带着这群IT人疯了起来。 热身是几个小游戏，热身的重点在于身体要动。
体验 no; yes, but; yes, and 对眼神移位 热身后，主要有2个大环节：
A.阿尔法星球人 三个人一组，手挽手 每个人每次只能说一个字，即相当于三个人扮演一个人来说话 假定一个场景 然后由场下观众进行提问，注意尽量提开放式问题
反思：接龙的时候，尽可能按照常规逻辑接，比如上个人说今，下个人紧接着说天，不需要过多思考。 停顿时间越长，大家的思绪就越容易跟不上。 如果一句话结束了，下一个人要主动停，尽量不要去开启意料之外的话题。
B.即兴表演 4-5人一组 2个人上前进行表演 注意，尽可能动作到位（或夸张） 剩下的2-3人随时喊 停 然后上前拍台上2人中的1人肩膀 替换台上的人 用刚才的动作，继续另一个场景环节的表演
反思：这个环节，我的内心有一些紧张，不是很容易入戏。 或许放下自我，只要接上一个动作即可。
这两个环节由浅入深，由易到难。整体设计很棒。 再次感谢娜娜，以及未来会Show，大家可以搜索微信公众号关注哦。
总结：即兴表演和敏捷思想有相通之处：
先热身，暖场 从简单到困难，逐步掌握 先动手，再思考 Yes, and 最后感谢敏捷之旅北京的组织者廉雨和张明同学。（只有廉雨的照片啦） 以及更多其他的志愿者们 - 最后送上一张大合影 - 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 版权声明 本文采用 CC BY-NC-SA 3.
杭州敏捷之旅组织者聚会（2019） Bob的分享（待整理）
胡键的分享： 一个知识点，公司的招聘条件会随着公司的发展，而进化。
有意思的发现： - 创业公司，能搞定事情第一位 - 大公司，填好坑
优秀的ScrumMaster（杨明） 从不同的视角（管理者、团队成员、ScrumMaster自身）来定义： - ScrumMaster有哪些特点 - 隐喻（画）
组织者聚会，唯一的决策： 2020年在西安聚会
创建敏捷之旅的github组织
希望可以借此，开始协调起来。
版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
关于作者 BoB Jiang
和BoB面对面学习Scrum
HiBlock区块链社区（hiblock.net）发起人
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
敏捷一千零一夜社区合伙人
《Scrum精髓》译者 Bob的博客 Github: bobjiang Twitter: @bobjiang123 Solidity中文文档
作者：安宝平 微信ID: abp0616
Scrum 点滴
一直想把自己使用和学习Scrum的一点心得体会写出来，因为各种原因一直没有动手，（主要原因是懒）。这次参加完“敏捷之旅2016-北京”之后正好碰见个4天的圣诞假期，再不动手就说不过去了。
在现在项目中折腾了将近4年，经历了很多很多，也和其他公司一些人讨论过Scrum，在此期间自己产生过很多疑问，也了解到别人的一些疑问，发现曾经搞清楚的问题有了答案没有记录下来，过了阵子完全忘记了，或者说那些问题的答案逐渐在自己的意识中边缘化甚至消失。自己的“组织过程资产”正在缩水，这是件恐怖的事
。趁着还没大幅缩水的时候做个文字版的记录吧。（如下内容是“现在”这个时刻的记录，半年之后会变化很多，至少现在对于Scrum的理解相比半年之前已经变化很多了。现在先记着，等研究半年后再做个记录。）
先定几个基调，嘿嘿：）
工程师如果知道这么写代码会出bug他肯定不会这么写，基本没哪个工程师故意写出有bug的代码。 工作性质决定了工程师写的代码哪怕一个单词拼写错误都可能出现bug，不是说开发工程师比其他行业的工作人员更容易犯错，而是由工作本身决定。（一个职员写一封英文邮件，有点拼写错误一般不会出现问题）。 个人或者团队的表现好与不好更多的原因在于事业环境因素。如果只抓着个人或者团队的错误不放，很有可能是在舍本逐末\缘木求鱼。 关于工程师文化：大家所谈的工程师文化都是积极的、正面的、向上的。。。我觉得吧，这有点不客观。脱离客观一般会出问题。 Scrum反对教条主义，同时反对生搬硬套Scrum的要求。不要“只是因为Scrum没有明确地提到就假定某个实践是不准许或禁止的。” 想不出来以什么形式记录这些内容，就用了模拟问答的形式，自己感觉良好。哈哈。
Q（1）: 我对于 “敏捷”粗浅的理解？
A:
a) 对于比较庞大的需求，相对于瀑布模式，在敏捷中每个迭代都交付庞大功能的小部分功能，而不是等到所有功能都开发完成之后再交付，这种更早、更快的持续交付就是敏捷，是交付层面的敏捷。
b) 为了保证每个迭代所交付的产出具有该有的质量，要对本迭代和之前迭代的所有交付做充分的测试，这些测试要在短时间内完成，人工测试难以完成，所以施行自动化测试（含单元测试、集成测试和页面交互的自动化测试）辅以人工测试。自动化测试速度比人工测试快，这是QC层面的敏捷。
引用某大咖的话“敏捷是一种心态：一种拥抱变化，拥抱学习的心态，敢于尝试，强调实战，快速反馈，适应环境和市场的变化。需要每个成员的紧密合作，需要积极融洽的团队氛围。”
Q（2）：Scrum是什么？
A: 在我看来Scrum讲的是工作流程，职责分工，如何与他人合作。是爱德华•戴明博士的管理理论在软件开发这个行业中的具体体现。是适合于软件开发这种工作的项目管理工具。
Scrum的流程是框架，文化理念才是核心。
Q（3）: 为什么要实行敏捷（Scrum）和实行时要注意什么？
A: 每个公司（团队）情况不一样，这个要看出发点或者目的是什么。就怕没有太清晰的目标，同时对于敏捷（Scrum）不甚了解的情况下引入。这种情况下引入Scrum比较容易制造出一个变形的Scrum团队：稍微问一下就会发现，其实是挂着Scrum的“羊头”卖着自己的“狗肉”，各层面问题仍然存在同时还给Scrum安了一个“徒有其名”的罪名。
想实行Scrum之前自己不妨多花些时间想想为什么要改变原来的开发模式，再找个Scrum专家（比如我，哈哈~）交流下，自己对Scrum做个深入了解，看看自己能否接受Scrum及Scrum是否适合自己。
Q（4）: Scrum Master工作的意义（产出），如何衡量？看起来Scrum Master没有做看得见的工作，凭什么要给你开薪水？
A: 这个么。。要是开发团队没有什么问题， Scrum Master确实没太大的意义，我也这么认为。但…是……，如果开发团队有很多问题，比如产出bug量很多，每个开发工程师一周之内用于修bug的时间大于等于1天。这样的情况下Scrum Master如果能把工程师每周用于修bug的时间降到1小时之内，整个团队的效率至少是20%的提升吧。一个团队年度预算如果是500W。嗯，这个产出就比较容易计算了。同时引用某大咖的话“敏捷不仅是对工作的改变，更是精神面貌的改变。”
Q（5）: 实行Scrum不需要对远期的需求做讨论（规划），只把当前几个迭代的需求讨论清楚就可以了？
A: 这个是对Scrum的误解！Scrum说的是不对远期需求做过细的讨论，但不是不讨论。比如:
l 开发的是一个全新的大项目：在开始第一个迭代之前还是要做高层次的开发规划，比如项目有12个功能模块，要在1年之内完成开发，此时要做一个年度的planning meeting。先把12个模块的流程图做出来，有了逻辑关系就有了开发顺序，再评估每个模块需要的人力。对比现有人员，就会知道是否需要补充新的人员或者评估出年度内会不会需要加班。
l 在已有项目上做新功能开发：在年度之初做planning meeting也是有必要的。只是此时可能不需要画流程图而是根据业务、市场的需求排列需求的开发优先级。
个人认为应该加入到Scrum Master培训中的内容：对于大型项目、多个Scrum团队并行开发的情形要做高层次的年度、季度planning meeting和retrospective meeting。
Scrum强调对于远期的需求不做详细的分析，只对近期要开发的内容做具体的定义，需求的细化是渐进明细的。这里要注意，低层次的、细枝末节的需求可以渐进明细，但是中高层次的需求就不能渐进明细了。反而要像瀑布开发模式那样，在最初就把中高层次的需求定义清楚。即,除了迭代的planning meeting要做，还要做季度和年度的planning meeting，要注意的是，这个年度的planning meeting比迭代中的planning meeting粒度要大的多，绝不是瀑布模型中细致入微的开发计划。对于怎么做如果加个限定词，那就是“必须”、“不遗余力”，否则容易形成需求层面的技术债务。如果在设计系统阶段没有对扩展性，耦合性，系统性能等等这些方面做充分的考虑，等问题出现时再补救会很头疼。张小龙很得意的一件事就是微信从一个小程序到现在的庞然大物没有经历过重构。
Q（6）: 实行Scrum之后不需要写文档了？
A: 这也是对Scrum的一个误解。Scrum强调面对面的沟通，避免撰写详细规格说明书，但不等于完全不写任何文档。有些文档仍然要写，并且要求还不低。我们项目组对于核心功能、重要功能和复杂功能，要求开发工程师一定要写detail design。写完的detail design通过了tech lead的审阅才能开始写代码。在此之前有时还需要工程师写出functional design（功能设计文档），所写的functional design由product owner审阅，审阅通过说明工程师对于功能需求理解到位，detail design审阅通过说明工程师在技术实现上基本没有偏差，再之后进行的开发才不会出现大的偏差。这样的QA工作做的到位再交付给QC时才不会出现过多的问题。我们这里在没有单元测试、集成测试等自动化测试的加持下做到平均每个工程师每个月产生2个bug，很大的原因在于上述QA工作。（不是说自动化测试不需要，不是我们不想做自动化测试，这些由项目组之外的管理层决定。这么大的项目目前由于缺失自动化测试导致的一些问题已经暴漏出来了。）
