Listen Now

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

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

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

《黑色敏捷书》简体中文版可在这里购买：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：测试已通过。 …

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

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

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

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

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 传播 ​

看看: 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：是的。不要让我开始，因为该行业已经有很多团队合规 –   Bas Vodde：我们不要暗中泄露这个想法。 （笑）   Dhaval Panchal：是的。 （笑）。组织经常会混淆，因为康是敏捷的，他得到了所有回报，所以我需要做的就是得到康所得的利益，所以我也会有益无害的。法拉利总是有钱人的问题。因为有钱人有法拉利，我也去买法拉利就使我变成有钱人。永远不会那样回事。–   康：太糟糕了！你能买法拉利但你还不够富有，？！ （笑）   Dhaval Panchal：不，你会变得更穷！   康：公司经理如何知道何时出现扩展问题？   Bas Vodde：当他们有不少团队时？   康 :(笑）好吧，这就是答案。   Bas Vodde：你在制定这个问题时遇到了很多麻烦，我猜想一个简单的答案应该有效。从 架构和事物中可以学到很多东西，我希望组织中的人们想要了解他们的问题并想知道他们的问题在过去是如何解决的。他们所做的扩展 架构或品牌或事情并不重要。因此，组织需要不断关注行业内容。他们需要不断地在内部查看他们所遇到的真正问题，而且往往不是报告的问题，因为通常认为“我们的问题是团队效率不够”，但通常情况下还有更多问题，而且往往更多当组织开始解释表面问题而不真正理解真正的问题时，这是错误的。然后他们最终试图找到错误问题的解决方案，使问题复杂化并再次创造新问题而不知道那些来自何处。因为添加到组织往往很容易，而不是真正深入了解动态是什么以及它们有什么问题.   康：人们应该去哪里了解有关LeSS的更多信息？   Bas Vodde：关于LeSS的更多信息的主要地方是LeSS网站Less.Works。 LeSS的大部分信息都在那里。你可以关注它。您可以加入参加一系列课程和活动，如果您愿意，可以联系您的从业者和培训师名单。有一些讨论群。所以你今天参加的培训我认为是LeSS业者的 。虽然我对今天的培训稍微有偏见，但我认为这是一个很好的培训。 9月或10月份在纽约会举办LeSS会议，确切的日期我不确定。 ​ 你要学习敏捷？你喜欢读悬疑书吗？ 我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail

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

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

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

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

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

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

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

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

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