Raygun的教育系列-采访General UI的Jason Thane的敏捷经验。
欢迎来到Raygun的教育系列。
Raygun每个月的目标是为您提供可行的见解，以使用最新的工具和方法来生产更高质量的软件。
敏捷
在这个免费的网络研讨会中，Raygun的联合创始人John-Daniel Trask与General UI的首席执行官Jason Thane和开发总监Kevin Klinemeier进行了一次对话，探讨了实施敏捷后实践如何使他们的团队更平滑，更高效的生产，同时节省了时间和金钱–特别是在生产中。
“后敏捷是指您的团队拥有一组敏捷工具，并且确切地知道何时使用它们……何时不使用”
Jason Thane-通用用户界面首席执行官
尽管敏捷实践是软件公司中最常用的管理框架，但许多人仍在努力将其发展为适应性强的框架。 很难为您的团队在工具和系统之间找到适当的平衡。
对于我们来说幸运的是，Jason详细介绍了一般UI使用哪些系统来每年为成千上万的客户持续生产高质量的软件。
在此网络研讨会中，您将学到：
- 通用UI如何通过敏捷后期实践制作出始终如一的高质量软件
- 实施敏捷后实践如何显着改善常规UI的输出质量以及您如何做到这一点（同时也使您的团队感到高兴）
- 当冲刺不一定是所有团队的最有效实践时
- 通用用户界面使用哪些工具来安排工作人员并确定其优先级
- 为什么软件的质量取决于团队的质量（以及亚里士多德对团队动力的评价）
- 如何将对等编程出售给管理层和您的客户
在此处观看完整的网络研讨会
在Soundcloud上收听：
网络研讨会的资源列表：
- Joy Inc.：http://amzn.to/1VTk7it
- Nordstrom卓越客户服务方式：http：//amzn.to/1VTk0nb
- 极限编程说明：http：//amzn.to/244bgyP
- 丰田Kata：http：//amzn.to/1N0M0C2
进一步了解 Raygun
完整转录：
John-Daniel：很好。 大家好。 我是John-Daniel Trask。 Raygun的联合创始人兼首席执行官。 我也欢迎您参加我们的第一个Raygun Education Series网络研讨会。 我和General UI的Jason和Kevin在一起。
凯文 ：你好。
约翰丹尼尔（John-Daniel） ：他们是我们西雅图的朋友。 所以我遇到了杰森，可能是什么？ 几个月前，现在。 因为我一直从西雅图扩展到澳大利亚。 我们的总部位于新西兰。 我们正在扩展到西雅图。 因此，我们一直在一起度过一些时间。
我有机会在这里参观了杰森的办公室。 并了解他们正在做的一些出色工作以及他们如何进行敏捷实践。 我想到他们正在做一些非常有趣的事情。 而且，我们的一些客户可能会发现从中学习确实很有趣。
因此，今天的格式将是Jason和Kevin之间的对话，谈论发生了什么。 如有任何疑问，请在边栏中写下。 您可能会听到我在后台对他们大喊大叫。 但是，否则请享用。 我们将尝试将其保持在30分钟以内。 但是，如果有很多问题，我们可能会再谈一点。 非常感谢你。
杰森：谢谢，京东。 我是Jason Thane。 我是General UI的创始人兼首席执行官。 这是凯文·克莱梅尔。 他是我们的开发总监。
而且，我们在这里谈论一个有争议的术语：敏捷后。 这并不是说我们已经在沐浴水中投入了敏捷性。 而是我们要谈论如何做，如何做以及为什么要在学会敏捷后再做这些事情。 当我说“敏捷”时，我是指作为形容词的敏捷，而不是敏捷–一个专有名词。 这种区别很重要，因为我们发现，在我们的工作中，我们遇到了许多客户和许多不同的开发团队，他们开始学习敏捷时，便将其视为一套习惯。 他们认为这是一种邪教活动，必须执行并遵守非常严格和有条理的规则。 而且它变得非常仪式化。
我想讲一个故事，以此为隐喻。 那就是第二次世界大战之后，美国在某些岛上建造了简易机场。 在这些岛屿上，当地人对战争期间来自西方世界的所有货物感到惊讶。 他们会看到飞机降落，并且会看到货物出来。 这批货物将具有前所未有的惊人技术奇迹。
然后战争结束了。 飞机停下来了。 但是飞机跑道仍然在那里。 因此，当地人实际上感到恐慌。 他们说：“好吧，我们必须取回这些好东西。 我们会做什么？”
因此，他们实际上会组织一场邪教，试图召回飞机。 因此，他们将用竹棍建造一座塔，并戴上这样的椰子耳机和波浪警棍，希望飞机能到达。 但是，事实上，飞机从未这样做过。 那是因为这些习惯是在没有真正了解飞机是什么，飞机来自何处，为什么的情况下进行的？
因此，我们认为可以这样实践敏捷。 这样，有些人会通过诸如筹划扑克之类的奇怪事情来追踪[听不清00:03:53]回顾的动向。 围绕敏捷开发了各种各样的仪式，并赋予了不同的名称，无论是好是坏。 事实是，如果您不了解为什么这些仪式存在并且真的不知道如何使用它们，那么这些仪式就毫无价值。
因此，我们今天要谈论的是我们追求“敏捷”的形容词所处的位置。 以及我们已经实施的一些工具。 我们没有将惯例视为仪式，而是将其视为工具。 每个工具都是一种优化。 因此，每种工具都适用于某些情况。 并在其他情况下非常不合适。 凯文，这是一个公平的介绍吗？
凯文 ：是的，似乎有点。
杰森（Jason） ：凯文（Kevin）实际上是我们的……他在所有这些方面都比我先进得多。 如果我没有说什么与凯文大相径庭的事情，我会为此感到高兴的。 这样您就可以给我反馈。
凯文（Kevin），您会说我们在通用UI上当前的敏捷实践状态是什么？ 我们针对什么进行了优化？ 我们没有针对什么进行优化？ 事情进展如何？
凯文：团队拥有的一些价值观是，不要创造知识之塔。 那是我们谈论的第一件事。 作为一家咨询公司，我们从事许多不同的项目，并且与客户交谈，以防止遇到无法获得项目进展的情况，因为知道该项目的人病了或刚好您想重新启动另一个项目时。
因此，需要进行沟通，因此您没有一个人拥有该信息，因此无法推动我们的许多实践。 这推动了我们所看到的结对编程……如果您来到我们的办公室，您会发现这种情况经常发生。 我确保至少有两个人知道发生了什么，并促使我们围绕轮换对进行练习。 因此，您不必每天与同一个人结对，并分享这些做法。
然后，这还有许多其他好处，那就是当您与某人配对时。 您不仅共享项目知识，而且共享工程实践。 因此，我会听到很多人在团队中谈论他们非常喜欢这种新的测试工具，或者只是喜欢这种编程技术的事情。 您可以观察到整个团队之间的病毒传播。 其中，如果Drew是提出该建议的人，那么本周与Drew结对的人们就知道这一点。 他们正在与下一个人，下一个人和下一个人共享它。 从沟通的角度来看，这最终是真正有效的，因为您可以在真实的代码中看到它。 而且我不必停止团队讨论此事的任何情况，只需花30分钟就可以发表演讲。 它只是发生了，它是人们参加工作并完成工作的结果而得到共享。
Jason ：因此，作为一种敏捷实践，应该将配对作为开发团队的实践。 该优化的目的是什么？ 最佳化不是什么？
凯文 ：是的。 是的 知识共享平等绝对是优化的目标。 您有两个人在看代码，谈论高质量的知识共享。
我将告诉您我进入同级编程的方式。 很久以前，我曾为这个家伙工作。 他要我尝试一下，我坚决反对。 我认为这是有史以来最糟糕的想法。 而且我不知道……顺便说一下，这是马特，您认识的人。
Jason ：适用于常规UI。
凯文：我从大学就认识他。 然后他学习了电机工程，而我学习了计算机科学的高级艺术，对吗？ 所以他来到我身边说：“我认为我们应该做这个对等编程的事情。”
我对他说……我一点都不为此感到骄傲。 我很幸运，他仍然是我的朋友。 我说：“好吧，如果您需要编程方面的帮助，我会帮助您。 但是我认为我不需要[听不清00:08:14]。”他说，“好吧。 是的 当然。 让我们尝试一下。”
在围绕同位编程的科学实验中，有趣的另一部分是，在这种环境下，我们正在与100％的代码审查进行合作。 因此，我们编写的每一行代码都必须经过相当正式的代码审查。 并不是说：“我会给您的代码盖章。 你给我盖章，”
那是，“让我们有四到五个人被要求发表某种评论并聚集在一起并审查该代码。”我并不是每天都讨厌它。 我肯定有一些问题。 我可以看到……这是我当时大学毕业后的第二份工作。 我可以看到它肯定在改善我的代码质量。 但是，天哪，花很长时间才能完成该代码审查过程。 其中很多内容是：“您现在超过了40个字符的限制。”显然，人们试图找到要说的东西，以便可以说出自己的话。
但是，另一件事是，这几乎是令人沮丧的，如果我再花45分钟或一个小时的时间看相同的代码，我也可以想到这些东西。功能齐全。
然后，当我离开代码审查时，我留下了所有这些更改以使代码起作用。 除了这些设计更改之外，这完全可以投入生产。 在完成这些更改之前，我花了三到四天的时间编写代码。 90％的时间里，这些东西无处可去。 这些是不错的建议，下次我会尽量记住。 而且只是没有发生。
所以现在我开始对等编程。 而且，虽然我们彼此很熟，但是当我们不得不弄清楚如何彼此合作以及如何再次交流时，最明显的是。 但是，一旦我们深入了解了这一点，当我进行代码审查时，我就会真正看到好处。 因此，当我们进行代码审查时，我们的团队有史以来第一次说：“我不知道。 看起来不错。 我们真的有时间将这种质量纳入代码中，因为我们没有在其之上构建任何东西。 一个人很容易……这只是经典的配对。 但这就是我们所看到的。 一个人会在想，花括号和分号在哪里？ 另一个人，[听不清00:10:41]在想：“我们在代码审查中经常听到什么？”或者，当《四人帮》一书出版时，或者那些更高的设计质量……
杰森 ：是的。 我向客户做了很多解释，我们为什么配对，为什么配对很重要，为什么效率更高，为什么更好地利用他们的钱？
当您通过一个建筑工地时，看到三个家伙在挖一个整体时，其中一些人可能会喜欢它并与之进行比较。 一个家伙在挖。 然后另外两个靠着铲子。
而且，实际上，这并不是一个不好的比较，因为当您是导航员而不是驾驶员时，会发生一种智力休息。 因此，配对是人的驾驶员。 他们准备好使用钥匙了。 另一个人是导航员。
事实证明，作为驱动程序，您实际上必须投入大量的计算资源和自己的大脑，才能将代码提供给飞行员，带钥匙的人，以及对格式进行很好的格式化。 您可以利用剩下的能力来考虑设计，体系结构和用户体验。 您可以考虑质量可测试性，在开发过程中进行测试。 您可以考虑美学。 您还可以并且应该做所有其他事情来使产品更好。 但这确实是一个难得的人，通常是一个数十年来对软件开发如此自动化的人，以至于他们在处理较低代码级别时可以想到较高的级别。
因此，配对实际上允许另一个大脑坐在那里思考其他事情。 其中一些是高级的。 就像我提到的那样，静态，设计，体系结构和用户体验。
其他事情则更为实用。 例如，边缘情况。 您是否想过此函数传递null时会发生什么？ 如果收到某些输入，您应该编写哪些测试来记录应用程序的某些行为？ 因此，这以一种更具体的方式表现出来，那就是，许多小错误都是在行内，线对中修复的，而不是被检入到存储库中。 稍后，将在哪里编译，构建，部署和发现它们。 然后，记录在案。 输入错误跟踪器，然后确定优先级，然后进行修复，然后进行验证，然后构建，然后再次部署。 这是一个极其低效的过程。 和…
John-Daniel： Jason，我有一款可以为您提供帮助的产品。
杰森：好的。 你必须要有Raygun。 好吧，我们真的发现配对是不可思议的[听不清00:13:30]。 我认为，所有开发人员都经历过的一些项目到结束时会出现很长的bug尾巴。 当您成对工作时，您会发现错误的尾巴要短得多，因为它们是在线固定的。
这是主要好处之一。 因此，软件项目管理的很多痛苦都涉及到高的错误打开率。 您最终尝试确定何时将[听不清00:14:06]逼近为零。 也许，这是非常量化的。 因此，配对可以减少并消除产品管理方面的许多风险。
因此，这是我们发现与客户相当相关的一项优化。 现在，它与我们所有的客户都不相关。 目前，我们正在大多数客户上使用它。 但不是所有的。 和任何敏捷实践一样。 说一种尺寸适合所有尺寸是不合适的。 如果有一个适合所有人的尺码，那将是每个人都这样做的方式。 并且将达成完全一致。 但是我们看到的是，对于哪种类型的敏捷有效，尚无共识。
原因是所有敏捷实践都是优化。 因此，我们称自己为“敏捷后”的原因是，我们要谈论的是不学习敏捷工具。 学习如何有一个强大的过程或[听不清00:15:05]过程，进行极端编程。
我们想说：“一旦您学会了如何做这些事情。 而且从根本上讲，您已经了解了为什么要做这些事情。 然后您可以练习。”当您练习时，您……而不仅仅是个人。 我的意思是，您和您的团队可以选择最适合这种情况的优化。 在那种情况下，这是一个不错的环境，涉及到您的客户，您的用户，谁在付款？ 您的管理结构和组织文化。 所有这些因素都是开发团队非常重要的投入，他们意识到并不断选择将最佳敏捷实践和优化应用于其开发路径。 这就是为什么后敏捷。
不是说我们要放弃敏捷。 我们只是说，这不是成功的灵丹妙药。 相反，您必须明智地使用一些工具。 您确实必须在充分了解它们存在的原因的情况下使用它们。
约翰·丹尼尔（John-Daniel） ：您能说根本没有[听不清00:16:16]吗？ 银弹的反面，如果愿意的话？
杰森（Jason）：我们已经摆脱了有序的[听不清00:16:34]流程。 我们从[听不清00:16:30]中汲取了想法，并将其应用。 但是，实际上，这些都是[听不清00:16:44]。
对于像我们这样的公司，精神是一种行之有效的优化。 原因是资源分配。 我们是一家顾问公司，一次服务10个客户。 因此，如果我们有冲刺，很难正确分配资源，因为圣徒的末日永远不会加在一起。 而且，您不能让所有客户都陷入一个一致的冲刺周期中……这真的很好。 我们尝试过，但无法做到。 因此，冲刺是对某些人非常有用的优化的完美示例。 如果您在整体组织中工作，或者您只有一个产品团队。 也许您有多个，但您只需要担心在一定时期内该团队的资源分配。
凯文：或者，如果您有一些合法的外部因素迫使您进入节奏。 因此，当我开始时，我做了[听不清00:17:38]。 合法的外部因素是发行是一场噩梦，历时四天。 而且我们不想经常这样做。 而且我们无法……我们拥有了所有这些活动部件。 因此，这迫使我们形成某种节奏，我们努力将其降低到两个星期而不是两个月。
但是，敏捷的发展方向是：“好的，了解什么是持续集成。 了解一下DevOps是什么，以及这种体验的自动化。”这使无法进行频繁发布的痛苦变得显而易见。 然后我们解决了。 而且我们不再需要外部时间表。
在进行一般UI咨询之前，我曾做过一些咨询，与曾遇到过其他外部节奏的客户一起工作。 就像他们有一个非常大的信用卡处理器一起使用，我确定您的钱包里有东西。 而且，出于法律原因，他们的原因可能就是我所说的人不知道的原因。 但是，无论如何，它是不可更改的，因此也可以定为一成不变。 但是他们只能在一定期限内发布，因为根据合同，他们必须给其他团队一些时间来应对这些问题。 现在，无论您是否认为这是一个好的计划，这都是他们为冲刺量身定制的情况。 有道理。
贾森（Jason） ：因此，我们不是在进行冲刺，而是在进行的工作，是指消除进行中的工作并衡量我们的进度。 那是[听不清00:19:10]风格。 也并不是说我们已经实现了正统的[听不清00:19:14]流程。 我们已经从该过程中获取了一些有用的东西。
一个很好的解释方式，而且每个人都对立口站很熟悉，对吗？ 站立是一种敏捷实践。 这是团队的工具。 站起来对于交流的团队很有用。 如果您的团队不说话，并且每天都有站立训练。 人们谈论他们昨天所做的事情。 他们谈论他们今天要做什么。 而您限制它的范围和时间，您实际上会站起来。 这些都是敏捷实践。
对于没有交流的团队来说，这可能是一个福音。 该团队一旦进行了交流并形成了凝胶，则可能不再需要站立式。 实际上，站立者可以成为他们选择拥有或不拥有的东西。 我认为我们大多数团队现在都有站立训练。 但是我们有一些团队没有。 没关系。
一旦您的团队真正具有自我组织能力，自我意识并能够自我优化，他们就可以做出选择。 而且我们不需要……自上而下地说，我们不必说他们必须以一种或另一种方式做事。 只要我们建立了这种信任。
只是，坚持我们的议程，我们使用了其他一些团队实践。 因此，我们谈到了一些正在进行的限制工作。 在开发过程中，我们做了很多测试。 这是我们拥有的非常重要的基本价值。 开发期间的测试也不是一种适用于所有情况的优化。
如果您要构建一个一次性演示，那么TDD来获得它可能不是明智的投资。 但是，如果您要构建某些东西，则需要持续任何时间。 或者，即使是可能会变成产品的演示，您也应该TDD。 然后，它可以容忍变化，它将是可持续的产品。
另一个优化，这是我经常选择的优化。 是，开放式沟通和配对，而不是我们所谓的穴居人编程。 因此，我认为默认模式……实际上并非如此。
如果您查看计算机科学专业的学生，将会有很多穴居人程序员从事他们的作业，然后上交作业。然后，我们发现很多配对正在发生。 配对的发生通常是因为两个男人是朋友，或者两个女孩是朋友……不是为了使性别偏见。 但是其中一个将一直指导另一个。 您最终将在那对中共享很多知识。 这就是许多计算机科学专业学生以及许多计算机实验室的工作方式。 也许这最初是因为计算机价格昂贵，而我们没有足够的计算机，但是我们是成对组织的。 但是，我认为，这比这更根本。
我认为实际上配对是人类共同工作的一种非常自然的状态。 配对时，我们与语音盒进行通信，并使用大脑中的言语电路来解决问题。 人们在养育子女时通过说话[听不清00:22:33]解决问题。 这就是我与业务伙伴Jason Greer所做的事情。 我们通过谈论正在解决的问题来制定决策。 而且我真的认为，最优化或不太自然的做法是穴居人程序员。
穴居人程序员就是这样说的：“好吧，我明白了。 我脑子里有了这个主意。 我要去洞穴里，下周再回来，这将完成。 这将是完美的。”
好吧，通常我们看到的是几件事。 第一，他们提出的想法与他们进入时所说的有所不同。或者，我们对它的理解有所不同，因为想法的交流并不完美。 这并不完美……有点不透明。
另一个是，也许他们根本不出来。 我们再也见不到他们。 但我认为，非常值得注意的是，当软件开发与周围的世界脱节时，它往往会朝着原本不应该的方向发展。 软件是一件非常复杂的事情。 它与周围的世界有着复杂的整合面。 正确实现集成的过程就是软件开发的过程。 和你必须沟通。 软件本身是一种活跃的交流。 而且，如果交流是潮流，并且与外界联系在一起，那么它比仅在一个人和计算机之间进行交流要优越得多。
那么我们从中看到了什么改进？ 我认为这真的很棒。 使我们的团队和我们的文化围绕交流而进行，并进行高带宽，高完整性的交流。 团队价值，我们已经看到了各种好处。 最重要的指标不仅是产出满足要求的质量。 但是，信任在我们的团队中共享。
因此，如果您整天与人结对，就会学会爱他们，除非您不这样做。 从管理的角度来看，当您不这样做时，当人们不相处时，我们会迅速发现，并且当团队不团结时我们会立即知道。 我们可以解决这些问题。 第一，也许我们可以进行重新分配，以使不相处的人不必整天坐在一起。 但是，当您坐在某个人旁边并一直保持真正的交流时，您往往会与同事融为一体。 这就是信任的源泉，也成为产品完整性的源泉。
凯文：这导致了有用地不同意的能力。 这是很多事情。 世界上有不止一种口味的冰淇淋，对吗？ 并非每个问题都有一个答案。 人们可能会不同意。 最好的对话……在过去的几个月中，我看到了这种转变。 是的，最好的对话是当我们以解决方案结束时，没人知道它是谁的解决方案，因为这只是每个人的解决方案。
我们不是在谈论我的答案，也不是在谈论杰克与杰森的答案。 就是这样，“好吧，让我们把它拿回来。 我们正在讨论优缺点，而我出于原本不是我的想法提出了建议。 而且它演变成比任何一种解决方案都更好的第三件事。 我们有一个答案。 那真的很强大。 也是当人们尊重同龄人时。 并说：“我了解。 我可以看到已经达成共识的小组，我们将聚在一起，提出不符合我意愿的解决方案，我想退出。 我还是不同意，”因为我是工程师，对吗？ “我的观点没有改变，但我会与小组保持一致，我将以我们作为小组同意的方式来建立它。 不是我要构建它的方式。 但这就是我们所说的。”这非常强大。 为了能够与您不同意的人相处。 但是您可以看到，这就是达成共识的方向。
杰森 ：是的。 我们相信团队等于软件。 软件的质量就是团队的素质。 特别是完整性和带宽以及团队的沟通，这就是为什么[听不清00:27:19]，对吗？ 因为有些人错误地优化了它们，然后将其取消。 远程团队彼此信任，彼此合作，对吗？ 但这很难。
在我们继续讨论这个问题之前，我确实要提及。 我想提到另一项非常关键的关键实践。 在常规用户界面上，这非常关键。 是，追溯。 因此，复古是我们作为团队取得进步的机会。 在谈论您在上一个团队中的表现时，进展如何？ 而且进展不顺利。 这是建立信任的巨大机会。 但这也是前进而不是倒退的机会。 因此，我们复古的目标是前进。 在前进的地方放一根棍子。 然后尝试一些将起作用或不起作用的新实验。 但是在下一个回顾中，您将确定它们是否起作用。 而让您向前迈进的事情，则保持不变。 没让你前进的东西就丢掉了。 持续改进和逐步改进的过程非常非常重要，也非常关键。 我还认为，这是一个非常深刻的想法，适用于软件开发以外的许多行业。
John-Daniel ：我们确实有一些问题要解决。 这是Tyler Frye [SP]的人之一。 是，您能否举一个实际示例说明组织中对等编程的外观？
杰森：好问题。 而且我实际上可以将其放在白板上。 好吧，也许我们不应该真正说出来，对吗？ 因此，我们实际上使用的是Mac Pro塔筒。 它们看起来很酷而且非常快，这很棒。 他们有两个雷电显示屏。 因此，我们并排镜像了雷电显示器。 然后，两个键盘和两个鼠标。
现在，键盘和鼠标是USB。 它们插入Mac Pro背面的USB端口。 而且一次只能移动一只鼠标。 我的意思是，您可以尝试，但如果您尝试同时移动它们两者，那么您会战斗。 一次只能输入一个人，否则会造成混乱。 关键不是要在输入设备上进行争夺。 关键是，您可以非常自然地从一个人换到另一个人，而不必屈肘于某人并抓住键盘。 整个工作日无需弯曲脖子即可坐下。 那真是太糟糕了。 因此，我们允许人们……人们被设置为坐直并看着他们的显示器。 但是，实际上，输入设备将进入显示器中的同一台计算机，因此这是所有这些的镜像。
凯文 ：那是有点紧张了吧？ 因为您有这两个角色。 我不知道您是否曾经听过。 但是配对中的两个角色是驱动程序和导航程序。 每个人都知道如何开车，因为那是您要做的一切。 导航员角色是人们必须学习的方法。 拥有一台计算机，并且您无法在另一人打字时移动鼠标和打字，这使您不必成为成双成对的程序员，这就是Kevin Klinemeier的术语。 但是，成双的程序员是两个彼此接近的人。 我在笔记本电脑上，杰森有笔记本电脑。 我们俩都在同一个项目上。
那不是我们想要的。 我们要强迫其他人不要在自己不愿意输入编辑器的范围内。 再想想更高层次的东西，对吗？ 有新的语言功能吗？ 或者，下一个测试是什么？ 并仔细检查一下成为一名优秀导航员的清单。 这就是建立力量的原因。
约翰-丹尼尔 ：酷。 在这里还有另一个问题。 我为一家拥有20名开发人员的中型非营利组织工作。 我们类似于咨询公司，因为我们有100个左右的部门。 因此，我们仍在尝试找出如何为项目分配资源。 您能否谈谈您使用什么工具和策略来安排工作人员并确定其优先级？ 此外，当管理层可能只是将其视为将我们的容量减少了一半时，关于如何帮助证明对等编程的任何建议？
杰森：凯文，我想回答第二个。 您要第一个去吗？
凯文 ：好的。 这里没有魔术子弹。 您所拥有的是有限的……正如您所知，我敢肯定您一直都在感受到这种痛苦。 您的资源有限且请求无限制。 任何工具都会使这种痛苦变得显而易见。 而且与软件过程的关系可能更少。 可能与做出此决定的管理者和领导者的挑战有关。 我们该如何决定何时要做十件事，而我们只能做五件事？ 您必须先了解有关组织的知识，然后才能使用工具。 如果您遇到的情况是一种工具，它可能会帮助您将其显示出来……我们什至不知道我们想做多少事情，也不知道他们要花费多长时间。 然后该工具……可能只是列出SaaS的工具，并允许您的开发人员估计它们将为您提供帮助。
我猜想，作为非营利组织，您可能不在同一个房间。 但是，如果您愿意，我总是从3M解决方案开始。 这是粘滞便笺和白板，非常简单但更重要-非常非常灵活。 我们在内部使用JIRA。 JIRA是一种功能强大的地板蜡和甜点浇头。 它做了很多事情。
每当我建立一个新的JIRA项目时，我要做的第一件事就是关闭50％的功能，因为我们实际上并未使用这些功能。 因此，有时使用某种工具确实会造成混淆。 只需写一张纸就可以说：“这就是问题。 而且，要花多长时间？”我将在对这个小组很重要的那些人上画一颗星。 和那个小组的一个圈子。 而且，仅凭一己之力就能弄清楚正在发生的事情可能是一种前进的道路。
杰森 ：我想再加一点点我们的秘密调味料。 就是说，当涉及到项目的实际资源分配时，我们不会将人员分配给项目。 我们分配要完成的项目。 而且，在大多数情况下，我们在配对站分配项目。 但是，实际上，我们让人们用脚投票，并着手进行他们最擅长的项目，…不一定是最熟练的，而是最感兴趣的项目。因此，通常我们真正希望看到的是知道很多东西的人有关客户，项目，技术或所有方面的信息。 然后有人正在学习所有这些。 因为它增加了知识的传播。
但是，从根本上说，资源分配的决定权取决于成对的开发人员。 团队对此进行了整理。 因此，我们永远不会遗憾地说：“您是最后一个站着的人。 你为什么不去做那件事？”也许那不合适。 因此，团队会努力解决。 您问题的第二部分…
约翰·戴妮（ John-Danie l）：[听不清00:34:55]泰勒（Tyler）也提出了类似的问题。 好吧，我认为您的答案可能重叠。 他问的是：当从非对等编程转换为对等编程时，您是否会鼓励大量的开发人员潜在地实现相同的目标？ 我们是由六个开发人员组成的小组。
因此，我认为这可能与“如何将其出售给管理层？”紧密相关。
杰森 ：是的。 出售给管理人员，并谈论经济学的残酷科学。 在短期内，当您采用对等编程时，您可能不会很快迷失方向，直到您的团队掌握了沟通方式和风格。
实际上，在最初的五个星期中，我们已经注意到有一个模式，即有五个星期的挫败感。 然后，在那之后，对于开发人员来说，这是非常积极的。
在向管理层出售对等程序时，您要问的问题是，您是否要构建可持续的软件产品。 如果您要构建一个由拥有该产品知识并真正拥有一个团队的团队来拥有，策划和维护的产品，那么这是一个更好的选择。 因为，当您配对时，如果一个人去度假或中彩票，或者……我们都知道开发人员会发生很多事情。 他们出于某种原因离开了团队。 您已经了解了构建的内容。 您没有[音频不清晰00:35:38]的知识，不知道有关代码库的所有知识。 然后穿过马路，再也不会回来，然后您的产品随该开发人员一起死亡。
但是，可衡量的和务实的优势也是巨大的。 而且我们有很多研究……实际上，我认为应该在资产中包括这些白皮书。 网络研讨会结束后，也许我们可以发布它们。
但是，显示了对等编程的经济优势。 它从共享的工程实践，更短的启动时间，在线错误修复和缺陷修复扩展而来。 总体而言，产品质量降低了对后续固定版本的需求。
凯文：您还需要努力与质量保证进行互动。 是的，如果您要与一个预期会进行一段时间开发的团队打交道。 然后有一段时间的质量保证，您只需要在那个时期内进行测试即可。 那不是我们的运作方式。 但是您可能会发现，这段软件开发的时间会更长。 因此，不要误以为是度量错误的问题。
因为，如果像Jason所说的那样，您已经捕获了几乎所有的错误，那么延长软件开发的时间就可以了。 我不会告诉你“所有人”。每个人都知道这是谎言。 但是您已经捕获了该期间的几乎所有错误。 而且它使质量保证仅是橡皮图章，然后这真的很强大。
杰森 ：一个很好的解释方式。 这是我有时会依赖的隐喻。 是，从A点到B点的安全性，这就是您的开发路径。 假设每个人都知道B点在哪里，那是不可能的。 但是您要从A点转到B点。
使用穴居开发人员，您可能会更快。 但是您并没有走很直接的路。 因此，您的路径更长。 使用对等编程，开发人员数量相同。 您的步伐更加平稳。 但是，管理风险要容易得多。 质量管理要容易得多。 当您到达B点时，您便拥有了一个可持续的解决方案，该解决方案可以持续存在并作为软件产品存在。 六个月后，它不会在葡萄树上死亡。 遗憾的是，这是软件行业所做的巨大工作的命运。
约翰丹尼尔 ：我们还有大卫的最后一个问题。 凯文（Kevin）早先谈到了团队成员的观点并提出了这个想法。 [听不清00:39:19]对于那些始终坚持要当老师而不是学生的人，您怎么办？ 谁在团队中工作，但好像他们是团队的主人？
凯文 ：这是一个很好的问题。 我将在这里思考片刻。 您可以做几件事。 第一，他们必须了解这是一个问题。 有几种解决方法。 我通常会说的是：“在大多数软件开发团队中，领域的重头戏是同行的尊敬。”在我目前担任总监的角色中，我深知这一点。
在某种程度上，没有人关心导演的想法。 仅当您要使用一些大的锤子动作（例如让人放松）之类的东西时。 剩下的时间里，没人在乎导演的想法。 他们想知道他们在项目中所尊重的人是否在同行中相互尊重。 因此，诸如360条评论之类的某种审阅过程可以使您每个人都共享有关其他人的反馈，从而开始获得进行更改的可见性。
如果你想去希腊哲学。 如果您像我一样阅读过亚里斯多德的修辞学维基页面，也就是Wiki页面。 但是他说：“为了说服任何人改变主意，您首先必须说服他们有问题。”
因此，我认为您必须从那里开始。 然后，一旦您说服他们存在问题，就可以继续讨论：“您将学到什么？ 您什么时候可以和其他人一起扮演学习角色？”
然后，如果遇到挑战：“您一直花时间在说话，但实际上并没有编写代码，”您可以开始针对他们进行调整。 [听不清00:40:58]
约翰丹尼尔（John-Daniel） ：杰森（Jason）想添加点什么吗？
杰森 ：是的。 我想我只是补充说沟通是关键。 特别是，我认为，在复古过程中，我们有机会将其中一些东西浮出水面，而不是让它们起来。 通过把他们带出来，您开始发展建设性的合作。
这就是为什么我们定期按节奏进行回溯。 而且，有了这项检查，我们就有机会进行改进。 而且在大多数情况下，如果有一个真正的[听不清00:41:33]，可以通过这种方式解决。 但是，您可能不得不面对情况发生变化的情况。
我们可能会说的另一种凯文主义是：“好吧，如果您不能更换团队，那么您就必须更换员工。”但这显然是不得已的方法。 我认为这是我们团队文化建设的目标，我们确实强调在软件开发团队中的信任和沟通。 目的是通过交流沟通解决类似问题。 也许它并不总是有效，但您必须尽力而为。
John-Daniel ：我们会总结在那儿。 我将跳回现场。 并且说，非常感谢大家的光临。 我真的很感谢所有问题。 我也发布了一些民意测验，以获取您对下届会议可以做什么的反馈。
有人评论说，视频质量，特别是早期的视频质量，有点低。 因此，我们目前仅在试用此软件。 幸运的是，这是一次讨论。 因此希望那不是太大的麻烦。 我们还将获取这些白皮书，并在接下来的一两个小时内将它们邮寄给所有人。 非常感谢您加入我们。 我希望您能加入我们的下一个。 谢谢。
凯文 ：谢谢大家。
