032 Nexus 如何制定计划
/
RSS Feed
031 创建 Nexus
/
RSS Feed
Richard Hundhausen和我讨论如何形成Nexus。 康（01:20）： Nexus是以某种程序化的方式形成的吗？还是有一些规则？ 理查德（01:26）： 嗯，我们更喜欢自组织，因此我们希望Nexus尽可能地自组织，就像其他框架需要一些组织重新设计来创建一个“泡泡”，让这个东西能够运作一样。与基于Scrum的其他框架一样。我们没有为管理者提供故事，因为在Scrum中没有管理者，只有自组织、自管理的团队。Scrum Master负责日常Scrum，帮助提高团队的生产力，提供教育和咨询。但最终是团队完成工作，是他们解决自己的问题。 康（02:13）： 我现在在考虑集成点。有Nexus冲刺审查吗？我正在看图表。 Richard（02:18）： 是的，如果你允许的话，让我解释一下。我们正在查看的图表可以在scrum.org上找到。它在Nexus指南中。这是一个PDF，就像Scrum指南一样。这是一个基本框架，免费提供的。它来自Ken Schwaber和我以及其他几位培训师。但scrum.org还有他们基于该免费框架的专业Scrum规模的实例，称为SPS（Scaled Professional Scrum）。所以有了Nexus框架，去利用它，享受它。但是如果你想了解一些关于规划、追踪工作、可视化和持续集成、持续交付的在规模上的经过验证的实践，以及你现在听到的一些更DevOps的东西，那么就是scrum.org的专业Scrum规模，专业Scrum规模项目。当你问我关于实践的问题时，我喜欢将这两者区分开来。Nexus框架没有提到它。就像Scrum没有提到它一样。好吧，在scrum.org，我们有一些我们认为在规模上非常有价值的实践。就像对于单个团队的专业Scrum一样，我们有关于如何实施Scrum指南的想法。 康（03:36）： 一个实践的例子可能是… 理查德（03:40）： 产品积压的细化。哦，哦，等等，不，这是单个团队Scrum中的一项实践。在规模上，它实际上是一个新的事件。所以我们做出的改变之一是，这个外骨骼现在需要进行细化，不仅仅是“嘿，这是个好主意”。让Scrum团队定义何时何地以及时间段，它可以为零。现在它是一个事件，何时何地以及细化的深度由Nexus决定。但同样，我们有关于跨团队细化和单个团队细化的实践。我应该回到一开始并说Nexus框架的目的。第一目的是识别、透明化、减轻/消除依赖关系。我们认为依赖关系是不好的，是摩擦点，是无法完成的原因，是无法交付价值的原因。在规模上，这只会加剧。其他的规模框架可能会以不同方式定义“依赖关系”，或者将其视为协调/学习的机会。而我们的根本动机不是将依赖关系视为学习的机会，而是认为依赖关系是不好的，应该被可视化和减轻。 康声音解说（05:07）： Nexus是通过将多个Scrum团队团结在一个产品周围而形成的组织工具。通过创建一个具有相互依赖以生产产品的团队组，Nexus成为围绕共同目标组织团队的强大工具。 康（05:45）： 团队学到了，总的来说，似乎依赖较少 理查德（05:48）： 是的，Scrum并不反对学习，Nexus也不反对学习，但我们不将学习作为消除依赖关系的途径。我们在框架中有其他的方式来处理这个问题。 康声音解说（06:04）： 下一集，Richard Hundhausen告诉我们Nexus如何进行计划。 康（06:11）： 而且产品积压是为整个Nexus的。 Richard（06:13）： 它是为整个产品的。我们认为，使用Nexus框架进行扩展是许多团队共同努力完成一个产品的过程。
030《Nexus 和团队 Scrum》，与 Richard Hundhausen
/
RSS Feed
康美国声音： 理查德·亨道森（Richard Hundhausen）为我们介绍了Nexus，这是一个用于进行多团队软件开发的框架。 康： 你刚才说Nexus是最简单的扩展框架。 理查德： 我研究了所有这些，其中一些需要一些严重的组织变革、重新设计或重构。而在Nexus中，我们只是假设你正在使用Scrum，所以Scrum已经存在并运作良好。我们在Scrum.org推荐首先使用专业的Scrum。我们有一个术语，我们称之为“nail it before you scale it”（在扩展之前先掌握），但我们理解组织正处于其发展过程中，如果你愿意，Nexus框架就像是一个外骨骼，你可以把它放在现有的Scrum框架周围，以便有机会进行扩展。 康： 听起来实际上与Less相似，至少在表面上是这样。因此，它谈到了团队的持续集成。现在，我不知道他们是否对谁应该进行持续集成有明确的规定，我也不知道它是否涉及任何产品定义类型的事物。Nexus在持续集成方面是否有规定，还是只是说：“嘿，他们应该使用持续集成”？ 理查德： 拿起Scrum指南，你会发现里面没有关于如何进行工作的具体指导。有事件，有时间盒的概念，有已完成的定义，但最终让团队决定。让团队决定如何完成他们的工作。开发团队就是让Scrum团队决定如何在工作周围自组织。角色明确，责任划分清晰，Nexus也有这样的特点，但我们不要求你放弃Scrum中的任何东西。因此，如果你的一个团队的大脑说：“哇，这是团队应该决定的事情”，那么你的Nexus大脑应该说：“这是Nexus应该决定的事情”。 例如，如果你想进行持续交付，我非常赞成，我认为在今天的时代，扩展开发工作需要这样做，但仍然由Nexus决定。团队、Scrum团队和Nexus需要确保在进行持续交付之前已经实现了持续集成，并且在进行这些操作之前，他们必须解决了技术上的卓越性问题，并且在控制他们的依赖关系和集成问题之前。但最终，我们不关心。我们认为这是一个好的做法，但让Nexus来决定，他们可以检查他们在这个旅程中的进展并相应地进行调整。 康： 什么是Nexus？ 理查德： Nexus是我们对一些事物的术语。实际上，这是未来操作系统Android的全球术语。在会计和法律领域，这是一个非常负载的术语，但在这种情况下，它是一种沟通的途径。从定义上来说，它是一种沟通的网络结构，因此作为一个扩展框架的名称，它非常合适。但是，Nexus框架中，我们将其中的Scrum团队称为Nexus。就像在单一团队的Scrum中，我们有三到九名开发人员，加上一个产品赞助者角色和一个Scrum Master角色，最多有11人的Scrum团队。我们对Nexus中的Scrum团队也有相同的概念，不仅因为它跟单一团队的开发者模式相似，而且还因为邓巴数的因素，管理大型会议等等。 康美国声音： 邓巴数是指一个人能够维持稳定社交关系的人数的建议认知极限。这个数字在1990年由英国人类学家罗宾·邓巴（Robin Dunbar）首次提出，他发现灵长类动物的大脑大小与平均社交群体之间存在相关性。邓巴非正式地解释为你不会因为未被邀请而加入他们在酒吧里碰到时会感到尴尬的人的数量。 理查德： 我们的大脑可以维护大约100到150个人，我们可以说：“哦，嘿，我认识你。你是那个在手持应用程序上做了非常好的UX的人。哦，嘿，你是我需要谈论爱达荷州新销售税的税收问题的利益相关者。” 康美国声音： 您是否是敏捷或Scrum的新手？正在寻找一种有趣的方式来获取成为敏捷团队知识的途径吗？快去阅读小说《敏捷黑帮》，这是一部关于项目经理需要将他的团队转变为敏捷的戏剧性小说，因为他的生命取决于此。这本书在美国的亚马逊上有售，在印度的pathi.com上有售，在中国，你可以在我的微信商店购买。链接在节目说明中。 下一集，理查德·亨
029 TDD对领导力的价值
/
RSS Feed
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框架的外骨骼。
027将未完成的故事纳入Sprint计划
/
RSS Feed
您可以通过邮箱：Brandon.Linton@Accenture.com或者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，但是为了保险起见我再说一下我的邮箱，我的邮件是brandon.linton@accenture.com。 兰瑟：这一集是前一集的延续。请参阅前26集，了解我们谈话的全部内容。
026便捷又实用的计算速度和待办事项的方法
/
RSS Feed
布兰登·林顿的联系方式： Brandon.Linton@accenture.com 兰瑟： 这一集，我们和布兰登·林顿讨论了关于计算工作速度的便捷的方法，特别是关乎未完成的用户需求。 布兰登： 你好，我叫布兰登·林顿。我住在底特律，它位于美国的密歇根州。我是埃森哲解决方案的敏捷教练。 我在敏捷空间工作了八年时间，提供咨询业务长达四年。很高兴能和兰斯一起工作。 兰瑟： 是的。我也很高兴能和布兰登一起工作。 布兰登： 很高兴来到这里。我们正在做一个关于需求的播客，主要研究那些需要较长时间才能完成的需求。 兰瑟： 是的。那么，这是一个问题吗？ 布兰登： 这不但是一个问题，还是一个大问题。不久前，我们在办公室就这件事情进行了一次简洁的沟通，是的，我们在谈论，或者说我在谈论一个我刚刚加入的团队，问题出现在一次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
025 作为开发者，如何熟练掌握TDD？
/
RSS Feed
最重要的几点： * 开始实践 * 如果某个问题难度太大：暂时保留下来，之后再回过头来重构代码 下面的情况说明你已经熟练起来了： * 一天8小时已经能写出很多个测试了 * 能重构4个较长的函数或者类，并让它们通过测试 * 很不喜欢收到跳过测试的建议 * 已经快一周没用过调试器了 下面的情况说明你已经非常精通了： * 能教会他人如何熟悉TDD * 你的团队项目有很高的代覆盖率了（高于80%），并且还在持续提升 * 团队的技术负债在每一轮冲刺中不断降低 开发者要熟练掌握TDD，必须得经历的那些事情： 先编写测试代码，再写产品代码。之后，你的大脑会形成条件化的思维，也就是形成一个新习惯。40/4挑战是一种培养新习惯的方法。它的意思是在4周的时间段里，写出40个单元测试。之后，你会在TDD上取得突破，并变得熟练。你在代码编写中会遇到好些困难，并发现困难通常都能通过先进行微测试来解决。你会发现一两个自己难以解决的问题，但没关系，继续努力。4周过后再来重新解决这个问题， 这时候你已经成为了专家，能用你条件化的思维来平衡测试与产品代码了。在回顾微测试提供的快速反馈时，你感到非常享受。你开始注意到你开发出了更多的功能，而且在修复有问题的代码上花费的时间越来越少。 开发者熟练不起来的常见原因有哪些？ 14到22集的IT戏剧《敏捷思维》中，我们列出了几个原因。毫无疑问，最常见的原因，就是开发者对于已有的思维定式太过于习惯和舒适了。“我不先写代码，就没法写出微测试来。”这种思维定式让他们不愿意战胜自己来尝试新事物。然后，不舒适的感觉让他们继续自己既有的固定思维，跳过了要先写的微测试，直接编写代码。但这样反而让通过测试和实现功能的周期更长，也更冒险，因为你老是会遇到问题却没有任何头绪。 下一集会讲述一种“调皮或优雅”的方式来计算团队速度，由敏捷教练Brandon Linton带给大家。
024 让整个组织实施TDD
/
RSS Feed
上一集，我们讨论了如何让团队实施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？
023 让整个团队都开始实施TDD
/
RSS Feed
如果14到22集里TDD 的IT戏剧一样，一旦你找到了具备测试驱动开发实施能力和可以积极驱动这件事的人选，那么你就占到了起手。我们会回顾Vanilla Pop让他的团队实施TDD的一些步骤，同时也会增加一些我认为很有效的小贴士。 步骤一、寻找火花 寻找一个思维灵活、而且资历也比较高能影响到团队其他人的人选。让他们积极地在样本代码上试验学习TDD，之后在实际工作中开始应用。 另一个策略，是雇佣一个有敏捷软件开发经验的开发者，通常被称为敏捷技术教练或是XP教练。让他参与几次团队的设计冲刺。敏捷教练，比如我自己，有十多二十年使用不同编程语言全栈实施TDD的经验，因此帮助你的团队在几天内改变编程模式，并不是难事。 步骤二、让火花称为火焰积极地研究学习团队工作中所写的代码 教会每个开发者如何结合自己的用户故事来实施TDD。在几轮设计冲刺中进行结对编程，这样你的开发人员就能得到足够的指导，了解如何自己解决最有挑战的微测试问题，就这样让火花燃烧起来。一开始会有些难度，大家也会学习如何删除、改变已有代码，运用新学到的设计模式以便更方便地添加微测试。 减少发布的压力，使每个团队成员都能有时间学到让他们能够产出产品功能的技能。举例来说：让团队决定来做更少的用户故事，这样他们能够为代码提供更多的微测试。另一种方法，是选择一个故事，以结对编程的方式来实施TDD。然后在下几轮的冲刺中，继续这样的方式，直到每个人都能在他们的日常工作中都操练过一些TDD。 40/4挑战，以及永远停留在初级阶段的危险 使用社交化帮助团队操练，讨论微测试在站立期间所取得的成就。 步骤三、投入，让壁炉的火焰更旺获取管理层支持 同他们交流在全部产品代码中使用TDD的愿景。选择两个月后的某时间，让团队讨论使TDD成为主流的产品标准。让产品的微测试工作更加透明 公开每天新增的微测试数量。讨论但不要吹嘘有站立会里有多少交付的微测试。在连续整合服务器的面板显示有关的数据是个好主意。 停止抱怨自动化测试。开发者很快就会开始指责“新事物”减缓了进度，而且看似没有多少好处。每个人都知道学习需要时间。在开始学习这个方法的前两个月，速度减慢是正常、普遍的现象。抱怨正常出现的现象，只会让管理层有所顾虑，担心团队的不安。为了度过这一阶段，我建议关注学习新技能积极的一方面，与组员分享减慢速度后所学到的新事物。之后，速度就会回升，变得更快，但学习的过程必不可少。 在设计冲刺回顾中讨论微测试工作，这样你的组员就会知道他们需要为产出持久的价值负责。利益相关方也要了解到团队的新方法。 步骤四、保障燃料的持续供给 团队工作协议应该把处置未通过的测试作为优先任务。唯一一个更重要的事情，是产品的应用交付。在测试未通过时，有关的人员或者结对小组，应该停下来了处理这个问题。 新增且没有单元测试的代码，应该被删除，就像未通过审阅的代码一样。 对交付应用的代码进行结对编程（定义交付应用代码）。 如果两个月之后，团队对于新代码的使用上还有问题，反思这一情况出现的原因，这种情况只可能因为创建的微测试有问题或者开发者没有按有关的流程执行引发。 期待在开始启动TDD的6个月之后，代码几乎不会出现瑕疵，或是同未采用测试时的旧代码相比错误明显减少。错误追踪系统中的数量走势应当相应地下降。 据我的经验，在历史代码上启用TDD一年之后，错误追踪系统已经用处不大了，只是个支持和开发部门间的工作流程罢了。出现的错误应该少于10个。 下一集，让整个组织实施TDD
022 TDD和Stack Overflow的专家开发者
/
RSS Feed
《黑色敏捷书》简体中文版可在这里购买：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：测试已通过。 …