kanban

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

由Agile42公司开发的看板披萨游戏遵循以下许可：Creative Commons Attribution-Share Alike 3.0 License. 仅仅通过教科书的方式传授精益敏捷的原则，是很困难的。人们必须亲身经历这些原则以体会它们是如何工作的。通过游戏，不必打乱日程工作或沉迷在技术细节，你就可以获得经验。这也是我们在培训中使用游戏和模拟的原因。如果没有合适的游戏，我们就创造一个，比如看板披萨游戏！ 通过agile42公司的这个游戏，你可以发现看板是什么。然而其他看板游戏通常关注白板概念和已有看板系统中的工作流，我们的看板披萨游戏教会大家如何从现有流程产生看板系统。 用纸做披萨 如agile42 Scrum Lego City Game，我们希望看板游戏用每个人都熟悉的东西并且每个人都能做。我们尝试远离IT环境，因此参与者不用考虑太多和他们现有工作环境的相似处。我们认为用纸做披萨这个想法太棒了——每个人都喜欢披萨，并且每人都知道披萨是怎么做的。（至少知道一般术语） 什么时候以及如何使用看板披萨游戏 如果你想要理解看板是什么，以及在日常工作之外的安全环境里实践一些精益概念，那么看板披萨游戏是最合适的！ 学习目标 从培训的角度这个游戏的目的是什么？我们希望参与者： 体验看板系统如何从已有的流程中浮现出来（如工作当中那样） 体验一个完整的看板系统（而不是只关注白板和相关概念） 理解白板是依赖于场景的：对于任何流程，都有许多不同设计的看板，这些都是适当和实用的，而不必只有一个最优的看板。 理解限制在制品（Work In Progress）的影响。 体验自组织和适应性。 充满乐趣! 每个团队都有不同颜色的纸、剪刀和其他材料（参见本页底部的完整物料清单）。团队根据配方裁剪、涂抹和粘贴这些材料以形成披萨。准备 这个游戏从开始到结束有一套PPT可以使用。（译者注：后续提供不需翻墙的链接） 确保充足的物料！ 每组至少4个人 可以一个组玩，但多组的话会增加有益的竞争，也会更有趣 (可选) 如果人数为奇数，可以考虑邀请他做观察员，担当质量监控并衡量交货时间。 游戏流程 1. 第一轮，创建一个隐含的流程 看板总是从你当前现有的流程开始的。在游戏的开始，让团队拿一些纸片并制作尽可能多的披萨（夏威夷）。如下图 展示一块做好的夏威夷披萨并解释怎么做的：一块披萨饼底（三角形纸），番茄酱（红色马克笔），3块火腿（粉色便利贴）和3块菠萝（黄色便利贴）。番茄酱要涂满饼底（译者注：记得披萨饼有卷边哦），馅料大小合适并均匀分布在披萨上。 演示烤箱盘并演示怎么用。烤箱一次最多烤3块披萨。烤的时间最少30秒。在烤的过程中不能动烤箱（增加或拿走披萨）！ 下面要求团队制作尽可能多的披萨，但要避免浪费，如准备好而不用的原材料。当你决定结束的时候（大概5-7分钟后，不事先确定时间），告诉大家停下来。 2. 介绍看板 在第一轮结束后，介绍看板和核心看板实践。 核心看板实践： 使工作流可视化 限制你的在制品数量（WIP） 管理流动（Flow） 实现反馈环 明确流程原则 一起改进 接下来，介绍计分系统并让团队自己算分。设计计分系统是为了提倡限制WIP，并且可以间接地流动（在这个游戏中，流动和交货时间是有关联的，只要人们不知道一轮的准确时长，他们就会重复相同的行为）。收集分数并记录到白板或者挂图上。 让团队把工作流可视化并且通过引入生产材料库存（披萨饼底，火腿块等）来使流程更明确。现在不要尝试优化工作流，仅仅把第一轮出现的内容记录下来。 让团队限制他们的在制品（WIP）。第一轮结束后团队有一堆的材料浪费了吗？每个步骤合理的WIP大小是多少？ 披萨的质量如何？有没有偷工减料？披萨饼底应该是一样大并且涂满番茄酱，馅料剪得很精美且分布均匀。 下轮开始之前，扔掉已经交付的披萨，但保留没有用过的材料，包括桌子上没烤过的披萨。 3. 第二轮，使用刚才建立的看板系统 现在用刚刚建好的看板系统开始下一轮。再次强调，快要结束的时候不要给出任何提示，当你觉得差不多的时候（5-7分钟后）就结束这一轮。结束后做一个小结并算分。 接着让团队花1分钟反思一下，他们的看板系统哪里挺好的，哪里需要改进，并再花1分钟重新设计工作流和尝试不同的WIP限制数目。 4. 第三轮，扩展 给游戏增加点复杂度，引入客户订单和一种新的披萨（蔬菜配方）。订单可以包含1种或2种披萨，只有整个订单完成了才能得分（订单里披萨的总分）。蔬菜披萨没有火腿和菠萝，只有7条蔬菜（绿色的便利贴）。可惜蔬菜一烤就很容易焦了，所以只能在披萨烤好后粘上。