敏捷理念

康美国
  • 5.0 (4)
  • Technology

康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。英文版在(English edition)： http://agilenoir.biz/feed/podcast/agile-thoughts

  1. Feb 11

    059 打破组织变革的幻想

    康美国： 我们在西雅图的 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.

    32 min
  2. 057 Craig Larman：用 LeSS 给企业减肥

    Jan 21

    057 Craig Larman：用 LeSS 给企业减肥

    我们在西雅图地区的 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.

    22 min
  3. 056 Craig Larman 揭秘敏捷宣言的幕后故事

    Jan 3

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

    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.

    14 min

  4. 06/25/2025

    034 Nexus冲刺评审对话

    康： 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.

    10 min

  5. 06/18/2025

    033 Nexus集成团队

    康： 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.

    8 min

  6. 06/04/2025

    032 Nexus 如何制定计划

    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.

    8 min

  7. 05/29/2025

    031 创建 Nexus

    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.

    5 min

  8. 05/14/2025

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

    康美国声音： 理查德·亨道森（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.

    5 min
See All (40)

Ratings & Reviews

5
out of 5
4 Ratings

About

康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。英文版在(English edition)： http://agilenoir.biz/feed/podcast/agile-thoughts

Information

  • Creator
    康美国
  • Years Active
    2017 - 2026
  • Episodes
    40
  • Rating
    Clean
  • Show Website
    敏捷理念