2015年11月27日，我们来自不同部门，为了共同的理想，相聚在一起。在欢乐声中圆满的完成第一期活动。 首先，王立杰老师给我们介绍了“JD敏捷创新社区”创立的初衷，以及我们的使命、愿景和核心价值。 1破冰 这是我们。认得出是谁吗？ 2创新工坊 创新工坊 开启 创新之旅实战演练 BOB带领我们进入游戏环节。设定游戏规则，下一秒钟，你永远不知道会发生什么~~~~ 设定一个圆，添加元素，编织出精彩的故事， 创新悄无声息的发生了；转换战场，根据新的要求添加相应元素；思维转换，让元素与元素，画面之间相互碰撞，让创新枝繁叶茂开出新的花朵。 第一组，精彩的神话故事诞生了~~~~~~~ 第二组，我们走的是科技、宇宙、穿越、爱情故事路线，小伙伴们有没有被颠覆到？ 第三组，卡通的故事画面，乐观、坚强、励志、富有想象力的故事情节让我们看到了武大郎的精彩人生。 游戏结束，梦醒了，我们通过一轮一轮的游戏环节，用手来思考，齐心协力完成任务悟出了创新的真谛。 3献计献策 最后，我们就社区的活动类别、活动方式等内容各抒己见，畅说欲言，为社区的发展确定了发展方向，从而使社区发挥更大的作用。 JD敏捷创新社区我们一直在路上，我们将携手共进创造更美好的未来！

这篇心得是来自参会者罗涛对于敏捷之旅2015年北京站的反馈，感谢罗涛！ 本周末有幸参加了史上最不靠谱的敏捷之旅北京2015会议，整个过程采用众筹模式进行，从场地，主题到费用，感觉都不错。今天根据我的感受，主要谈谈对主题和讲师的一些感想。 在这次会议中，有很多主题，分为四个分会场进行，由于前期参与过很多次活动，所以，其中大部分内容是知道的，并且对某几位讲师也比较熟悉。因此，在选择上，更偏重于内容的选择，但发现在这个敏捷大会上，标题党也是存在的。 首先，我发现很多标题很吸引人，有些讲师的学历也很高，大多数博士啊，但是，真因为如此，太过于偏重先进理论的阐述，基本上是在从论文中提取观点，虽然自成体系，但对于我等偏重实践的屌丝来说，如果不是昏昏睡去，就是溜之大吉。 然后，对于那些实践派和工作坊，则是人气爆棚，大受欢迎，求签名求加微信瞒不过来，台上的讲师，各个都是身经百战，虽然在理论上可能略有不足，但实战经验丰富，台下听众，踊跃互动，结束后还会继续攀谈，加微信，忙的不亦乐乎！ 听众中，也有很多不同的声音，有为了求解心中问题的答案而来，又为了坚持自己的信念而来，有寻找同好而来。因目的不同，所表述各异，即使同一话题，因为听众的具体情况不同，也会出现全然不同的两种结论，现场就会进行讨论，氛围很好。 那么我的感觉是什么呢？ 首先，现在这个社会，不要再堆砌理论了，大家都是聪明人，没点干货，就不要出来浪费时间了，不关你是最新的理论成果还是酷炫的未来趋势，如果不能满足用户的当前需求，那一切都是浮云。 第二，不要纠结于理论上的完美，大部分软件工程的理论和标准都是在实践的基础上总结出来的，所以你看到的标准和理论，都是别人已经做过很多的实践，能用就用，没有匹配的，自己先干起来吧，这个互联网+的时代，产品好用是硬道理。 -———-以下为广告————— 感谢我们的金牌赞助商 ”)”) 其他赞助商 场地赞助商 礼品赞助商 图书赞助商 清华大学出版社 图灵教育出版社 博文视点出版社 人民邮电出版社

这篇心得是来自参会者龚正对于敏捷之旅2015年北京站的思考，感谢龚正！ BOB老师，您好 上周日参加的北京敏捷之旅，对于最后座谈会上大家讨论的一个问题很有感触，写了一篇心得~ -——————————————————————————– 上周日参加了北京的敏捷之旅，连续听了四位老师的讲座，新学到了不少知识，对之前的一些问题又有了新的认识。最后的一场座谈会中，大家讨论的一个问题让我联想到了两种管理思维的不同之处。 座谈会上，有位PMO的同学问到PMO员工未来的发展规划和职业道路，一位老师回答说，在自组织团队里，PMO是会消失掉的，PMO的作用是帮助项目经理管理项目，如果项目经理可以管理好项目的话，PMO就不需要存在 了，所以PMO的工作是把自己干掉，这听起来很矛盾。当时有另一个同学就反驳、并列举了他们公司中PMO的职责，比如客户的沟通、纠正项目经理管理中的问题、提供项目经理职业发展规划、督促项目经理进行自我提升等等。最后因为会议时长的原因，这个话题就没有继续讨论下去。 话题结束后，我开始思考传统的管理思路和敏捷管理思路的区别。传统的管理方法中，管理者好像在假定下级的管理者和员工因为经验的缺失、视野不够高，他们的管理能力是不胜任的，所以才需要进行监督和控制，管理者把大量的精力投入到对项目的管控中，当项目越来越多时，管理者便设立了PMO辅助他进行项目管理，PMO办公室开始制定项目流程、控制项目过程、用KPI考核绩效，用项目管理的工具来跟踪项目的执行。 敏捷的管理思路更多的是强调团队的自组织和自律性，认为团队可以自行的做好自己的计划、执行和监督的工作。所以不需要管理者过多的干预，团队也可以自发的协调好彼此的关系，管理者需要信任下属，给予他们适度的授权。 两者的区别类似于管理学中的X理论和Y理论，传统管理思维认为大部分人是被动的，所以需要被管理，而敏捷管理思维则认为大部分人是主动的，所以他们可以自己管理自己。两种不同的出发点，产生了两种不同的管理方式，采用哪一种管理方式，则取决于管理者的性格和所处的环境了。 -—————————————————————————- 谢谢BOB老师还有其他的会议组织者，周日一天学了很多东西~ -—–以下是广告—— 感谢我们的金牌赞助商 ”)”) 其他赞助商 场地赞助商 礼品赞助商 图书赞助商 清华大学出版社 图灵教育出版社 博文视点出版社 人民邮电出版社

这本书很早之前就买过一本，大致看过目录，感觉是一本不错的书。不过一直没有详细阅读。 最近想翻出来看的时候发现不知书去哪儿了，只能破费再买一本。 本书中我最大的收获是，要区分是谁的问题。父母和孩子发生冲突后，是孩子的问题，还是父母的问题？ 很多父母，包括我自己也是这样。经常会分不清楚到底是谁的问题？ 如何区分呢？ 问题属于孩子时 我的体会是，先问自己，孩子的这个行为给我带来什么影响？如果木有影响或者只是面子问题，那么多数这个问题是孩子的问题。比如说： 孩子早上赖床 孩子不好好吃饭 如果是孩子的问题，并且孩子需要帮助，那么从长远来看，最有效的帮助方式就是不提供帮助。 这里的不提供帮助，不代表要忽视孩子存在的问题，转而去做父母自己的事情。而是不提供父母的解决方案。 比如父母可以用如下方式进行沟通： 简单的敲门砖 积极倾听 问题属于父母时 当问题属于父母的时候，父母可以有如下做法： 直接改变孩子 改变环境 改变自己 书中有一个例子，很生动的描述了这3个做法。有兴趣的可以买书，翻到105页仔细阅读哦。 本书给我另外2个启发是： 我-信息 如何实践“没有输家”的解决方案 我-信息指的是在沟通的时候，要更多采用我开头

标题：翻转组织—通用医疗敏捷转型案例 副标题：在强监管下启动敏捷项目，组建自管理团队 首先说明一下这个案例是我的好朋友黄喆和他的同事方建国亲身经历，在DanielTeng的辅导下所实现的敏捷转型。 本文一共分为3个部分，这是第一部分。 在规模化敏捷中组织文化转型和组织结构转型一直是两个很棘手的问题。如何构建跨职能、跨模块的全功能团队？如何导入自组织的文化？团队自设计的过程可能是同时解开这两个难题的钥匙。本文将展示一个在大型医疗企业中进行团队自设计的案例，希望可以为读者带来一些启示。 背景&结果 在选敏捷教练进入之前，GE Surgery SW团队已经自己在敏捷的道路上进行了1年左右的探索。当时团队的状态是： 1团队文化有“自组织”的萌芽，但命令和控制仍是主流。 2有Sugary的产品包括三大子系统：Xray Control, Imaging以及Application。共五支跨职能团队（包括开发和测试人员），每支团队分别负责不同的子系统，具体如图1所示。这就导致team在开发一个用户关心的feature时，需要很多倒手和协调的工作。一个功能要倒手几次才能进行系统集成，降低了交付效率。同时，这也迫使PB中存在很多的TechnicalStoy。项目PO在计划PB时不能完全按照客户（医生）的需求去排列feature开发的优先级。 3五支团队有一名项目PO，维护整个产品的PB。每支团队各有一名team PO，维护team一级的PB。每个团队的PO关注的是较细节的需求，但这实际上应该是团队关心的内容。每支团队独立的PB也比较容易引发局部目标和整体目标的冲突。 4每支团队都有一名兼职的SM。由于同时兼职开发工作，所以这位SM的工作基本以引导各种Scrum会议为主。没有更多的精力去帮助团队改进和成长。 在敏捷教练团队（Daniel Teng和他的同事们）进入GE Surgery SW团队并进行了评估后，他们提出了两种启动敏捷转型的方法：一种是变革式的，而另一种是渐进式的。他们和Surgery SW经理高剑宏进行了一次深入的探讨，并决定对组织文化和组织结构进行一次由内向外的变革。随后Daniel设计并引导团队进行了团队自设计的工作坊。这次里程碑式的工作坊在Surgery SW内部也被称为“团队成年礼”。通过这次成年礼，团队完成如下转变： 1组织开始转型为“自组织”型的组织文化。团队的自组织意识得到了很大的鼓励和提升。 2组建了4支具备端到端开发能力的跨模块的Feature Team。打消了团队之间的依赖。 3取消了团队一级的PO和PB，只保留一个项目一级的PO，维护一份整体项目的PB。4支团队都只关心整体目标，避免了局部目标和整体目标冲突的问题。 4设置两名专职的SM，每位SM负责两支团队。SM可以更深入的引导团队进行持续改进。 接下来让我们来看看团队评估和成年礼的具体过程。 评估和筹备 在Coach进入团队进行了为期3天的评估后，Daniel向Surgery软件经理高剑宏提出需要对团队进行一场由内到外的变革。这意味着两个方面。首先，要将团队的组织文化转变为“自组织”型的文化，让团队成员成为“成年人”。其次，需要对团队的组织结构进行调整。建立功能团队，合并PO和PB，设置专职的SM。 这对于SurgerySW无疑是一场深入而巨大的变革。作为经理的高剑宏需要考虑变革所带来的好处及其可能引发的后果。团队是否可以适应新的组织文化？团队结构的调整势必会造成一部分已有工作的浪费并对项目造成一定的影响，这样的影响是否可以接受？在这种转型中，经理的角色应该发生怎样的转变？种种问题并非短时间 可以考虑清楚。所以在提出建议后，Daniel请剑宏仔细的考虑三天的时间。最终，三天后剑宏给出的答复是“Goahead!”。一场由内而外的变 革也随之拉开了帷幕。 转型前的Surgery SW团队的管理水平大致位于“Manager-led team”与“Self-Managing team”之间（见图4）。团队可以管理Sprint内部的工作，但团队的工作流程、DOD以及每个Sprint所做的Feature都是被管理层（经理、PO以及SM）所指派的。而这次转型的目标是要让团队达到“Self-Designing team”的水平。这就需要将认领任务、制定工作流程、定义DOD以及团队设计的权利移交给团队。受到Craig Larman和Ahmad Fahmy的“How to Form Teams in Large-Scale Scrum? A Storyof Self-Designing Teams”的文章的启发，Daniel建议引导团队进行一次自设计的工作坊。在这次工作坊上Coach会引导团队进行自设计，选举他们认可的SM，并定义团队自己的流程和DOD，以此完成权利的移交，从而带动组织文化朝“自组织”方向转型。这项建议随后也得到了高的同意。 作为前期准备的一项重要活动，在自设计工作坊前一周，教练还通过微信群将相关的消息提前发布给了团队。并告知如果希望竞选SM的同学需要提前准备一个2-3分钟的竞选演讲。这一提前准备活动为团队提供了一个“转型”的信号，同时也让团队中的成员有较充分的时间思考是否愿意竞选SM。 本文一共分为3个部分，这是第二部分。 团队自设计工作坊——成年礼 当天 所有的团队成员和Coach都参与了这个工作坊，Daniel先引导团队进行了一个破冰仪式。之后，经理高剑宏介绍了本次团队重新组建的目的： 1消除团队间的依赖，提升团队的端到端交付能力。 2最终形成4支全功能团队，每支团队6名成员。 3选举两名专职的ScrumMaster。 整个自设计工作坊为期一整天，其具体计划如下： Scrum角色介绍（2小时） SM发表竞选演说（0.5小时） 团队自组建（1小时，2个迭代） 团队选出他们希望的SM（10分钟） 团队确认自己的现状和发展目标（1小时） 组建虚拟团队（2小时） Scrum热身介绍 为了让团队可以就PO和SM的具体职责达成一致。Daniel首先为整个团队介绍了Scrum中的角色和职责，让大家对理想的团队和SM建立了基本的概念。

传统软件开发（或者说瀑布式软件开发）方法，对于需求的看法是 – 尽可能详细的了解需求、分析需求以形成详尽的需求文档，然后就把文档交付给开发部门。敏捷软件开发中则是完全不一样的做法。首先敏捷需求是ODDE的，其中有一个点很重要就是Detailed Rightly (Appropriated) – 详略得当。 什么是详略得当 介绍详略得当之前，我们先看一张图 在上图的产品列表（Product Backlog）中，最左边分为几个部分：已完成，细粒度，粗粒度，下一版本。已完成无需介绍，下面分别介绍一下细粒度，粗粒度，下一版本。 细粒度 细粒度的意思是这些产品列表条目是相对比较明确的，详细的。团队对于这些条目的认知是达成一致的。经常有学员问我，那这些条目到底多大合适？这里有一个经验值供参考（根据行业不同会有很大不同） – 一般来说，一个团队在一个迭代内完成6-12个条目为宜。细粒度一般也意味着马上要做的条目。 粗粒度 粗粒度指的是这些条目的细节还不清楚，团队有可能没有达成共识。粗粒度一般是接下来2-3个迭代要做的条目，并且会在产品列表梳理会上，对粗粒度的条目进行拆分、澄清，从而有可能变成细粒度的条目。 下一版本 有一些条目是近期不会考虑的，但从产品规划上需要有考虑的。比如正在做一个安卓APP，从长远来看是需要做iOS版本的，不过可能要3个月后才会考虑。这样的条目就是下一版本的。 为什么详略得当很重要 敏捷需求是有分层的，正如上一节讨论的，分为：已完成，细粒度，粗粒度，下一版本。 如本文的题图（感谢Alistair Cockburn博士），产品列表中的条目也是可以分为鱼虾级别（故事）、大海级别（Epic）和风筝级别（Theme）。 那么为什么详略得当如此重要呢？ 这是因为产品列表条目，我们（作为人类）不可能一次获得所有信息。在产品开发的早期，获得的信息尤其少，那这个时候做出的需求分析（或决策）怎么可能包含所有的条目呢？因此条目就不可避免的有大海和风筝，只有少量的鱼虾可以完成。随着完成的鱼虾越来越多，我们获得的信息也越来越多，对产品的认知也越来越清楚，从而能够做出更加可信的决策。 写在最后 本篇文章起源于“敏捷之旅北京众筹群”中，和火星人陈勇之间的一次讨论。我的观点和陈勇老师略有不同。用户故事，顾名思义，是从用户的角度来讲故事。那么它的核心是产品负责人和开发团队之间都了解这个用户故事是解决什么问题的。而不是一定要从Theme拆分成多少个Epic，从而再拆分成多少个Story这样的一个过程。 讨论原文如下： 火星人 18:20 我在开发中摸索出一个新体系，能在战术层面融合uml fpa story scrum mvc这几个东西 火星人 18:21 以前都是战略层面上融合，“兼容”但是没有具体做饭法 火星人 18:26 最近做项目的时候发现了一种很多人本能会用但稍加改良就能统一所有方法的东西 火星人 18:43 涉及到jira中theme epic story三层需求的定义 火星人 18:44 用这种方法可以让两个人分解出来的三层内容几乎相同 火星人 18:46 就是因为头疼分解问题，我观察了项目前期的需求，发现了一些规律。等我到笔记本上打字吧 火星人 18:50 我们发现有一种故事比较“舒服”，就是可以放在“作为一个……，可以（故事）……，以便……”，这种故事都是动宾词组，比如“上传简历”，“查看商品”等等，从文学的角度正好放在“可以”后面。 火星人 18:50 另外一种故事则有点问题，比如“货物管理”“配置子系统”，完全不可能“可以货物管理”，或者“可以配置子系统” JinKenny 18:51 这就是As a…I want….So that…结构 火星人 18:51 后来我们就把洞宾词组的放在第三层（Jira和TFS都叫Story），名词的放在第二层，并将其分解为相应的动宾词组 火星人 18:52

引导是什么 从英文来看facilitate的意思是使能够、使之变得更容易的意思，大致可以延伸理解为支持并推进。 国内对facilitate的翻译包括引导、催化、促动、建导等。 入门大揭秘 入门法则快速记忆–TRRE 时间盒（Timebox） 引导之前，首先要明确时间规则。有两点需要注意： 明确作为引导师，你有多长时间。比如10分钟、1小时、1天，时间不同选择的引导技术和工具是截然不同的。 在引导过程中，需要给出明确指令，接下来的环节是多长时间。比如5分钟、7分钟等。同时会用计时工具进行计时。 结果（Result） 接下来要介绍的是这个环节的产出是什么，或者说对参与者的期待是什么。结果或产出一定要具体，也可以结合下面的例子环节，给出具体示例。 规则（Rule） 然后就需要介绍规则是什么。介绍规则的时候，还可以介绍一下哪些是违反规则的，给出示例。 上述TRR讲完之后，可以结合在一起给出完整的例子。 示例（Example） 如果是非常简单的引导技术和结果，可能会略过例子环节。而我碰到的大多数引导过程是需要给出例子，或许是引导师邀请参与者共同示范。 总结 引导技术入门是TRRE，即Timebox,Result,Rule,Example–时间盒，结果，规则，示例。

现在钱不值钱的时代，100元竟然还能这么超值，这帮家伙一定脑子浸水了，一帮有爱的家伙 做个爱学习的IT人，不只是开发人员，研发团队所有成员都应该开放的来学习。名额有限，100元可获得敏捷之旅2015北京站纪念奖章一枚，大会PPT，门票1张，价值30元精美笔记本+笔一套，价值50元的敏捷图书一本，价值6000元CSM免费培训的抽奖机会，还有更多赞助商礼品等着你…… 支持我们的众筹 我们为什么要众筹 本次会议（敏捷之旅北京2015）是参与者的会议，你想有一个什么样子的会议都可以参与讨论、设计、提议（筹钱、筹力、筹讲师、筹场地、筹平台等）。每位参会者都能够真正参与其中，发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助都可以。任何想法都可以@廉雨 或者 @姜信宝 众筹的收益： 1. 交到志同道合的朋友 2. 支持敏捷社区发展 3. 与业界敏捷精英交流与分享彼此的敏捷实践与心得 4. 抽奖获得各种奖品和书籍

最近和几个新朋友聊天，自我介绍的时候说我是敏捷教练。紧接着问题来了，朋友经常会问什么是敏捷教练？ 下面是我微信朋友圈几个不错的解释： 授人以渔 敏捷+教练 敏捷价值观的布道者 有能力协助排除敏捷障碍的人  引导者 高情商的牧羊犬 下面是我的理解（观点）： 敏捷教练，对应的英文是Agile Coach，也就是说它是两个词的组合，即敏捷+教练。下面我们分别了解一下什么是敏捷，什么是教练。这对了解敏捷教练非常有帮助。 什么是敏捷 敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。（摘自wikipedia） 敏捷的另一个定义 – 敏捷是尽早频繁地交付商业价值。（感谢Alistair Cockburn） 什么是教练 国际教练联盟（International Coach Federation) 定义教练：“ 专业教练作为一个长期伙伴，旨在帮助客户成为生活和事业上的赢家。教练帮助他们提升个人表现，提高生活质量。教练经过专业的训练，来聆听，观察，并按客户个人需求而定制Coaching方式。他们激发客户自身寻求解决办法和对策的能力，因为他们相信客户是生来就富于创意与智慧的。教练的职责是提供支持，以增强客户已有的技能，资源和创造力。”（摘自百度百科） -—————–华丽丽的分割线—————— 我们了解了什么是敏捷，什么是教练之后，现在来看看敏捷教练到底干什么？ 敏捷教练做什么？ 敏捷教练做的工作主要分为3个方面： 个人方面 敏捷教练要有能够搞定关键人物（如Sponsor，经理，团队里的tech lead等）的能力。这个能力包含但不限于教练，个人影响力，唤醒者工具箱等。 团队方面 敏捷教练能促使团队自组织，成为高效能团队，并能够自驱动变得更加高效。 组织方面 仅仅一个团队变得高效并不能保证整个组织高效，或者产品的高效产出。这还需要整个组织变的高效。这可能包含但不限于组织结构的调整、工作流程的调整、工作环境的调整等。 -—————–华丽丽的分割线—————— 熟悉Scrum的朋友应该知道有一个角色叫ScrumMaster，那么ScrumMaster和敏捷教练又有什么区别呢？（摘自David Ko的博客） Scrum Master 對象: 針對某個團隊 任務: 主要是重心是幫助團隊實施 Scrum 和專案的關聯: 通常和專案緊密結合 和團隊的關聯: 是團隊的一份子, 要保護團隊 所需要的訓練: Scrum master 這個角色要懂的事情 有敏捷的相關經驗: 不必要 敏捷教練 對象: 針對個人或是團隊 任務: 變革管理, 敏捷性 (agility) 和專案的關聯: 和專案無關, 或是說並不隸屬於某個專案

唠叨几句 为什么不靠谱？因为每年敏捷之旅都是要先招募组织者，然后由组织者来决定会议时间、地点、流程、讲师等等。今年我们想来点不靠谱的事情，所有的内容全部由参会者来决定，每个人都可以发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助。 10月10日有了这个想法之后，一个下午的时间约400人就聚集在一起。 敏捷之旅众筹介绍： 什么是敏捷之旅 敏捷之旅（Agile Tour）是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。如今已步入第8个年头，敏捷之旅目前正走向全球，并且获得了敏捷联盟（Agile Alliance）及Scrum联盟（Scrum Alliance）的支持。 敏捷之旅中国从成都站开始，到今年已经有20个城市举办过敏捷之旅，每年参会人数达到2000多人。 为什么要众筹 本次会议（敏捷之旅北京2015）是参与者的会议。给自己办一次聚会，会议内容、流程方案、讲师筛选、场地布景，这些都由你决定。每位参会者都能够真正参与其中，发动自身的资源，邀请好友，推荐讲师，联系场地，寻找赞助都可以。任何想法都可以@廉雨 或者 @姜信宝 众筹的收益： 交到志同道合的朋友 参加会议 抽奖获得各种奖品和书籍 众筹参与规则 众筹参与规则（草拟，大伙可以跟，并修正）: 1.我组织，转发@廉雨 的众筹宣传图片到朋友圈 或者拉5个感兴趣的人入群。 2.我出力，认领一件任务，免活动门票。（联系@廉雨） 3.我出钱，众筹本次会议费用（具体再定） 4.第一条必选，第二条第三条必选一条 当前进度 A. 愿望列表 敏捷之旅北京众筹愿望列表，格式“1. xx愿望+你的名字”，请大家复制本条消息接龙，要求简洁明了: 1. 希望有户外活动，不仅仅户内分享—王立杰 ； 2. 希望有大牛分享，如Henrik Kniberg—姜信宝； 3. 实战的案例分享和演练—尹利霞； 4. 希望有失败案例和问题分析—王璐； 5. 希望分享大企业如何做敏捷转型案例或思路（如果没有案例）； 6. 如何将传统团队及流程顺利移植到敏捷—春儿； 7. 能众筹一个自己的xx馆做活功基地—张学海； 8. 敏捷团队组织与建设+案例分享—王彬； 9. 众筹一个敏捷书店—李建昊； 10. 希望可以把敏捷的理念推广到传统行业，如制造业等—王梓晨； 11. 继续去年讨论过的敏捷育儿话题— 何永振； 12. 与国际敏捷组织交流—刘静； 13. 希望定期（每月）有活动—刘广民； 14. 建立积累维护一个敏捷实践的案例库 （成功、失败，各种场景….) —贾锦杰。 15. 各种常用敏捷开发或测试使用的工具介绍—曾莉莉；