QCon北京2013大会 大会时间：2013年4月25-27日 大会地点：中国·北京 国际会议中心 社交篇 这次QCon大会上，碰到很多老朋友，也认识许多新朋友。听@Shining介绍uPerform是本届QCon的赞助商，首先想到Bill Li和王宇同学。另外QClub全国协调人@柴峰同学很健谈。认识了更多thoughtworks的高人，瑶瑶，徐八叉，刘海生等等等等。 休息期间去图灵展台，认识了大名鼎鼎的谢工，以及图灵的知名编辑小花 当然还有很多InfoQ的同学们，包括Charles, Kevin, 司巧蕾, Wendy, Jesse, Floyd等 演讲篇 《胜任管理》 组织的进化——单一目标的组织（举例：不用知道事情肮脏的背后，如吃鱼香肉丝，不用知道猪是怎么养的。 组织发展面临的障碍： 等级制度 疏离感 输血文化 成功背后的幽灵 标准化培训 入职培训 团队拓展 在线学习1 结对实践 文化技能导入 定制化学习曲线 榜样的力量 学习型组织（参考第五项修炼） 建立共同愿景 团队学习1 改变心智模型 自我超越 系统思考组织的重新思考： 成员，知识工作者 任务，知识传递 度量标准，知识影响力  知识漏斗 vs 知识影响力 谜题（Mystery）vs 自我学习1 启发式探索（Heuristic）vs 自我理解 算法（Algorithm）vs 行为改变 代码（Code） vs 客户、社区影响力 读书雷达 学习验证画布 参考资料 自我介绍@QCon 有关QCon： QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。 秉承”促进软件开发领域知识与创新的传播”原则，QCon各项议题专为中高端技术人员设计，内容源于实践并面向社区。演讲嘉宾依据各重点和热点话题，分享技术趋势和最佳实践；作为主办方，InfoQ努力为参会者提供良好的学习和交流环境。

Scrum丰富的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。 这篇发表于1986年的文章产生了很大影响，文章中提出的很多概念都促成了我们今天称为Scrum的方法的形成。Scrum不是缩写，而是一个从橄榄球运动中借用的术语，在橄榄球运动中，这个术语指的是在意外犯规或是球出界后，重新开始比赛的一种方式。就算你不是橄榄球迷，可能也看到过争球，两队的前锋球跟前围成一圈，胳膊架在一起，低着头，争夺球权。 竹内弘高和野中郁次郎使用橄榄球和争球的隐喻描述产品开发： 产品开发那种“接力赛”的方式……可能和最快速、最灵活的目标有冲突。如果采用一种替代的方法，一种整体方法，或者叫做“橄榄球”方法——团队作为一个整体完成比赛，来回传球——能够更好地满足当今竞争的要求。 1993年，Jeff Sutherland和他在Easel公司的团队把1986年那篇文章中的概念与面向对象开发、基于经验的过程控制、迭代和增量开发、软件过程和生产率研究、复杂适应系统中的概念结合起来，创建了用于软件开发工作的Scrum过程。1995年，Ken Schwaber在OOPSLA 1995 （Schwaber 1995）上发表了第一篇关于Scrum的论文。此后，Schwaber和Sutherland，一起或是独自完成了几个关于Scrum的出版物，包括Agile Software Development with Scrum （Schwaber与Beedle，2001）、Agile Project Management with Scrum（Schwaber 2004）和《Scrum指南》（“The Scrum Guide”，Schwaber与Sutherland，2011）。 翻译自《Essential Scrum》，作者Kenny Rubin

我最喜欢的一句话 成功的执行一项无意义的计划 是导致失败的致命原因 如果企业费尽心思开发出来的产品没人想要， 那么是否按时、按预算完成计划就无关紧要了。 精益创业使用来自丰田生产方式的精益思想来指导创业活动，避免在创业活动中的巨大浪费。 精益创业是一个关于“开发-测量-认知”的反馈循环，不断的开发，然后进行测试测量，得到一些认知，根据学习到的知识进行下一轮的开发。 精益创业首先有一个关于“价值的假设”，然后推出一个最小可行产品（MVP）进行假设的验证。 书里提到许多例子，比较典型的有两个： 印度乡村洗衣服务 美国最大的网上鞋店Zappos 价值假设得到验证后，下一步关于增长的假设需要得到很高的关注。书内提到传统的衡量指标（虚荣指标），有比较大的欺骗性，比如总用户数，总浏览量，总点击数。如果网站今天的总浏览量为2万，那么这些浏览量来自一个用户，还是2000个新用户呢？ 关于增长假设，书中提到两个比较好的验证方法： 同期群分析 对比测试 在各种验证假设后，得到的报告、报表中，衡量指标要符合三个“可”的标准 可执行：指标简单易懂 可使用：指标具有指导意义 可审查：数据来源可信 如果假设验证失败，那么面临一个选择，是继续坚持当前的假设，还是做出转型。如果要转型，都有哪些转型，下面是书中提到的一些转型方法： 放大转型 缩小转型 客户细分市场转型 客户需求转型 - 200多家连锁的大肚三明治（Potbelly Sandwich Shop） 1997年开办时是一家古董店。为了吸引更多顾客到店里，店主开始售卖三明治。 平台转型 商业架构转型 - 摩尔理论。公司一般会在两种主要商业架构选其一：高利润低产量；或低利润高产量。前者经常和B2B或者企业销售流程相关；后者与消费类产品相关 价值获取转型 增长引擎转型 - 病毒式、黏着式、付费式 渠道转型 技术转型 在当今的市场环境下，如果你跑的比市场慢，那么很快就会被淘汰。 所以除了验证价值假设和增长假设，还有一个很重要的关键点就是加速创业公司的发展。 公司发展大致分为三类增长引擎（模式）： 黏着式 - 客户一旦用了产品后，很难换成竞争对手的 病毒式 - 依赖现有用户的口碑宣传，影响其他人加入 付费式 - 依赖付费的方式增加新客户，比如广告 最后再介绍两个精益中比较好的理念： 小批量 五个为什么

10月29日晚，很高兴参加了“AgileChina Salon - 持续交付” （https://event.weibo.com/636715） 这次活动邀请到了《持续交付》一书的作者， Jez Humble。 能够近距离的和大牛交流，很兴奋啊。 引子 flickr.com 每天可以发布10次以上。试想我们的软件多久可以发布。 持续交付需要频繁发布（releasing frequently） 但是频繁发布，包含哪些内容： 1. 构建正确的内容 - build the right thing 2. 降低发布风险 - reduce risk of release 3. 真正的项目进度 - real project progress 在累积流图中（CFD）， 我们通过降低batch size（WIP），达到降低lead time的目的。 但是batch size多大合适， Jez建议： 3-4天的工作量。 部署流水线，是持续交付的核心内容。 Dark launching是什么？ 发布不等于部署。 通过特性开关（feature toggle），可以讲部署好的内容进行发布，或者关闭。 很好的持续交付的资源：持续交付网站

敏捷之旅2012北京站总结 12月1日是忙碌的一天，也是充实的一天。这一天敏捷之旅2012北京站落下了帷幕。自从9月9日开始，在接近三个月的紧锣密鼓的筹备后，我们（组织者）有了一个完满的结果。 关于组织非盈利活动的一些个人感受： 第一要素：钱。古语，兵马未动粮草先行就是这个道理。对于非盈利活动，寻找赞助商就是这个第一要素。 设置共同的目标（vision）。这个是至关重要的，否则只是一群人在做事，而不是一个团队。（group vs team）举个例子：我们的共同目标是在12月1日办一个200人规模的敏捷之旅社区活动。 建立核心团队。 明确责任和权利。发挥团队的自组织和个人积极主动性。 尽早确定演讲嘉宾（哪怕没有确定话题，尤其是有影响力的嘉宾，可以为活动带来人气）。 宣传要在有了吸引听众内容的基础上，否则就错过了宣传的最佳效果。这一点基于上一条，需要尽早确定演讲嘉宾。 本次敏捷之旅北京站的活动要感谢 主要赞助商：OutSofting 场地赞助商：清华大学出版社 媒体支持：海丁网和InfoQ中文网 敏捷之旅北京的后续报道 报道1 - 来自mebusw的CSDN blog

敏捷之旅北京的话题如下： Keynote： 段念 《生长出来的敏捷》 乔梁《小心ScrumBUT——如何让敏捷落地生根》 敏捷转型：（天） 钱安川《如何用2天交付一个项目看板工具》 杨烽熵《敏捷变革的企业战略与实施》 敏捷管理：（人） 伍斌《自动自发的敏捷团队》 唱鑫《年轻的心-敏捷实践校园行》 敏捷实践：（地） 霍金健《与CI共舞》 话题的详细细节，请猛击这里。 敏捷之旅2012北京的活动已经过去10多天了，但是一些做的好的地方一直留在我的脑袋里，现在整理一下： 提前一天的签到彩排，排除了很多异常情况（比如团队报名的如何签到；如果找不到打印的名字怎么办等应急方案） 中午发盒饭，流水线作业，参会者自动自发的排队，效率很高。 现场的路线导向，参会者很方便的找到不同的分会场。 关于作者 姜信宝 请点击这里

游戏简介： 这个游戏将要求所有参与者站立完成。大家围成一个大圈，在一个共同的标准和规则下，在既定的时间里，完成抛球的动作，达成一定的目标。然后通过每个迭代的改进，提升团队协作的效率。 我们在以往的实践中，做过几十场不同规模的团队抛球游戏。本场，我们也将向最大规模发起挑战。团队成员将能收获，较大团队的协作和持续改进，是如何完成的。 抛球游戏，是一种越来越多地被Scrum培训师采用的敏捷游戏。通过这个游戏，你可以收获： 通过迭代逐步提高工作效率 领导力是如何产生的 团队是如何学习-检视-适应 回顾的力量（reflection） 工作流（或节奏） 下面介绍游戏规则： 所有人是一个团队（大的团队） 传递的球必须有滞空时间（滞留在空气中，不能手递手） 球不能传给左右相邻的人 开始传送点=结束传送点（球从哪儿开始传递，还要回到这里才能得分） 每个迭代时间2分钟 迭代之间有1分钟的时间，大家可以讨论如何提高效率 我们一共做N个迭代（N=5） 第一次迭代之前有2分钟的准备时间 每次迭代之前，团队做一次估算 最后做总结 几个小提示： 流程- 经常团队会问“这样可以吗”？ 需要指向规则，并明确这是“团队的流程” 便签 - 如果团队有明显效率提升时，要求团队写下感受以及原因。这样可以帮助游戏最后的总结。 计时 - 注意timebox 如果团队稳定后，在最后一轮设置一个更有挑战并不可实现的目标。 反思的角度： 发生了什么？ 哪个迭代感觉最好，为什么？ 哪个迭代效率提高最大，为什么？ 反思的力量 设置不可能的目标之后，发生了什么，为什么？ 领导是如何产生的？ 有没有好的建议，但是没有被采纳？ 为什么？ 回到工作中，哪些内容可以带回去？ 参考链接：QCon Beijing 2013 敏捷嘉年华

游戏简介： 这个游戏将要求所有参与者站立完成。大家围成一个大圈，在一个共同的标准和规则下，在既定的时间里，完成抛球的动作，达成一定的目标。然后通过每个迭代的改进，提升团队协作的效率。 我们在以往的实践中，做过几十场不同规模的团队抛球游戏。本场，我们也将向最大规模发起挑战。团队成员将能收获，较大团队的协作和持续改进，是如何完成的。 抛球游戏，是一种越来越多地被Scrum培训师采用的敏捷游戏。通过这个游戏，你可以收获： 通过迭代逐步提高工作效率 领导力是如何产生的 团队是如何学习-检视-适应 回顾的力量（reflection） 工作流（或节奏） 下面介绍游戏规则： 所有人是一个团队（大的团队） 传递的球必须有滞空时间（滞留在空气中，不能手递手） 球不能传给左右相邻的人 开始传送点=结束传送点（球从哪儿开始传递，还要回到这里才能得分） 每个迭代时间2分钟 迭代之间有1分钟的时间，大家可以讨论如何提高效率 我们一共做N个迭代（N=5） 第一次迭代之前有2分钟的准备时间 每次迭代之前，团队做一次估算 最后做总结 几个小提示： 流程- 经常团队会问“这样可以吗”？ 需要指向规则，并明确这是“团队的流程” 便签 - 如果团队有明显效率提升时，要求团队写下感受以及原因。这样可以帮助游戏最后的总结。 计时 - 注意timebox 如果团队稳定后，在最后一轮设置一个更有挑战并不可实现的目标。 反思的角度： 发生了什么？ 哪个迭代感觉最好，为什么？ 哪个迭代效率提高最大，为什么？ 反思的力量 设置不可能的目标之后，发生了什么，为什么？ 领导是如何产生的？ 有没有好的建议，但是没有被采纳？ 为什么？ 回到工作中，哪些内容可以带回去？ 参考链接：QCon Beijing 2013 敏捷嘉年华

PMBOK基本过程组和它们对应的敏捷概念 启动过程 vs 章程（charting） PMBOK启动过程：评估项目价值（固定预算），定义初步范围（固定范围），分配资源（固定资源），以及确定时间线（固定时间）。 敏捷章程：确立愿景（共同的理解），确定目标（共享的目标），组建团队（没有承诺），以及确定时间线（固定时间）。每次迭代（里程碑）的开始重新审视愿景。 规划过程vs持续计划 PMBOK规划过程：所有计划活动（项目计划、HR、风险管理等）在项目开始已经完成。 敏捷持续计划：当有更多的信息与业务优先级改变时，计划活动发生在项目之前和贯穿始终。 执行过程vs持续交付 PMBOK执行过程：计划最终定下来后工作才开始（当前过程），利益相关者是满意的（至少这个时候）以及取得资源。 - 敏捷持续交付：贯穿项目始终计划和交付在1-4周的迭代中进行。 监控过程vs适应变化 PMBOK监控过程：为了交付固定范围的内容要严密监控时间和成本。 敏捷适应变化：时间和成本是固定的，范围基于变化的业务需求是可变的。 收尾过程vs收尾 PMBOK收尾过程：项目结束的时候得到客户与利益相关者验收的正式过程。 敏捷收尾：非正式的过程因为贯穿项目始终客户与利益相关者已经提供反馈。收尾阶段一个重要的活动是回顾。这是实现持续改进的一个关键点。 PMBOK知识领域和它们对应的敏捷概念 整合管理变成迭代计划、跟踪与管理。 范围、时间、成本管理变成固定时间与成本、可变范围。 质量管理变成持续集成、测试驱动开发、持续改进。 人力资源管理变成更关注于团队而不是个人，奖励团队的成功而不是个人的成功。 风险管理变成以迭代为基础的（比如所有计划与审查会议）整个团队参与识别、监视与分析风险的频繁反馈。 沟通管理变成经常的面对面沟通、每日站会、迭代计划与审查会议。 转载请注明来源 原文来自VersionOne

什么是CSM（Certified Scrum Master） CSM，即Certified ScrumMaster，是Scrum联盟发起的Scrum认证。CSM可以帮助团队正确使用Scrum，从而提高项目整体成功的可能性。CSMs深刻理解Scrum的价值观、实践以及Scrum框架。CSM是“服务型领导”，帮助Scrum团队一起紧密合作。CSM也会保护团队免受内部和外部的分心。 CSM的收益 通过获得ScrumMaster证书（CSM），您将获得： 扩展您的职业机会，尤其是在敏捷领域 展示您对Scrum知识理解的深度 学习Scrum基础，以及和最棒的Scrum专家交流ScrumMaster角色的知识 参与Scrum专家的社区 作为CSM，您有能力担任ScrumMaster。通过CSM认证过程，您可以深度理解Scrum框架，包括Scrum角色、活动和工件。 CSM认证通过后，您还将获得2年的Scrum联盟会员资格。会员可以加入当地的用户组、在线的社交网络、参加Scrum Gathering的深度折扣，以及更多的会员资料。 如何获得CSM认证（Certified Scrum Master） 为了获得CSM证书，您需要参加Scrum联盟授权培训师（即CST，作者Bob就可以发证）的线下面对面课程。 课程后参加在线的CSM考试（考试链接发到注册邮箱）。60分钟内完成50道题，答对37道即通过。（单选题） 通过考试后，需要接受CSM证书许可并完善你的Scrum联盟会员资料。 CSM认证的第一步是开始了解Scrum。Scrum联盟也准备了一系列材料，您可以进一步学习。 接着参加2天的线下课程。 在成功完成课程后，紧接着是参加在线考试，考试通过后就可以获得CSM证书。 原文链接 了解BoB Jiang