敏捷理念

059 打破组织变革的幻想

康美国 — Wed, 11 Feb 2026 20:50:17 +0000

康美国：我们在西雅图的 Beyond Agile 聚会上采访了 Craig Larman。 Craig Larman 是一位知名的敏捷实践者和软件开发人员。敏捷宣言的历史: https://agilemanifesto.org/history.html Craig Larman: http://www.craiglarman.com LeSS（大规模Scrum）的官方网站是：https://less.works

The post 059 打破组织变革的幻想 first appeared on Agile Thoughts.

057 Craig Larman：用 LeSS 给企业减肥

康美国 — Wed, 21 Jan 2026 21:26:42 +0000

我们在西雅图地区的 Beyond Agile 聚会上，采访到了 Craig Larman，他正在做一场演讲。 Craig Larman 是一位知名的敏捷实践者和软件开发人员。敏捷宣言的历史: https://agilemanifesto.org/history.html Craig Larman: http://www.craiglarman.com LeSS（大规模Scrum）的官方网站是：https://less.works

The post 057 Craig Larman：用 LeSS 给企业减肥 first appeared on Agile Thoughts.

056 Craig Larman 揭秘敏捷宣言的幕后故事

康美国 — Sat, 03 Jan 2026 18:42:23 +0000

Craig Larman 是一位知名的敏捷实践者和软件开发人员。敏捷宣言的历史: https://agilemanifesto.org/history.html Craig Larman: http://www.craiglarman.com LeSS（大规模Scrum）的官方网站是：https://less.works

The post 056 Craig Larman 揭秘敏捷宣言的幕后故事 first appeared on Agile Thoughts.

034 Nexus冲刺评审对话

康美国 — Wed, 25 Jun 2025 21:25:10 +0000

康： Richard Hundhausen带我们了解Nexus如何进行冲刺评审。插播：我们将拥有Nexus Nexus，nexus，nexus。 Richard：让我在这里转个弯。这里有一个地方规模化Scrum与Scrum不同的是：我们不让各个团队进行单独的冲刺评审。我们有一个整体的冲刺评审，叫做Nexus冲刺评审，整个Nexus参与。所以所有Scrum团队、他们的产品负责人、Scrum Master，以及与该冲刺目标相关的利益相关者，都来参加评审，他们检查已完成的集成工作，不只是说，嘿，我们要回顾团队一完成的六个PBI，但诚实地说，这些PBI可能汇总成更大的功能想法。所以我们要检查Nexus在该冲刺中交付的这些更大的功能，并获得反馈。我们有一些技术。我的意思是，这可能是在一个大房间里的长会议。 Richard：如果你在观看功能一到十的电影，而我在那里是因为我关心功能八。哦是的。就像，我真的不在乎这部电影的前两幕，直接到我的部分吧。所以我们建议规模化时采用一些更大型的房间引导技术，比如科学展览会、集市，你可以在冲刺评审室周围设置站点。康：嗯。 Richard：不同的利益相关者可以去不同的领域区域或角色，以这种方式查看他们一直在做的工作。康：所以你是团队的一部分，你在团队交付的某个部分上工作。 Richard：是的。康：你可能有点不耐烦，嗯嗯，确实如此。关于坐在满屋子其他人中间，无论格式是什么，你正在谈论采用不同的格式来解决这个问题。是的。在某些方面，我认为这是一个好问题，因为如果我对我们整个Nexus正在交付的东西不感兴趣，那可能存在一些问题。也许问题出在我身上，也许问题出在Nexus上，我不知道。但我只是说，这也可能是一个健康的方式来找出如何解决这个问题。 Richard：这是对的。如果你想不采用发散合并方法，而是有更多的单一反馈点，这样所有不同的Nexus团队都可以交叉学习并看到，你知道，我实际上从未见过Android应用程序的样子。对吧。所以是的。让我们把它放在大屏幕上。我更多是从利益相关者的角度来说的。康：哦，我明白了。哦是的，是的。那总是一个， Richard：你不想让他们疲惫，因为那样他们下次可能就不会出现了。对吧。康：不，那实际上是个大问题。 Richard：你知道，没有利益相关者反馈的产品注定要失败。所以。康：是的。是的。 Richard：所以我们确实建议为所有事件设置时间盒，但我们从不建议具体是什么。康：我明白了。 Richard：我们唯一说的是每日Scrum应该不超过15分钟，但是这些大房间事件，让Nexus决定时间盒是什么。可能通常两周冲刺的四小时会议由于分布式团队或多地点或其他原因必须是14小时。除此之外，在这里总结一下，转个弯，冲刺评审之后，我们有回顾会，但我们将其分解为预备会议。所以就像我们有Nexus每日Scrum，来自不同团队的代表聚在一起，使过去24小时的集成问题透明化。我们在Nexus冲刺回顾会有这个预备会议，来自不同Scrum团队的代表使整个冲刺中什么进展顺利、什么没有进展顺利、学到的经验透明化，与其他团队分享。康：哦，好的。 Richard：因为，你知道，团队一可能没有经历团队三在冲刺中遇到的问题，团队二可能没有经历团队四在冲刺中取得的成功。康：嗯。 Richard：所以我们有这个小的预备会议，是对话式的，你可以做笔记。这些输出进入各个Scrum团队的回顾会，不只是正常的那种。这是Scrum指南中的。它只面向Scrum团队，他们检查并调整流程，寻找改进。记住新的Scrum指南，你必须至少带一个改进回到你的团队用于下一个冲刺。康：好的。 Richard：这个大房间事件的不同之处，抱歉，Nexus冲刺回顾事件是我们有一个后会议。所以来自各个Scrum团队的代表，也许与之前相同的人，在各个Scrum团队回顾会结束后聚在一起，使这些改进或实验透明化。我不想说这是为了问责，康：对。 Richard：但这也只是为了自下而上的智慧。嘿，看看我们在学什么，看看我们在做什么。看看我们如何在团队二那里应用它。团队三在那个后会议中记录这些。就像，那很酷。 […]

The post 034 Nexus冲刺评审对话 first appeared on Agile Thoughts.

033 Nexus集成团队

康美国 — Wed, 18 Jun 2025 18:03:41 +0000

康： Richard Hundhausen向我们介绍Nexus集成团队。 Richard：我想指出，Nexus中有一个新角色，可能是最容易被误解的角色，这可能是因为它的名字。它叫做Nexus集成团队。这不像其他规模化框架，那些框架中他们是做工作的人，他们负责合并代码、编写测试和修复构建问题。而这个团队实际上是一个来自Nexus的即时团队。比如说我们在Nexus中有五个七人团队，总共有35个实际做工作的人。在任何一个冲刺中，其中几个人会戴着臂章，上面写着”我在Nexus集成团队”。日常工作中，我在我的Scrum团队里做我的事情。我在写代码，写测试，做一些部署工作。但是如果那种信号灯亮起，比如我们的构建服务器停止了，康：有趣。 Richard：那么戴着臂章的人会说，好吧，那是我的事，或者是我们的事。然后他们会去处理那些集成问题，或者试图清理那些依赖关系，这些可能是技术依赖。你知道，我们的图表，你们看不到，但我们有三个齿轮在三角形的三个角上，叫做集成工作。我喜欢称之为持续集成、持续测试、持续交付，或者自动化构建、自动化测试、自动化交付，随你怎么称呼。但这些轮子一起转动，需要有人照看并保持它们的润滑，确保我们的云账户有订阅，确保构建在运行，服务器没有满载。这类运维工作。 Richard： Nexus外部没有人帮助这项工作。有一个叫做Nexus集成团队的团队，但他们就是我们自己。这不像你去找一个固定团队说，嘿，（敲门）构建变慢了，你们能修复吗？不是的，这些人作为他们日常工作的一部分来照看这些。所以实际上这与其他方法没有太大不同，比如团队做工作，不仅是做什么，还有怎么做。对吧。我们也一样。只是我们说需要有一些戴臂章的人对此负责，这样如果没有其他人站出来，这些人就必须要做。除此之外，观念是一样的。康：对我个人来说，这里有很多很酷的想法，不管我是否在使用Nexus，都值得思考对我意味着什么。比如那些总是处于红色状态的持续集成环境是没有帮助的。这确实在公司中发生。你有人可以去找，说，嘿，这不起作用，你能为我做什么？所以这很好。 Richard：让我澄清一下。就像单个团队的Scrum Master一样，Nexus集成团队有点像Nexus规模化的Scrum Master。他们应该始终采取教练、咨询、培训、引导的立场，只有在这是唯一方法时才动手。换句话说，假设我在那里，我是Jenkins专家，我戴着Nexus集成团队的臂章，Jenkins停止了。这不是说我会收到电击去修复Jenkins。我会说，好吧，哪个团队报告的？让我们和他们坐下来，也许以群体方式。康：嗯嗯。 Richard：向他们展示，哦，嘿，这是发生的事情。康：嗯嗯。 Richard：你们正在运行一个较旧的构建，使用的框架在Jenkins中不受支持，所以这不是Jenkins的问题。康：对。 Richard：但我们可以在那里添加这些组件。我可以向你们展示ood或其他东西是如何工作的，对吧。如果你们需要的话，可以拉取那些引用。是的，也许我们会从中创建一个wiki并让所有人都能使用。但我不是直接去那里修复它。Nexus集成团队应该始终从教练、咨询的立场开始。我就在你们肩膀后面向团队展示。康：酷。 Richard：如何做这些事情。但如果他们完全迷失了，是的，我是说，我会谈论，嘿，如果Scrum团队，一个团队因为这样的事情无法工作一天。康：嗯嗯。 Richard：我们谈论的是数千美元的损失。康：嗯嗯。 Richard：如果一个Nexus因为某些自动化问题或其他什么原因而陷入僵局，比如他们的仓库满了或丢失了，那可能是几万美元的损失。康：这确实会发生。 Richard：这确实会发生。康：无论他们是否使用Nexus，那种僵局都会发生，而Nexus能更快地暴露这个问题，因为有人在关注它。 Richard：所以我认为我们需要有人负责。我是说，最后的手段。康：嗯嗯。 Richard： Nexus集成团队必须让车轮重新回到轨道上。康：对我来说，Nexus是团队之间的一个设计联盟，现在有了这个设计联盟，如果你叫它北约或其他什么名字，比如，如果其中一个团队遇到问题，那么这就变成了整个组织的问题。然后当他们去对抗组织时，实际上会获得更多的推动力。我是什么意思？有些组织有票务系统和那些不在乎的人。他们有一个大的票务队列，按先来先服务的原则处理事情。有时候实际上并不完全是先来先服务，因为这关乎谁喊得最大声和其他一些因素。我见过团队的集成系统环境崩溃，因为某个地方有一个环境团队需要有登录和更改的密钥。 […]

The post 033 Nexus集成团队 first appeared on Agile Thoughts.

032 Nexus 如何制定计划

康美国 — Wed, 04 Jun 2025 23:02:43 +0000

Richard: 你已经在一个团队中使用Scrum一段时间了，他们接受产品待办事项增量——团队在冲刺结束时交付的需求。现在，你将其扩展到一个更大的组织，多个团队需要协调他们的努力来交付一个产品待办事项增量。团队数量可能是两个、五个、十个。想象一下让这些团队朝着一个产品待办事项增量工作所需的协调努力。Richard Hundhausen告诉我们这在Nexus中是如何完成的。 Richard: 这是一个正常的产品待办事项列表，尽管是大规模的。它会在顶部有更准备就绪的项目。康：而那个产品待办事项列表是为整个Nexus的。 Richard: 它是为整个产品的。我们相信使用Nexus框架进行扩展是关于许多团队在单一产品上工作。康：我明白了。 Richard: 这很快就会分解为”什么是我的产品？”有很多技术来识别这一点。Nexus框架不是关于将Scrum引入每个部门——比如维护、IT或财务。我见过组织尝试这样做。那不是扩展。这是为了多个Scrum团队想要在单一产品、单一产品待办事项列表、单一产品负责人上工作的情况。 Richard: 就像在Scrum中一样，我们用冲刺计划会议开始冲刺。在Nexus中，冲刺计划会议包括每个团队的预测和计划。这是那些大房间会议之一，来自每个Scrum团队的代表在预会议中会面，使依赖关系透明化。有细化、规模估算和一些权衡，这样团队可以交付在冲刺期间没有PBI跨越团队边界的项目。此外，最适合的团队选择每项工作——注意依赖关系并在冲刺结束时交付可演示的价值。 Richard: 然后这些代表将PBI带回到他们各自的Scrum团队的冲刺计划中。团队决定预测是否符合他们的容量、速度和完成定义。使用新的Scrum指南，每个冲刺都期望有改进。如果团队同意他们可以完成PBI，他们就制定计划。当最后一个Scrum团队完成他们的冲刺计划时，整个Nexus冲刺计划会议结束。每个人都等到最后一个团队预测并最终确定他们的计划。例如，如果第五个团队意识到他们缺少培训人员，他们可能需要与其他团队协调以调整依赖关系。康：所以听起来他们在为下一个冲刺中能够交付的内容在团队间构建一个共享的待办事项列表。 Richard: 某种程度上。我们实际上没有共享的冲刺待办事项列表，除了作为跨团队依赖关系的视图。在规模化时有一个新的工件叫做Nexus冲刺待办事项列表。你可以把它想象成来自每个Scrum团队待办事项列表的PBI在流程图中可视化——每个团队一行：待办、进行中、完成，也许还有一个”阻塞”列。康：嗯嗯。 Richard: Nexus中的任何人都可以说，”哇，第一个团队在等第二个团队的PBI，而第二个团队甚至还没开始——冲刺已经过半了。” 康：嗯嗯。 Richard: 所以这是个别团队冲刺待办事项列表预测的只读、聚合视图。康：嗯嗯。 Richard: 谁维护或查看它？你在那个工件上举行每日Scrum吗？这由Nexus来决定。 Richard: 日常中，就像在Scrum中一样，我们有每日Scrum——一个同步会议来计划当天。规模化的不同之处是Nexus每日Scrum，在各个团队的每日Scrum之前举行。来自每个Scrum团队的代表参加这个预会议。它像正常的每日Scrum一样有时间盒限制。在这里，他们使过去24小时的集成或依赖问题透明化。其他团队可能会说，”我们今天正要涉及那个——谢谢提醒。” 康：嗯嗯。 Richard: 或者”审计员在大楼里？好的，我们会注意。”依赖关系可能在人员、领域、技术组件或甚至代码库之间——尽管我们不建议团队之间有私有存储库。Nexus每日Scrum的输出成为各个团队每日Scrum的输入。康：嗯嗯。 Richard: 这就像Scrum的Scrum，除了它是必需的并且首先发生。康：我喜欢它首先发生的想法。我和其他教练在一天结束时做过多团队Scrum，很难对我们这么晚学到的东西做出反应。这很有道理。 Richard: 有时我被问到，”我们还能做Scrum的Scrum吗？”我说，”嗯，就像在单团队Scrum中一样，不行——你不被允许和人交谈。” 康： <笑> Richard: 那是个玩笑。康：太好了。<笑> Richard: […]

The post 032 Nexus 如何制定计划 first appeared on Agile Thoughts.

031 创建 Nexus

康美国 — Thu, 29 May 2025 21:35:48 +0000

Richard Hundhausen和我讨论如何形成Nexus。康（01:20）： Nexus是以某种程序化的方式形成的吗？还是有一些规则？理查德（01:26）：嗯，我们更喜欢自组织，因此我们希望Nexus尽可能地自组织，就像其他框架需要一些组织重新设计来创建一个“泡泡”，让这个东西能够运作一样。与基于Scrum的其他框架一样。我们没有为管理者提供故事，因为在Scrum中没有管理者，只有自组织、自管理的团队。Scrum Master负责日常Scrum，帮助提高团队的生产力，提供教育和咨询。但最终是团队完成工作，是他们解决自己的问题。康（02:13）：我现在在考虑集成点。有Nexus冲刺审查吗？我正在看图表。 Richard（02:18）：是的，如果你允许的话，让我解释一下。我们正在查看的图表可以在scrum.org上找到。它在Nexus指南中。这是一个PDF，就像Scrum指南一样。这是一个基本框架，免费提供的。它来自Ken Schwaber和我以及其他几位培训师。但scrum.org还有他们基于该免费框架的专业Scrum规模的实例，称为SPS（Scaled Professional Scrum）。所以有了Nexus框架，去利用它，享受它。但是如果你想了解一些关于规划、追踪工作、可视化和持续集成、持续交付的在规模上的经过验证的实践，以及你现在听到的一些更DevOps的东西，那么就是scrum.org的专业Scrum规模，专业Scrum规模项目。当你问我关于实践的问题时，我喜欢将这两者区分开来。Nexus框架没有提到它。就像Scrum没有提到它一样。好吧，在scrum.org，我们有一些我们认为在规模上非常有价值的实践。就像对于单个团队的专业Scrum一样，我们有关于如何实施Scrum指南的想法。康（03:36）：一个实践的例子可能是… 理查德（03:40）：产品积压的细化。哦，哦，等等，不，这是单个团队Scrum中的一项实践。在规模上，它实际上是一个新的事件。所以我们做出的改变之一是，这个外骨骼现在需要进行细化，不仅仅是“嘿，这是个好主意”。让Scrum团队定义何时何地以及时间段，它可以为零。现在它是一个事件，何时何地以及细化的深度由Nexus决定。但同样，我们有关于跨团队细化和单个团队细化的实践。我应该回到一开始并说Nexus框架的目的。第一目的是识别、透明化、减轻/消除依赖关系。我们认为依赖关系是不好的，是摩擦点，是无法完成的原因，是无法交付价值的原因。在规模上，这只会加剧。其他的规模框架可能会以不同方式定义“依赖关系”，或者将其视为协调/学习的机会。而我们的根本动机不是将依赖关系视为学习的机会，而是认为依赖关系是不好的，应该被可视化和减轻。康声音解说（05:07）： Nexus是通过将多个Scrum团队团结在一个产品周围而形成的组织工具。通过创建一个具有相互依赖以生产产品的团队组，Nexus成为围绕共同目标组织团队的强大工具。康（05:45）：团队学到了，总的来说，似乎依赖较少理查德（05:48）：是的，Scrum并不反对学习，Nexus也不反对学习，但我们不将学习作为消除依赖关系的途径。我们在框架中有其他的方式来处理这个问题。康声音解说（06:04）：下一集，Richard Hundhausen告诉我们Nexus如何进行计划。康（06:11）：而且产品积压是为整个Nexus的。 Richard（06:13）：它是为整个产品的。我们认为，使用Nexus框架进行扩展是许多团队共同努力完成一个产品的过程。

The post 031 创建 Nexus first appeared on Agile Thoughts.

030《Nexus 和团队 Scrum》，与 Richard Hundhausen

康美国 — Wed, 14 May 2025 19:24:52 +0000

康美国声音：理查德·亨道森（Richard Hundhausen）为我们介绍了Nexus，这是一个用于进行多团队软件开发的框架。康：你刚才说Nexus是最简单的扩展框架。理查德：我研究了所有这些，其中一些需要一些严重的组织变革、重新设计或重构。而在Nexus中，我们只是假设你正在使用Scrum，所以Scrum已经存在并运作良好。我们在Scrum.org推荐首先使用专业的Scrum。我们有一个术语，我们称之为“nail it before you scale it”（在扩展之前先掌握），但我们理解组织正处于其发展过程中，如果你愿意，Nexus框架就像是一个外骨骼，你可以把它放在现有的Scrum框架周围，以便有机会进行扩展。康：听起来实际上与Less相似，至少在表面上是这样。因此，它谈到了团队的持续集成。现在，我不知道他们是否对谁应该进行持续集成有明确的规定，我也不知道它是否涉及任何产品定义类型的事物。Nexus在持续集成方面是否有规定，还是只是说：“嘿，他们应该使用持续集成”？理查德：拿起Scrum指南，你会发现里面没有关于如何进行工作的具体指导。有事件，有时间盒的概念，有已完成的定义，但最终让团队决定。让团队决定如何完成他们的工作。开发团队就是让Scrum团队决定如何在工作周围自组织。角色明确，责任划分清晰，Nexus也有这样的特点，但我们不要求你放弃Scrum中的任何东西。因此，如果你的一个团队的大脑说：“哇，这是团队应该决定的事情”，那么你的Nexus大脑应该说：“这是Nexus应该决定的事情”。例如，如果你想进行持续交付，我非常赞成，我认为在今天的时代，扩展开发工作需要这样做，但仍然由Nexus决定。团队、Scrum团队和Nexus需要确保在进行持续交付之前已经实现了持续集成，并且在进行这些操作之前，他们必须解决了技术上的卓越性问题，并且在控制他们的依赖关系和集成问题之前。但最终，我们不关心。我们认为这是一个好的做法，但让Nexus来决定，他们可以检查他们在这个旅程中的进展并相应地进行调整。康：什么是Nexus？理查德： Nexus是我们对一些事物的术语。实际上，这是未来操作系统Android的全球术语。在会计和法律领域，这是一个非常负载的术语，但在这种情况下，它是一种沟通的途径。从定义上来说，它是一种沟通的网络结构，因此作为一个扩展框架的名称，它非常合适。但是，Nexus框架中，我们将其中的Scrum团队称为Nexus。就像在单一团队的Scrum中，我们有三到九名开发人员，加上一个产品赞助者角色和一个Scrum Master角色，最多有11人的Scrum团队。我们对Nexus中的Scrum团队也有相同的概念，不仅因为它跟单一团队的开发者模式相似，而且还因为邓巴数的因素，管理大型会议等等。康美国声音：邓巴数是指一个人能够维持稳定社交关系的人数的建议认知极限。这个数字在1990年由英国人类学家罗宾·邓巴（Robin Dunbar）首次提出，他发现灵长类动物的大脑大小与平均社交群体之间存在相关性。邓巴非正式地解释为你不会因为未被邀请而加入他们在酒吧里碰到时会感到尴尬的人的数量。理查德：我们的大脑可以维护大约100到150个人，我们可以说：“哦，嘿，我认识你。你是那个在手持应用程序上做了非常好的UX的人。哦，嘿，你是我需要谈论爱达荷州新销售税的税收问题的利益相关者。” 康美国声音：您是否是敏捷或Scrum的新手？正在寻找一种有趣的方式来获取成为敏捷团队知识的途径吗？快去阅读小说《敏捷黑帮》，这是一部关于项目经理需要将他的团队转变为敏捷的戏剧性小说，因为他的生命取决于此。这本书在美国的亚马逊上有售，在印度的pathi.com上有售，在中国，你可以在我的微信商店购买。链接在节目说明中。下一集，理查德·亨

The post 030《Nexus 和团队 Scrum》，与 Richard Hundhausen first appeared on Agile Thoughts.

029 TDD对领导力的价值

康美国 — Wed, 17 Jan 2024 19:26:17 +0000

Lancer： Sunil Srivastava和我讨论了测试驱动开发对领导层的价值。 Sunil：从领导的角度来看，他们关注的是我们如何更快、更便宜、更迅速地交付产品，而不仅仅是代码。所以，如果你从这个角度去思考团队如何能够交付高质量、易于改变且成本低廉的代码，尽可能快地完成，这就是测试驱动开发可以帮助领导层的地方。 Lancer：比如说我是某公司的副总裁，我在考虑进行TDD；我需要花钱请顾问进来，让我的组织掌握这种技能。那我为我的投资能得到什么回报呢？ Sunil：你能够让你的团队更快地行动？ Lancer：那是如何实现的？他们如何更快地行动？ Sunil：因为TDD涉及单元测试，他们能够在代码层面进行测试。所以，如果你能在代码层面进行测试，并且进行多个测试，那么你就减少了对更大的应用进行依赖性测试的需要：回归测试、性能测试和其他集成测试。打破这种依赖性是很重要的，因为其他测试可能需要更长的时间，会拖慢开发交付的速度。所以，如果你不需要为更大的应用创建太多的测试，并且在单元测试层面有信心，你的构建速度会更快。你会更多地使用低层级的测试，不需要进行那么多高层级的测试，这样就节省了维护那些难以维护的应用测试的时间。 Lancer： TDD让你的团队花更多时间编写新功能，花更少时间修复错误，因为错误更少了。 Sunil：是的。所以从副总裁和领导的角度来看，你关注的是，正如你所说的，团队更专注于新功能的开发，而不是修复错误和重新工作。这降低了项目的持续成本，这意味着我可以更快地交付产品，这才是他们关心的，对吧？所以速度更快，上市时间大大缩短。这就是测试驱动开发从领导角度提供的好处。 Lancer：当企业想要转向新方向时，TDD也能够使代码更轻松地跟随业务方向而变化。 Sunil：因为代码编写得易于理解，是模块化的，所以能够更轻松、更快速地进行转变。 Lancer：为变革制定预算。我觉得我们有点谈到了。所以如果我要花钱雇人来改变我的组织，我需要知道我会得到什么回报。我们说过你将会得到更快的功能交付和转向能力，可能还有其他一些东西。所以归根结底，如果我们要谈论资金，这对你的组织有什么价值呢？ Sunil：你知道，一些团队关注的关键点是，正如我所说的，更快的交付、24/7的运行时间、更高的代码质量、更少的缺陷、更低的成本。我认为这些最终转化为，低成本、更高的交付运行时间以及能够转向。这些是领导关心的事情。我认为这就是你可以向领导展示的。 Lancer：当我们谈论时，我想到了另一个点。错误库存会减少，趋近于零。 Sunil：是的。这涉及到技术债务。TDD可以帮助你将技术债务减少90%或80%。我见过一些团队通过实践测试驱动开发，几乎消除了相当于10年技术债务的情况。 Lancer：跟随TDD大师正在进行的酷炫事物，或者与我们合作将您的企业转变为一个精益、高效、零缺陷的微测试机器。请前往TDD gurus.weebly.com。下一集我们将听取Richard Hundhausen关于Nexus敏捷扩展框架的意见。 Richard：如果你愿意，Nexus框架只是围绕现有Scrum框架的外骨骼。

The post 029 TDD对领导力的价值 first appeared on Agile Thoughts.

027将未完成的故事纳入Sprint计划

康美国 — Tue, 18 Jul 2023 17:18:32 +0000

您可以通过邮箱：Brandon.Linton@Accenture.com或者Twitter联系到布兰登·林顿兰瑟：你的团队一直致力于研究用户需求，然而有时候他们并没有实现所有的需求。在上一集中，我和布兰登·林顿讨论了如何将未完成的需求进度记录到你刚刚完成的sprint中。现在我们将继续讨论，当你把这些未完成的需求或者需求们带入下一阶段计划时，你该如何处理它们。布兰登：我们总是想尽可能的反映出最真实的情况。如果你知道这个需求是13个点，那么就不要说它是20个点。因为接下来会有两种可能：第一，这个需求变得更小，因为剩下的工作量更少。第二，这个20点的需求现在已经变成40个点了，因为原始的工作量评估是不准确的。兰瑟：也许企业架构师走过来，说：“不，你需要增加功能，例如申请登录等等…”，那么现在这个需求就难多了。布兰登：是的，我想我还没有遇到过一个愿意推翻现状的团队。这跟信用无关，只跟它的大小有关。而你又做了多少努力？让我们来谈谈这个场景，它可能比你想象的要大的多，这有助于团队更好的理解工作速度，尤其是当你遇到了一些需要做这种改变的事情。如果这个SDK的实现比我们想象的困难得多，那么就请重新评估它，试着让你的工作速度尽可能的真实，尽可能做出最好的承诺。展示你真正相信的他们的工作速度，或者基于你对他们的深入理解进行速度评估。这种练习将使你更接近持续的、真实合理的节奏。兰瑟：如果这个需求只剩下3或5个点，你就把它搁置了，然后因为你得到了所有额外的点数，突然间，你的下一个Sprint速度就被人为的提高了。现在你并不能真正的去计划它，这于你的计划无益。布兰登：是的，你的意思是，如果你完成了一个20点的需求，而它实际上只需要付出3个点的努力，那么你就通过虚假的方式提高了你的工作速度；在下一个sprint中，这给你的利益相关者设定了一个虚假的期望。你也可以这样做，对吧？因为你们是一个scrum的团队，对吧？你认为你应该能够维持下去，那么你就是这样惹上麻烦的。兰瑟：简单来说，在已经完成的工作中，速度等于需求点。当你使用Sprint计划来规划未完成的工作时，不管你在之前的Sprint中已经完成了多少工作，你都必须对剩余的工作量进行重新评估。兰瑟：布兰登，请问该怎么联系您呢？电子邮件或者Twitter？布兰登：我现在根本记不起我的Twitter了，它主要是用来发牢骚的。兰瑟：如果你有任何问题，你可以在推特上对布兰登抱怨，就像我们在这个播客上说的一样，你可以在Twitter上找到他；当然也有可能是布兰登·林顿在 Twitter上搜索你。布兰登：林顿，L-I-N-T-O-N，但是为了保险起见我再说一下我的邮箱，我的邮件是brandon.linton@accenture.com。兰瑟：这一集是前一集的延续。请参阅前26集，了解我们谈话的全部内容。

The post 027将未完成的故事纳入Sprint计划 first appeared on Agile Thoughts.

026便捷又实用的计算速度和待办事项的方法

康美国 — Mon, 05 Dec 2022 17:26:51 +0000

布兰登·林顿的联系方式： Brandon.Linton@accenture.com 兰瑟：这一集，我们和布兰登·林顿讨论了关于计算工作速度的便捷的方法，特别是关乎未完成的用户需求。布兰登：你好，我叫布兰登·林顿。我住在底特律，它位于美国的密歇根州。我是埃森哲解决方案的敏捷教练。我在敏捷空间工作了八年时间，提供咨询业务长达四年。很高兴能和兰斯一起工作。兰瑟：是的。我也很高兴能和布兰登一起工作。布兰登：很高兴来到这里。我们正在做一个关于需求的播客，主要研究那些需要较长时间才能完成的需求。兰瑟：是的。那么，这是一个问题吗？布兰登：这不但是一个问题，还是一个大问题。不久前，我们在办公室就这件事情进行了一次简洁的沟通，是的，我们在谈论，或者说我在谈论一个我刚刚加入的团队，问题出现在一次sprint计划会议上，他们有一个需求；但是在上一次的sprint中，他们还有多个需求没有完成。我们的需求依然具有很高的优先级。他们说，这是8个需求，我们可以先完成5个，然后把剩下的3个放在最后一个sprint中。总之，一切就是从这里开始的。兰瑟：我们把讨论的这个数字称为需求点，当团队有一大堆工作要做时，他们会制定一个sprint计划。布兰登：对的。兰瑟：最终他们得到了我们称之为速度的东西。布兰登：是的。但是速度到底是什么呢？拿开车来说，我们开车的时候车会有一个车速。速度有很多不同的形式。对，在scrum一文中，我给速度下了定义，你知道的，这只是一个大概的定义，或许它可以用更好的词语来定义，但是在这里我想说的是，在布兰登的世界中，速度是点数，需求的总点数就是在sprint中已经完成的、结束的那些。再没有比这更贴切的说法了。兰瑟：在这里，为了进一步强调布兰登的观点，我们假设一个场景：团队有10个需求，所有需求的点数相同，都是5个点。因此，这意味着如果他们完成所有的需求，他们需要完成50个需求点。布兰登：所以即使你有10个需求，但是你只能完成其中一个，那么，这就是你的速度。即使其他的需求即将完成，那也与你的速度无关。这有点像踢足球，如果你没有进球，不管你离终点有多近，一英寸，一码，还是50码，你都没有完成。因为拥有可持续的速度，意味着拥有一个能无限期保持的可重复的速度。兰瑟：所以正如布兰登所说，这并不是为了计算你的点数，而是为了建立你可以用于制定计划的指标。这些指标应该等同于我们在不确定的时间内所能达到的目标。布兰登：有趣的是，一个新的团队，往往会说，这个需求需要完成的点已经不是8个了，我们已经完成了5个，所以我们只需要计算剩下的3个。当然，这也引起了争论，那么，什么叫需求完成呢？他们说，嗯，这个任务，还有这个任务，你是知道的，这个，这个也是好的，这个已经完成了90%了，布兰登，对吧，我获得了所有的点，我们几乎就要完成了。但我总是说，好吧，你是在为谁做这个？这可能是多方面的，这取决于你工作的团队。如果这是某个应用程序的“保持登录”功能，当你返回后，不需要再次登陆，这个时候，除了保持登陆复选框，你的所有功能都是正常的，这对您的最终用户来说不是很有用，因为您登录的内容会一直存在，你甚至没有选择。这个功能并没有完成，它几乎快要完成了，但仍然是未完成状态。那么我要说的是，你的用户关心你做了多少吗？未来的用户能体会到它的价值吗？他们并不在乎你做了多少，他们只在乎你还有没有完成。兰瑟：这就好比，我把所有要买的东西都放进购物车，然后到了结账台，收银员说，对不起，这些东西我们不卖了，你不能买了。就像，我想要的东西都拿了，但是我却不能把它带回家去。所以我想我只在乎我能不能把它们带回家。布兰登：这可能会揭示一些有趣的机会，如何更好地分割需求。用你的比喻，如果我有一辆装满东西的购物车，我到了结账台，但是那是只收现金的，然而我没有现金。好吧，我当然没有现金了，我得在这里排队。但是如果我有现金，那至少是一种可以满足的用例或场景。因此，这可能意味着有机会将需求分开。但另一个，我们谈话的另一部分，我们现在怎么处理这些需求呢？尤其是因为你是对的… 兰瑟：现实情况是，一部分需求完成了，但是另一部分需求并没有按时完成。他们根据邓恩的需求来计算工作速度。所以他们整理了所有的邓恩需求。他们把每个人的需求点加起来，可能一共是50个，但是他们仍然有一些需求没有完成，现在他们想为此制定一个计划。布兰登：假设这仍然是一个优先级高的事项。我在刚开始就会问：这些问题是否仍然重要，你知道，中途或部分完成，这些是否依然是迫切需要的。如果不是，把它们放在待办事项里，以后再做；如果是的话，你仍然想去追求这些，那么就像我平时所说的，让我们好好研究它们，再重新进行评估，因为在开始研究这些东西时，我们在sprint中可能学到了一些东西，但是还没有完成。我们现在是否能更好的知道完成这个需求实际上比我们之前估计的要付出更多的努力。兰瑟：是的。所以我有90%的需求完成了一段时间，假设这是一个20点的需求，我没有得到任何点数，我没有，我知道那不是斐波那契函数。很抱歉，伙计们，但这是一个20点的需求，我不明白，现在我们又要重新评估它，我们要评估什么工作是被遗留的，什么是仍然需要做的，或者是完成剩下的需求还需要什么东西。布兰登：对的。布兰登：是的。我们不想考虑的是，我们已经投入了多少精力。在速度方面，我们总是告诉团队，你需要非常专注于剩下的工作来完成这个任务。还有我们提到的那个场景，比如说，你知道的，20点的需求现在实际上只有13点，因为我们已经完成了一些工作，我们投资了一点，但还有很多路要走。你可能会说，好吧，我上一次sprint时做的工作没有得到表扬。你是完全正确的，那不是速度，对吧？你，我们，我们并没有完成。现实就是一个20点的需求现在变成了13点。所以如果我们看一下点数的总和，假设这是一个发布，现在你怀疑100个点降到了93个，对吧？你的，你的完成时间移动了一点点，对吧？你还没有完成需求，所以这不是工作速度，就拿获得信用来说，嗯，不要为之而担心。但事实却是，为了达到同样的价值，只需要少做一点努力，你想重新评估它，你知道，当这个需求仍然拥有优先权时，你需要考虑重新评估它。兰瑟：下一集，布兰登将继续劝阻我们不要把速度看做是衡量团队付出努力的方法或者是某种形式的信用，而不去估量他们已经完成的工作。布兰登：你知道的。我知道你想尽可能的反映出最真实的情况。所以，如果你知道这个需求是13点，就不要说它是20。 Tout Agile Noir Chinese version

The post 026便捷又实用的计算速度和待办事项的方法 first appeared on Agile Thoughts.

025 作为开发者，如何熟练掌握TDD？

康美国

最重要的几点： * 开始实践 * 如果某个问题难度太大：暂时保留下来，之后再回过头来重构代码下面的情况说明你已经熟练起来了： * 一天8小时已经能写出很多个测试了 * 能重构4个较长的函数或者类，并让它们通过测试 * 很不喜欢收到跳过测试的建议 * 已经快一周没用过调试器了下面的情况说明你已经非常精通了： * 能教会他人如何熟悉TDD * 你的团队项目有很高的代覆盖率了（高于80%），并且还在持续提升 * 团队的技术负债在每一轮冲刺中不断降低开发者要熟练掌握TDD，必须得经历的那些事情：先编写测试代码，再写产品代码。之后，你的大脑会形成条件化的思维，也就是形成一个新习惯。40/4挑战是一种培养新习惯的方法。它的意思是在4周的时间段里，写出40个单元测试。之后，你会在TDD上取得突破，并变得熟练。你在代码编写中会遇到好些困难，并发现困难通常都能通过先进行微测试来解决。你会发现一两个自己难以解决的问题，但没关系，继续努力。4周过后再来重新解决这个问题，这时候你已经成为了专家，能用你条件化的思维来平衡测试与产品代码了。在回顾微测试提供的快速反馈时，你感到非常享受。你开始注意到你开发出了更多的功能，而且在修复有问题的代码上花费的时间越来越少。开发者熟练不起来的常见原因有哪些？ 14到22集的IT戏剧《敏捷思维》中，我们列出了几个原因。毫无疑问，最常见的原因，就是开发者对于已有的思维定式太过于习惯和舒适了。“我不先写代码，就没法写出微测试来。”这种思维定式让他们不愿意战胜自己来尝试新事物。然后，不舒适的感觉让他们继续自己既有的固定思维，跳过了要先写的微测试，直接编写代码。但这样反而让通过测试和实现功能的周期更长，也更冒险，因为你老是会遇到问题却没有任何头绪。下一集会讲述一种“调皮或优雅”的方式来计算团队速度，由敏捷教练Brandon Linton带给大家。

The post 025 作为开发者，如何熟练掌握TDD？ first appeared on Agile Thoughts.

024 让整个组织实施TDD

康美国

上一集，我们讨论了如何让团队实施TDD，也就是用微测试来发展他们的代码。让一个团队实施TDD非常有帮助，因为这样展示了TDD的实施不仅可行，而且很有价值。下一步是如何让整个组织采纳实施TDD。没有组织的接受，在管理层或者产品负责人更换的时候，TDD就有可能被否决。这种事情随时都有发生：团队自己发现了新事物的价值，管理层换人了，不理解团队的做法，于是开始干预，并停止了相应的做法。所以，组织的采纳是对TDD未来价值的确认。这样能使TDD成为公司文化、雇佣政策和职业路径的一部分。在一个团队成功展示了TDD的价值之时，就是全面实施TDD的时候了。步骤一、让顶层人员熟悉相关情况包括有关的管理人员、架构师以及产品负责人管理层应该了解实施TDD需要的付出和会有的回报，这样他们就不会以负面的形式进行干预。开发人员最不喜欢实施TDD时的不确定性。挑战包括让管理层、架构师和产品负责人熟悉TDD时，这三类人群有着完全不同的需求和对TDD不同的看法。因此，传递的消息、目的和技术对话的效果都应当有所不同。步骤二、进一步实施开发者需要学会如何使用单元测试库，如何重构代码，如何设置连续整合服务器，以及如何采用先编写测试的设计。这些在起始阶段都会减慢开发者的速度。即使管理层已经作出了决定，开发人员也会按照自己的想法接受或者反对TDD。虽然并不需要每个人的同意，各团队需要40%到60%的开发人员有使用TDD的意愿。增加甚至长达数年的学习激励，可以让态度“还不明朗”的开发者开始先试用TDD几个月。根据我的教练经验，这足以使TDD新手变得熟练。我见过较好的实施方法包括，副总为每位开发者分配奖金，团队的领头人负责确立一些可实现但又有挑战性的TDD实施目标。这样，也就确定了微测试数量的目标。如上一集提到的40/4挑战一样，目标是需要在两三个月的时间段里，让开发人员实现熟练掌握TDD的效果。步骤三、设置标准设置标准会成为团队对任务完成最低的定义。一种便捷的方式，就是让标准透明可见，容易通过连续整合展开。下面是一个例子： * 拥有一台连续整合服务器 * 服务器必须执行编译步骤，并让其可见 * 服务器必须执行微测试，并让其可见 * 服务器必须执行微测试的代码覆盖率评估，并让其可见 * 服务器必须执行宏测试，并让其可见 * 不能交付未通过测试的代码 * 服务器必须执行设计负债，并让其可见 * 新代码必须有90%的代码覆盖率最后的一项对有大量历史遗留代码的情况较为困难，需要花费数年甚至数十年的时间来达到90%的代码覆盖率。因为任何理由都不可能让我们一切都从零开始来重写代码。添加到历史代码库的新类应该有很高的代码覆盖率，但是在用连续整合服务器实施检查时会较为困难。步骤四、可持续的系统雇佣政策需要直接地针对熟悉TDD或是对学习TDD持开放态度的人。在目前的情况下，招聘反对TDD的开发人员是不合适的。这样的招聘行为只会导致他们与同事之间的压力，以及增长整个组织负面的状况。因此，可以把TDD和结对编程作为面试的一个步骤。在实施级别薪酬的组织里，把测试自动化和代码重构作为确定级别的一部分指标。下一集，作为开发者，如何熟练掌握TDD？

The post 024 让整个组织实施TDD first appeared on Agile Thoughts.

023 让整个团队都开始实施TDD

康美国

如果14到22集里TDD 的IT戏剧一样，一旦你找到了具备测试驱动开发实施能力和可以积极驱动这件事的人选，那么你就占到了起手。我们会回顾Vanilla Pop让他的团队实施TDD的一些步骤，同时也会增加一些我认为很有效的小贴士。步骤一、寻找火花寻找一个思维灵活、而且资历也比较高能影响到团队其他人的人选。让他们积极地在样本代码上试验学习TDD，之后在实际工作中开始应用。另一个策略，是雇佣一个有敏捷软件开发经验的开发者，通常被称为敏捷技术教练或是XP教练。让他参与几次团队的设计冲刺。敏捷教练，比如我自己，有十多二十年使用不同编程语言全栈实施TDD的经验，因此帮助你的团队在几天内改变编程模式，并不是难事。步骤二、让火花称为火焰积极地研究学习团队工作中所写的代码教会每个开发者如何结合自己的用户故事来实施TDD。在几轮设计冲刺中进行结对编程，这样你的开发人员就能得到足够的指导，了解如何自己解决最有挑战的微测试问题，就这样让火花燃烧起来。一开始会有些难度，大家也会学习如何删除、改变已有代码，运用新学到的设计模式以便更方便地添加微测试。减少发布的压力，使每个团队成员都能有时间学到让他们能够产出产品功能的技能。举例来说：让团队决定来做更少的用户故事，这样他们能够为代码提供更多的微测试。另一种方法，是选择一个故事，以结对编程的方式来实施TDD。然后在下几轮的冲刺中，继续这样的方式，直到每个人都能在他们的日常工作中都操练过一些TDD。 40/4挑战，以及永远停留在初级阶段的危险使用社交化帮助团队操练，讨论微测试在站立期间所取得的成就。步骤三、投入，让壁炉的火焰更旺获取管理层支持同他们交流在全部产品代码中使用TDD的愿景。选择两个月后的某时间，让团队讨论使TDD成为主流的产品标准。让产品的微测试工作更加透明公开每天新增的微测试数量。讨论但不要吹嘘有站立会里有多少交付的微测试。在连续整合服务器的面板显示有关的数据是个好主意。停止抱怨自动化测试。开发者很快就会开始指责“新事物”减缓了进度，而且看似没有多少好处。每个人都知道学习需要时间。在开始学习这个方法的前两个月，速度减慢是正常、普遍的现象。抱怨正常出现的现象，只会让管理层有所顾虑，担心团队的不安。为了度过这一阶段，我建议关注学习新技能积极的一方面，与组员分享减慢速度后所学到的新事物。之后，速度就会回升，变得更快，但学习的过程必不可少。在设计冲刺回顾中讨论微测试工作，这样你的组员就会知道他们需要为产出持久的价值负责。利益相关方也要了解到团队的新方法。步骤四、保障燃料的持续供给团队工作协议应该把处置未通过的测试作为优先任务。唯一一个更重要的事情，是产品的应用交付。在测试未通过时，有关的人员或者结对小组，应该停下来了处理这个问题。新增且没有单元测试的代码，应该被删除，就像未通过审阅的代码一样。对交付应用的代码进行结对编程（定义交付应用代码）。如果两个月之后，团队对于新代码的使用上还有问题，反思这一情况出现的原因，这种情况只可能因为创建的微测试有问题或者开发者没有按有关的流程执行引发。期待在开始启动TDD的6个月之后，代码几乎不会出现瑕疵，或是同未采用测试时的旧代码相比错误明显减少。错误追踪系统中的数量走势应当相应地下降。据我的经验，在历史代码上启用TDD一年之后，错误追踪系统已经用处不大了，只是个支持和开发部门间的工作流程罢了。出现的错误应该少于10个。下一集，让整个组织实施TDD

The post 023 让整个团队都开始实施TDD first appeared on Agile Thoughts.

022 TDD和Stack Overflow的专家开发者

康美国

《黑色敏捷书》简体中文版可在这里购买：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail （《敏捷思维》在背景中播放） Vanilla：呃，你就是Lecter先生吧？ Hannibai：Lecter博士。叫我Hannibai就好了。 Vanilla：博士先生，TDD是如何运作的呢，我们可以尝试使用吗？ Hannibai：流程似乎非常简单，和开发者熟悉的传统工作流步骤恰好相反。目前我对这样工作的效果比较关注。此外，我还很关注这种工作流的价值。 Vanilla：呃，是的。回到工作流上，你了解这些步骤吗？ Hannibai：工作流似乎是，第一步，研究产品代码，发现你想变动的地方。 Vanilla：没错，正是。 Hannibai：第二步，决定具体的设计。考虑是新增方法，还是直接修改已有的代码。 Vanilla：然后呢？关键的步骤是？ Hannibai：是的，Clarice。第三步是—— Vanilla：呃，Clarice？ Hannibai：请让我继续说，第三步是很有趣的一步。我们并不是直接变动代码，相反，我们会写出—— Vanilla：（很激动地）测试代码！ Hannibai：没错，为变动代码所写的微测试。有时候，我们需要改变一个已有的接口，或者写一个新的对象和函数，然后用测试来驱动调用已有代码里的新接口。确定微测试的规格，是实现下一步功能的最简单方法。 Vanilla：（很夸张地）然后呢？ Hannibal：第四步，运行微测试，查看是否能通过。观察红色的错误提示。你看见是哪个了没有（严肃地），Clarice？ Vanilla：啊哈…… Hannibal：也就是说，微测试的确有可能通不过。但你知道吗，Clarice？ Vanilla：啊…… Hannibal: (angrily) There is no sense in writing automated tests that cannot indeed fail! Hannibal：（有些生气的样子）如果所写的微测试100%会通过的话，就没必要写啦！ Vanilla True Vanilla：确实如此。 Hannibal：还有第二个原因，你知道不？在我们添加或是修改了产品代码之后，可以观察测试结果由失败到通过的改变。第三个原因，先写测试，能让你从代码调用者的角度思考。调用代码的人才是新功能的使用者。这不像你自己独自吃掉一个蛋奶酥，很快当。学会用良好的方式编写接口，不可能像吃蛋奶酥一样一下子就好。这一切是一种更高明的代码编写方法。 Vanilla：（觉得尴尬和唐突）呃，好的。听起来挺不错的。我们可以开始了吗？ Hannibal：没错。我们把故事分成两部分，一部分要使用TDD，另一部分不用TDD。我们用计时器来测量每个组所花费的精力。 Vanilla：好的，为什么这样做呢？ Hannibal：（清了清喉咙）啊，亲爱的Clarice，你看见了没？我们必须了解TDD的确是能节省开发和测试环节时间的。不然何必使用TDD呢？ Vanilla：是的，有道理。 Hannibal：计时开始，大家行动吧！ (Typing sound. Music. Time passes. Ding.) （打字的声音。音乐。时间过去了。叮。） Vanilla：测试已通过。 […]

The post 022 TDD和Stack Overflow的专家开发者 first appeared on Agile Thoughts.

021 代码覆盖丑闻

康美国 — Thu, 20 Aug 2020 19:06:03 +0000

Vanilla Pop：IT团队怎么样呢？我们可以用TDD来实施一次设计冲刺，然后看看情况吗？ Horst：我还是坚持我自己不赞成微测试的政策。不过，我很乐意让团队来自己决定如何才能向我交付功能和质量。代码狗：我不相信TDD。你不能在写代码之前就先写好测试啊。你知道吗？没人会这样做。你想想，不过几周，就会回到老样子，我称之为错误驱动开发。我们调试代码的人就是这样做的。架构师：我改变了。请教了专家，建议我尝试一下更为灵活的思维。我努力做得更好。不再强加观点给同事。让团队决定，而不是我自己命令他们。一首叫“Kumbiyah”的歌，我们都开始唱唱好吗？Pop是对的。他向我展示了一种方法，所以，我们需要做的就是开始实施。管理层希望我们带头，实现全部代码100%的微测试覆盖。副总已经签发这件事。会有个连续整合服务器来运行它们。我们只需要实施即可。这就是目前的规矩。好运哈。 Jose：（小声说）呃，灵活思维持续不到5分钟。 Junior Joe：（小声说）你认为那会是个新记录吗？代码狗：啊，这不会发生的。我们不会真地那么做吧？那是质量控制的事情啊。 Jose：我不知道。Vanilla Pop之前的工作很出色。你看过这些测试没？代码狗：呃…没有，那是Pop的东西呢。 Junior Joe：我觉得有点眉目了。我支持。 Vanilla Pop：谢谢。架构师：Vanilla Pop和Junior的覆盖率有40%。这是一个小的也是新的单页应用。代码狗也在做TDD，按我的估计，下周我们可实现100%覆盖。我们努力前进吧，伙计们。（时间过去了。）星期二，50%。星期三，60%。星期四，65%。星期五，85%。（继续前进！）星期一90%。架构师：不错！我对代码狗的转变印象深刻。他抓住了TDD的精髓。实际上，他处理的代码块实现了100%的覆盖。我提议给他颁个奖。代码狗：（吃惊了）哇，谢谢！各位开发人员：（拍了拍代码狗的背。） Junior：干得好！ Vanilla：很自豪能认识你。 Jose：对开发者来说很不错了。 Vanilla：他真地这样做到了。 Horst：这是什么情况？我这样滑动屏幕，为什么什么都看不见呢？代码狗：（尴尬的样子）我知道这是什么情况。我会调试并修复的。（关门了） Jose：很奇怪。他的代码是100%覆盖的，却似乎是有错误一样。 Junior：也许是个整合的问题？我审阅了他的代码，并建议他在视图层停止调用I.O.。不大量使用虚构的对象，就没法进行微测试。架构师：代码狗在哪里？我希望它能适当重构一下代码。他的代码过于占用网络带宽了。 Vanilla：他正在处理一些Horst发现的情况。架构师：什么？不可能吧！他的代码有100%的覆盖，看看这些漂亮的代码覆盖报告。 Vanilla：是的，真是个奇迹。Junior，你能向大家展示下他的微测试吗？ Junior：啊，好的！ Vanilla：啊，天呐。图灵的魂魄都会为此震惊的。 Jose：你看看Pop？他不是一个像你这样有个性的开发者。 Junoir：你会认为他的50个微测试什么测试也没做吗？我没有理由不这么想？ Vanilla：这些测试是假的。架构师：这人真不可思议！他只是假装在TDD！ Jose：哦，天呐。他居然这样做了。真是疯狂，搞砸了。天呐，糟糕极了！解说：代码覆盖是分析了解团队的代码自动化进展的好方法。但是如果推进得过快，或是用政策来强制实施，就容易得到虚假的结果。代码覆盖测试工具能让我们了解测试运行的时候哪些代码被执行，但并不能告诉我们自动化的测试是否在起作用。设想一个针对两个数值求和的函数。如果测量代码覆盖时，函数被执行，那么就会有100%的覆盖，但是代码全覆盖并不意味着函数会返回一加一等于二这样的结果。结对编程或者审阅测试代码可以避免造假。如果你要审阅代码，那么检查微测试代码比检查产品代码更重要。微测试规格体现了开发者的意图。如果微测试质量足够好，那么我们可以相信能通过测试的产品代码也是高质量的代码。下一集，TDD和Stack Overflow的专家开发者。

The post 021 代码覆盖丑闻 first appeared on Agile Thoughts.

020 TDD破坏者

康美国

Vanilla Pop：看见了没？在写产品代码前先写一小段测试，一切都会非常完美。 Joe：我不知道，我觉得思维上还不太适应这种向后工作的方式。 Vanilla：但这样操作对你来说是很容易的，对吧？ Joe：那是自然！我已经从这儿学到了这套方法！ Vanilla：（声音听起来不太确定）呃，我们继续结对编程吧。 Joe：你知道吗，我感觉你非常担心的样子。而且，我需要独自工作，不然我会感觉自尊心受伤了。 Vanilla：好的，你都这样说了，那行。（时间一点点过去了，音乐声配上打字的键盘敲击声。在这天结束的时候，关灯时开关发出了响声，门也砰地一声合上了。）第二天 Vanilla：我们看看这些测试吧。 Joe：来吧！你会喜欢这些测试的，我还做了一些调整。 Vanilla：呃？我点击测试按钮的时候，停顿了一下，而且…… Joe：（很自豪地说着）弹出了一个对话框！ Vanilla：呃…… Joe：是的，这个对话框会询问用户希望往测试中传递什么样的疯狂参数。这样，我就可以用一个测试来取代你的4个测试了。 Vanilla：啊……现在测试时，我需要进行互动才能—— Joe：很厉害不是吗？如果需要进行调试，就都全部准备好了！ Vanilla：但是Joe，我并不希望与微测试进行互动。有时候，会有数千个微测试，与它们互动时间上是没法操作的。只需要点击一下，全部的微测试就应该都开始运行了。 Joe：（心碎了）噢！明白了，我来处理吧。（过了一段时间） Vanilla：为什么今天的测试运行报告比昨天少了一些测试呢？ Joe：有些测试不知怎么回事，一直通不过，所以我禁用了一些测试？ Vanilla：等一下！你的意思是，我每天都在增加测试，而你开始工作的头几天，你就直接把测试数量减下去了？ Joe：这么说，是的。你的测试在我调整了代码之后就不起作用了。 Vanilla：是吗？你应该维护已经提交的测试，不然我们就只能原地踏步。 Joe：但是你把测试设计得太不灵活了。你得同意使用对话框，让用户手动输入测试参数的方法，就像我之前实施的那样—— Vanilla：但是Joe，每个微测试都是针对单一的情景设计的，仅仅就一个情景。这样测试才简单易懂，而且容易维护。 Joe：那如果测试没通过，你希望我怎样处置呢？打开对话框，没错对话框很有用！ Vanilla：你需要维护测试，Joe。 Joe：可是我怎样知道哪一部分出了问题呢？是测试还是我的代码？ Vanilla：测试的结果会提醒你有情况。这时你需要调查分析，并做出判断：是自己的代码出了问题，还是测试需要更新。解说：Vanilla Pop正在让组员开始学习TDD。第一个错误，就在于他没有让Joe和他一起结对编程。教育系统培养的开发者习惯自己独立完成任务。而且，很多开发者习惯花费几个小时，自己面对着电脑挣扎，而不愿意与其他同行争执和讨论。这就是我们的本性。这个特性对学习编程其实还是有利的。我们坐在电脑前，独自折腾代码，不断反复，直到变得足够好，最终成功地交付项目。但还有更好的方式。我们已经不再是学员，而在公司上班的好处，就是这里有很多熟练的开发者。开发者一起工作的时候越多，依靠这种社交方式，一个人的技能就会越快地传递给另一个开发者。如果能实施TDD这样的新流程，速度会明显快得多。结对编程是学会技术实践的好办法，一个秘密武器。不然，Vanilla Pop和初级程序员Joe依靠不断反馈的方式学习，会慢得多。下一集，代码狗卷入了一场代码覆盖丑闻。

The post 020 TDD破坏者 first appeared on Agile Thoughts.

018 产品负责人不喜欢测试驱动开发 (TDD)

康美国

联系: 想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/ 018 产品负责人不喜欢测试驱动开发(TDD) 解说：Vanilla Pop向产品负责人讲述团队在做的TDD。 Horst：Vanilla Pop，你好！你的工作真做得挺好，公司里新的明星员工。你对现在的工作怎么考虑的呢？ VPop：设计冲刺（sprint）计划会议在明天。我主要在为我们团队试验性地实施TDD，而且—— Horst：TDD，是和测试有关是吗？ VPop：没错。微测试。我觉得已经可以向整个团队教授如何实施了。才开始的时候会对开发的速度有些影响，但适应了之后速度就会回升。（脑海里的声音：会减缓一些速度？他确定这样能行吗？） Horst：不好意思啊，Jose不是已经在测试这个App了吗？有人在测试，为什么还要另外再测试呢？ VPop：呀，这两种测试是不一样的。Jose所做的是宏测试，有些还是手动的。我们所做的是自动化微测试，只检测代码是否运作正常，而不是产品的功能。（脑海里的声音：测试代码，而不是功能？到底是什么意思哦？） Horst：抱歉，但Jose进行的测试，不也是在测试代码吗？不是吗？ VPop：没错，但这些测试会更详尽地测试一小段代码，代码有没有瑕疵会马上显现出来。 Horst：所以，你的意思是Jose的测试速度很慢？ VPop：其实不是。如果说他的测试速度慢的话，主要是慢在我们寻找有问题的代码这一环节。宏测试并不能帮助我们定位代码的问题在哪里。它只能让我们知道代码有问题。 Horst：但是如果你们花费时间，去编写对代码的测试，而我们已经另外有独立测试的时候，听起来有些过度测试的感觉。我更希望你们编写功能性的代码，而让Jose去处理质量控制。 VPop：并不是这样的。如果所有的开发人员都这样做的话，我们可以确保代码零瑕疵。（脑海里的声音：“零”，他当真说的是零瑕疵吗？他真是疯了！） Horst：如果所有的开发人员都这样做，他们就是在进行重复的多余的测试，而没有把精力花在编写软件的功能上。不行！我们必须保持更快的速度，我们一定要在市场上占据到需要的位置。产品的功能才是重点！（Horst的口号） Every business wants features that keep working and don’t want to pay for bug fixes […]

The post 018 产品负责人不喜欢测试驱动开发 (TDD) first appeared on Agile Thoughts.

017 不受架构师青睐的微测试

康美国

联系: 想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/ 017 不受架构师青睐的微测试欢迎在康美国的微店查看这一集的播客注释：https://weidian.com/s/161651986 解说：Vanilla Pop个人在运用TDD有一些新的突破，他已经开始在代码里实施了。问题是，有些和他一起工作的同事不太理解他的新方法。 (A knock. Architect says “enter”. Door closes) （敲了一下门。架构师说了声“请进“。之后门就关上了。）架构师：我请你来我办公室讨论你的项目。 VPop：哦，是的。有什么没弄好的地方吗？架构师：我正在审阅你提交的代码，觉得有几处情况。你有变动这些代码的项目编号吗？ VPop：是的，当然有。我写在提交代码的注释里了。架构师：但是……你的代码里面到处都是变动呢。啊，你看看，我们有好几个新文件：聚集测试、记录测试和比率测试。你增加了自动测试功能，很漂亮，我很喜欢。但是，项目555439的功能只针对比率文件。你有看过这段代码注释吗？这段注释写得很好，用直白的语言清晰地表达了这些代码的用途。 Pop：那是那是，但—— 架构师：你只需要变动一个文件，但是你动了三个，并且还新增了三个测试。其实我不是抱怨新增的这些测试。但你确实不应该变动其它的代码。 Pop：好的，明白—— 架构师：毕竟变动越多，漏洞就会越多。我的意思是只动记录这个文件。 Pop：在比率执行的时候，会调用记录。记录会打开网络连接，这样会将我的微测试减缓大约10,000倍。架构师：当真如此？ Pop：确实这样。通常记录会与一个服务通讯。所以它会等待网络超时，这样测试会花费超过一分钟，而不是一毫秒。所以我才重写了记录，以便它可以利用缓存的内容。我使用TDD方法来重写了代码，所以会多出一个记录测试文件。架构师：是这样的呢，开始你都没告诉我。那另外的这个类呢？ Pop：它也需要重写—— 架构师：重写？ Pop：没错。这样才能改变代码的设计，又不影响它的行为。只有动了其它的几个类，才能确保将Rater同微测试不应该执行的一些操作分开，比如写入数据库、文件系统或者网络这些。架构师：别忙！意思是你没有写一段整体的系统测试，而是通过额外的代码变动来实现了这一系列微测试，是吗？ VPop：这些微测试执行得很快很快，而且你知道吗，当微测试发现错误时，也就应该知道了有问题的代码大概是在哪里。架构师：但是一个系统测试可以覆盖数千个微测试。我想要的并不是这些……我其实是希望测试整个系统（想想关于系统的那段话）！ […]

The post 017 不受架构师青睐的微测试 first appeared on Agile Thoughts.

016 在不确定性的影响下运行

康美国

联系: 想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/ 016 在不确定性的影响下运行 Narrator: 上一集，Code Dog试图阻止Vanilla Pop尝试TDD。现在，让我们看看这是如何影响香草流行体验TDD的能力 (Office sounds, keys clattering, VPop continues doing TDD, while plagued by voices of uncertainty (use echoey voices like in a Hitchcock film.) VPop: 我要怎么再试一次？这有点难。这个测试库。我想这就是断言的写法。也可能是错的。我怎么知道测试是正确的？ 1 Voice (Code Dogs words are haunting VPop): 首先这个测试倒退太多太多了 VPop: 好的。现在就写产品代码。哈。我花了那么多时间写一个测试。我真的很想花一天的时间来编写产品代码。但这不是TDD对吧？但什么是TDD？什么是正确的测试？生命是什么？我觉得很不舒服！怎么回事？ 2 Voice: 为什么不编写更多的产品代码呢？我是说谁先写测试？ VPop: 好的，好的。集中注意力。(紧张)需要集中注意力。必须集中注意力。只为产品代码写一个存根.。然后运行….那个…测试。还是不行。 VPop: 呃！ (clickt) 点运行测试，做到了！ […]

The post 016 在不确定性的影响下运行 first appeared on Agile Thoughts.

015 TDD恐惧、不确定性和沮丧的扩散

康美国

TDD恐惧、不确定性和沮丧的扩散

The post 015 TDD恐惧、不确定性和沮丧的扩散 first appeared on Agile Thoughts.

014 为什么开发人员不做TDD

康美国

联系: 想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/ 014 为什么开发人员不做TDD 老实说，做TDD并不难，尽管如果你听一位高级开发人员向他的管理层抱怨为什么他们不能在他们的软件上做TDD，你会认为你需要一支天才团队才能成功。但是，很多新开发人员都加快了这一实践，所以这并不是关于聪明或经验丰富的问题。开发人员不采用TDD的原因是多种多样的。我们将在即将播出的剧集中探讨常见的问题： Vanilla pop: “但是如果我们在编写代码时添加测试，我们就会捕获开发人员的意图。” Junior Joe: 你能相信我有5次单元测试吗？ Code-dog: 你什么？你是说写测试*当你构建代码的时候？您的意思是在构建代码之后，并且只有在Sprint结束之前还有一些时间。 Big Pic Architect：”我不想只测试代码，我想测试系统！ Horst the PO: Ja, 我们有办法让你构建更多的功能。我们首先要执行的是“无单元测试”策略！“ Jose Wisenheimer: 你说我应该做单元测试？单元测试？我们不需要任何讨厌的单元测试！没有那些臭人，我们就能得到质量！“ 下一集，Vanilla Pop 和Code Dog 体验TDD FUD 传播

The post 014 为什么开发人员不做TDD first appeared on Agile Thoughts.

055 购买扩展架构，还不如找到问题的解决方案

康美国

看看: LeSS.Works Bas Vodde：我是Bas Vodde，是大规模Scrum或LeSS 架构的“偶然”创建者，在花我大部分的时间来构建产品，编写代码，指导和提供培训。并且在尝试找出奇怪的组织动态，技术问题以及不时地为开源做贡献。就是这样。剩下的大部分时间我就是和家人一起度过的 Dhaval Panchal：Dhaval Panchal，住在在休斯顿，我与组织合作过渡到敏捷。我更喜欢他们没有选择如何做，但更有兴趣解决他们面临的实际问题。我也是一名Scrum培训师，所以我为人们做培训。我喜欢摩托车，如果我在会议中有不齐的注意，很有可能是在想足球。你可以在twitter @DhavalPanchal上找到我 (https://twitter.com/dhavalpanchal) 康：我对Bas有一个问题。有位副总裁正在寻找扩展架构。他对你说，“嘿Bas，我听说你有一个扩展架构。我一直在看这些其他架构。”他浏览了已列出来的名单然后说：“请告诉我，LeSS到底是什么？” Bas：我对这个话题感到不舒服。说“我们需要一个扩展架构”是个错误的起点，因为他已经设计了太多的假设。所以我有可能只会告诉他LeSS是一种通过创建一个更简单的组织来扩展的方式，或者我会告诉他，如果他现在正在寻找扩展架构，那么他可以先选择其中一个并在他想要谈在组织遇到的问题再回来。那时我们将会帮助他解决这道问题。假设你知道所有问题，然后觉得解决方案是在于扩展架构将，这可不是个良好的起点。 Kang：它会在生活中发生吗？ Bas Vodde：不常见。我猜会发生的，但是因为LeSS是一种看似简单的工作方式，很多人会想寻找复杂的东西 – Dhaval Panchal：很复杂的 Bas Vodde： – 这样，他们不会认真地看LeSS，这那没关系。当我与组织合作时，我喜欢帮助他们找出问题，而不一定给他们一个解决方案。就像达瓦尔先前所说的那样，他们需要拥有他们所拥有的问题。他们不应该寻求购买该问题的解决方案。我的搭档Craig Larman喜欢强调的是我们不希望他们租用一个流程。我们需要他们拥有这个过程。对吧？因为如果你租东西，它不是你的，而你并不是那么关心它。对很多人来说，租房和拥有房屋之间的区别在于你对它的关心程度。你给它的护理量是非常不同的。因此，当你开始假设我们需要购买敏捷扩展架构时，你已经假设我们不想拥有它并且将要租用我们将要采用的东西。所以这是一个错误的起点 Dhaval Panchal：没有一家公司在这个世界会因为是最敏捷架构的公司而获得奖项。对你说对吗？您获得的回报是你为客户解决的问题。 Bas：也许对于其中一个架构来说，这将是一个很好的额外业务模式：合规性评估和年度合规性奖励。（笑） Dhaval Panchal：是的。不要让我开始，因为该行业已经有很多团队合规 – […]

The post 055 购买扩展架构，还不如找到问题的解决方案 first appeared on Agile Thoughts.

054 Less团队和产品所有权标签

康美国

看看: LeSS.Works Lancer: Dhaval Panchal开始了关于团队和管理的讨论。Dhaval ：2010年，需要一个移动开发团队和一个网络开发团队。现在，当响应性开始发挥作用时，有两种焦点区域的需求就消失了，因为技术允许他们处理不同类型的设备，但在问题出现之前，这种技术是永远不会出现的。这几乎就像，你知道，向前走了两步，后退了一步，然后一些技术允许你向前移动一点点。对吗？所以，当你看到“大规模是什么意思”的问题时？对我来说，这意味着，“我们能建立起真正帮助我们变得更好的工具吗？”而不是“我怎么能为所有人找到很多工作？”总有一些新技术会让你完全过时。如果您有能力构建您自己的工具，通过构建您自己的工具来构建您自己的改进，那么您就不会依赖外部代理来向您销售该工具。 Dhaval：人们有很大的动机去建立技术工具来解决这个问题。比如，在我合作的一家公司做游戏设计。他们用来进行设计的工具是一个内部工具，这是整个组织中资金最少的工作，而它本应是最大的资金投入，因为它为设计师节省了大量的时间。相反，设计师们正在做他们自己的内部黑客和捷径来克服工具的缺点，他们雇佣了越来越多的设计师来应对他们不得不做很多设计的事实。当问题是你有非常糟糕的工具去做这项工作的时候，增加更多的人到设计部门就永远解决不了这个问题。 Lancer : 大规模化您的企业可以很好地避免这种情况吗？ Bas: 我想你可以简单地把它概括为当你变大的时候，人们逐渐地从团队中拿走越来越多的责任。所以你的团队就没那么负责任了。工具方面只是症状之一。 Lancer: 所以说，如果一个团队变得比其他人更不负责，那么他们就会介入提供一些东西。嗯，也许我们是在说，“嘿，我们在测试平台团队中也要有一个测试平台。”也许这就是这种模式开始乱作一团的原因。 Dhaval: Bobby, 我们在较少课程中讨论过的假设经理，可能是高层管理人员可以实施的最简单的解决方案。当高层看到一个问题时，他们会雇一个经理来处理这个问题，对吗？让经理想办法解决问题，而不是把责任推回团队，这与把责任交给一个人不同，因为Bobby现在就要处理了。对吗？他承担了整个问题的全部责任，而实际上，如果他们回到整个团队，那么五个人可能会找到一个比一个人更好的答案。 Lancer: 在我参与过的一些企业里，人们生活在问题中，他们不想告诉任何人这件事，因为他们担心有人会接手这个问题。把它从他们身边拿走，也许以一种让人更不愉快的方式来解决它。所以我想我明白你的意思了。 Dhaval: 从我培训的经验中，我了解到“我的问题”对我来说比“你的解决方案”更重要，因为它是我的。我对我的问题有自主权，但只要解决方案来自外部，它就不是我的了。因此，我的第一反应是回击而不接受。 Lancer: 我们正在接受的训练中的信息是，我们不会为团队做太多的事情。这么说公平吗？你怎么总结？我们如何让团队拥有更多的所有权？因为我们在做Scrum，团队应该拥有所有权，对吗？敏捷宣言，原则和价值观。团队应该拥有这个过程，但是当你进入一个企业时，这个部分不会发生。 Dhaval: 我喜欢的是，在今天的课结束时，我们讨论的是竞争者分析被添加为另一个产品待办项目，让团队自己去调查，并获得更多的产品所有权的事实，这在某些方面是相反的。Bas 你应该纠正我的错误。 Lancer: 是对于一个产品负责人和很多团队来说，PO的角色并不是那么明确，这意味着PO的角色不是讨论开发人员关于需求的问题，而是到业务中的另一栋大楼，与任何要求需求的人交谈。然后一路回到开发大楼让他们知道。Bos的建议是。。。 Dhaval: 为了将最终用户和客户直接连接到Dev团队，这基本上是业务人员和开发人员的敏捷宣言中的原则，他们必须每天一起工作。 Bas: 然后我们开始解释它，因为业务人员是产品的所有者，这就是事情出了问题的地方。 Lancer: 生意人不应该是最好的产品所有者吗？ Bas: 嗯，由于采用Scrum的困难，业务人员最终不是产品所有者，而其他人得到这份工作是因为很难让真正的业务方面的人参与进来。 Lancer: 如果他们真的参与进来，他们可能还不是一个商人，这意味着他们没有参与到他们以前的角色中去。 Dhaval: 或者，即使你让一个业务人员从业务部门代表成为产品负责人，这个人在多大程度上代表了他们试图引导的其他五十个人的需求。当功能是纠正一两类最终用户遇到的问题时，开发团队最好直接与这些最终用户联系，而不是让这个业务人员解释他们对开发人员说的话。现在，这个PO可以出现在房间里澄清任何语言，因为他们与团队有着更好的工作关系。但是，PO很少能成为管道。 Lancer: 有两种形式的越来越少，基本越来越小。对于这些球队来说，什么是理想的P.O.？ Bas: 对我来说，理想的P.O.是一个能清晰明了并做出决定的人。我最喜欢的一位听众会坐在房间的后面，听每个人讨论一个特定的话题。经过10分钟的争论，他会站起来说：“这就是我们要做的。”他会坐下来，这基本上就是他所做的。他听取了所需的所有意见。然后他明确表示他是产品负责人。他做出了决定。他毫不怀疑地向每个人表明了这个方向，然后他把自己从那次讨论中移开，让它继续下去。因此，组织中的每个人都知道产品的愿景和目标，每当有一个相对高级别的决策需要与产品相关时，他就会在那里做出决定，这样你就不会因为你要去哪里的不确定性而受阻。那是我最喜欢的产品所有者之一。有关LESS的培训、课程和事件的更多信息，请浏览到http://LeSS.works.他们的活动在全球各地发生。 Lancer: 下一集，Bas将告诉我们，购买扩展架构，还不如找到问题的解决方案。你的朋友，康美国

The post 054 Less团队和产品所有权标签 first appeared on Agile Thoughts.

052同样有趣的动力，但在规模上

康美国

Bas Vodde，在湾区，Less的创始人之一
Bas: 巴斯：我们如何获得一个团队的相同乐趣动态，但与多个团队一起工作？因为管理经常会增加太多的东西，官僚主义，以及团队和实际用户之间的距离，所以不再有乐趣了。
康: 所以呢你要试着把有趣的部分放大，就像，你知道，我们可以完成工作。

The post 052同样有趣的动力，但在规模上 first appeared on Agile Thoughts.

051 为什么人们想要大规模Scrum？

康美国

Bas：为什么人们关心缩放？因为，嗯，我想有一个正当的理由，而不是那么合理的理由；有些产品你可能只有当你有一个以上的团队才能建立。你需要弄清楚如何用一个以上的团队来构建产品。为什么许多公司关心缩放如果他们已经有不止一个团队。他们不一定需要它，但你知道，大型产品，由于各种不同的原因而变得更大。一旦他们有了一个以上的团队，他们将需要弄清楚如何与多个团队一起工作。

The post 051 为什么人们想要大规模Scrum？ first appeared on Agile Thoughts.

050 如何引入LeSS系列敏捷框架

康美国

我想你应该弄明白了一点--有很多不同的规模化Scrum框架。如何有效地将Scrum从一个团队扩展到数百个，是业界许多人正在努力解决的一个大问题。

The post 050 如何引入LeSS系列敏捷框架 first appeared on Agile Thoughts.

013 开发意图与圣经

康美国

在古腾堡以前，“圣经”的印刷是由一队和尚用大量手工制作的-甚至是纸和墨水。在一年多的时间里，许多人参与了“单一圣经”的制作。软件开发也是如此。

The post 013 开发意图与圣经 first appeared on Agile Thoughts.

012 TDD的一个案例

康美国

TDD是一个聪明的过程。通过在编写代码之前编写测试，您将最终使用代码来扩展测试。

The post 012 TDD的一个案例 first appeared on Agile Thoughts.

011 老办法是不可持续的

康美国

假设你的工作是编写一个程序，在屏幕上输入单词“知道”。

The post 011 老办法是不可持续的 first appeared on Agile Thoughts.

010 敏捷和TDD玩忽职守

康美国

在过去的二十年中，敏捷革命曾经是很尖锐并且是可选择的，而现在是IT行业大多数团队使用SCRUM和看板的主流。您可能还没有意识到，尽管这两个流行的精简权重框架是有价值的更改。它们根本不涉及如何构造支持频繁交付的代码。

The post 010 敏捷和TDD玩忽职守 first appeared on Agile Thoughts.

009 介绍测试驱动开发系列

康美国

我们的今天也是未来[echo, jetsons sounds or future sounding music] 世界一直前进，但仍然没有飞行汽车[whawha wha..] 。嗯，的确有会飞的汽车但是却没有大规模生产。为什么不量产呢？我们的开发人员和经理是为什么仍然没有这么好的东西的部分原因吗？是lT低质量的跟踪记录的责任吗？我们必须使用补丁，然后安装，并且希望这个新版本不会使事情变得更糟？

The post 009 介绍测试驱动开发系列 first appeared on Agile Thoughts.

008 导体—连续集成

康美国

连续集成坐标的测试金字塔的内容就像交响乐的指挥一样。
回顾金字塔一般有三层：阁楼里充满了UI宏观测试，中间有皮下宏观测试，底层是大量的微观测试。CI的目标是尽可能快地向团队提供有价值的反馈。

The post 008 导体—连续集成 first appeared on Agile Thoughts.

007 尺寸重要

康美国

在这一点上，我希望你得到了为什么在金字塔上层测试过度会导致金字塔跌倒的想法。在上一集里我提到了你可以得到一个测试金字塔工作表。这个工作表可以用来计划如何建立测试项目中最雄伟的金字塔。

The post 007 尺寸重要 first appeared on Agile Thoughts.

006 来自于狮身人面像中的谜语以及就在金字塔中的答案

康美国

狮身人面像是一个神话人物，有人的头和狮子的身体，喜欢提出问题并要求答案。如果你没有正确的回答问题，狮身人面像吃你。在IT行业，最接近狮身人面1像这个角色的质管和上线经理，他们虽然不可能吃你的，但会问一些问题来决定你的产品是否在一个好的状态下。

The post 006 来自于狮身人面像中的谜语以及就在金字塔中的答案 first appeared on Agile Thoughts.

005 皮下测试

康美国

团队发现，只是因为验收标准可能让测试难以维护以及不可靠的UI测试，其中许多实际上不需要通过UI执行，而是在下面的某个子层中。

The post 005 皮下测试 first appeared on Agile Thoughts.

004 金字塔的神秘层

康美国

在网上你就可以浏览到测试自动化金字塔的图像，你会看到宏观测试是在顶部和微观测试在底部，就如协商好的一样。但是位于二者的中间仍隐藏着许多神秘。我全副武装去探索了许多其他公司的自动化金字塔。我了解到，有些人将他们的服务API测试放在这里，有些人将独立的数据库测试或其它一些测试超出了边界，如过程和网络。但是每个人都同意，他们可以在底层保持简单的成千上万的的微观测试但只有少数UI和全栈的测试在玻璃阁楼顶部（所以我们可要看好这个昂贵的LV包了？）。这中间，秘密地空间，就是我们可以把尽可能多的不需用户界面的宏观试验放在这。所以这秘密的一层住着很多形形色色的“皮下”测试。

The post 004 金字塔的神秘层 first appeared on Agile Thoughts.

003 金字塔顶层

康美国

当测试金字塔底部最大的空间大到足以容纳几个足球场和一个怪物卡车，而这个金字塔的顶层只有一个长长的桌子的房间，大屏幕电视、冰箱、迷你吧！

The post 003 金字塔顶层 first appeared on Agile Thoughts.

002 金字塔的基石

康美国

金字塔的最小楼层是顶部，因为它比宽敞的底部窄得多。而顶部只有一个乒乓球桌和电视的空间，底部有一个足球场或两个房间。

The post 002 金字塔的基石 first appeared on Agile Thoughts.

001 坚不可摧的金字塔

康美国 — Wed, 22 Mar 2017 00:00:00 +0000

要有持续的自动化测试，有一种方法就是你需要有二个层次的测试。

The post 001 坚不可摧的金字塔 first appeared on Agile Thoughts.