Think BIG, act small First heard this sentence ‘think big, but act small’, I am totally inspired. Why? I am a trainer, and have many friends like me as trainers or consultants. Often I have some ‘great’ ideas, but I didn’t move forward, so I would miss some opportunities as well. Then if I have any idea, and would like to make it real, and I have to do something, aka.

交付还是交代 了解过Scrum的同学，或拿到 Certified Scrum Master (CSM) 认证的同学，应该都知道Scrum是一个框架，3-3-5-5，分别是： 3个角色 3个工件 5个事件 5个价值观 然而这里面有很多重点，或可能被人忽略的地方。 今天要反思的一个点是我最近1年的感悟，即交付。 什么是交付 交付不仅仅是交出答案，而更应该是有“响”，即付出有对应的回报（最直观的回报，可以用金钱衡量，或可以和金钱挂钩的度量）。 举个简单的例子：比如我们要开发软件中的一个特性（feature）。 如果只是完成了开发和对应的测试工作，（或甚至有的只完成了需求分析或设计文档工作）那么这个时候的特性，无法使用，也不能为团队带来直观的回报。 可能团队会很辛苦，996，天天加班。但作为没有办法度量结果的团队，只能说他们有了交代，而不是交付。 什么是真正的交付呢？ 交付指的是，特性真正完成，可以交付给客户使用。由此，客户（以及用户）的问题得到真正的解决，并且变得很高兴。然后团队也变得很兴奋。（当然，客户变得高兴之后，从长远看，收入也会变得顺畅）。 我们要选择交付还是交代 答案毋庸置疑，但往往我们会局限于自己的视角，以为我们选择的是交付，而实际是交代。 我们可以尝试通过如下的问题，来检验是否是交付： 这个工作对于客户的价值是什么？ 这个工作是否解决了客户的某个问题？ 这个工作是否节省了客户的时间或金钱？ 这个工作是否帮客户带来了更多的用户？ 还有更多的问题吗？欢迎一起来探讨 赶快扔下那些交代，一起来专注于交付吧！ 想要学习 CSM敏捷认证，一起来报名吧！ 关于Bob Jiang BoB Jiang HiBlock区块链社区（hiblock.net）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者

Retrospectives 回顾 本文描述的回顾（retrospectives），是 Scrum Guides 中描述的事件之一，即周期性的反思工作流程与方法。 Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。 … … Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过 程的责任者以及团队的一员参加该会议。 Sprint 回顾会议的目的在于: 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何; 找出并加以排序做得好的和潜在需要改进的主要方面;同时, 制定改进 Scrum 团队工作方式的计划。 Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。 在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完成DoD”的定义的方式来计划􏰀高产品质量。 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。 在下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进可以在任何时间执行，Sprint 回顾会议􏰀供了一个专注于检视和适应的 正式机会。 – 摘自于《Scrum指南》 Think BIG, Act small 从今天（2018年11月20日）起，每天写一段文字。 无论是敏捷、Scrum、社区、区块链、或任何有感而发的内容，要做一个每日的记录。

Scrum 官方权威指南 收听有声版 | 官网下载PDF 由Scrum创始人 Ken Schwaber 和 Jeff Sutherland 开发并维护 版本：2017中文版 Scrum 指南的目的 Scrum 是用于开发、交付和持续支持复杂产品的一个框架。本 Scrum 指南 包含了 Scrum 的定义，其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则。Ken Schwaber 和 Jeff Sutherland 创造了 Scrum，Scrum 指南也由他们撰写并提供。总之，他们是 Scrum 指南的后盾。 Scrum 的定义 Scrum（名词）： Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 是： 轻量级的 易于理解的 难以精通的 Scrum 是一个框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的工作上。Scrum 并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于 Scrum 的成功与使用是至关重要的。 Scrum 的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。对于 Scrum 的规则描述将会贯穿全文。 使用 Scrum 框架的其它不同特定技巧将不在本文中描述。 Scrum 的应用 Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始，Scrum 在全球范围内已得到了广泛应用：

摘要： 本文主要描述Scrum中完成的定义（Definition of Done，DoD）以及验收标准（Acceptance Criteria，AC）的用法。 “坑”的描述 完成的定义，即DoD不清晰，不仅仅是概念本身可能存在误解，常常由深层次的原因引起的。 完成的定义 与 验收标准 实际可能的例子 每日站会上，团队成员A：“昨天我完成了条目1！今天我将开始工作于条目2上。” 两天后，产品负责人找到团队，“条目1怎么回事，这个流程和我想要的并不一样……” 上面这个场景，每天都在不同的团队上演着。为什么会发生这样一幕？有可能他们缺少完成的定义与验收标准 完成的定义（摘录自Scrum指南） “完成”的定义 当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解；以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。 这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。 如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。 每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。 随着团队的成熟，“完成”的定义会扩展，包含更为严格的标准来保证更高的质量。当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。 在Scrum指南中我们可以看出： 整个产品有统一的完成的定义 完成的定义是Scrum团队制定的，并共同理解的 每个团队可以定制自己的完成的定义 完成的定义可以扩展（当团队成熟之后） 完成的定义一个例子（有下划线的内容为当前产品的完成的定义，随着团队成熟，其他未有下划线的部分，可以逐步加入到完成的定义中）： 验收标准 验收标准（AC）是针对单个条目（如用户故事）而言的，如何验收（或确保）单个条目是满足客户要求的。验收标准具有如下的作用： - 定义用户故事或特性的边界 - 帮助厘清客户要求 - 团队与客户（以及产品负责人）达成共同理解 - 根据验收标准可以有效的产生测试用例 验收标准的一个例子： 用户故事： 作为一个互联网银行用户， 我想要看到每日交易明细， 以便我很清楚每笔交易之后自己的账务情况。 验收标准的例子如下： - 默认显示最近一周的每笔交易明细 - 显示当前账户余额 - 显示指定日期时间段的交易明细 ###完成的定义与验收标准

引言 敏捷火热，随之出现很多敏捷热词，比如敏捷组织、敏捷营销、敏捷管理、敏捷blah blah。在这么多敏捷词汇背后，映射出敏捷已经受到越来越多的行业与人群的关注。然而就在我们日常工作的组织中，有很多与敏捷相悖的陷阱（或常识）。这里和大家分享如下几个： 跨地域团队 狂热的敏捷 外包客户服务 大规模敏捷的困扰 SAFe or safe 跨地域团队 软件开发工作，没什么比得上大家坐在一起更高效了。 “通讯基本靠吼，交通基本靠走”，虽然这只是一句顺口溜，然而放在软件开发工作中是非常贴切的。 我想要寻求某个问题的答案时，只要站起来走到同事身边，吼一下就可以了。 现代移动互联网时代，越来越多的工具尝试代替人与人之间的沟通，比如Skype, Slack, Trello, Teambition, Leangoo,等等。发个消息过去之后，就如石沉大海没有了回应。这是一种什么心情呀。 因此，对于软件开发工作不要跨地域团队。（注：这里的地域可以大到国家，小到楼层） 狂热的敏捷 组织敏捷转型催生了对于敏捷培训师、引导者以及咨询师的大量需求。很自然地出现了求大于供。这种情况下就会出现一些浑水摸鱼的人，来满足企业和组织的需求。如果雇佣了一名知识与经验不足的敏捷咨询师，组织很快就会对于敏捷失望透顶，失去兴趣。那么以后再想重整旗鼓就很难了。 因此选择靠谱的敏捷培训师、咨询师是很重要的第一步。 外包客户服务 如果你和客户之间没有直接的链接，那么你将失去创新的机会。你也就不会得知客户真正想要什么。很不幸的是，很多组织在缩减成本，往往会把与客户直接对话的客服部门进行外包。 停止外包你的客户服务工作吧！ 大规模敏捷的困扰 我不相信有一个完美的框架，可以帮助组织很好的实现大规模敏捷。以前没有，以后也不会有。盲目地相信有这种解决方案的人，是懒惰的，是想逃避责任的。 在选择或实施大规模敏捷之前，需要问以下问题： 为什么要采用大规模敏捷 想要解决的组织问题是什么 SAFe还是safe SAFe是一种以价值流为核心的大规模敏捷方法。组织因此可能变得更高效或以客户为中心。但很多企业选择SAFe的时候并不理解敏捷宣言，不理解敏捷的价值观。寄希望于一套完整的框架方法可以帮助组织进行整体一次性的转型。SAFe方法提供了一套完美的完整的框架（包含原则、方法、实践），给高层领导者一种很安全（safe）的感觉。然后组织根据自己的情况进行裁剪与适应。 在转型的初期，这是奏效的。然而随着时间的推移，转型的深入，这种方法很可能无法完全适应组织的需求。因为SAFe并不提及组织结构的改变。 而企业或组织的核心是盈利，是需要完成产品开发。另外一种大规模敏捷方法LeSS，是以产品为核心，特性团队（组织结构的变化）为基础，以系统思考、精益思想等为原则的框架。 想要大规模敏捷，除了问下上述的两个问题，更多要全局思考。 有关LeSS更新信息请参考

什么是CSM课程 CSM的课程及证书已经赋予你16个SEU的学分，可以用于后续申请CSP认证。鼓励大家通过申请成为CSP来继续提升你的Scrum经验及技能。 对于PMP，你可以参考下面的指引去申请获得PMI的16个PDU学分。我们本人都没有PMI网站访问的权限， 下面信息不一定最更新，但我相信可以作为参考开始你的学分申请。（听说PMI在12月全面更新了PDU申请的方法，若你能跑通新的流程，请分享细节给我参 考。应该有一个课程内容PDU比例的分配，我建议：Technical 12 / Leadership 2 / Strategy 2） 登入成功后，在首页导航栏选择myPMI 进入myPMI页面后，在页面右侧，会有一块蓝色区域“Report PDUs” 进入“Report PDUs”页面后，选择“Course or Training” 在“Course or Training”完成对应信息，例如provider、activity、description等相关信息（相关信息请看下面培训师信息，若有不全的，请告知我，我要持续完善） 在“PDU Claimed”的三大领域分布16PDU，可以按照12、2、2分布（我的建议） 勾选I agree this claim is accurate，点击Submit即可 完成以上操作，可在Dashboard和Claim History查看~ 关于培训Provider的具体信息，在你填写PDU申请时，你可以使用如下信息： Provider: Bob Jiang, CST （请留意，你并不需要在PMI供应商列表里匹配到我们的这个信息） Activity: Certified Scrum Master (CSM) Summary: A 2 fully days training covering fundamental Agile project management and Agile delivery mindsets, principles, process, ceremonies, roles, artifacts and related techniques based on Scrum framework.

宝宝说敏捷简书专栏开通，欢迎大家关注。 宝宝说已注册域名，现招募一名网站设计的小伙伴，一起搭建宝宝说网站。 对于宝宝说敏捷如果您有任何想法或建议，欢迎我和联系。 内容大纲 新闻 社区 荐书 课程 新闻 3月我陆续写了9篇文章，具体可以参考我的简书专栏。 主题包含敏捷与成长，如Agile的起源、Scrum和看板的区别、如何快速学习新知识、理想与现实等 社区 Agile1001四月份活动预告 - 4月16日 DevOps实战 荐书 《在Toyota学到的只要纸1张的整理技术》- 本书的核心内容是思路整理，工具是用的一张纸。简短易用的一本书。具体可以参考链接。 课程 - Certified Scrum Master (CSM) 敏捷认证课程 2017年4月16日17日 上海 https://yihuode.io/activities/444 2017年4月24日25日 深圳 https://yihuode.io/activities/436 2017年5月25日26日 北京 https://yihuode.io/activities/419 关于我 姜信宝 （Bob Jiang） 中国北方第一位CST（Certified Scrum Trainer） 资深敏捷教练、创新教练 旨在帮助企业改进工作方法以取得更好的商业价值 Certified LeSS Practitioner，《Scrum精髓》的译者 Agile1001 (敏捷一千零一夜)联合创始人 我的博客 https://www.bobjiang.com 邮件： bob@bobjiang.com 微信： bob_jiang_xinbao 电话： 13910939018