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 许可协议。
转载请注明出处！
东方与西方的文化差异有哪些 昨天在过马路（人行横道）的时候，被一辆汽车吓着了，这让我想起在新加坡、美国等地遇到的汽车会主动避让人行横道的行人。 从而激发我想试着找一下东方与西方文化有哪些显示的差异。
过马路时人让车，还是车让人 系统论与还原论 喝热水还是冷水 喝茶还是喝咖啡 靠左走还是靠右走 如果两种文化同时存在，会发生什么情况呢？ 过马路时，人车都麻烦了，不知道谁该让谁。 看问题的时候，是应该看整体还是分开看。 热水还是冷水。
那么在文化发生差异的时候，你会怎么选择？ 如果站在对方的视角，尝试理解对方的感受，你会得出什么结果？
最后分享一个有意思的事情。 有一次我和一个澳洲朋友一起去参加一个大会， 他选择热水 我选择冰水 他选择茶 我选择咖啡
哈哈……
行动 每日问题 东西方文化差异还有哪些？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
敏捷与架构的关系 微信群里有伙伴在讨论： > 在敏捷开发中，如何进行架构设计？
最好的答案是来自于“敏捷软件开发宣言”对应的“敏捷原则”：
最好的架构、需求和设计出自自组织团队。
那对于敏捷开发的团队要不要进行架构设计？ 什么时候进行架构设计？ 如何进行架构设计？
敏捷开发的团队肯定也是需要架构设计的。 软件开发，不管用什么方式，都离不开架构设计。 对于软件架构的定义如下：
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
什么时候进行架构设计 在敏捷开发的过程中，架构设计是渐进的、持续进行的。
如何进行架构设计 架构设计是团队做出的，恰好满足当前业务需求的。 举个例子，如果是一款手机app，刚刚做出来的时候，不需要过多考虑并发（如1000个并发）；而是满足业务流程即可。
在敏捷开发的过程中，关键的点在于透明性及适应和调整。 不管采用什么架构，都需要是团队做出的决定。 团队都知道选择这个架构的原因是什么， 以及有什么缺陷 后续什么时候需要对这个架构进行改造 等等
行动 每日问题 在敏捷开发过程中，你们的软件架构是如何进行的？ 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
ScrumMaster的十大错误 敏捷进入中国有18年了，现在各个行业都在说敏捷，每个ScrumMaster都在说scrum。本身这是个好事，可是出现了很多“敏捷大仙”。用各种预定义的流程、工具、文档替代了敏捷，这已经背离了敏捷的精髓，敏捷的本质。
注明：BoB在工作中也碰到了很多敏捷的误区，与作者深有同感。
1. 因为敏捷而敏捷 其实大家并不关心敏捷，而是关心敏捷背后的那个“快”。（我有一篇文章专门描述，敏捷不是快）。除去“快”，敏捷更应该关注目标及个人成长。
ScrumMaster的口头挂着“敏捷、Scrum、看板”，经常会说敏捷要求我们做这个，敏捷要求我们做那个，blah,blah…… 这个不是答案，敏捷也不仅是项目管理工具或流程。敏捷更多是一种心态的改变。
敏捷应该帮助企业和个人实现目标（即价值）。
团队成员不想开每日站会，讨厌计划会，回顾会。为什么？因为团队认为敏捷是另一套流程，我已经996了，还要加这么多会议，不如去写代码。
在敏捷转型的过程中，“拒谈敏捷”，认真思考如下问题：
你的目标是什么？ 为了达到目标，你需要什么？ 达到目标的阻力是什么？ 你怎么知道达到目标了？ 敏捷里面有非常多的实践了，比如Scrum的5个会议，看板，用户故事，等等。但是用每个实践之前，尝试回答上面的问题，并且和团队一起来回答。
2. 管理心态 ScrumMaster不用管人，而是帮助改进系统，提升公司和个人价值以及移除障碍。ScrumMaster并不是角色，也不是头衔。 作为ScrumMaster，是与团队在一起帮助团队完成工作。提供团队的需要，解决团队的问题。
良好的ScrumMaster观察团队工作，使之透明并识别改进机会。
3. 推敏捷 不要向团队推敏捷，推工程实践。而是让团队主动用敏捷方法。 参考我之前的文章，推还是拉敏捷
让团队决定他们要如何解决问题。团队需要时间成长。
4. 4W1H（Who, What, When, WHere, How） ScrumMaster主动的什么也不做。表面上什么也不做。产品开发是客户、产品负责人及团队的工作。作为ScrumMaster是帮助团队成长，改进系统。
下面这些对于ScrumMaster很常见： - 分配任务 - 编写用户故事 - 提前规划迭代列表 - 估算 - 更新任务板 - 认为对所有问题负责 - 选择配置scrum工具 - 决定什么是团队的障碍 - 计算团队成员的能力（容量）
认真思考一下，作为ScrumMaster你有没有做过类似的事情。如果做过，请认真反思。
5. 定义团队协议及DoD ScrumMaster和团队一起共同制定团队协议、DoD，而不是代替团队，一个人制定好。询问团队他们想要什么样子的协议，DoD。 这是团队的事情，作为ScrumMaster，是帮助团队制定协议和DoD。 让团队理解协议和DoD的好处，并制定出来。
6. 定义需求或任务 ScrumMaster是帮助产品负责人和团队的，但产品负责人和团队要做他们自己的工作。
产品负责人不准备产品路线图，不提前准备需求，不去和干系人或真实客户探讨，不梳理产品列表。 作为ScrumMaster，需要帮助产品负责人认识到这些问题，并提供相应的工具，辅助产品负责人。
7. 定义优先级及计划 不要成为产品负责人的代理，永远不要。 产品列表的优先级（顺序）是产品负责人的职责，ScrumMaster可以帮助产品负责人认识到： - 如何排序 - 排序的参考因素 - 什么时间排序 - 什么时间准备好产品列表
最近推荐了一系列敏捷书单，总结如下：
Scrum好书 工程实践书单 敏捷教练书单 产品经理书单 引导书单 行动 如果你有其他好书，或者书单要推荐，欢迎联系BoB。
每日问题 你在读什么书呢？ 与BoB面对面 报名BoB的敏捷认证课程 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
转载请注明出处！
