Avsnitt
-
Lancer： Sunil Srivastava和我讨论了测试驱动开发对领导层的价值。 Sunil： 从领导的角度来看，他们关注的是我们如何更快、更便宜、更迅速地交付产品，而不仅仅是代码。所以，如果你从这个角度去思考团队如何能够交付高质量、易于改变且成本低廉的代码，尽可能快地完成，这就是测试驱动开发可以帮助领导层的地方。 Lancer： 比如说我是某公司的副总裁，我在考虑进行TDD；我需要花钱请顾问进来，让我的组织掌握这种技能。那我为我的投资能得到什么回报呢？ Sunil： 你能够让你的团队更快地行动？ Lancer： 那是如何实现的？他们如何更快地行动？ Sunil： 因为TDD涉及单元测试，他们能够在代码层面进行测试。所以，如果你能在代码层面进行测试，并且进行多个测试，那么你就减少了对更大的应用进行依赖性测试的需要：回归测试、性能测试和其他集成测试。打破这种依赖性是很重要的，因为其他测试可能需要更长的时间，会拖慢开发交付的速度。所以，如果你不需要为更大的应用创建太多的测试，并且在单元测试层面有信心，你的构建速度会更快。你会更多地使用低层级的测试，不需要进行那么多高层级的测试，这样就节省了维护那些难以维护的应用测试的时间。 Lancer： TDD让你的团队花更多时间编写新功能，花更少时间修复错误，因为错误更少了。 Sunil： 是的。所以从副总裁和领导的角度来看，你关注的是，正如你所说的，团队更专注于新功能的开发，而不是修复错误和重新工作。这降低了项目的持续成本，这意味着我可以更快地交付产品，这才是他们关心的，对吧？所以速度更快，上市时间大大缩短。这就是测试驱动开发从领导角度提供的好处。 Lancer： 当企业想要转向新方向时，TDD也能够使代码更轻松地跟随业务方向而变化。 Sunil： 因为代码编写得易于理解，是模块化的，所以能够更轻松、更快速地进行转变。 Lancer： 为变革制定预算。我觉得我们有点谈到了。所以如果我要花钱雇人来改变我的组织，我需要知道我会得到什么回报。我们说过你将会得到更快的功能交付和转向能力，可能还有其他一些东西。所以归根结底，如果我们要谈论资金，这对你的组织有什么价值呢？ Sunil： 你知道，一些团队关注的关键点是，正如我所说的，更快的交付、24/7的运行时间、更高的代码质量、更少的缺陷、更低的成本。我认为这些最终转化为，低成本、更高的交付运行时间以及能够转向。这些是领导关心的事情。我认为这就是你可以向领导展示的。 Lancer： 当我们谈论时，我想到了另一个点。错误库存会减少，趋近于零。 Sunil： 是的。这涉及到技术债务。TDD可以帮助你将技术债务减少90%或80%。我见过一些团队通过实践测试驱动开发，几乎消除了相当于10年技术债务的情况。 Lancer： 跟随TDD大师正在进行的酷炫事物，或者与我们合作将您的企业转变为一个精益、高效、零缺陷的微测试机器。请前往TDD gurus.weebly.com。下一集我们将听取Richard Hundhausen关于Nexus敏捷扩展框架的意见。 Richard： 如果你愿意，Nexus框架只是围绕现有Scrum框架的外骨骼。
The post 029 TDD对领导力的价值 first appeared on Agile Noir.
-
您可以通过邮箱：[email protected]或者Twitter联系到布兰登·林顿 兰瑟：你的团队一直致力于研究用户需求，然而有时候他们并没有实现所有的需求。在上一集中，我和布兰登·林顿讨论了如何将未完成的需求进度记录到你刚刚完成的sprint中。现在我们将继续讨论，当你把这些未完成的需求或者需求们带入下一阶段计划时，你该如何处理它们。 布兰登：我们总是想尽可能的反映出最真实的情况。如果你知道这个需求是13个点，那么就不要说它是20个点。因为接下来会有两种可能：第一，这个需求变得更小，因为剩下的工作量更少。第二，这个20点的需求现在已经变成40个点了，因为原始的工作量评估是不准确的。 兰瑟：也许企业架构师走过来，说：“不，你需要增加功能，例如申请登录等等…”，那么现在这个需求就难多了。 布兰登：是的，我想我还没有遇到过一个愿意推翻现状的团队。这跟信用无关，只跟它的大小有关。而你又做了多少努力？让我们来谈谈这个场景，它可能比你想象的要大的多，这有助于团队更好的理解工作速度，尤其是当你遇到了一些需要做这种改变的事情。如果这个SDK的实现比我们想象的困难得多，那么就请重新评估它，试着让你的工作速度尽可能的真实，尽可能做出最好的承诺。展示你真正相信的他们的工作速度，或者基于你对他们的深入理解进行速度评估。这种练习将使你更接近持续的、真实合理的节奏。 兰瑟：如果这个需求只剩下3或5个点，你就把它搁置了，然后因为你得到了所有额外的点数，突然间，你的下一个Sprint速度就被人为的提高了。现在你并不能真正的去计划它，这于你的计划无益。 布兰登：是的，你的意思是，如果你完成了一个20点的需求 ，而它实际上只需要付出3个点的努力，那么你就通过虚假的方式提高了你的工作速度；在下一个sprint中，这给你的利益相关者设定了一个虚假的期望。你也可以这样做，对吧？因为你们是一个scrum的团队，对吧？你认为你应该能够维持下去，那么你就是这样惹上麻烦的。 兰瑟：简单来说，在已经完成的工作中，速度等于需求点。当你使用Sprint计划来规划未完成的工作时，不管你在之前的Sprint中已经完成了多少工作，你都必须对剩余的工作量进行重新评估。 兰瑟：布兰登，请问该怎么联系您呢？电子邮件或者Twitter？ 布兰登：我现在根本记不起我的Twitter了，它主要是用来发牢骚的。 兰瑟：如果你有任何问题，你可以在推特上对布兰登抱怨，就像我们在这个播客上说的一样，你可以在Twitter上找到他；当然也有可能是布兰登·林顿在 Twitter上搜索你。 布兰登：林顿，L-I-N-T-O-N，但是为了保险起见我再说一下我的邮箱，我的邮件是[email protected]。 兰瑟：这一集是前一集的延续。请参阅前26集，了解我们谈话的全部内容。
The post 027将未完成的故事纳入Sprint计划 first appeared on Agile Noir.
-
Saknas det avsnitt?
-
布兰登·林顿的联系方式： [email protected]
兰瑟：
这一集，我们和布兰登·林顿讨论了关于计算工作速度的便捷的方法，特别是关乎未完成的用户需求。
布兰登：
你好，我叫布兰登·林顿。我住在底特律，它位于美国的密歇根州。我是埃森哲解决方案的敏捷教练。
我在敏捷空间工作了八年时间，提供咨询业务长达四年。很高兴能和兰斯一起工作。
兰瑟：
是的。我也很高兴能和布兰登一起工作。
布兰登：
很高兴来到这里。我们正在做一个关于需求的播客，主要研究那些需要较长时间才能完成的需求。
兰瑟：
是的。那么，这是一个问题吗？
布兰登：
这不但是一个问题，还是一个大问题。不久前，我们在办公室就这件事情进行了一次简洁的沟通，是的，我们在谈论，或者说我在谈论一个我刚刚加入的团队，问题出现在一次sprint计划会议上，他们有一个需求；但是在上一次的sprint中，他们还有多个需求没有完成。我们的需求依然具有很高的优先级。他们说，这是8个需求，我们可以先完成5个，然后把剩下的3个放在最后一个sprint中。总之，一切就是从这里开始的。
兰瑟：
我们把讨论的这个数字称为需求点，当团队有一大堆工作要做时，他们会制定一个sprint计划。
布兰登：
对的。
兰瑟：
最终他们得到了我们称之为速度的东西。
布兰登：
是的。但是速度到底是什么呢？拿开车来说，我们开车的时候车会有一个车速。速度有很多不同的形式。对，在scrum一文中，我给速度下了定义，你知道的，这只是一个大概的定义，或许它可以用更好的词语来定义，但是在这里我想说的是，在布兰登的世界中，速度是点数，需求的总点数就是在sprint中已经完成的、结束的那些。再没有比这更贴切的说法了。
兰瑟：
在这里，为了进一步强调布兰登的观点，我们假设一个场景：团队有10个需求，所有需求的点数相同，都是5个点。因此，这意味着如果他们完成所有的需求，他们需要完成50个需求点。
布兰登：
所以即使你有10个需求，但是你只能完成其中一个，那么，这就是你的速度。即使其他的需求即将完成，那也与你的速度无关。这有点像踢足球，如果你没有进球，不管你离终点有多近，一英寸，一码，还是50码，你都没有完成。因为拥有可持续的速度，意味着拥有一个能无限期保持的可重复的速度。
兰瑟：
所以正如布兰登所说，这并不是为了计算你的点数，而是为了建立你可以用于制定计划的指标。这些指标应该等同于我们在不确定的时间内所能达到的目标。
布兰登：
有趣的是，一个新的团队，往往会说，这个需求需要完成的点已经不是8个了，我们已经完成了5个，所以我们只需要计算剩下的3个。当然，这也引起了争论，那么，什么叫需求完成呢？他们说，嗯，这个任务，还有这个任务，你是知道的，这个，这个也是好的，这个已经完成了90%了，布兰登，对吧，我获得了所有的点，我们几乎就要完成了。但我总是说，好吧，你是在为谁做这个？这可能是多方面的，这取决于你工作的团队。如果这是某个应用程序的“保持登录”功能，当你返回后，不需要再次登陆，这个时候，除了保持登陆复选框，你的所有功能都是正常的，这对您的最终用户来说不是很有用，因为您登录的内容会一直存在，你甚至没有选择。这个功能并没有完成，它几乎快要完成了，但仍然是未完成状态。那么我要说的是，你的用户关心你做了多少吗？未来的用户能体会到它的价值吗？他们并不在乎你做了多少，他们只在乎你还有没有完成。
兰瑟：
这就好比，我把所有要买的东西都放进购物车，然后到了结账台，收银员说，对不起，这些东西我们不卖了，你不能买了。就像，我想要的东西都拿了，但是我却不能把它带回家去。所以我想我只在乎我能不能把它们带回家。
布兰登：
这可能会揭示一些有趣的机会，如何更好地分割需求。用你的比喻，如果我有一辆装满东西的购物车，我到了结账台，但是那是只收现金的，然而我没有现金。好吧，我当然没有现金了，我得在这里排队。但是如果我有现金，那至少是一种可以满足的用例或场景。因此，这可能意味着有机会将需求分开。但另一个，我们谈话的另一部分，我们现在怎么处理这些需求呢？尤其是因为你是对的…
兰瑟：
现实情况是，一部分需求完成了，但是另一部分需求并没有按时完成。他们根据邓恩的需求来计算工作速度。所以他们整理了所有的邓恩需求。他们把每个人的需求点加起来，可能一共是50个，但是他们仍然有一些需求没有完成，现在他们想为此制定一个计划。
布兰登：
假设这仍然是一个优先级高的事项。我在刚开始就会问：这些问题是否仍然重要，你知道，中途或部分完成，这些是否依然是迫切需要的。如果不是，把它们放在待办事项里，以后再做；如果是的话，你仍然想去追求这些，那么就像我平时所说的，让我们好好研究它们，再重新进行评估，因为在开始研究这些东西时，我们在sprint中可能学到了一些东西，但是还没有完成。我们现在是否能更好的知道完成这个需求实际上比我们之前估计的要付出更多的努力。
兰瑟：
是的。所以我有90%的需求完成了一段时间，假设这是一个20点的需求，我没有得到任何点数，我没有，我知道那不是斐波那契函数。很抱歉，伙计们，但这是一个20点的需求，我不明白，现在我们又要重新评估它，我们要评估什么工作是被遗留的，什么是仍然需要做的，或者是完成剩下的需求还需要什么东西。
布兰登：
对的。
布兰登：
是的。我们不想考虑的是，我们已经投入了多少精力。在速度方面，我们总是告诉团队，你需要非常专注于剩下的工作来完成这个任务。还有我们提到的那个场景，比如说，你知道的，20点的需求现在实际上只有13点，因为我们已经完成了一些工作，我们投资了一点，但还有很多路要走。你可能会说，好吧，我上一次sprint时做的工作没有得到表扬。你是完全正确的，那不是速度，对吧？你，我们，我们并没有完成。现实就是一个20点的需求现在变成了13点。所以如果我们看一下点数的总和，假设这是一个发布，现在你怀疑100个点降到了93个，对吧？你的，你的完成时间移动了一点点，对吧？你还没有完成需求，所以这不是工作速度，就拿获得信用来说，嗯，不要为之而担心。但事实却是，为了达到同样的价值，只需要少做一点努力，你想重新评估它，你知道，当这个需求仍然拥有优先权时，你需要考虑重新评估它。
兰瑟：
下一集，布兰登将继续劝阻我们不要把速度看做是衡量团队付出努力的方法或者是某种形式的信用，而不去估量他们已经完成的工作。
布兰登：
你知道的。我知道你想尽可能的反映出最真实的情况。所以，如果你知道这个需求是13点，就不要说它是20。
Tout Agile Noir Chinese version
-
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的专家开发者。
-
联系:通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/坚不可摧的金字塔:要有持续的自动化测试，有一种方法就是你需要有二个层次的测试：宏观测试和微观测试！现在想象一下由二层组成的金字塔或三角形，宏观测试在底层，而且数量体积最大，上层则是三角形体积最小的一部分或我们可以说 -塔尖。宏观测试在测试数量上很少，它需要部署应用程序的部分或全部，它是一种功能性的测试，用来查看这个功能是否是客户所预期的微观测试是一种单元化测试，用来检测代码的运行是否是开发商预期的。跟踪测试金字塔几何，因为微观测试是一种高价值而低成本的测试，所以我们能够建立并维护成千上万的微观测试，宏观测试虽然也具有很高的价值但成本也很高。当我们在建立宏观测试时我们需要确认我们用对了方法。我们将在未来的续集中讨论更多关于这二个层次的敏捷理念和窥视隐藏于金字塔中的秘密。亲爱的敏捷朋友，如果您想了解更多关于敏捷管理实践或技术实践如何解决诸如错误版本或需求误解的问题，请加入我们的邮件列表(http://AgileNoir.biz/AgileThoughts)，我们将给您免费的指南和工作表。如果您有兴趣，那么定期的正规工作开发人员和管理人员可以购买低成本产品，例如在线课程，网络研讨会和书籍，以帮助您将具有挑战性的项目变成每个人都想要的伟大项目。或者如果您寻找一个巨大的变化，重新调整您的开发或管理技能，以便您可以加入这个热门新项目。甚至为自己的事业打造出辉煌和美好的前景。我二十年以上的产品开发经验为您服务。你的朋友，康美国
-
最重要的几点：
* 开始实践
* 如果某个问题难度太大：暂时保留下来，之后再回过头来重构代码
下面的情况说明你已经熟练起来了：
* 一天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
你要学习敏捷？你喜欢读悬疑书吗？我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail
-
《黑色敏捷书》简体中文版可在这里购买：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：测试已通过。
Hannibal：好极了，Clarice！TDD比我想象的还要有用！我没想看到绿色指示条的时候，那种喜悦的成就感多好！看看我们的测试报告！我们通过了6个测试，确认了代码能满足我们的需求。只花了一小时。看看呢！就点一下运行按钮，测试不到一秒钟就执行完毕了。每个微测试只需要几百分之一秒。好极了。
Vanilla：是的。
Jose：看看呢，你们两个伙计在干什么？
Junior Joe：Vanilla Pop与Stack Overflow的顶级开发者一起结对编程？
Jose：Pops会成为另一个XMan？
Hannibal：我都兴奋起来了，嘴巴都有口水了。我能吃掉你的。
Vanilla：哇，博士先生，请冷静下来。
Junoir：是午饭时间了。先生，我们是不是可以…
Hannibal：博士
Junior：把尊敬的博士先生带去吃午饭。
Vanilla：呃，我没有——
Hannibal：好极了，我们一定会有个安静、封闭些的地方。最好可以大声喊叫。我住得离这里不远，我可以带你们三个过去吃午饭吗？
Jose：当然——
Vanilla：Jose和我有事情要忙呢。
Jose：有吗？
Junior：我们可以帮你们搞定的。
Vanilla：不，我们还需要你们的帮助呢。
Junoir：你需要吗？
Hannibal：噢，真遗憾呢……
Junior：不，不，Pop。博士和我会过去的，我稍后再帮你。
Vanilla：但是——
Hannibal：Clarice，我们出发吧。（他们的声音消失在了走廊里。）我得到了非常非常想要的一个短柄槌球，现在只需要一些新鲜的肉食就好啦。
Jose：好的，Pop。什么情况？我们午饭的时段并没有其它安排呢。
Vanilla：我不相信那个人。
Jose：你太偏激了。不管怎样，我们去买个汉堡吧，我饿了。
Vanilla：我觉得我们以后见不到Junior Joe了。
(Suspense sound)
（暂停的声音）
(Door sound)
（开门声）
Vanilla：你回来了哦，Lecter博士。Joe呢？
Hannibal：Joe说他有点事情要外出一趟。你应该一起来吃午饭的，Clarice。享受美食就像是坐在上帝身边一样，我总是这样说。
Vanilla：啊，让我给Joe打个电话。
Hannibal：荒唐，我们还要写代码呢。来，我把计时器弄开。让我们做第二部分，不用TDD，看看是什么情况。
(Typing music)
（打字的声音）
Hannibal：真让人兴奋，不是吗？
Vanilla：没错，我们像开发者通常那样写代码，然后调试错误，执行代码，发现并修复问题。花了这么多时间才得到正确的代码，我一点不吃惊。
Hannibal：没错。用TDD的话，我们会觉得好像在做设计工作一样，有些不适应。使用常规的“发现错误再解决”开发模式，我们会忙着写代码，围着调试器忙乎，直到代码能投入使用。
Vanilla：我们甚至有一个小的程序来执行我们的代码。多浪费时间呢，全部都是手动操作。我觉得我们的测试都还不够深入。
Hannibal：我同意。我们的测试没有记录。全部都没有记录呢。就好像我们从来都没测试一样。大家都明白了吧，我敢说，Pop，如果时间太紧张，大家可能想完全跳过测试。但是我们用计时器的结果来看，反而节省了10%的开发时间。不过——
Vanilla：不过，没有自动化测试的时候，所以我们的进度反而落后了。
Hannibal：的确如此。
Vanilla：如果我们调整了功能，我们就不会——
Hannibal：（吃着美食的声音）那个好吃的绿色进度条告诉我们一切都状态良好。知道全部代码都状态良好很重要。我们就可以很快发布代码了。（他站起啦，准备离开）Vanilla Pop先生，这非常有学习的价值。我谢谢你了。编写TDD的微测试代码所的投入，和它持续不断的回报相比，简直是微不足道。我们随时都可以运行这些测试。而使用调试器运行的手动测试的价值，只是一次性的。举例来说，我亲爱的Vanilla，如果我说让我们调整一下还没测试的代码，接着再继续手动测试，你觉得怎样呢？
Vanilla：我担心我会抗议的。这样会花费至少20分钟，来重做我们在调试器里所做的工作。
Hannibal：正确！所以微测试每天都会产出价值。手动测试的价值就如同昙花一现，是一次性的。手动测试真是个负担，确实如此。但是想进行手动测试的心理诱惑是很大的。不过，换个方法，点一下运行，微测试就搞定了！执行所有自动化微测试的付出几乎是零。
Jose：有谁看见Junior Joe了吗？他不接电话呢。
(Suspense)
Hannibal：打搅下，我得走了。（开关门的声音）
Vanilla：噢，天呐，就像我最糟糕的噩梦一样。可怜的Joe。我就知道不应该让他和那个怪物一起离开的！现在都见不到Joe了。
Jose：你和Lecter检查了代码了没？
Vanilla：当然，为什么这样问？
Jose：连续整合面板报告有微测试未通过。
(Suspense)
Vanilla：不可能啊，我们在提交前运行了全部的测试……等等，看到这里了没？有人提交了一个有瑕疵的代码。
Jose：噢，看呀，构建的代码开始了另一个测试。你看看那。无论是谁解决的这个问题，代码已经通过测试了。
Vanilla：让我看看是谁提交的代码。记录提示说是Junior Joe提交的。他肯定在家里忙着办公呢。
Jose：他在Slack上给我发了消息，说他吃了午饭回家了。他之前给我说过，他在家手机信号不太好。所以你还觉得他是个怪物吗？
Vanilla：呃，好吧，没事了。
Jose：看看楼下的街上。那不是Lecter博士和Code Dog吗？
Vanilla：噢，天啊，看起来鲶鱼被换成了三文鱼。祝三文鱼好运。
Narrator:
解说：如果你喜欢这段很有戏剧性的TDD故事，那么你会喜欢阅读《黑色Scrum》漫画书的。这本漫画让你跟随Ace，一位高冷的敏捷顾问，一起探险、了解Scrum。如果你不喜欢漫画，那么看看《黑色敏捷书》这本小说吧。它讲述了一个项目经理，把已有的瀑布型项目转变为敏捷管理，而使项目获得了生机。漫画和小说都可在亚马逊购买。印度的顾客可在Pothi.com购买《黑色敏捷书》，而中国的顾客可在我的微店（LancerKind1234）购买。注释中有这些商品的链接。
部分音效来自以下FreeSound.org用户：keweldog和risto_alcinov和Breviceps.
你要学习敏捷？你喜欢读悬疑书吗？我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail
-
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 or have the team slow down because the code can’t be refactored. End of story. 解说：向非开发人员和质量控制人员解释微测试和宏测试的差别非常困难。这里，Vanilla Pop就像是在向非开发人员推广讲解如何进行高效开发一样。这肯定困难重重，因为他把产品负责人放到了不利的位置。不要把TDD当成是一个独立于开发的环节介绍给产品负责人。或许你会觉得这样太过于含糊了，但其实并不是。TDD对你或者你的团队是新事物，并不代表它是可省略的多余的环节。如同你应该采用良好的代码设计模式，或是给代码加上注释一样，这是你应当已经采用的一项开发实践。既然TDD是开发实践，那么，产品负责人对此作出的决定是不专业的，就像他们不应该决定代码中的错误处置和错误代码传递一样。不要把产品负责人放在这样的位置上。相反，Vanilla Pop应该继续实施TDD，花费精力让必须要使用TDD的同事，也就是其他从事开发的同事，来接纳TDD。最后，他可以简单地告知项目负责人近来工作上的改观，他们采用了一种新方法，能明显减少代码错误，同时也保持了已有的工作效率，并且能在一两个月里，提高开发新功能的速度。每一个公司都希望自己产品的功能是有效可用的。他们也希望，不要为代码上的错误而买单，或者因为无法重构代码而影响了整体工作的速度。本集故事到此结束。 下一集，我们将听到团队测试人员的想法。（Jose的口号）
-
联系:想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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：这些微测试执行得很快很快，而且你知道吗，当微测试发现错误时，也就应该知道了有问题的代码大概是在哪里。 架构师：但是一个系统测试可以覆盖数千个微测试。我想要的并不是这些……我其实是希望测试整个系统（想想关于系统的那段话）！ 解说：偏见是影响采用TDD的一个很重要的因素。架构师习惯了全面宏观的思维，过于偏好全面的系统测试。VPop不应该放弃，但是他需要意识到，改变架构师的这一偏见，需要时间和实际经历、体验的过程。才开始的话，方法之一，就是把“敏捷思维”第1到第8集的链接发给他，也就是我们的“测试金字塔”系列。这种类型的全局思维，也正是架构师的全局性偏见。 完整版本1： 你喜欢读悬疑书吗，一本关于敏捷思维的悬疑书？《黑色敏捷书》非常有意思，依靠戏剧性的故事讲述，教会你敏捷思维。欢迎在康美国的微店查看这一集的播客注释：https://weidian.com/s/161651986
-
联系:想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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) 点运行测试，做到了！ 红点 3 Voice: 真的？这怎么能很好地利用你的时间呢？你的薪水太高了，不能写测试。 VPop: 哈。好的，写一些产品代码。(拍打，拍打)完成。一种硬编码的解决方案，可以通过测试。 4 Voice: 为什么不继续编写产品代码呢？你不需要再做一次测试。你知道它会过去的。 VPop: 必须.运行..测试。（点击)嗯？我有一个红点 5 Voice: 看吧！你甚至连那个愚蠢的测试都没成功。你得放弃这种疯狂！ VPop: 等一下！我把考试和错误的课程联系起来了。愚蠢的错误。好的。让我们再做一次测试。通过！绿色点！ Voice: 公司里没有其他人这样做。这真的值得吗？所以花了很多时间写测试。 VPop: 嗯，我觉得这个主意不错。如果不这样，我当初就得花很多时间写代码，而不是构建产品代码。测试非常简单，着手开始写产品代码也非常简单.....一定有严重的误会。TDD立即帮助我发现这一点，而不是一个小时后才发现。因此，也许我应该继续下去，看看这个TDD的想法会带来怎样的结果。我希望Code Dog不会横加干涉。 Narrator: 这里有两种挑战，一种是可以避免的，另一种是不可避免的。不可避免的是大脑的“再训练”。遵循熟悉的习惯时，前额叶皮层不是很活跃。情况很熟悉，大脑已经接受这样的理念，即开发行为意味着花费大量时间使用调试器、以手动的方式进行代码的单元测试。Vanilla Pop试图建立一种新的习惯，他的额叶皮质像灯泡一样亮着，忙碌而努力。他感觉自己努力去做新的TDD是极其困难的。这样一来，这两种工作方式花费的时间是相同的。但是，由于前额叶皮层非常活跃，不管Vanilla Pop的感觉如何，他会花更多的精力做新的TDD，而不是遵循他现有的习惯。因此，阻止自己写产品代码，这本身就需要一定的意志力。 学习新习惯需要努力，这是不可避免的。我们只需要保持这种状态，最终额叶皮层会转移到“自动驾驶”的低能量状态。可以避免的是应对恐惧、不确定性和沮丧所需花费的努力。如果Code Dog没有告诉Vanilla Pop所有这些负面的事情，如果管理层明确支持TDD，那么Vanilla Pop就不用面对自己那么多负面的想法。因此，开发人员在学习TDD时获得明确支持是非常重要的，这样他们才能更好地在再培训过程中进步。 下一集，我们听一下架构师讲TDD: (Soundbite) 参考： 如果你熟悉TDD，那么可以听听第12集的例子：http://agilenoir.biz/podcast/012-an-example-of-doing-tdd/ https://www.amazon.com/Power-Habit-What-Life-Business-ebook/dp/B0055PGUYU/ref=sr_1_2?ie=UTF8&qid=1544998605&sr=8-2&keywords=the+power+of+habit 习惯的力量：https://www.amazon.com/Power-Habit-What-Life-Business-ebook/dp/B0055PGUYU/ref=sr_1_2?ie=UTF8&qid=1544998605&sr=8-2&keywords=the+power+of+habit 意志力：https://overcast.fm/+M-dLnUsiY/09:50
-
联系:想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：http://agilenoir.biz/zh/敏捷理念/015 TDD恐惧、不确定性和沮丧的扩散TDD恐惧、不确定性和沮丧的扩散Code-Dog：早上好，Pop。你早到了。现在才10点。Vpop: 是的。我一直在听这个播客，想尝试一下其中的一些想法。Code-Dog: 哇！你在做什么？考试课？VPop: 嗯, 当我构建代码的时候，我正在构建一些微测试，并且-Code-Dog: 你什么？你是说写测试*当你构建代码的时候？您的意思是在构建代码之后，并且只有在Sprint结束之前还有一些时间。VPop: 不，我是说在那之前我在写测试，它叫TDD和-Code-Dog: 伙计，我听说过测试驱动的开发，这是一些糟糕的东西！VPop: 我有一本叫做TDD的书，我正在试一试。Code-Dog: 你还记得即时掘金吗？会计？他的老板告诉整个团队他们必须开始做这件事。他们都不知道.所以他们后来写了测试，我想他们做的还不够，因为他们还没有部署他们的应用程序。VPop: 嗯那个项目是一堆臭虫。所以是的。我试一试，以防我们的经理逼我们这么做。Code-Dog: 嗯，不可能。在那之后，公司里所有的其他经理都太害怕了。VPop: 当队里没有人知道怎么做的时候，他们会期望什么呢？Code-Dog: 就是这样啊？你现在正在学习，所以他们可以让我们以后再做。伙计我不知道.。也许你最好不要这样，这样我们就能让工作还是一件美差！VPop: 你知道吗，上一次Sprint，我花了大部分时间来追踪生产中的一个问题？一定是代码合并改变了处理程序的级别Code-Dog: 是啊，真的是太烂了。但是大家都知道你需要解决这个问题。VPop: 但我们不需要有这个问题。如果我们对所有新的代码更改执行了TDD，我们将致力于添加新的功能，因为我们不会有bug了Code-Dog: 算了吧，没有虫子？你见过这种事吗？永远没有bugs？VPop: 我听到了，但是的，我在其他公司的一些朋友每天都在发送新功能， 他们只是不发送一些自动测试失败的东西。如果你做很多测试，那么你就不会有错误。Code-Dog: 有理有据。但是，编写大量的自动化测试需要大量时间，不是吗？我的意思是说这个早上你花了多久时间？我打赌你现在应该已经完成了.VPop: 是啊，我在学.嘿，失去一个人冲刺修复错误已经减慢了我们的速度。作者和这个敏捷思想播客都说，许多开发人员在编写代码时花费了50%或更多的时间在调试器上跟踪问题。Code-Dog: 你猜对了！确认电脑才是用正确的方式运行的。VPop: 完全正确！您正在手动对代码进行单元测试，您所做的确认将永远不会再运行。但是...Code-Dog: lay it on me SocratesVPop: 但是，如果我们在编写代码时添加测试，就会捕获开发人员的意图。这些微测试将被检入并执行，以此永远防止代码倒退。Code-Dog: 嗯。坚持住，勇往直前。奖金时间快到了。你会在这个TDD上拿你的奖金冒险吗？得了吧，TDD是不是花了你更长的时间来完成这个故事？VPop: 好吧.。是啊，我确实觉得慢了点。这让我觉得困难多了。Code-Dog: 如果你搞清楚了，你可以教我。至于我，我得去工作了。Narrator:一个早期的采用者，VanillaPop，已经发现了TDD，并且正在尝试应用它。Code-Dog只是一个恐惧，不确定性和沮丧的来源。这种常见的开发人员习惯，害怕走向不确定的道路，来自于坚持承诺的条件，有时甚至失败。因此，当一个团队面对创新时，可能会迫使其成员避免创新并坚持下去。作为团队成员或经理，你的工作是鼓励这一创新朝着正确的方向前行。作为一名经理，你需要小心谨慎，不要像前面提到的经理那样指挥和控制他的团队到错误的情况，因为他们不具备成功的因素。一个好的策略是提升那些有新想法的人，并给他们在FUD面前进行实验的空间：恐惧、不确定性和沮丧。衡量他们的实验成功，然后，如果战略显示出成功的迹象，有创新者配对计划与其他人，直到整个团队有新的能力。下一集我们将看到vinillapop恐惧不确定性和沮丧的表现。
-
联系:想成为所有管理者争夺的高端开发者吗?想成为带领公司中最好的团队的经理吗？康美国帮助您将软件开发技能或开发人员的管理技巧提升到新的高度，并提供一些有见地见解的建议。通过邮件跟我联系，康美国将发给您免费的视频，文章和工作表。有时候我会给您发送关于低成本的学习产品，例如电子邮件课程，书籍以及在线研讨会：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.WorksBas 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会议，确切的日期我不确定。
-
看看: LeSS.WorksLancer: 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将告诉我们， 购买扩展架构，还不如找到问题的解决方案。
-
看看: LeSS.WorksBas Vodde，在湾区，Less的创始人之一 Bas: 巴斯：我们如何获得一个团队的相同乐趣动态，但与多个团队一起工作？因为管理经常会增加太多的东西，官僚主义，以及团队和实际用户之间的距离，所以不再有乐趣了。 康: 所以呢你要试着把有趣的部分放大，就像，你知道，我们可以完成工作。 Bas: 我不会说扩大乐趣，但我的搭档Craig Larman 喜欢说，他喜欢减少产品开发过程中的痛苦和折磨。我喜欢与大型组织合作的原因之一是我发现了很多聪明的人，但他们却做着如此愚蠢的事情。对我来说，这种动力是很吸引人的，而且有很多的组织动力导致了这种行为。发掘这些动力是驱动我从事这项工作的动力之一。 我记得在九十年代，我和一个三人的团队一起工作，那很有趣。然后我和一个由四个人组成的团队一起工作，这是我最后一次用一个团队建立一个产品。在那之后，它变成了大型的团队，所以有30个人的团队，数百人的团队。一开始，我就像大多数人一样，是债务环境的受害者，假设这就是它的工作方式，并假设它应该那样工作,并且人们应该选择这样工作。但是，经过更多的探索，与更多的人交谈，并获得更多的经验，我很快发现，他们不一定知道他们应该如何工作，或想要这样工作。 这往往是许多动态和假设的结果。我对为什么会是这种状态越来越感兴趣。 下一集，Dhaval Pachal 和Bas Vodde 将加入我们的行列，我们将一起讨论错误的假设，这些假设会导致我们在缩放方面遇到问题。 你的朋友，康美国
你要学习敏捷？你喜欢读悬疑书吗？我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail
-
看看: LeSS.Works
Bas Vodde在湾区，拥有Less的创始人之一
Bas：为什么人们关心缩放？因为，嗯，我想有一个正当的理由，而不是那么合理的理由；有些产品你可能只有当你有一个以上的团队才能建立。你需要弄清楚如何用一个以上的团队来构建产品。为什么许多公司关心缩放如果他们已经有不止一个团队。他们不一定需要它，但你知道，大型产品，由于各种不同的原因而变得更大。一旦他们有了一个以上的团队，他们将需要弄清楚如何与多个团队一起工作。
多年来，我一直试图说服产品管理者们，他们不需要用这么多人在产品上。后来，我意识到这些工作在产品上的人是不会突然被移除走的。因此，我们没有试图说服公司他们不需要这么多人，而是问一个问题，如何协调好工作，直到他们显然并不需要每个人。因此，我们停止了这场不需要扩大规模的战斗，尽管这通常仍然是事实。康: 下一集，Bas将告诉我们，扩展是如何严重地从产品开发中获取乐趣的。
Bas：为什么人们关心缩放？因为，嗯，我想有一个正当的理由，而不是那么合理的理由；有些产品你可能只有当你有一个以上的团队才能建立。你需要弄清楚如何用一个以上的团队来构建产品。为什么许多公司关心缩放如果他们已经有不止一个团队。他们不一定需要它，但你知道，大型产品，得到，大尝试各种不同的原因。一旦他们有了一个以上的团队，他们将需要弄清楚如何与多个团队一起工作。
多年来，我一直试图让产品相信，他们不需要太多的人在产品上工作。后来，我意识到这些工作在产品上的人是不会突然被移除走的。所以，我们没有试图说服人们他们不需要那么多的人，而是问了一个问题，我们如何才能让他们和这么多人一起工作，如果他们能很好地工作，那么很明显他们需要那么多的人。因此，我们开始更加关心停止战斗。你不需要扩大规模，尽管这通常仍然是事实。康: 下一集，Bas将告诉我们，扩展是如何严重地从产品开发中获取乐趣的。
你要学习敏捷？你喜欢读悬疑书吗？我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail
-
看看: LeSS.Works
我想你应该弄明白了一点--有很多不同的规模化Scrum框架。如何有效地将Scrum从一个团队扩展到数百个，是业界许多人正在努力解决的一个大问题。
Scrum是20世纪80年代发现的一个轻量级框架，用于响应对更快地构建新产品的加速需求。Scrum没有一种清晰的方法可以跨越数百名从事一项产品工作的人。现在Scrum已经从一个早期采用软件开发的方法开始变成了软件团队组织的主流方式，大型企业对这个问题很感兴趣：如何有效地与多个团队进行Scrum？
今天，有超过几十个规模化的Scrum和敏捷框架。在本系列文章中，我们将研究这些框架中的一些，以了解它们背后的哲学以及它们之间的区别。首先，我们从称为LAST的大型Scrum框架开始。在这些剧集中，我采访了LESS的创始人Bas Vodde和Craig Larman。为什么我要从LESS开始？作为一名作家，我意识到“敏捷黑”的自然续集将是写另一部关于规模化的商业小说。“黑色格兰德”是作品的标题。因此，我开始通过与其他IT顾问的交谈来进行研究，并试图找出他们使用的是什么框架，以及哪些框架让他们感到高兴。虽然LESS不是最流行的规模化框架，但支持less的人说服我 ,less解决了公司在规模化敏捷时所面临的更多问题。其他规模化框架，如众所周知的Safe框架，往往禁止额外的管理或流程层。
下一集，我们将前往阳光明媚的加州湾区，并与Bas Vodde讨论“为什么人们想要缩放”
http://www.infoq.com/cn/articles/less-framework
在这边有还有LeSS播客情节051 为什么人们想要大规模Scrum？052同样有趣的动力，但在规模上053 衡量好的，而不是错误054 Less团队和产品所有权标签055 购买扩展架构，还不如找到问题的解决方案你要学习敏捷？你喜欢读悬疑书吗？我感觉学习敏捷有一点难。下班时候我要玩还是休息。我的书架上我有很多敏捷书和小说书。下班时或者周末我经常看小说书可是非小说很小就看。从2000我也写很多本小说书。为了我喜欢每个人了解敏捷，我写专项的小说书黑色敏捷。这个书你会阅读很快乐也学习敏捷。如果你有兴趣，你可以买在我的微店。如果你不喜欢这本书你告诉我然后我还你的钱：https://weidian.com/s/161651986?wfr=c&ifr=shopdetail
- Visa fler
