康： Richard Hundhausen带我们了解Nexus如何进行冲刺评审。 插播： 我们将拥有Nexus Nexus，nexus，nexus。 Richard： 让我在这里转个弯。这里有一个地方规模化Scrum与Scrum不同的是：我们不让各个团队进行单独的冲刺评审。我们有一个整体的冲刺评审，叫做Nexus冲刺评审，整个Nexus参与。所以所有Scrum团队、他们的产品负责人、Scrum Master，以及与该冲刺目标相关的利益相关者，都来参加评审，他们检查已完成的集成工作，不只是说，嘿，我们要回顾团队一完成的六个PBI，但诚实地说，这些PBI可能汇总成更大的功能想法。所以我们要检查Nexus在该冲刺中交付的这些更大的功能，并获得反馈。我们有一些技术。我的意思是，这可能是在一个大房间里的长会议。 Richard： 如果你在观看功能一到十的电影，而我在那里是因为我关心功能八。哦是的。就像，我真的不在乎这部电影的前两幕，直接到我的部分吧。所以我们建议规模化时采用一些更大型的房间引导技术，比如科学展览会、集市，你可以在冲刺评审室周围设置站点。 康： 嗯。 Richard： 不同的利益相关者可以去不同的领域区域或角色，以这种方式查看他们一直在做的工作。 康： 所以你是团队的一部分，你在团队交付的某个部分上工作。 Richard： 是的。 康： 你可能有点不耐烦，嗯嗯，确实如此。关于坐在满屋子其他人中间，无论格式是什么，你正在谈论采用不同的格式来解决这个问题。是的。在某些方面，我认为这是一个好问题，因为如果我对我们整个Nexus正在交付的东西不感兴趣，那可能存在一些问题。也许问题出在我身上，也许问题出在Nexus上，我不知道。但我只是说，这也可能是一个健康的方式来找出如何解决这个问题。 Richard： 这是对的。如果你想不采用发散合并方法，而是有更多的单一反馈点，这样所有不同的Nexus团队都可以交叉学习并看到，你知道，我实际上从未见过Android应用程序的样子。对吧。所以是的。让我们把它放在大屏幕上。我更多是从利益相关者的角度来说的。 康： 哦，我明白了。哦是的，是的。那总是一个， Richard： 你不想让他们疲惫，因为那样他们下次可能就不会出现了。对吧。 康： 不，那实际上是个大问题。 Richard： 你知道，没有利益相关者反馈的产品注定要失败。所以。 康： 是的。是的。 Richard： 所以我们确实建议为所有事件设置时间盒，但我们从不建议具体是什么。 康： 我明白了。 Richard： 我们唯一说的是每日Scrum应该不超过15分钟，但是这些大房间事件，让Nexus决定时间盒是什么。可能通常两周冲刺的四小时会议由于分布式团队或多地点或其他原因必须是14小时。除此之外，在这里总结一下，转个弯，冲刺评审之后，我们有回顾会，但我们将其分解为预备会议。所以就像我们有Nexus每日Scrum，来自不同团队的代表聚在一起，使过去24小时的集成问题透明化。我们在Nexus冲刺回顾会有这个预备会议，来自不同Scrum团队的代表使整个冲刺中什么进展顺利、什么没有进展顺利、学到的经验透明化，与其他团队分享。 康： 哦，好的。 Richard： 因为，你知道，团队一可能没有经历团队三在冲刺中遇到的问题，团队二可能没有经历团队四在冲刺中取得的成功。 康： 嗯。 Richard： 所以我们有这个小的预备会议，是对话式的，你可以做笔记。这些输出进入各个Scrum团队的回顾会，不只是正常的那种。这是Scrum指南中的。它只面向Scrum团队，他们检查并调整流程，寻找改进。记住新的Scrum指南，你必须至少带一个改进回到你的团队用于下一个冲刺。 康： 好的。 Richard： 这个大房间事件的不同之处，抱歉，Nexus冲刺回顾事件是我们有一个后会议。所以来自各个Scrum团队的代表，也许与之前相同的人，在各个Scrum团队回顾会结束后聚在一起，使这些改进或实验透明化。我不想说这是为了问责， 康： 对。 Richard： 但这也只是为了自下而上的智慧。嘿，看看我们在学什么，看看我们在做什么。看看我们如何在团队二那里应用它。团队三在那个后会议中记录这些。就像，那很酷。 … The post 034 Nexus冲刺评审对话 first appeared on Agile Noir.

康： Richard Hundhausen向我们介绍Nexus集成团队。 Richard： 我想指出，Nexus中有一个新角色，可能是最容易被误解的角色，这可能是因为它的名字。它叫做Nexus集成团队。这不像其他规模化框架，那些框架中他们是做工作的人，他们负责合并代码、编写测试和修复构建问题。而这个团队实际上是一个来自Nexus的即时团队。比如说我们在Nexus中有五个七人团队，总共有35个实际做工作的人。在任何一个冲刺中，其中几个人会戴着臂章，上面写着”我在Nexus集成团队”。日常工作中，我在我的Scrum团队里做我的事情。我在写代码，写测试，做一些部署工作。但是如果那种信号灯亮起，比如我们的构建服务器停止了， 康： 有趣。 Richard： 那么戴着臂章的人会说，好吧，那是我的事，或者是我们的事。然后他们会去处理那些集成问题，或者试图清理那些依赖关系，这些可能是技术依赖。你知道，我们的图表，你们看不到，但我们有三个齿轮在三角形的三个角上，叫做集成工作。我喜欢称之为持续集成、持续测试、持续交付，或者自动化构建、自动化测试、自动化交付，随你怎么称呼。但这些轮子一起转动，需要有人照看并保持它们的润滑，确保我们的云账户有订阅，确保构建在运行，服务器没有满载。这类运维工作。 Richard： Nexus外部没有人帮助这项工作。有一个叫做Nexus集成团队的团队，但他们就是我们自己。这不像你去找一个固定团队说，嘿，（敲门）构建变慢了，你们能修复吗？不是的，这些人作为他们日常工作的一部分来照看这些。所以实际上这与其他方法没有太大不同，比如团队做工作，不仅是做什么，还有怎么做。对吧。我们也一样。只是我们说需要有一些戴臂章的人对此负责，这样如果没有其他人站出来，这些人就必须要做。除此之外，观念是一样的。 康： 对我个人来说，这里有很多很酷的想法，不管我是否在使用Nexus，都值得思考对我意味着什么。比如那些总是处于红色状态的持续集成环境是没有帮助的。这确实在公司中发生。你有人可以去找，说，嘿，这不起作用，你能为我做什么？所以这很好。 Richard： 让我澄清一下。就像单个团队的Scrum Master一样，Nexus集成团队有点像Nexus规模化的Scrum Master。他们应该始终采取教练、咨询、培训、引导的立场，只有在这是唯一方法时才动手。换句话说，假设我在那里，我是Jenkins专家，我戴着Nexus集成团队的臂章，Jenkins停止了。这不是说我会收到电击去修复Jenkins。我会说，好吧，哪个团队报告的？让我们和他们坐下来，也许以群体方式。 康： 嗯嗯。 Richard： 向他们展示，哦，嘿，这是发生的事情。 康： 嗯嗯。 Richard： 你们正在运行一个较旧的构建，使用的框架在Jenkins中不受支持，所以这不是Jenkins的问题。 康： 对。 Richard： 但我们可以在那里添加这些组件。我可以向你们展示ood或其他东西是如何工作的，对吧。如果你们需要的话，可以拉取那些引用。是的，也许我们会从中创建一个wiki并让所有人都能使用。但我不是直接去那里修复它。Nexus集成团队应该始终从教练、咨询的立场开始。我就在你们肩膀后面向团队展示。 康： 酷。 Richard： 如何做这些事情。但如果他们完全迷失了，是的，我是说，我会谈论，嘿，如果Scrum团队，一个团队因为这样的事情无法工作一天。 康： 嗯嗯。 Richard： 我们谈论的是数千美元的损失。 康： 嗯嗯。 Richard： 如果一个Nexus因为某些自动化问题或其他什么原因而陷入僵局，比如他们的仓库满了或丢失了，那可能是几万美元的损失。 康： 这确实会发生。 Richard： 这确实会发生。 康： 无论他们是否使用Nexus，那种僵局都会发生，而Nexus能更快地暴露这个问题，因为有人在关注它。 Richard： 所以我认为我们需要有人负责。我是说，最后的手段。 康： 嗯嗯。 Richard： Nexus集成团队必须让车轮重新回到轨道上。 康： 对我来说，Nexus是团队之间的一个设计联盟，现在有了这个设计联盟，如果你叫它北约或其他什么名字，比如，如果其中一个团队遇到问题，那么这就变成了整个组织的问题。然后当他们去对抗组织时，实际上会获得更多的推动力。我是什么意思？有些组织有票务系统和那些不在乎的人。他们有一个大的票务队列，按先来先服务的原则处理事情。有时候实际上并不完全是先来先服务，因为这关乎谁喊得最大声和其他一些因素。我见过团队的集成系统环境崩溃，因为某个地方有一个环境团队需要有登录和更改的密钥。 … The post 033 Nexus集成团队 first appeared on Agile Noir.

Richard:  你已经在一个团队中使用Scrum一段时间了，他们接受产品待办事项增量——团队在冲刺结束时交付的需求。现在，你将其扩展到一个更大的组织，多个团队需要协调他们的努力来交付一个产品待办事项增量。团队数量可能是两个、五个、十个。想象一下让这些团队朝着一个产品待办事项增量工作所需的协调努力。Richard Hundhausen告诉我们这在Nexus中是如何完成的。 Richard:  这是一个正常的产品待办事项列表，尽管是大规模的。它会在顶部有更准备就绪的项目。 康： 而那个产品待办事项列表是为整个Nexus的。 Richard: 它是为整个产品的。我们相信使用Nexus框架进行扩展是关于许多团队在单一产品上工作。 康： 我明白了。 Richard: 这很快就会分解为”什么是我的产品？”有很多技术来识别这一点。Nexus框架不是关于将Scrum引入每个部门——比如维护、IT或财务。我见过组织尝试这样做。那不是扩展。这是为了多个Scrum团队想要在单一产品、单一产品待办事项列表、单一产品负责人上工作的情况。 Richard: 就像在Scrum中一样，我们用冲刺计划会议开始冲刺。在Nexus中，冲刺计划会议包括每个团队的预测和计划。这是那些大房间会议之一，来自每个Scrum团队的代表在预会议中会面，使依赖关系透明化。 有细化、规模估算和一些权衡，这样团队可以交付在冲刺期间没有PBI跨越团队边界的项目。此外，最适合的团队选择每项工作——注意依赖关系并在冲刺结束时交付可演示的价值。 Richard: 然后这些代表将PBI带回到他们各自的Scrum团队的冲刺计划中。团队决定预测是否符合他们的容量、速度和完成定义。使用新的Scrum指南，每个冲刺都期望有改进。如果团队同意他们可以完成PBI，他们就制定计划。当最后一个Scrum团队完成他们的冲刺计划时，整个Nexus冲刺计划会议结束。每个人都等到最后一个团队预测并最终确定他们的计划。例如，如果第五个团队意识到他们缺少培训人员，他们可能需要与其他团队协调以调整依赖关系。 康： 所以听起来他们在为下一个冲刺中能够交付的内容在团队间构建一个共享的待办事项列表。 Richard: 某种程度上。我们实际上没有共享的冲刺待办事项列表，除了作为跨团队依赖关系的视图。在规模化时有一个新的工件叫做Nexus冲刺待办事项列表。你可以把它想象成来自每个Scrum团队待办事项列表的PBI在流程图中可视化——每个团队一行：待办、进行中、完成，也许还有一个”阻塞”列。 康： 嗯嗯。 Richard: Nexus中的任何人都可以说，”哇，第一个团队在等第二个团队的PBI，而第二个团队甚至还没开始——冲刺已经过半了。” 康： 嗯嗯。 Richard: 所以这是个别团队冲刺待办事项列表预测的只读、聚合视图。 康： 嗯嗯。 Richard: 谁维护或查看它？你在那个工件上举行每日Scrum吗？这由Nexus来决定。 Richard: 日常中，就像在Scrum中一样，我们有每日Scrum——一个同步会议来计划当天。规模化的不同之处是Nexus每日Scrum，在各个团队的每日Scrum之前举行。来自每个Scrum团队的代表参加这个预会议。它像正常的每日Scrum一样有时间盒限制。在这里，他们使过去24小时的集成或依赖问题透明化。其他团队可能会说，”我们今天正要涉及那个——谢谢提醒。” 康： 嗯嗯。 Richard: 或者”审计员在大楼里？好的，我们会注意。”依赖关系可能在人员、领域、技术组件或甚至代码库之间——尽管我们不建议团队之间有私有存储库。Nexus每日Scrum的输出成为各个团队每日Scrum的输入。 康： 嗯嗯。 Richard: 这就像Scrum的Scrum，除了它是必需的并且首先发生。 康： 我喜欢它首先发生的想法。我和其他教练在一天结束时做过多团队Scrum，很难对我们这么晚学到的东西做出反应。这很有道理。 Richard: 有时我被问到，”我们还能做Scrum的Scrum吗？”我说，”嗯，就像在单团队Scrum中一样，不行——你不被允许和人交谈。” 康： <笑> Richard: 那是个玩笑。 康： 太好了。<笑> Richard: … The post 032 Nexus 如何制定计划 first appeared on Agile Noir.

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框架进行扩展是许多团队共同努力完成一个产品的过程。 The post 031 创建 Nexus first appeared on Agile Noir.

康美国声音： 理查德·亨道森（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上有售，在中国，你可以在我的微信商店购买。链接在节目说明中。 下一集，理查德·亨 The post 030《Nexus 和团队 Scrum》，与 Richard Hundhausen first appeared on Agile Noir.

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.

您可以通过邮箱：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集，了解我们谈话的全部内容。 The post 027将未完成的故事纳入Sprint计划 first appeared on Agile Noir.

布兰登·林顿的联系方式： 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 The post 026便捷又实用的计算速度和待办事项的方法 first appeared on Agile Noir.

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的专家开发者。 The post 021 代码覆盖丑闻 first appeared on Agile Noir.