iis积压_分解敏捷流程积压

最新推荐文章于 2024-09-18 20:39:31 发布

danpu1174

最新推荐文章于 2024-09-18 20:39:31 发布

阅读量140

点赞数

文章标签： python java 人工智能大数据 linux

原文链接：https://www.javacodegeeks.com/2011/08/breaking-down-agile-process-backlog.html

版权

iis积压

分解积压流程是任何敏捷流程中最重要的步骤之一。

多年来，我发现分解好的待办事项越好，该待办事项的实现就越顺利。

我发现，积压成功或失败的最大影响者是分解积压的过程。

分解积压是什么意思？

在我们真正讨论如何分解积压之前，值得花一点时间来讨论我的意思是分解积压。如果您遵循某种敏捷过程，则可能会有一个故事板。在该故事板上，您可能有一条泳道专门用于准备开始准备积压的步骤。

分解积压工作的过程是将积压工作从已选择实施的状态转移到准备实施的状态。不同的团队以不同的方式表示这种过渡，但是大多数团队都有某种方式表示准备好待处理的待办事项。因此，当我谈论分解待办事项时，我的意思是将待办事项移入准备好进行开发的状态的过程。

为什么要分解积压？

那么，为什么我们要这样做呢？我们为什么不简单地拿起积压的积木并开始进行开发呢？
我们花时间分解积压的主要原因是因为我们坚持了两次测量和一次切割的古老哲学。

分解积压的过程是预先思考，为我们成功完成积压提供一条路径的过程。

通过跳过这一关键步骤，我们几乎不可避免地要为失败做好准备。

不拖欠我的积压工作就像在进行为期一周的露营之旅，将您碰巧在车上的一切都带走，而不是仔细计划所需的东西。

包装正确的装备

既然我们已经讨论了分解积压的原因以及为什么要做积压，让我们来谈谈其中涉及的步骤。

步骤1：按原样查看待办事项
在此步骤中，我们的目标是了解积压，并评估我们需要询问的积压问题种类以及可能受积压实施影响的代码区域。
我们将要仔细阅读积压的内容，并试图了解所要索取的基本思想。我们希望寻找任何类型的问题区域，这些问题区域要么表明无法实现所要的内容，要么需要对现有系统或范例进行重大的体系结构更改。我们还希望查找表明积压的日志可能太大，实际上可能是一个胖日志，需要将其分解为较小的积压。

步骤2：预审受影响的代码区域
在充分了解待办事项的含义之后，我们应该对所涉及的代码领域有所了解。重要的是要看待积压的实现可能会影响的代码区域，以便我们知道自己要进入的领域。

没有什么比认为容易实现然后实际查看代码并发现必须彻底清除它才需要做任何事情更糟的事情了。

我们的目标不是解决问题，也不是概述解决方案。我们只希望对受影响的代码进行足够的教育，以便能够与企业进行对话以了解实现此积压将需要做什么。

步骤3：与业务部门和质量检查人员进行初步讨论
了解了待办事项的基本概念以及可能受影响的代码领域之后，我们准备就此待办事项与业务和质量保证进行讨论。
这里的目标是完全了解将要实施的内容以及积压的目标是什么。我们在这里进行质量检查，以便开发团队和质量检查人员同时对积压工作有相同的了解。我们不希望质量保证或开发团队决定他们认为积压的含义。如果可能的话，请业务部门负责积压的人员准确告知双方他们想要什么是很重要的。

步骤4：定义骨架测试
在离开有关积压的最初讨论之前，我们想拿出每个人都同意的测试的最初框架。这是一个非常重要的步骤，通常会被忽略，因为团队经常认为QA会开始并编写一些测试。

重要的是要确保所有人（包括开发人员和企业）都同意将用于完成积压工作的常规测试。

在不确切知道将使用什么标准来判断积压工作是否完成并事先同意的情况下，您可能在任何给定时间都致力于质量保证或业务的异想天开。

定义骨架测试有助于定义范围。这并不意味着需求和细节不能改变，而是意味着对于当前的需求和标准集已经足够了解，可以开始开发了。

我经常称骨架测试为“完成标准”。有时，我实际上已经改写了一份积压工作，以明确说明在这次会议之后达成的已完成标准。

类似于

在以下情况下完成此积压：

我可以创建一个新用户
我可以从管理工具中看到新用户存在
审核新用户的创建，并指定有关用户创建的详细信息。

第5步：解决积压
如果您无法完成积压任务，那么您将无法清楚了解实现目标所需要做的事情。
分配积压任务是分解并确定实现积压所需步骤的过程。我经常尝试使完成的标准以业务语言的形式，而任务以实现细节的形式。

分配积压的任务可能很麻烦，但它类似于在出差之前规划行程并仔细包装用品。在分配积压任务时，我会尝试考虑完全实现积压所需的每个顺序步骤。该过程的一部分通常涉及解决方案的实际设计，因为如果没有某种设计，通常很难创建一系列步骤以达到最终目标。

这就是为什么我认为任务如此重要，可以确保正确的前期设计的原因之一。

许多敏捷团队认为敏捷并不意味着前期设计。 这根本是不正确的。

敏捷意味着我们不会预先设计整个系统，但是在实施之前，我们应该始终尝试在某种程度上进行设计。特别是在复杂的系统中。任务分配还有助于将积压工作分解为可行的部分，团队的不同成员可以共同或孤立地进行工作。如果未正确分配任务，则很难协调单个积压项目的工作。
我经常喜欢为每个任务定义完成标准，以确保选择某个给定任务的任何人都能理解它的完成时间。

要注意的一件事是某些任务是顺序的还是可以并行完成。在可能的情况下，最好将待办事项划分为并行任务，但是很多时候必须按顺序执行任务。