产品列表梳理会议是Scrum中非常重要，而很容易被忽略的一个会议。说它重要，是因为Scrum开始之前就需要有准备就绪的输入，这个输入就来自于产品列表梳理会议的结果，即初始的产品列表。而对于刚开始转型敏捷的团队，往往会忽略掉产品列表梳理会（需求梳理），从而造成迭代计划会时间过长，或者无法准时开始迭代等等问题。要想解决这个问题，需要首先明确为什么在迭代开始之前要进行梳理会议，以及谁需要参加这个会议，在这个会议都有哪些活动等。 产品列表梳理会议，是迭代就绪的很好的指示，即只有产品列表准备好了，才可以进入迭代。另外，梳理会议是由产品负责人发起或负责，可以召集开发团队参与，也可以只有相关的开发团队成员或相关的利益干系人参与。 产品列表梳理会议的内容可以总结为如下几个字：增删改。首先需要明确一点的是产品列表不是固定不变的，它是可以随着新需求的出现而变化的（即好的产品列表符合DEEP原则，参加博文产品待办列表和用户故事）。 增：那么当出现新需求的时候，就需要增加一条产品列表条目，并且针对新的条目也需要符合良好用户故事的标准（INVEST）。 删：某条需求如果已经不再需要，或者市场条件变化后该需求就可以删除了。 改：产品列表的修改还可以分为以下几类： 重新估算用户故事大小、 重新排用户故事的顺序、 用户故事拆分等。 调整发布计划 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算

Scrum工件主要包含一下3种： 产品Backlog Sprint Backlog 产品增量 产品Backlog 在Scrum中，主要由产品负责人[参见Scrum入门基础系列之Scrum角色]整理和维护产品Backlog。产品Backlog是Scrum中维护需求的主要工件，也是做好Scrum的第一步。一个好的产品Backlog，是要符合DEEP原则的，即，产品Backlog是详略得当的（Detailed Appropriate），涌现的（Emergent），估算的（Estimated）和排序的（Prioritised）。详情参考参考之前我发的博文“产品Backlog和用户故事的原则”。 一般来讲，产品Backlog里面都可能包含哪些内容呢？新特性、改进项、缺陷修复、文档需求等。 Sprint Backlog Sprint Backlog主要由挑选的当前Sprint要完成的产品Backlog条目，以及根据这些条目进行拆分后的任务组成的，在Sprint Backlog中还有一个很重要的东西就是当前Sprint的目标，团队根据这个目标以及产品Backlog的排序来进行挑选。 Sprint Backlog的内容是由团队来决定的，具体的工作方法和实现方式，也是团队自己来决定的。在这一点上，充分体现了团队的自组织能力。 产品增量 产品增量是Scrum中非常重要的工件，因为产品增量才是最终交付给客户的内容。因此每个Sprint团队必须交付产品增量，以符合如下原则： 交付的产品增量必须是高质量的。也就是说每个产品增量是潜在可以发布的。 交付的产品增量符合团队的完成定义（Definition of Done） 产品负责人（或客户）能够接受产品增量 另外，产品增量也是团队进展的一个标识。开发团队通过不断地交付产品增量，给团队本身和利益相干人以信心，促使产品最终发布。团队进展还有其他常用的标识是燃尽图和任务板。一般使用燃尽图和任务板时，是为了使当前的进度公开给更多的其他团队或干系人。 完成定义，指的是当产品增量完成的时候，必须是团队成员共同理解的完成，而不会出现歧义。并且产品增量需要是高质量的，潜在可以发布的。也就是说，当产品负责人要发布当前的产品增量的时候，马上可以发布出去。完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。还有，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成定义中。 Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算

Here I would like to talk about product backlog refinement meeting, including what activities should be in this meeting, who should join this meeting and why we need refinement meeting. Why to have product backlog refinement meeting As the figure above, it occurs during sprint for product backlog refinement meeting, and normally no more than 5% total time of sprint. E.g during sprint 1, Product Owner (PO) will conduct refinement meeting for sprint 2 and sprint 3.

最近一直在反思一个问题，那就是瀑布式软件开发的问题究竟出在哪儿了？这个问题首先要先问问瀑布式开发的鼻祖–Winston Royce，而看了Royce当年的论文之后，有不小的发现。其实他当时提出瀑布式软件开发就已经指出这个过程存在很大的问题，在论文中他提出，瀑布式开发中测试在很靠后的阶段才第一次介入（接触到软件），如果发现设计中（或需求上）的问题结果很严重。 论文的原文如下： 结果不言而喻，提出者已经质疑的一个理论，被无限放大了。 接下来从另外一个角度继续探究这个问题，即瀑布式软件开发是从哪儿学来的？我们很容易的可以从制造业的流水线工厂内找到相似的模型。针对制造工厂的生产环节，努力做到的一点是标准的（相同的）输入，经过流水线后，会产生标准的（相同的）输出。因此在输入的时候就要想尽办法要让内容保证标准。如下图，瀑布式软件开发也在做同样的事情。 所以在瀑布式软件开发中，首先要做的事情是尽可能的收集需求，收集的越多越好，越详细越好；接着就是做需求分析和设计，这个阶段也是追求完美，最后根据这些完美的详尽的文档制定出一份无懈可击的计划，然后开发团队按照计划执行就搞定了。 如果发生需求变更怎么办，有需求变更委员会。据我个人的经验，需求变更是很难通过需求变更委员会的批准的。因为瀑布式软件开发会认为我都已经做完设计了，这个时候变化会带来大量返工。所以越到后面的阶段，变更越难。 那么瀑布式软件开发有没有优点呢？下面我们看看瀑布式软件开发有哪些优点：【翻译自https://www.waterfall-model.com/】 在进入下一个阶段之前必须完成当前阶段的工作。因此如果该阶段有问题可以很容易的发现。 许多重要信息都留在纸面上。新员工进入项目时，可以很方便的知道进行到哪儿了。 瀑布式软件开发方法几乎所有的软件开发者都熟悉，也很容易采用。 最后，你怎么看呢？

Scrum会议包含Sprint计划会、每日例会、Sprint评审会、Sprint回顾会。下面分别介绍这几个会议，按照一个简单模板进行介绍： WHY、WHAT、WHEN、WHO、HOW，即为什么要有这个会议，这个会议的输入和输出是什么，什么时间开这个会，谁来参加，如何开好这个会议。 Sprint计划会 WHY Sprint计划会是为当前Sprint做计划的会议。 WHAT Sprint计划会的输入为产品Backlog，最新的产品增量，团队的能力和开发速率；输出为Sprint Backlog和Sprint目标。 WHEN Sprint计划会议发生在Sprint开始的时候。对于一个4周的Sprint，计划会时间应该小于8小时，2周Sprint，计划会时间小于4小时，以此类推。 WHO Scrum团队（产品负责人、开发团队、ScrumMaster）都应该参加Sprint计划会。 HOW Sprint计划会议有两种方式。 方式一：传统的两段式会议 - 第一部分由产品负责人和开发团队一起决定要完成什么（What），第二部分由开发团队来决定如何完成（How）。 方式二：循环式 - 1 产品负责人和开发团队选择产品Backlog最上面的那个用户故事，2 开发团队根据团队能力和以往的速率决定是否可以完成这个用户故事， 3 如果可以完成，那么拆分用户故事为任务，否则选择结束Sprint计划会议。4 重复上述1，2，3直到团队无法承诺更多的用户故事。 每日例会 WHY 团队每天同步信息 WHAT 团队会根据每日例会的情况，1. 调整燃尽图（如果有的话） 2. 调整Sprint Backlog或Sprint Backlog中的任务。 WHEN 强烈建议每天固定时间和地点开始 WHO 开发团队、ScrumMaster、产品负责人（可选）、其他利益干系人（可选） HOW 团队围成圈，面对彼此，回答如下3个问题：1. 从上次例会到现在我完成了什么？ 2.从现在到下次例会我将会完成什么？ 3. 有什么障碍或问题？在整个每日例会过程中，只有猪（隐喻投身Scrum的角色）才可以发言。 Sprint评审会 WHY 在Sprint结束前，产品负责人接收或拒绝开发团队的Sprint目标。团队检视和调整开发的产品增量。 WHAT 输入为Sprint目标和Sprint Backlog，输出为潜在可交付的产品增量和调整的发布计划。 WHEN Sprint结束前 WHO 开发团队、ScrumMaster、产品负责人、其他利益干系人（建议邀请，尤其是有关联工作的） HOW Sprint评审会是一个非正式会议，即这个会议上不需要准备幻灯片来进行完美的表演，团队需要展示出他们的工作成果。另外产品负责人应该不是第一次看到Sprint的成果，也就是说很可能在平时，开发团队每完成一个用户故事，产品负责人就已经评审一个。最后不过是一个仪式，可以让团队拥有成就感。 Sprint回顾会 WHY Sprint结束前，团队一起为开发流程做出改进而努力。 WHAT 输入为各类主观和客观数据，输出为行动计划，有可能放在专门的改进Backlog，也可能放在下一个Sprint的Backlog中。 WHEN Sprint结束前，一般在Sprint评审会之后。 WHO 开发团队、ScrumMaster、产品负责人。（一般不建议经理参加） HOW 设置环境 收集数据 产生洞察 确定行动 结束会议 具体细节请参考《敏捷回顾》一书（Agile Retrospectives）

2014-12-21 黄喆 敏捷一千零一夜 记录者，黄喆，软件攻城狮，CSM，热爱敏捷、精益。目前工作于GE，从事软件过程改进、敏捷项目管理等工作。希望能在Agile1001这个大家庭中与大家交流、学习、共同成长。 -——分割线——– 600%现金人民币纯利收益；亲身经历组建创业团队、MVP产品设计、拉投资、虚虚实实的商业博弈、吸引天使客户的反馈、痛苦的产品转型、高大上的兼并和重组以及激动人心的现金分红；最后，还结识了一群激情四射、才华洋溢的队友！这么Fancy的事就发生在一个下午，三个半小时之内，而且还是免费的！您一定是在做梦吧？！！哈哈，绝对没有！这一切都发生在Agile 1001在敏捷之旅上为我们带来的“O2O体验式工作坊”中！笔者有幸参与其中，爽到之后不敢独享，还要分享出来让大家眼馋一下，从而再次提升一下自己的幸福指数。哈哈，太邪恶有木有。。。 废话不多说，咱们直奔主题，这次Agile 1001为我们带来的“O2O体验式工作坊”的主题是最近火遍全球的精益创业。但其采用的方式是纯体验式的，整个活动下来没有一句说教，就是一个字“玩儿”！参与工作坊的同学首先被随机的分成了3个小组，每个小组选出一名CEO负责创业公司决策和一名CPO负责产品设计。笔者非常幸运的被大家推选为了CEO，而来自“汽车之家”的刘阳 同学被我们推举为了CPO，这可能是我们做的第一个也是最正确的决定。至于当CEO为啥“幸运”，选CPO为啥“正确”，这个我们后面会说。 “家里菜团队” “来就吃”团队 俺们“微饭”团队，在讲的是CPO,我是。。。你们猜猜。 工作坊的游戏规则很简单：三个组的目标都是做一款餐饮APP，需要有自己的特色，总共三个MVP，每次交付一个纸面原型，然后选择是否发布给市场获取反馈（但同时也要承担竞争组针对性的打击），最终三个迭代后在三个组中PK出唯一的获胜团队。（不知道MVP和纸面原型概念的童鞋要赶紧补习一下啦，这里不解释喽）。之后就是这次工作坊的最大亮点，每个团队被要求进行一轮真金白银的创业集资，每位团队成员都必须拿出真的人民的币来进行这次集资，而最终在游戏中获胜的团队将会“席卷”另外两个团队的所有集资，然后按照股本比例分红！赤裸裸的零和博弈and真金白银的输赢啊！不要太刺激了有木有？！！在一番面面相窥的严肃思考后，大家小心翼翼的将自己热乎乎的人民币放到了团队集资袋中封好。然后，为了另外两个组的人民的币，我们义无反顾的踏上了激动人心的创业之旅。 下面来说说我们的“创业”历程。我们小组对这款餐饮App取名“微饭”，我们的CPO刘总和大家讨论后对“微饭”的定义是：实现客户的提前在线订餐，让食客可以到了就吃，在节省食客就餐时间的同时提高餐馆的翻台率。双赢！很不错的想法是吧？可后来的事实证明我们差点就在这里犯了最致命的错误，幸亏我们后面悬崖勒马，才避免了一出创业悲剧的上演。我们小组经历了一个Sprint的忙碌，终于满头大汗的做出了第一个MVP，团队成员一致决定向市场发布我们的产品，不畏竞争对手可能的针对，听取市场的反馈。另外的两个小组中“家乡菜 ”小组和我们一样选择了发布，另一个“来就吃” 小组则选择了隐藏自己的产品意图暂不发布。从这里开始一出狗血创业剧正式拉开了序幕！ “微饭”的第一次产品发布很炫很过瘾，但在礼节性的掌声后，围观群众全都作鸟兽散去，等等！说好的天使客户和用户反馈呢？没有反馈就失去了MVP的意义啊，这可不行！于是我们团队紧急开会，一起讨论如何才能激发用户的反馈。最终，在试了各种诱惑招数失败后，我们“机智的”向市场推出了“天使用户配股”政策：只要给我们提供反馈并被我们认定为有价值后，就可以获得微饭1%到5%的原始股权。也就是说如果我们组获胜，天使用户就可以按照比例参与分红。这招果然有效！ 立杰和伟忠老师都来给我们提出了建议，立杰老师的建议非常劲爆，他告诉我们原来我们这个提前定餐的“好主意”早已经被大众点评实现了，但事实证明这个提前定餐的模式中国人并不受用，没有太多人喜欢提前定餐，而这个产品定位的失败也导致了大众点评最近的IPO失败，大量员工流失，境遇岌岌可危！天，我们差点犯了前人已经犯过的错误，这反馈很有价值啊！伟忠老师的反馈则相对正能量一些，他认为我们的产品特点不突出，没有清晰的产品定位，建议我们简化产品突出一两个特点。嗯，想想也确实是如此，我们好像做出了一个前人已有的产品嘛，没有特点就和没做一样嘛。为了答谢两位天使用户的干货反馈，我们决定赠与他们各3%的股权，并向大家发布了这个消息以激励更多的天使反馈。（嘿嘿，5%的最高配股奖励当然是不能轻易给出，大家都懂的，放在那里还要吸引更多的天使用户嘛~~~） 一正一反，一黑一白，两位天使的反馈拿到了，之后的关键就是我们该如何进行调整了。我们的CPO刘总双眉紧锁，抓破头皮（哈哈，这当然是我编的），然后做出了一个艰难的决策：调整产品方向，彻底放弃提前定餐服务，转向社交朋友圈约饭，然后推出餐付宝，最终以海量餐费支付作为盈利模式。这个决策的改变肯定不会是一帆风顺的，团队成员也提出反对的声音“这么大的调整我们还是在做最初定义的产品吗？”不过我们“英明”的刘CPO最终毅然决然的顶住了压力，坚定地推行了这个决定，而事后回想这其实就是整个游戏的关键转折点，让我们在后面的PK中占到了先机。我们当时选他做CPO真是选对人了。基于反馈对产品进行了调整，然后等待市场的再次检验，我们的路子完全是按照经典精益创业的剧本在走嘛，后面总该一番风顺了吧。可是狗血的剧情还在继续，在“黑暗森林”中的另外两名猎手也在瞄准着我们。。。。 接下来的第二个迭代我们这边并没有太多可说的了，就是在纸面原型上打造朋友圈约饭功能，试图通过这个功能先圈住用户。这里我来说说其他两个组的情况。“家乡菜” 团队本来的主打是“附近餐馆”，在第二轮迭代后又加入了订桌服务以及健康元素，很多好的想法，但却没有一个明确的主题定位。再说“来就吃” 团队，就是那个在第一轮中选择不发布的团队，他们是我们最大的冤家，因为他们居然和我们第一轮MVP的产品定位是一样的，都是主打“提前定餐服务”，在我们第二轮已经改变调整产品策略的时候，他们却还在一心想着怎样才能和我们在“提前定餐”这个产品细分上一决高下，处心积虑的推出了“免注册”服务试图通过提高用户留存率打败我们。在第二轮发布后，他们才知道自己扑了个空！当时，我都可以听到他们心碎了一地的声音，哈哈。这样虚虚实实的商战剧本竟被我们两个团队给真人秀了，但别急，后面还有更狗血的！ 第三个迭代中，其他两个团队大概已经感觉到了“微饭”的强劲势头，决定华华丽丽的进行高大上的“兼并重组”，试图合两家之力打败我们“微饭”。面对这个来势汹汹的杀招，我们微饭团队在评估了两位竞争对手的情况后，做出了“以一扛二”的生死决策，继续打造“餐付宝”这个最终杀手锏，以此在最终的角斗场上和对手进行决斗。反观另两个组的“华丽重组”则在后来演变成为了一场灾难，失败的公司重组成了下一个被真人秀的狗血剧本：两个产品没能有效的取长补短实现融合，重组后产品显得更加凌乱没有主题，而两个组的决策权也没有处理好，还是站在原组的立场各说各话。原本1+1>2的初衷却带来了1+1<1的结果，而作为这场“煎饼（兼并）”大戏的观众，我真正体验到躲在阴暗的角落里偷笑的感觉。。。（啊！西红柿飞来！另外两个组的同学表打我啊！） “他们在庆祝合并重组！！” 经历了三个跌宕起伏的MVP迭代后，这场最终的宿命对决在我们“微饭”和重组后的“家乡菜”之间展开了。我们组派上了CPO刘总一人去面对他们重组后的两个团队，面对对面黑压压一片、杀气腾腾、摩拳擦掌的气势，那时，我看着威风凛凛的刘总，不禁想起了“风萧萧兮。。。”不不不，绝对是“诸葛亮舌战群儒”的场景！这里卖个关子，不向大家交代我们两个产品对决的具体过程了（其实是写的太多，老婆喊去吃饭了），只能告诉大家两个产品的最终对决过程就如两位江湖大侠过招，你来我往，明争暗斗，枪林弹雨，刀光剑影，一不小心就会一败涂地，死无完肤，尸骨无存，人间蒸发。。。。等等，你这还是敏捷工作坊吗！这明明是地下黑暗铁笼擂台的节奏啊，太夸张了吧！嘿嘿，笔者认为当时的实际对决的紧张状况真的不亚于此哦！如果大家不信，想印证笔者的描述，有机会也可以来亲身参与一下Agile1001的O2O工作坊（赤裸裸的植入广告，太不敬业了。。。） 想来说到这里聪明的读者也已经猜到了故事的结尾，我们“微饭”最终赢得了游戏的胜利，席卷了另外两个组的集资（切。。。还用猜！你当大家是傻子吗！！开篇不就说了吗！）。欧也！把他们两个组的集资给朕拿来，弟兄们按照股份比例开始分赃，不对！分红！当我们拿到了他们两组的集资袋时，说实话，真是下了我们一跳，两组加起来整整960大洋，他们也真真的是蛮拼的啊！再看我们微饭组的集资，真是不要太开心了~我们组加上天使投资总共才160块！！！1：6，以小博大，完胜！我们组的队员是不是今天应该去买彩票！？ 这里停下来说说，为啥前面说我被选为CEO是很幸运的。其实是因为当时集资的时候，大家都让我这个CEO先放钱，我当时很囧的看着这帮队友们，心里飞速的想，黄喆啊，你这钱包包里的钱可都是好不容易才从老婆大人那里批下来的，平时卖体力做软件换血汗钱也不容易，你可要冷静，要冷静，想好了。。。最终我颤颤巍巍的从兜里费劲的掏出了50大洋放了进去，而我的这帮“亲密”队友思密达见我放了50进去，马上说“CEO就是豪爽！我们不能放的比CEO还多啊，Bula。。。Bula。。。”一个个比猴儿还快的都塞了10块钱进去，有一位看着最“忠厚老实”的同学可能是被我感召了，使劲咬了咬后槽牙，最后放了20。。。。而此时、此刻、此地，俺这个在三个半小时前被推到集资最前线的“CEO”，就成了全世界最幸运的宠儿！投入50，三个半小时，拿回股本，纯利284，净赚600%，干净利索！此刻我只能傲娇的说，哎呀！人生的第一桶金来的太快，伦家还没有准备好呢嘛~哈哈，当然，我的队友们，以及为我们投资并为我们提供极具战略价值反馈的天使投资人们也最终拿到了6倍的回报，大家都笑开了花儿（一群见钱眼开的家伙。。。敏捷圈子不是应该很高大上的吗？） “分赃有我！！哈哈” 好了，本来想简单写写就收笔的，一口气写了这么多，话痨毛病又犯了。最后，感谢一下立杰和伟忠两位老师为我们免费的提供了这次挣钱的机会。。。不对，是学习的机会！让我们在快乐的玩耍中学到了精益创业的很多很多。 再多说一个小细节，在最后我们拿到另外两组的集资袋看到960元的天文数字后，我们的第一反应是想把这笔巨款退还给他们，但当我们提出这个建议后，另外两组却无比爽快地拒绝了。。“有钱就是任性啊！”。当时我就想，虽然我们是赢钱的一组，但可能他们两组的同学们才是在这次工作坊中收获最多的人。和960块比起来，这些经历可能会成为他们创业路上的第一桶金。也许今天他们输了960块，但明天却会因此赚到960万，甚至也在美国上市圈他个960亿回来，所以我要赶紧代表“微饭”团队向他们献上最真挚的祝福！最重要的是，赚了钱别忘了我们啊~~~ 好了，真的就写到了这里了！不能再扯了，最后感谢敏捷之旅，感谢Agile1001，感谢立杰、伟忠、Bob、谢钊，感谢参与这次工作坊的所有同学，让我学到了这么多。祝愿Agile1001越办越好，我也会尽我的力量为Agile10001这个大家庭贡献更多的力量！ 记录者，黄喆，软件攻城狮，CSM，热爱敏捷、精益。目前工作于GE，从事软件过程改进、敏捷项目管理等工作。希望能在Agile1001这个大家庭中与大家交流、学习、共同成长。 筒子们，你们也想要开这样的工作坊吗？可以留下电话联系我们。。。 -——————————————————

话题介绍- 商业模式探索工作坊： 当我们说敏捷，我们希望把事情做对；当我们说用户体验，我们希望产品能够得到用户的喜爱；而一个产品的成功，往往还需要第三个维度，它是否能够挣到钱？商业可行性对初创企业尤其重要。对商业模式的分析正是为了解决这类问题。这是一个风靡的名词，商业模式画布，帮团队在产品诞生初期可视化设计商业模式，再根据市场变化去调整。商业模式是否仅仅只是商业模式画布？不！真实的初始化过程，饱含假设，纠结，岔路，抉择。 意启部落小伙伴们来了，让我们来一起体验一个商业模式如何诞生。 工作坊中会涵盖： - 产品网络图分析 - 画布分析 - 价值主张探索 - 画布迭代 - 商业模式假设验证 意启工作坊介绍：  如果您还在用老的方式在创业、创新，寄希望有一个“好”点子砸到你的头上，然后一举成功，那你还没有开始就已经Out了。意启致力于帮助传统行业的创业团队利用颠覆性方法和流程加速孵化。目前意启正在帮助甜甜圈和会把奶牛帮两个传统行业的初创企业加速成长。同时，意启还学到的和体验到的总结并推出系列课程。意启目前关注的颠覆性方法和流程包括：Growth Hacking、病毒性传播、傆型(Pretotyping)、增长引擎、精益创业、引导技术、设计思维(Design Thinking)等。 12月20日，我们不见不散：报名地址

敏捷实战之O2O精益创业 进入2014年，移动互联网开始不断重构我们的生活，最典型的例证莫过于O2O的全面开花，从以“美团、大众点评、京东快点”为代表的团购、点评等服务，再到以“嘀嘀打车”为代表的“我要我有模式”的打车、家政、美甲、外卖等服务，无不对传统行业开始新一轮颠覆。在这个以速度见称、以用户体验为重的时代，敏捷又该如何切入？如何调整？如何做到低成本的快速交付?如果你想挑战一下自己，请参加我们这个工坊。 这是一个纯玩体验工坊，因为我们一直主张在实战中获取经验值，所以你会跟你的新成员一起做计划、掷筛子、制作图表、做纸面原型、拜访客户、情景话剧、现场演示。。。。。玩得High与不High,请尽情发挥想象力吧！场地原因，我们只招募4个创业小组，每个小组只有8人，需要ScrumMaster、PO各1人，Scrum Team由分析、开发、测试角色各2人组成跨职能团队。其他再多的人可以充当围观呐喊者，当然也可以客串各个团队的客户(其实，从别人的成功失败中，获取经验也很重要的)。四个小组会共同面对一个O2O命题作文(暂时保密)，需要以敏捷、精益的方式展开工作，经历三个Sprint快跑。在这个PK过程中，每个团队需要在一个下午的时间内亲手做出来产品原型，供客户检验，得到现场呼声最高的团队胜出。当然，你们需要跨过我们提前设置好的各个障碍。 兴奋？紧张？担心？焦虑？没有关系，本次工坊由Agile1001富有经验的经典F4组合倾情奉献，并提供贴身指导。 -——————————————————————————- ² 关于F4团队 我们专注于各种案例故事分享，重点覆盖敏捷开发、精益创业、产品创新、组织变革等话题，每月至少一次公开课。 ² 敏捷一千零一夜Team介绍： 王立杰， 《敏捷无敌》作者 ，《敏捷开发一千零一夜》主编，多年研发管理与敏捷实施经验，专注于精益创业与产品创新、敏捷组织转型、研发效率提升。曾为百度、Nokia、VMWare、爱立信、朗讯、E人E本等多家公司做过各种敏捷培训和咨询；曾经在 “Scrum Gathering、 AgileChina、 Agiletour、51CTO、TiD”等大会做过多次演讲，荣膺2014 TiD大会10大最受欢迎讲师。 姜信宝， 喜欢新鲜事物，喜欢读书，喜欢分享，愿意和大家共同进步。 Agile1001公开课联合发起人之一。（https://agile1001.org) 我的博客：https://bobjiang.com 《Essential Scrum》译者（原作者：Kenneth S. Rubin） E-MAIL: jiangxb@gmail.com CSP,CSM,PMP 热衷和推广敏捷，是中国敏捷社区的主要推动者之一。 杜伟忠， 多年软件研发和管理经验，主要专注于精益与敏捷落地实践。曾多次在QCon、TOP100、敏捷大会上做分享。 谢 钊， 十年软件实施、项目管理、产品设计分析等方面工作经验，目前主要专注于敏捷、精益、产品规划、企业知识管理等方面的学习、实践和探索。 工作经历：服务过的公司包括海辉集团（现文思海辉）、软通动力，目前在职于京东商城。 参与并组织过的敏捷相关活动： 2013年敏捷之旅（北京）大会； 2014年的Scrum Gathering大会； 2013年度敏捷厦门群英会； 业余爱好：绘画（书法），每天在微信圈分享一副习作（凡关注者均有可能获得习作一副）。 积极、主动、乐观；学习、交流、提升、分享！ 有钱就是这么任性，报名地址：请点我

自从2010年开始，敏捷之旅北京站已经连续成功地举办了四届。2014年12月20日将迎来敏捷之旅北京站第五届，此次的主体是 与敏捷思奔，旨在将本地的同行聚集在一起，分享知识，交流经验，将有众多业内知名敏捷实践者分享多年实战经验，更有真枪实弹的敏捷代码切磋互练，欢迎敏捷爱好者踊跃参加，与我们一起探讨软件开发的敏捷思奔之旅。 活动时间：2014年12月20日 09:00-18:00（周六） 活动地点：北京市海淀区上地西路6号联想研究院 活动费用：需支付门票，组织者提供与会人员饮用水及午餐（非盈利活动，门票收入用于讲师差旅以及活动组织费用） 购票须知： 为了更好的参会效果，此次敏捷之旅北京站接受报名300人，现场支付票价100 RMB  普通票价80元RMB，早鸟票价已售罄  5人以上团体购票，请联系 姜信宝 jiangxb@gmail.com 13910939018 支付方式： 支付宝转账：13810098755（jaylian@yeah.net） 廉雨 微信红包：加 13810098755（jetlian12）廉雨 海丁网线上支付 https://t.cn/R7sh7gh 支付说明： 转账同时留下姓名、电话及邮箱 此账号是唯一通过转账报名方式 联系赞助：agiletourbeijing@gmail.com 活动奖品 ShineScrum提供的价值7000元CSM认证培训名额1个 银河快车提供的价值450元南山滑雪场全天滑雪情侣电子票3对 精美专业图书100+ *日程安排* 上午场 时间 主题 会场 9:00 9:30 签到 前台 9:30 10:30 《Scrum想说爱你不容易》 姜信宝 主会场 10:40 11:40 《产品开发的敏捷原则和方法》 周金根 主会场 11:40 13:00 午餐 下午场 时间 分会场1 （商业画布） 分会场2 （敏捷实战） 分会场3 分会场4 13:00 14:00

Agile Tour（以下称为敏捷之旅）是一个国际非盈利性组织，于2008年成立，总部位于法国。其目的是提供一个高效有趣的敏捷开发学习途径，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。它通过一系列的活动，在全球范围内推广敏捷的思想和实践，帮助企业更好的实施敏捷。 非盈利活动的背后离不开一大群“最可爱的人”，即我们每年活动的组织者们。正是有了他们牺牲自己宝贵的休息时间和与家人团聚的时间，才能使敏捷在北京传播开来。让我们来认识下2014年北京站组织者： 姓名： 张峰 部门岗位： 京东-云平台-高级经理 邮箱：zhangfeng@jd.com 主要工作经历：2005年毕业后从事冶金行业自动化工控程序设计，后在国产数据库公司人大金仓工作，2009年进入电商行业，加入B2B & B2C 综合电商千寻网，2010年加入京东，见证了京东POP平台从无到有的过程，参与过POP商品、类目、订单等多个系统的建设，并带领团队完成京东机票系统第一版的设计和上线，2011年负责京东开放服务（JOS），现负责京东服务市场，京东服务定制（众包模式）等业务 姓名： 张明 公司： 联动优势 邮箱：Thomas0927@163.com 个人简介： 认证Scrum专家（CSM）2006年毕业后在方正从事银行系统程序设计研发，而后参与过民航系统、通信系统的多个领域的设计研发工作，2011年进加入联动优势电商公司，负责第三方支付平台搭建，参与过账户核心系统改造、风控防钓鱼、预授权支付、快捷支付、付款平台等多个系统的建设，并带领团队完成基础支付平台、付款平台等系统设计研发和上线，负责电商公司基础支付组，参与支付平台系统优化改造。目前在项目中正推行敏捷，希望能和大家进一步交流学习。同时，也是另一个NGO组织（960灾难逃生救助公益组织）的参与者和发起人之一 姜信宝 （Bob Jiang） 敏捷教练，旨在帮助企业改进工作流程以取得更好的商业价值。 作为一名认证的Scrum专家（CSP，CSM），他曾在爱立信为公司提供敏捷转型的支持，为北京移动提供过敏捷辅导，现在他正在京东商城进行精益敏捷的转型。在此期间，他曾担任过ScrumMaster、团队成员和项目经理等不同角色，深谙敏捷转型的艰辛与不易。另外他还是《Scrum精髓》一书的译者。 Bob是国内敏捷社区的主要推动者，从2011年起他组织并参与了敏捷之旅、ScrumGathering China 、敏捷中国、QCon等大会。另外他还是Agile1001公开课（https://agile1001.org）的联合发起人，微信公众号是Agile1001。他的博客是https://bobjiang.com 廉雨 邮箱：bjlianyu@hotmail.com 个人介绍： 一名开发人员，敏捷爱好者，CSM。 专注于敏捷开发，敏捷个人，喜欢跑步、旅游、阅读等。 一直在传统企业为政府等做业务系统。 13年开始接触敏捷，并在团队中推广敏捷。在敏捷组织中收获很多，向更多敏捷前辈学习。 熊志男 我是一名测试老人，敏捷新人。传统的测试工程师正在被边缘化，通过学习和实践敏捷，我对于测试的理解也逐渐从“和开发对着干”发展到“无意与开发为敌”，再到今天的“打入开发内部”，真正融入团队中，抛开以往头衔和职位对于自己的限制，为团队中每个成员服务，也为自己服务。 刘芸 微信号：ly15201392806 邮箱：liuyun@phei.com.cn 电子工业出版社博文视点策划编辑，专注于IT专业技术图书的策划出版服务。IT相关技术爱好者，曾编辑出版过《京东技术解密》、《Swift语言快速入门》、《敏捷方法论》等多领域图书。 谢钊 积极、主动、乐观；学习、交流、提升、分享 十年软件实施、项目管理、产品设计分析等方面工作经验，目前主要专注于敏捷、精益、产品规划、企业知识管理等方面的学习、实践和探索。 l 工作经历：服务过的公司包括海辉集团（现文思海辉）、软通动力，目前在职于京东商城。 l 参与并组织过的敏捷相关活动： Ø 2013年敏捷之旅（北京）大会； Ø 2014年的Scrum Gathering大会； Ø 2013年度敏捷厦门群英会； l 业余爱好： Ø 绘画（书法），每天在微信圈分享一副习作。 Mail：zxie2008@gmail.com；微信：iamxiezha 姓名：喻泽高（安静的发狂者） 公司：联想研究院 邮箱：dennis.yu@live.cn 个人简介： 高级软件工程师，多年VOIP从业经验，丰富的移动互联网即时通信应用开发经验，专注移动互联网音视频通信领域，目前就职于联想北京研究院视频通信技术研究室，负责联想明星产品“友约”的后台架构设计和实现。认证Scrum专家（CSM），推崇敏捷方法和自组织团队，并在团队中推广，颇有收获，非常期待能与大家交流学习。 王一男 北京航空航天大学软件工程与管理硕士，现广联达软件股份有限公司PMO经理、公司研发管理信息化及敏捷研发管理培训讲师、公司研发管理信息化项目经理、敏捷教练 拥有丰富软件敏捷研发管理实战经验，先后在两家上市企业成功实施基于信息化工具的敏捷项目管理，并成功实现了基于信息化数据度量的敏捷团队持续过程改进。 在2014年TID（中国质量竞争力）大会上被评为最受欢迎讲师，演讲题目：《敏捷项目度量》、《Atlassian工具集在敏捷项目管理的应用实践》 姓名：Melody LIU（刘玉青）