Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки:

💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?”"

В целом статья неплохая, но есть нюанс. Как говорил человек, который создал роль Product Owner и Scrum-Master:

💬 "So I split the role in two, giving the Scrum Master the how and the Product Owner the what.
<...>
The Scrum Master and the team are responsible for how fast they're going and how much faster they can get. The Product Owner is accountable for translating the team's productivity into value."
—"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeffrey Sutherland

Именно команда ответственна за скорость разработки. А скорость разработки напрямую зависит от внутреннего качества программы, т.е. за Software Design. Говоря архитектурным языком, команда отвечает за Quality Attribute Modifiability.

Product Owner описывает в User Story функциональный инкремент, в то время как команда декомпозирует его на Tasks, которые описывают системный инкремент.

Одна и та же функция может поддерживаться различными вариантами конструкций.
В качестве подпорки под дверь можно использовать конструкцию в виде камня, а можно и в виде книги.

И, наоборот, одна и та же конструкция может выполнять разные функции. Например, тот же камень можно использовать в качестве функции якоря, или орехи им колоть. Это т.н. дихотомия функции и конструкции.

Конструкция может совпадать с функцией, а может не совпадать. Как и Bounded Context (Solution Space) может совпадать с Subdomain (Problem Space), а может не совпадать.

На простом примере: у ножниц два функциональных компонента, один - чтоб держать, а другой - чтоб резать. Но конструктивно ножницы состоят их двух половинок и гвоздика. Иногда конструктивный элемент называют модулем, а функциональный - компонентом.

Но вернемся к User Story. Поясню на примере. Камень сам по себе бесполезен для разжигания костра. Два камня бесполезны сами по себе. Но два камня во взаимодействии могут высекать искру. У них появилось новое, emergent свойство, т.е. они образовали систему. Система обладает свойствами, которыми её элементы по отдельности не обладают.

Так вот, Product Owner пишет "нужна искра". Это функциональный инкремент, добавляющий новую, видимую функциональность в систему, которую можно протестировать приёмочными тестами уровня компонентных или сквозных тестов.

Отдельно взятый камень протестировать на уровне компонента или системы нельзя, т.к. он сам по себе не обладает emergent свойствами. Они появятся только тогда, когда будут завершены все необходимые системные инкременты, которые образуют систему.

Product Owner не пишет в User Story "взять один камень, взять другой камень". Это пишет команда в Tasks, на которые декомпозируется User Story. Product Owner отвечат за функцию, а команда - за конструкцию.

Это нерушимое правило, нарушение которого приводит к накоплению техдолга и к деградации темпов разработки, что, в свою очередь, приводит к утрате экономической целесообразности итеративной разработки, поскольку внесение изменений становится дороже заблаговременного проектирования. На эту тему есть у меня хороший Long Read.

Команда не должна согласовывать с Product Owner системный инкремент. Вот что по этому поводу говорит Open Agile Architecture Standard:

💬 Fowler would strongly promote the view that code refactoring requires no justification; rather it is part of a developer's "day job". This does not mean that we have to take on a massive code restructuring exercise for a legacy codebase; on the contrary, there may be no reason whatsoever to restructure the code for a stable legacy project. However, that said, developers should refactor their code when the opportunity arises.
—"Open Agile Architecture™" by The Open Group, Chapter "6.5.1. Justifying Ongoing Investment in Architectural Refactoring"

Подробнее здесь.

Но тут есть еще один нюанс, о котором - в следующем посте.