Иерархия типов задач

(https://www.atlassian.com/ru/software/jira/guides/issues/overview#what-are-issue-types)[https://www.atlassian.com/ru/software/jira/guides/issues/overview#what-are-issue-types] - вот такую иерархию предлагает jira. В целом она кажется здравой, понятной и всеобъемлющей.

tndt-139 - мои раздумия по иерархии

Связи здач

• Связана - задачи независимы и могут делаться в любом порядке, но полезно иметь ссылку между ними. Связь одноранговая
• Зависит - что-то среднее
• Блокирует/Блокируется - Задачу невозможно продвинуть на более поздний этап, чем блокирующая. Например закрыть при незакрытой блокирующей, или начать работу до начала работы над блокирующей
• Подзадача/композитная - вот эта наверное не особо нужна, или нужна, разбить задачу, которая очень велика, но атомарна на несколько неполностью функциональных, но логически завершенных кусков, отдельно поревьюить, вместе вылить. Т.е. композитная задача это задача.

Объединения задач

Исследуется в tndt-139

• Подзадача/композитная - самое мелкое объединение, как новый тип задачи композитная.
• История
• Эпик/Тема
• Релиз это отдельная система, но сюда допишу, чтобы было видно место в иерархии
• Категория

В agile История - это маленький эпик внутри команды, длинной в 1 спринт (т.е. в нем не будет одновременно исследований и продуктовых, но может быть будут связанные баги) А эпик, это очень длинная история в несколько спринтов, в котором да, будут и исследования, и продуктовые задачи, и тестирование, и отлов багов. Что-то что займет львиную часть релиза. *Может быть и несколько релизов, хотя так это большt напоминает категорию. Но у нас есть например столь большие эпики по вводу новых систем, что мы их сознательно делаем в несколько релизов, в первом самый базовый, и, часто урезанный (но законченный и готовый функционал), в следующих нескольких релизах доделываем тот основной функционал, что задумали. Но в отличии от категории этот набор закончен. Например Table - такой эпик, в первом релизе мы его создаем, подключаем к первой таблице, повторяем существующий функционал и чуть-чуть его расширяем одним фильтром (выглядит это бедно, но это база, которая уже делает чуть лучше, чем было). В следующих релизах мы увеличиваем количество фильтров до базового, в основном используемого набора, и только после их реализации считаем эпик завершенным. Дальнейшие задачи по компоненту будут уже в рамках категории, так как не важны или не задуманы изначально, а будут появляться в процессе использования системы. Т.е. такие эпики выходящие за границы релиза почти всегда будут порождать новую категорию.

Реализация

Пока кажется проще держать две сущности связи, для связи вперед и назад.

tndt-6 - первая задача по теме.