坎板的大型内部特征

Question

这一天，我正在阅读一些关于看板过程和敏捷方法的教程/建议，但是对于这个看板方法，我有两个大问题。

我所理解的是用户故事是关于增加商业价值的，就像我们的客户可以使用的特性。主要的问题是，我们有许多看似琐碎的特性(例如，管理solr同义词的简单形式)，但由于集群的缩放/协调细节(使用zk刷新同义词和从数据库中重新加载exmaple)，这些特性很难实现，可能需要几天/几周的时间才能完成。

既然看板的细节每个用户故事都必须独立，那么如何将这个用户故事分解成更小的用户故事呢？我能把它分解成关于实现细节的用户故事吗？(实现协调算法，实现X存储服务等)

我的最后一个问题是关于架构更改/重构。由于它没有增加任何业务价值(对我们的客户是不可见的)，您如何在这个方法中反映这个任务？

Answer 1

看板是一种专注于识别正在进行的工作(并将其最小化)的方法。这是它的核心概念。它的基础是日本汽车公司的准时工作流程。被困在某个地方的东西并没有在工作流中以尽可能快的速度移动。通常，它是与scrum配对的，在这种情况下，它被称为scrumban，尽管这与敏捷原则没有多大关系。

为了使坎班工作得好，故事或任务应该是相似的。让一辆小型货车通过设计来建造滑板车大小的东西的过程将在装配线上造成问题。因此，要想推动一项需要一个月才能完成一周的任务的工作流程，就会有问题。这是可以完成的，但是您需要意识到它对工作流的其他部分意味着什么。

故事或任务可以有依赖关系。只需要确保依赖关系在下一次移动之前就完成了。考虑一下有两个任务的情况，A和B。必须先完成A，然后才能编码B。如果同时将这两个任务放在待办事项中，可能会有人首先使用B --这会很糟糕，因为它有一个无法向前移动的任务--工作正在进行中。此外，如果A已经启动，并且部分完成了，那么B就会启动，您可以再次看到正在进行的工作无法向前推进的情况。

这就是为什么强调独立任务的原因。然而，这并不意味着所有任务都必须是独立的--只是您不应该同时处理两个依赖的任务，或者以错误的顺序工作。这方面的控件是将事情放到待办事项中的能力。

将注意力放在类似大小的故事上，在整个过程中移动，并限制一次在给定列中的数量，那么就有可能向客户提供更好的反馈，说明需要多长时间才能通过工作流。

因此，您完全可以将其分解为实现故事或任务。如果您使用的是物理板，请考虑使用一个特定的颜色粘性便条来描述一个更大的故事的部分细节，以便能够看到和理解这些信息(可能包括它们的依赖性信息)，以便在试图了解董事会的总体情况时能够更快地看到和跟踪这些信息。

在kanban中，没有任何东西可以与敏捷的应用程序相媲美，这些应用程序试图最小化设计时间(注意，敏捷宣言背后的原则中没有任何东西表明没有设计，尽管它可能是对“欢迎更改需求，甚至在开发后期也是如此”或“工作软件是进步的主要衡量标准”被解释为“设计是一文不值”的反应，但我怀疑宣言的任何签字人是否会提出这一声明)。当你看到各种板的演示时，你会看到如下的东西：

第一个图像有一个“指定”列。第二篇是“分析”和“设计”栏目。

正如敏捷宣言背后的原则所描述的，关键是拥有可工作的软件并与客户一起工作。负责将任务放入待办事项的个人完全能够将内部重构任务放入其中。我还听说过经理在必要时执行整个scrum风格的sprint，这是80%的内部任务，或者是周五的重构一天，您在周五进行代码清理。明智的经理/产品负责人会这么做，因为如果不解决内部(非终端用户面临的任务)，可以通过的任务的大小会越来越小(随着时间的推移，对类似大小的事情的估计会越来越大)，因为产品上的技术债务会增加。

敏捷或看板中没有任何东西说你不能拥有自然的‘重构库XYZ’的任务。如果产品负责人批准了要执行的任务(或者说，将事情放到待办事项中的工作流是)，那么就执行它。如前所述，如果不这样做，开发最终将陷入停滞。

我将指出，不这样做违反了原则：“持续关注技术卓越和良好的设计可以增强敏捷性。”通过将代码库保持在给定质量的恒定状态，就可以更好地预测整个项目将花费多长时间(而不是让速度随着技术债务的增加而变慢)。

理论上，敏捷过程应该不断地重构代码，尽管这不是我经常看到的。在某种程度上，这与程序员说“这需要多长时间”的能力有关。在顾问从事某项工程的情况下，经常会有一些“只要我说会有”便会有“这会花多少时间”，而会考虑到不断的重构。这样的声明对于内部开发来说难度更大，因为“➔需要一个星期的时间”--如果你走捷径/不做重构的话，你能在3天内完成吗？“➔”嗯，是的……“➔”很好！3天就可以完成了。“这与其说是敏捷的问题，不如说是组织中开发人员的授权。

相关阅读：

• 什么是Scrumban？
• 精益软件Scrum-禁令
• 精益软件看板自举我将指出，这篇文章专门讨论的是一个非常大的项目问题，它涉及将大故事分解成更小的故事。

Answer 2

我不知道看板的具体内容，但总的来说，敏捷的文化是，您必须能够在每次迭代结束时向您的客户演示新特性。这个演示通常必须是完整的，因为它必须让UI、业务逻辑和持久性过程工作(通常称为vertical slice)。

但是，在像您这样的“琐碎”特性需要太多技术工作的情况下，您的团队可能会问您的客户是否同意在迭代结束时只看到部分演示。例如，只有UI和业务逻辑可以工作，但没有任何持久性(因为这是瓶颈)。如果客户同意，那么您可以将持久性分解为另一个故事。

如果你的客户可能不同意，你可以尝试把故事分解成更小的部分。虽然在你的情况下，打破这个故事可能没有帮助。如果这是一个简单的CRUD，您可以将C、R、U和D操作分解成单独的故事，但是在开发这些故事的第一个故事时，您仍然需要在持久性层上进行“几个星期”的技术工作。

所以，最后，如果你的客户不同意“部分垂直切片”的想法，如果你不能把故事分解成更小的部分，或者打破它们对你没有帮助，那么你就有一个非常可能的结果:你将无法在一次迭代中交付这个特性。

如果发生这种情况，如果您的团队正在计算每次迭代完成的故事点(速度)，那么您所拥有的就是一个零速度的迭代。这通常是团队中的一些东西必须改变的迹象。这就引出了你最后一个问题(关于重构)的答案：

从我(非常有限和脱离上下文)的角度来看，你的团队可能面临着摆脱技术债务的问题。您使用的持久化机制会阻碍您的速度，这可能与技术债务没有直接关系，这对于您的团队正在开发的特定业务来说可能确实是必要的；但是，如果不是这样，您的团队必须能够在您当前使用的机制一开始就切换到另一种持久性机制，这会产生更多的问题，而不是解决问题。

例如，如果您想要减少更改“模式”(因为NoSQL没有任何模式)或执行大量迁移(因为您不需要这样做)的工作量，您可以使用NoSQL数据库。但是，如果你的系统一团糟的话，做这个开关可能被贴上“不可能”的标签。如果您的架构太耦合到您当前使用的数据库，则切换的唯一方法是重构您的系统，使其与持久性机制分离。

因此，关于如何将重构融入您的方法，我相信另一个问题已经涵盖了这个主题，所以我最好不要在这里重复。

Answer 3

看板的细节每个用户故事必须是独立的。

你从哪弄来的？看板不要求工作单元是“用户故事”，而且看板没有禁止您首先开发组件，然后使用第一个组件开发第二个组件，等等。每个组件仍然可以遵循一个典型的看板工作流，在开始时进行分析，在最后进行测试和部署。在这种情况下，您可能需要重新考虑“部署”意味着什么。

如果你有一个大的功能需要开发很多周，你将不得不把它分解成小的子功能，甚至更好的组件--至少，如果你试图开发任何一种合理的架构。当然，一些中间组件本身可能不会为您的客户提供任何业务价值。但是实际上，由于您将为每个子特性或组件开发测试，所以可以使用工作测试来证明特定组件已经“就绪”。该组件为将要使用该组件的团队中的开发人员提供“业务价值”。所以，在你对看板的解释中，你唯一需要适应的就是你的“完成的定义”，当涉及到内部组件时。

他说，这不应该阻止你思考如何组织开发过程，这样你就可以尽早地将价值交付给最终的客户，并且以更小的步骤实现。使用您的示例:首先可以用一个非常基本的、简单的“虚拟”算法来开发具有复杂算法本身的表单，并且在第二步中对该算法进行改进或改进。存储服务可能需要某种管理控制台和/或某种日志机制来使其工作--这也可以算作“业务价值”。