021 代码覆盖丑闻

敏捷理念
敏捷理念
021 代码覆盖丑闻
Loading
/

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的专家开发者。

020 TDD破坏者

敏捷理念
敏捷理念
020 TDD破坏者
Loading
/

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依靠不断反馈的方式学习，会慢得多。 下一集，代码狗卷入了一场代码覆盖丑闻。

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

敏捷理念
敏捷理念
018 产品负责人不喜欢测试驱动开发 (TDD)
Loading
/

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

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

敏捷理念
敏捷理念
017 不受架构师青睐的微测试
Loading
/

联系: ​想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。 通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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：这些微测试执行得很快很快，而且你知道吗，当微测试发现错误时，也就应该知道了有问题的代码大概是在哪里。   架构师：但是一个系统测试可以覆盖数千个微测试。我想要的并不是这些……我其实是希望测试整个系统（想想关于系统的那段话）！ …

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

敏捷理念
敏捷理念
016 在不确定性的影响下运行
Loading
/

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

014 为什么开发人员不做TDD

敏捷理念
敏捷理念
014 为什么开发人员不做TDD
Loading
/

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

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

敏捷理念
敏捷理念
055 购买扩展架构，还不如找到问题的解决方案
Loading
/

看看: 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：是的。不要让我开始，因为该行业已经有很多团队合规 –   …

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

敏捷理念
敏捷理念
054 Less团队和产品所有权标签
Loading
/

看看: 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将告诉我们， 购买扩展架构，还不如找到问题的解决方案。 ​ 你的朋友， 康美国​