内容来源：敏捷+社区线上直播005期，《我在哈啰的敏捷之旅》分享实录
分享者：哈啰出行陈文博
关注本公众号回复“哈啰”即可获取本次分享的视频回放、下载PPT
非常开心在空中和大家相聚，希望在接近一个小时的时间我们都能有所收获。首先感谢Bob老师和网易杭研的李岩同学，是因为他们的支持，我才能够在这里和大家分享。在开始之前，先简单自我介绍一下，我是陈文博，供职于哈啰出行PMO部门，一名成长中的敏捷教练，今天有很多敏捷社群的小伙伴来支持，谢谢大家！
【正式分享之前，先上一个彩蛋】
查看原文
言归正传，今天的分享将分为两部分：
第一部分是我在哈啰做的一些敏捷实践，包括目前我是怎么操作Scrum的，如何利用透明拉通团队共识，如何利用内驱力模型来激励团队，以及我在兼顾多个Scrum团队时如何培养内部的Scrum Master。 第二部分将给大家分享我在内部敏捷社区的一些做法，包括我是怎么发起内部敏捷社区Thor，以及社区是怎么运营的。 一、我的敏捷实践
首先给大家分享的是敏捷宣言的第一句话，”我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。” 分享这句话的原因是，我觉得敏捷实践是没有最佳实践这么一个说法，永远都是在不断地迭代，不断地找到更适合当前组织和团队上下文的一种做法，所以我在这里给大家分享的，也是基于我自己团队的上下文找到的目前最好的方法，后续还会继续迭代，以便做得更好。
查看原文获取更多材料
内容来源：敏捷+社区线上直播004期，《OKR与敏捷》分享实录
分享者：有赞效能改进工作者费解
关注本公众号回复”有赞”即可获取本次分享的视频回放、下载PPT
OKR是一个很热门的话题，我所在的公司（有赞）很早以前就开始实行OKR了。2014年老板去硅谷进行调研，带回来一种新的管理方式，一直执行到现在。本次分享也是我在OKR实践方面的一些经历和感受。
OKR与项目管理、敏捷，都是一种提升公司或组织效能的手段，OKR与敏捷之间也有着千丝万缕的联系，它俩是相通的，都有很多不确定性，不是你做了就一定能成功，还需要达成很多平衡。
管理是一门艺术，系统思考和组织设计，是两种底层能力，在敏捷实践过程中一定会涉及到。要组建一个敏捷团队，一定要有具体的角色，我们在组建团队的时候就开始做组织设计，在大规模敏捷框架里，组织设计也是一项非常重要的工作。
小调查
你在组织中处于什么角色？
你在组织中处于什么角色？比如项目经理、敏捷教练、ScrumMaster、技术负责人等。你在做决策时，是否客观？很多时候在小范围内做局部优化工作，没办法做到全局理性，为什么呢？我们发现，无论是什么角色，在做自己工作的过程中，视野会被工作范围所局限。
如何突破自身的角色和有限的视野，看到更大的范围和跃迁到更高的维度，就要回到系统思考的话题。
系统思考来源于系统动力学，是一门学科。其中有一个属性，系统有一种层层嵌套的现象，所看到的是一层，如果想要看到更大更高的那一层，就要跳出所在的范围，到更高维度的世界去。实践敏捷也是如此，需要系统思考和更高维度的视野。
我的敏捷世界观
见山就是山 | 见山不是山 | 见山还是山
我的敏捷世界观： 见山就是山。最开始接触敏捷的时候，从课程中学到很多关于敏捷的方法、工具等，比如：三三五五。那时认为敏捷就是这个样子的，要实施敏捷的话，以它提供的框架，按部就班地来执行就可以了。这个阶段学到的是敏捷的形，没有参透敏捷的本质。 见山不是山。后来经历了很多项目管理、组织优化、效能改进的工作，不经意间会根据需求和场景，将学到的敏捷知识和方法加以变通，灵活运用到实际的工作中。比如：基于整个组织的现状，运用同理心，感受需要被引导和改进的部分，然后慢慢结合敏捷去实践。随着时间的推移，我们在更多领域中加入了敏捷的元素，也做了一些创新。这个阶段是领会到敏捷的本质，逐渐融会贯通的过程。 见山还是山。经过反思沉淀后我们发现，敏捷给出的方法论适用于很多工作场景，能解决很多问题，是前人经过无数实践总结出的方法。我们也会慢慢去反思：为什么要做敏捷？敏捷的本质是什么？ 我认为敏捷的本质有三个：
优先级。我们的优先级是否明确。在一个团队或大的组织中，有没有做事的方法？优先级是什么？人在同一个时间段只能做一件事，先做哪件后做哪件？ 高质量的交付。我们做事的目的一定是为了交付，为了产生价值，高质量的交付是敏捷的一种结果。 灵活变化。我们的组织或团队是否能够灵活应对外界的变化。如果是就是敏捷的，也不用刻意强调三三五五，僵化的敏捷不是敏捷。 一次灵魂拷问
你存在于组织中的价值是什么？
前面问的是你在组织中的角色是什么。现在我们思考一下：你在组织中的价值是什么？是管理项目，还是作为一个敏捷教练带领敏捷团队？我们的出路在哪里？关注在哪个层面？
敏捷之上的世界
大千世界 | 道法术器 | 价值在外
根据系统思考的原则，需要看到更高的维度。因此除了敏捷之外，还要看到敏捷之上的世界，看清问题的本质。
佛曰：三千世界。世界之外还有世界。在实行敏捷的同时还应该有更高维度的思考和实践。
道法术器。道法是指我们学敏捷不应只是学习它的方法，还应该理解其本质；器是工具，工具是管理的辅助手段，在工具的制定方面，一定是工具适应组织，而不是组织来适应工具。在敏捷实行过程中，即便工具设置得再好，如果实际操作起来完全不匹配组织的现状，使用起来也会很别扭。术包括敏捷方法提供的框架和工具，比如前面提到的三三五五之类的。在这里值得注意的是：要站在道和法的层面，从更高的角度来审视，是否需要用到所有的这些工具，避免生搬硬套，使敏捷变得僵化。
价值在外。不要以为敏捷团队的敏捷就是端到端的了，在敏捷团队之上还有更高维度的团队，比如：部门、业务线、事业部、甚至公司。我们要从全局看整体的目标是什么、以及是否达成。敏捷团队产生的价值是什么，包括对公司的价值和商业价值。
“价值在外”这个词是管理大师彼得德鲁克提出的，即：我们所做的任何事情都是在组织外部，才会被评价和被认可的。我们所做的动作，是帮助公司完成敏捷转型，还是是为公司创造价值？在做组织设计时，我们也需要面向是否创造外部价值。
查看原文获取更多材料
English Version
敏捷词汇表 A Acceptance Criteria (AC)接收标准（验收标准） 产品负责人从业务或干系人角度定义的外部质量特征。接收标准定义期望的行为并用于判定PBI（产品待办列表条目）是否开发完成。 为了让用户、客户或其他权威机构认可，组件或系统必须满足的退出标准 Acceptance Test 接收测试 验证是否满足接收标准的测试过程。 一种测试，定义每个PBI必须交付的业务价值。接收测试可以验证功能需求或非功能需求，如性能或稳定性。这种测试用来帮助指导开发过程。 针对用户需求和业务流程的正式测试过程，执行此过程以确定系统是否满足接收标准，并且使用户、客户或其他授权的实体能够决定是否接受此系统。 Acceptance Test Driven Development (ATDD) 接收测试驱动开发 一种技术，在开发过程开始之前，参与者使用实例讨论接收标准，然后将其分解成一组具体的接收测试。与“实例化需求(Specification By Example)”同义。
Accountability 责任担当 教练信任教练对象，并通过双方从开始就共同设计的架构和方法，以不带主观臆断和责备的态度，使教练对象在思考、学习或行动的过程中对自己的发展进程和目标负责。教练以“每个人都要对自己的发展b负责”的心态来协助教练对象建立起对自己的责任担当系统。建立责任担当的问题包括：“你会怎么做？”“什么时候？”
Adaptation 适应（调整） 经验式过程（Empirical Process）的三个支柱之一；适应是一种反馈，用来对正在开发的产品或产品开发过程进行调整。另外可以参阅“经验式过程”、“检视”和“透明”。
Agile 敏捷 敏捷宣言中表示的一组特定的加个管和原则。参见敏捷宣言网站。 泛指，用于指代一组相关的增量式迭代开发方法。Scrum是一种敏捷开发方法。另请参阅“极限编程”、“看板”和Scrum。 Artifact 工件 在产品开发过程中产生的实际附属物。如产品待办列表、冲刺待办列表和潜在可交付的产品增量都是Scrum的工件。
B Boy Scout rule 童子军原则 离开营地时，总是做到比发现时更干净。如果地上脏乱，不管是谁弄脏的，都清理干净。 每次在一块代码区工作，离开时总是要把代码整理得比你动手时更干净，而不是弄得更乱。 burndown chart 燃尽图 一种曲线图，横轴是时间（如迭代内的每天），纵轴上是迭代内剩余工作量。随着时间的推移，剩余的工作量越来越少，图表上的一般趋势是工作量燃烧到0.通过计算趋势线，可以在燃尽图上显示对应的产出，从而了解工作什么时候可以完成。如下图： burnup chart 燃烧图 和燃尽图相对。一种曲线图，用来显示逼近目标的工作进度，纵轴上标有目标值。随着时间推移，工作逐渐完成，进度线条逐步上升并接近于目标线。在燃烧图上，我们可以通过计算趋势线显示对应的产出，从而了解什么时候可能完成。如下图： C cadence 节奏 规则的、可预测的节律或心跳。具有一致持续时间的冲刺，为每一次开发工作建立节奏感。
chaotic domain 混乱域 需要快速响应的一种情况。我们深陷危机，需要立即采取行动，以防止损失扩大化并至少需要重新建立一定的秩序。 Cynefin框架中域的一种。请参阅“繁杂”、“复杂”、“简单”域。 commitment 承诺 把自己和行动过程绑定在一起的行为。Scrum鼓励承诺。承诺意味着无论顺利与否，每个团队成员都专注于达成团队的共同目标。
We are looking for the translators please contact bob@bobjiang.com
中文版
Glossary Agile
中文版
Source
Glossary A
Acceptance Test Driven Development (ATDD) Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. (see more)
Acceptance Testing An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
English Version
我要提问 我要回答 加入敏捷社区，限时优惠
目录 [TOC]
问题1 如果Scrum团队中有一个团队成员不愿意认领该Sprint中的任何任务，作为ScrumMaster你会怎么办？
问题2 如果Scrum Master同时兼任团队成员，认领任务，你认为可以吗？如果可以，为什么？如果不可以，为什么？
问题3 下午2点马上要开Sprint计划会议，现在是下午1点50分。产品负责人说他没时间参加Sprint计划会，但他不介意在他缺席的情况下团队自己开Sprint计划会。作为Scrum Master你会怎么办？
问题4 你是团队的ScrumMaster，准备去会议室开会。此时团队的分析师边哭边从你身边跑过，另一位工程师也怒气冲冲的从你身边跑过，他们都跑向经理的座位。你走进会议室，明显感觉到会议室的气氛不对，剑拔弩张。平时分析师负责编写需求并传递给工程师，分析师总是修改需求，埋怨逐步积累并在这次爆发了。在这个时候，作为Scrum Master，你会怎么做？
问题5 如果一个项目需要大量的架构工作，比如需要6周时间来进行基础架构设计，那么是否可以前3个Sprint（假设一个Sprint是2周）用来做架构设计呢？如果可以，原因是什么？如果不可以，原因是什么？
问题6 Scrum Master能不能同时兼任多个团队的Scrum Master？如果可以，原因是什么。如果不可以，原因是什么。
问题7 Sprint进行到一半的时候（比如两周的Sprint，过去了一周），总监要把团队中的一名骨干成员调走到另一个重要的项目。作为Scrum Master，碰到这样的情况，你会怎么办？请列出具体的解决方案以及原因。
问题8 你听说公司内有个团队在用Scrum并且很成功，如果你也想在自己的团队尝试Scrum，你会怎么做？
问题9 每日站会上，团队成员A不关心其他人的内容（和其他人的任务没有交集），也不认为有必要关心。作为Scrum Master，你会怎么办？
问题10 连续3个Sprint团队都只完成了承诺的Product Backlog Item的一部分（即没有完成计划会上的承诺），作为Scrum Master，出现这个情况，你会怎么办？
问题11 假设这是团队的第一次Sprint评审会（Review），客户（或业务方）说他很忙，没有时间参加Review会议。作为团队的Scrum Master，这种情况下你会怎么办？
问题12 敏捷宣言中提到“可工作的软件”高于“详尽的文档”，快速响应变化，那么假设你是一个测试人员，如何在一个scrum团队中快速把握每个需求间的内在联系，更好的覆盖测试对象？
问题13 今天的题目和每日站会有关。假设你是团队的ScrumMaster，在开每日站会的过程中（比如进行到一半的时候），有一名团队成员突然离开（他已经回答完三个问题了）并回到座位上开始他的工作，如果出现这样的情况，作为ScrumMaster，你会怎么办？
问题14 在每日站会上，团队成员A说他完成了任务1，今天计划完成任务2.团队成员B说等一下我有个问题，任务1和我手上的任务3需要做联调测试，任务3我还没完成，任务1不能算完成。为什么会出现这种情况？如果出现这种情况，作为ScrumMaster，你会怎么办？
问题15 假设你是团队的ScrumMaster，你们团队马上要开始一个新项目（公司的重要项目）。整个团队都很兴奋，但是对于团队能够完成多少工作以及什么时候完成，团队搞不清楚如何给管理层一个大致的估算。此时，作为ScrumMaster，你会怎么办？
问题16 你正在参加一个大型的项目开发，产品列表（product backlog）里面大概有200多个条目（需求）。假设你是产品负责人，项目刚刚启动，你需要对着200多个条目进行排序，这个时候你会怎么办？
问题17 实行敏捷之后，工作量很透明，也拆分了任务，大家也都认领。但有一个问题：怎么能让大家认领工作更合理，有些人3天做一个任务，有些人一天做3个任务。如果光靠任务量来统计，也不公平，因为能力不同，任务难度不同。所以，问题是作为ScrumMaster，怎样能更合理的分配工作？
问题18 新来的成员不愿意在早会上吐露心声，总会觉得早会是秀的场合。如果不说出点高大上的就不好意思说，也不维护看板，也很被动。你也找他单独谈过几次，但也没有改变。作为ScrumMaster，你还会怎么办？
问题19 一个Sprint中团队提前3天完成了所有的需求，作为ScrumMaster你会怎么办？如果提前了0.5天完成了所有需求呢，你会怎么办？
赞助 有了你的赞助，Bob会继续更新本页面，以及敏捷词汇表 以太赞助：0x521aacB43d89E1b8FFD64d9eF76B0a1074dEdaF8
#Scrum的精髓 经常也会叫做敏捷精髓，最最根本就是拆分 + 优化
3个拆分： 1. 拆分时间 2. 拆分产品 3. 拆分组织
2个优化： 1. 优化流程 2. 优化价值
拆分时间 Scrum中固定时间盒（Sprint）就是原来一年的版本，拆小成1-4周的时间盒。
拆分产品 需求条目化。原来是需求一起分析、设计、编码及测试。Scrum中每个需求尽可能小，是一个一个条目。（参考大小，一个Sprint内完成4-10个条目）
拆分组织 大团队拆成小团队，且每个小团队都是端到端的跨职能团队。
优化流程 每个Sprint结束时，团队都会进行回顾会，来优化团队及组织的工作流程。因此每个组织都有自己独特的流程，流程是长出来的。
优化价值 每个Sprint，及工作中，会不断的针对Product backlog进行排序、拆分（优化工作）
行动 每日问题 针对敏捷的精髓，你的观点呢？欢迎留言讨论。 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
之前我有过一篇博客介绍，如何进行快速有效的估算。 这次介绍一下估算中的故事点，有哪些好处
敏捷估算 敏捷中常用的估算是故事点，今天就谈谈故事点。 故事点本身是没有单位的数字，那么为什么采用这个故事点，主要有2大好处：
方便预测 有效的度量团队开发速率 故事点用于预测 比如团队的速率是每个Sprint（迭代）10-15个故事点，下一版本大概有100个故事点要完成。 那么团队大概需要7-10个Sprint（迭代）来完成下一版本。
度量团队开发速率 敏捷转型之后，很大的一个痛点在于如何度量团队的改进成果。 这里有许多可以度量的维度。 其中有一个度量维度就是团队的开发速率，而故事点是团队开发速率的体现结果。
举个例子： 团队一开始的开发速率可能是10个故事点，随着时间的推移，大概3-5个Sprint后，团队的开发速率提升到12个故事点。 但是如果采用人天（或人小时）来估算的话，就没办法体现出团队的开发速率。
最后 故事点的估算，是针对PBI（产品待办列表条目） 人天（或人小时），是针对任务 不同的估算单位，用于不同的场景。 当然，任务如果拆分的足够小，也可以省略估算。
行动 每日问题 你的团队采用故事点了吗？没有采用的原因是什么？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
