我叫Victor，我是Sportmaster的系统分析师。今天，我想谈谈分解任务并将其转移到开发中。任何物体都是由零件组成的，无论是汽车还是软件产品。而且，将这些对象中的任何一个从其组成部分组装成一个整体都需要花费时间。有时-甚至很长的时间。特别是如果在此之前您不只是分解主要部分，而是决定在原子层次上深入研究它的底部。
适当设置任务和完全混乱之间的界线在哪里？我将分享一个示例，说明我们Sportmaster如何定期从业务部门接收开发任务。
从上面的示例中可以看到，每个任务的描述在很大程度上取决于客户的想象力和常识。在更多的地方，更少的地方，但是分析师需要以某种方式使用它。有时它们还指示功能的边界，有时它们只是发送主题。如果我们将这样的任务直接转移到开发中，那么最终我们将得到一些难以理解的东西。你该怎么办
用脚走路去询问客户所有要求，明确出口处的确切位置。的确，仍然有金牌客户，实际上是大多数客户-他们在Confluence中编写了所有要求，因此您可以随时阅读并提出问题。并且，当使用该功能的框架一切都清楚之后，就可以开始执行任务了。
为什么分解
分解的主要目的是使企业可以快速实现其所有愿望，并使用户从构想本身到功能的外观花费尽可能少的时间。为此，您可以执行较小的任务，尽管任务虽然很小，但仍可以将有效的功能提供给用户。
除了实现满足用户和业务需求的全球目标之外，任务分解还使您能够从客户那里获得更快的反馈，无论开发是朝着正确的方向发展，还是根本没有达到客户的想象。
如果最初的任务很大，而我们一次完成了整个任务，那么我们将花费大量时间在此上，并且在客户提出意见之后，我们将不得不丢弃所有内容。好吧，如果任务很小，最多一天或两天的工作，就可以了。返工大约需要相同的数量。第二种方法也更便宜。更何况双方都保存了神经。
如果将一项功能分为几部分，则开发人员可以并行处理它们。因此，我们将并行化流程并加快prod中功能的输出。重要的是任务应尽可能少地相互依赖。
加上快速测试和错误修复。再次，小功能比巨大的功能更容易测试。如果出现问题，开发人员将在“修复”上花费很少的钱，并且一切都会更快地工作。
在与客户一起分解任务的阶段，您可以立即了解在此时此刻重要的功能，以便开始获利，可以留待以后使用的功能，以及可能不必要的功能。
对于企业而言，重要的是要知道工作功能将以多快的速度出现。而且，当您分解成多个任务时，我们可以预测并更准确地估计完成任务所需的时间，而不是拥有大量工作要做的时间。但是，除了在工作时间上更容易评估小任务这一事实之外，开发人员还更容易评估工作过程中可能出现的风险。
例如，更新了框架，淘汰了一些方法，代码有问题等等。将小任务投入工作，我们将所有这些风险降到最低，即使这样的任务阻塞了线程中的某些内容，它也不会像它是一个繁重的任务（它将完全阻塞所有事物）那样重要。如有必要，有可能提出一个可行的解决方案并将技术欠款放入待办事项中，待问题解决后再进行处理。
分解的基本方法和规则
任务分解有两种主要方法-水平和垂直。对于水平，任务按工作类型，级别或组件划分。例如，我们使每个任务都经历几个阶段：前端，后端，数据库。而采用水平方法时，一项任务排在后面，第二项任务排在前面，第三项导致数据库更改。
为什么这种方法不好？完成每项任务后，我们将无法使用功能。只有从三个来源收集结果，我们才能得到某种结果和反馈。因此，通常不使用水平分解。
垂直方法要方便得多，在垂直方法中，可以在每个任务中使用可视功能-任务经过所有阶段，并且输出包含可以分析，测试，显示给客户并在必要时进行更正的结果。并快速启动和使用。
如果我们讨论这些规则，那么这里我只确定了三个。首先，任务必须在逻辑上完成，也就是说，任务本身是独立的。它不应破坏其周围的逻辑，并且必须必然带有至少某种商业意义，从而使用户收到。同时，您不应该将那些没有商业意义的任务分解为多个部分（理想情况下，它们根本不应该存在）。
其次，完成一项小任务的结果应该带来小的变化。更改越小，它们进入通用代码的速度就越快，因此该代码不会过时。此外，小任务有助于避免合并时开发人员之间的冲突。
第三，您不应该将任务分解为非常微观的部分。如果分解得太小，将需要很长时间来管理这些任务。在每个阶段，您可能必须重新排列它们的优先级，重新建立依赖关系连接，仅此而已。因此，开发速度不会增加，相反，会急剧下降。因此，您需要寻找中间立场。
分解方法
取决于来源，分解方法的数量差异很大：在某处表示只有八种，在十处表示是二十种。我想强调一下我每天在工作中必须使用的方法。
多种需求
当故事中存在连词“和”，“或”时，此方法最方便使用。例如，消费者想下订单并用卡或奖金付款。该任务可以分为三部分：第一项，用户下订单，第二项，他用卡付款，第三项，使用奖金。
使用场景
另一种常见的方法是根据用例划分任务。在这种情况下，一个故事是一条主要路径，而另一些则是另一条路径。假设某个用户想要购买一件商品，那将是主要情况。但是还有其他方法-他可能会立即将产品放入购物篮中并付款，或者他可能想在购买之前将其与其他产品进行比较。然后，我们将产品比较作为一项单独的任务。
也许他不想立即购买，但将其放到某个地方，添加到收藏夹中，以便他以后可以返回。或者用户喜欢该产品并准备购买，但该产品已无库存。因此，您需要让他知道货物何时出现。这就是我们得到四种方案的方式。
从简单到复杂
“ Sportmaster”网站的主页包含横幅。我们可以做的最简单的事情就是拍摄一张照片并将其展示给用户。这是传达正确信息的最简单，最快的方法。然后，我们可以增加功能，不添加一张图片，而是添加三张或四张图片，将它们组合成一个网格。这是一个单独的任务。
通过这种方法，在执行每个后续任务时，功能应该会增加。例如，我们可以在网格中制作一个轮播，然后添加一些链接，文本，按钮和其他内容。通常，首先我们实现最简单，性能最快的版本，然后再转到更复杂的版本。
就在最近，我参与了实施横幅的类似任务。该横幅应悬挂在主要横幅上，并由CMS控制。如果您问客户他想管理什么，他会很乐意回答而不会眨眼-每个人。因此，在这里一定要深入探讨该主题，并强调当前需要管理的内容，经常使用的内容以及几乎从未使用的内容。因此，优先考虑实施并划分任务。
运营（CRUD）
这可能是最常见的分解方法。在这里，任务分为创建，读取，更新和删除操作。它适用于需要管理或配置某些任务的任务。例如，下订单的任务分为四个较小的任务：创建订单，查看订单，编辑订单和删除订单。
界面选项
需要多个接口选项时使用。例如，一个站点必须支持多种语言。首先，我们制作俄语版本。然后，在其他国家/地区投放服务时，我们会添加英语。如果该国家/地区使用英语以外的语言，那么我们也可以添加该语言。在这种情况下，首先用一种语言完成所有操作，然后逐步添加翻译变得更容易。
最近，我们完成了一个法人实体个人帐户项目，该项目需要多语言支持。截止日期很紧，所以他们最初用一种语言来做所有事情，但为进一步翻译奠定了基础。现在，添加对一种新语言的支持仅需完成一项小任务。如果您需要一次添加多种语言，则会为每种语言创建一个单独的任务。
按角色分离
适用于功能暗示多个角色和用户组操作的情况。在Sportmaster网站上，用户可以具有不同的角色。例如，按角色将用户分为授权用户，匿名用户和呼叫中心用户。后者的角色也可以分为两个角色-它可以是普通用户或管理员。
对于每个角色，我们可以做一个单独的任务。首先显示一个匿名用户，然后在授权用户的任务中添加一些高级功能。并且不要忘记呼叫中心接线员的技术角色及其功能。
错误处理
如果期限紧迫，并且需要尽快提供最低功能，则可以将错误处理纳入单独的任务中。在这里，我们不是在谈论编写测试，而是在处理与站点集成的用户和系统的错误。假设我们正在处理包含产品图块的目录页面。每张卡都有说明，照片和其他信息。
碰巧有些信息不是来自数据库。
也许，如果我们谈论的是品牌或材料，则可以忽略掉它，而根本不显示信息。但是，如果没有提供价格或名称，是否值得出示此卡？
在这种情况下该怎么办？可以在单独的任务中解决此问题，然后处理每个单独的字段。也就是说，如果价格没有到来，那么我们将执行一个操作，则该产品的描述将丢失，而另一个将丢失。用户错误也是如此。如果他输入的内容有误，并且显示了错误，例如“找不到页面”或错误500，我们必须向他显示发生了什么的具体信息，并提供脚本给他下一步可以做什么。
此方法还适用于需要快速获得功能反馈以决定是否保留它的情况。
静态然后动态
这是我最喜欢的方式之一。适用于可能在“存根”上实现功能（即，外部系统尚未准备好支持该功能）的情况。例如，不能通过CMS控制主页上的某些块。或菜单，当我们在代码中创建并将其显示给用户时，但同时不能由企业控制。为了进行更改，企业需要不断地进行开发并要求这样做。
在这里，我们优先考虑用户需求和利润。即使我们可能会遇到一些不便，用户也可以立即获得现成的功能。因此，我们将任务分为几部分，并首先使新块对用户可用，但是企业尚不能直接对其进行管理。但是，然后我们可以与某些系统或数据库集成，业务本身将能够交换项目并自行添加新项目，并且我们将在不参与开发的情况下绘制它们。
我们经常使用这种方法：首先，我们在自己的数据上创建功能，这些功能无法从外部进行控制，然后添加动态信息并开始从第三方系统接收数据。
性能
如果任务总体上是复杂且繁琐的，则不清楚从哪一端进行处理，则可以忽略绩效。首要任务是要提供一种现成的功能，尽管它工作缓慢，但还是可以正常工作。接下来的任务是加快工作速度。例如，搜索商品，应用过滤器，获取任何信息可能是一项缓慢的工作，
有时大部分精力都花在了快速创建功能上，而最初的实现并不那么困难。但是您可以从缓慢的实施中学到很多东西，而且它对用户将有一定的价值，否则他们将无法执行一些重要的操作。在所有这些情况下，任务都分为“使之工作”和“使其快速”。
可能的困难
如果您决定在项目中使用任务分解，那么您遇到的第一个困难很可能就是任务之间的相互依赖。以我的经验，这是最常见的线程阻塞问题。为避免这种情况，应负责任地进行分解并给予足够的时间。
另一个困难是确定分解任务所需的精细程度。在这里，只有常识充当界限。例如，我们采用城市选择组件。它具有按钮，一些文本和一个输入字段。您应该完成多少任务？
我们为自己推论出一条规则，即任务应在不超过一周（约40小时）的时间内完成。我们正在谈论所有阶段：分析，开发，测试的阶段。此外，还考虑了后端和前端开发的两个阶段，包括每个阶段的审查和测试。
史诗的边界并不总是清晰的，这也给我们带来了问题。最近，我们接到了下订单的任务。她的边界在哪里？输出应该是什么？对于我们来说，尚不清楚我们是否需要完成所有功能或选择某些部分。该史诗是否包含付款，还是已经是单独的史诗。
有些任务很难理解如何分解以及何时分解。我们在收到史诗级的任务时分解了大多数任务，但是在某些情况下，例如在分析阶段，则需要这样做。我们接受了这项工作，并认为所有必要的数据已经在我们的集成系统中，但是在分析过程中，结果表明我们要么对数据格式不满意，要么问题在于数据本身的质量，要么需要其他系统进行改进我们已连接。然后，我们必须“在存根上”执行任务，并将另一项添加到待办事项中，我们将在解决主要问题后开始进行工作。
看来，这就是全部。如果您在评论中分享故事，这将是很棒的，您使用的是哪种任务分解方法以及原因。
谢谢阅读！