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

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

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

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

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

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

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

Bas Vodde，在湾区，Less的创始人之一

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

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

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

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

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

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

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