Agile Thoughts

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

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

​ 狮身人面像是一个神话人物，有人的头和狮子的身体，喜欢提出问题并要求答案。如果你没有正确的回答问题，狮身人面像吃你。在IT行业，最接近狮身人面1像这个角色的质管和上线经理，他们虽然不可能吃你的，但会问一些问题来决定你的产品是否在一个好的状态下。 The post 006 来自于狮身人面像中的谜语以及就在金字塔中的答案 first appeared on Agile Thoughts.

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

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

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

金字塔的最小楼层是顶部，因为它比宽敞的底部窄得多。而顶部只有一个乒乓球桌和电视的空间，底部有一个足球场或两个房间。 The post 002 金字塔的基石 first appeared on Agile Thoughts.

联系: ​想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。 通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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.

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

联系: ​想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。 通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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.

看看: 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.

看看: 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.

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

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

我想你应该弄明白了一点--有很多不同的规模化Scrum框架。如何有效地将Scrum从一个团队扩展到数百个，是业界许多人正在努力解决的一个大问题。 The post 050 如何引入LeSS系列敏捷框架 first appeared on Agile Thoughts.

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

TDD是一个聪明的过程。通过在编写代码之前编写测试，您将最终使用代码来扩展测试。 The post 012 TDD的一个案例 first appeared on Agile Thoughts.

假设你的工作是编写一个程序，在屏幕上输入单词“知道”。 The post 011 老办法是不可持续的 first appeared on Agile Thoughts.

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

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

最重要的几点： * 开始实践 * 如果某个问题难度太大：暂时保留下来，之后再回过头来重构代码 下面的情况说明你已经熟练起来了： * 一天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.

上一集，我们讨论了如何让团队实施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.

如果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.

《黑色敏捷书》简体中文版可在这里购买：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.

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.

联系: ​想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。 通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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.

联系: ​想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。 通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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.

If you’re listening to this episode while nervously glancing at your laptop wondering if ChatGPT is about to write your performance review, well… you’re in good company. Today we’re diving headfirst into the topic that’s keeping tech workers up at night: AI taking your jobs. And to help us navigate this digital existential crisis, I’ve […] The post 316 Putting Agentic AI and Agile to work Developing Code first appeared on Agile Thoughts.

If you’re listening to this episode while nervously glancing at your laptop wondering if ChatGPT is about to write your performance review, well… you’re in good company. Today we’re diving headfirst into the topic that’s keeping tech workers up at night: AI taking your jobs. And to help us navigate this digital existential crisis, I’ve […] The post 315 AI WILL take our Jobs! with Bryan Finster first appeared on Agile Thoughts.

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

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

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

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.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Mentioned in this episode: killed by google: https://killedbygoogle.com build your own LLM: https://www.freecodecamp.org/news/code-an-llm-from-scratch-theory-to-rlhf/ The post 314 Deflation Economy and Unemployment—Why although unemployment is low you still don’t have a job first appeared on Agile Thoughts.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Mentioned in this episode: killed by google: https://killedbygoogle.com build your own LLM: https://www.freecodecamp.org/news/code-an-llm-from-scratch-theory-to-rlhf/ The post 313 How AI is Disrupting Social Contracts first appeared on Agile Thoughts.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Mentioned in this episode: killed by google: https://killedbygoogle.com build your own LLM: https://www.freecodecamp.org/news/code-an-llm-from-scratch-theory-to-rlhf/ The post 312 AI as a Capital Market first appeared on Agile Thoughts.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Mentioned in this episode: Bullshit Jobs: https://www.amazon.com/Bullshit-Jobs-Theory-David-Graeber/dp/150114331X Lie flat movement: https://en.wikipedia.org/wiki/Tang_ping The post 311 IT jobs, AI, and the Dystopian Gap first appeared on Agile Thoughts.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Robots, Trump, manufacturing: https://youtu.be/kdHOwXw2B2g?si=vAqzrR5yj3ZRS4do Svelte: https://madewithsvelte.com/ui-library The post 310 Paradigm shifts in software development via AI: better software? More of it? Modernization? first appeared on Agile Thoughts.

Connect with Will at: https://bsky.app/profile/wiverson.com https://www.linkedin.com/in/wiverson Mentioned during the series: Will’s Youtube channel: https://changenode.com/ https://www.youtube.com/@ChangeNode Robots, Trump, manufacturing: https://youtu.be/kdHOwXw2B2g?si=vAqzrR5yj3ZRS4do Svelte: https://madewithsvelte.com/ui-library The post 309 Are Software Development jobs GONE FOR GOOD—or just Evolving? first appeared on Agile Thoughts.

Egil Østhus on LinkedIn: https://www.linkedin.com/in/egilconr/ Video of Egil talking about Unleash https://www.youtube.com/watch?v=HVBXxFZGVfc Go here to get started with Unleash: https://www.getunleash.io Four Pillars Excerpt from FeatureOps whitepaper and FeatureOps introduction There are four pillars of FeatureOps: Other Resources: Short introduction on feature flags: https://martinfowler.com/bliki/FeatureFlag.html It’s also important to understand how to use a Keystone Interface: https://martinfowler.com/bliki/KeystoneInterface.html And dark launching a feature: https://martinfowler.com/bliki/DarkLaunching.html Longer […] The post 308 How to get started with Unleash Feature Flags first appeared on Agile Thoughts.

Egil Østhus on LinkedIn: https://www.linkedin.com/in/egilconr/ Video of Egil talking about Unleash https://www.youtube.com/watch?v=HVBXxFZGVfc Go here to get started with Unleash: https://www.getunleash.io Four Pillars Excerpt from FeatureOps whitepaper and FeatureOps introduction There are four pillars of FeatureOps: Other Resources: Short introduction on feature flags: https://martinfowler.com/bliki/FeatureFlag.html It’s also important to understand how to use a Keystone Interface: https://martinfowler.com/bliki/KeystoneInterface.html And dark launching a feature: https://martinfowler.com/bliki/DarkLaunching.html Longer […] The post 307 Indications in product development that suggest you need feature flags first appeared on Agile Thoughts.

Egil Østhus on LinkedIn: https://www.linkedin.com/in/egilconr/ Video of Egil talking about Unleash https://www.youtube.com/watch?v=HVBXxFZGVfc Go here to get started with Unleash: https://www.getunleash.io Four Pillars Excerpt from FeatureOps whitepaper and FeatureOps introduction There are four pillars of FeatureOps: The post 306 How Feature Flags are a form of Technical Debt first appeared on Agile Thoughts.

Egil Østhus on LinkedIn: https://www.linkedin.com/in/egilconr/ Video of Egil talking about Unleash https://www.youtube.com/watch?v=HVBXxFZGVfc Go here to get started with Unleash: https://www.getunleash.io Four Pillars Excerpt from FeatureOps whitepaper and FeatureOps introduction There are four pillars of FeatureOps: The post 305 Feature flags—Fine grain control of Features gives Ops, Business, and Customers new capabilities first appeared on Agile Thoughts.

Egil on LinkedIn: https://www.linkedin.com/in/egilconr/ Video of Egil talking about Unleash https://www.youtube.com/watch?v=HVBXxFZGVfc Go here to get started with Unleash: https://www.getunleash.io The post 304 Unleash, the world’s most popular feature toggle first appeared on Agile Thoughts.

FREE chapters of Beyond Cracking the Coding Interview: https://bctci.co/free-chapters Mike recommends http://Interviewing.io as a great place to practice interviews. The post 303 Attracting Software Development Interviews first appeared on Agile Thoughts.

Mentions NBC News about Columbia student selling code interview cheating tool  https://www.nbcnews.com/tech/tech-news/columbia-university-student-trolls-big-tech-ai-tool-job-applications-rcna198454 Beyond Cracking the Coding Interview: https://www.amazon.com/Beyond-Cracking-Coding-Interview-Successfully/dp/195570600X Free chapters of Beyond Cracking the Coding Interview: https://bctci.co/free-chapters The post 302 Developer resumes are DEAD says Mike Mroczka  first appeared on Agile Thoughts.

Mentions The post 301 Cheating on Coding Interviews first appeared on Agile Thoughts.

Mentions The post 300 Cracking coding interviews with Mike Mroczka first appeared on Agile Thoughts.

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

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