Проблема движения задачи от бизнес-идеи до реализации - не новая, и каждая команда пытается решить её (более или менее успешно) в соответствии со своим опытом и пониманием этой проблемы. Существующие методологии, призванные помогать, зачастую только запутывают. Чтобы срезать острые углы и недопонимания, организуются планирования и груминги (grooming), которые сжигают рабочее время команд и иногда запутывают ещё больше. Главная задача этого руководства - организовать бесшовное и бесконфликтное движение задачи от бизнес-требований до технической реализации. Мы опустим такие важные элементы разработки, как бурные обсуждения и даже груминги, сосредоточив внимание на исполнении специалистами своих обязанностей и передаче задачи дальше, в соответствии её с жизненным циклом. Я исхожу из того, что навыки членов команды соответствуют их ролям, и что все выполняют свои задачи на приемлемом уровне. Можно выделить четыре основных этапа решения бизнес-задачи, которые сменяют друг друга в рамках задачи: бизнес-требование, функциональное требование, техническое задание и техническая реализация. Бизнес-требование - это описание задачи в том виде, в котором она получена от бизнеса. Для этого применяют общие понятия из предметной области продукта. Я, как пользователь, хочу зайти на сайт, используя свои логин и пароль. Я, как пользователь, хочу загрузить свою фотографию в профиль и чтобы она отображалась на аватарке. Функциональное требование - это описание функции, выполняемой приложением, в виде последовательности действий пользователя и результата этих действий. В нём описывается бизнес-требование языком, понятным для аналитика - общими понятиями из предметной области разработки. Функциональное требование 1: Пользователь вводит логин и пароль на веб-странице входа и авторизуется в системе. Функциональное требование 2: Пользователь загружает файл, файл сохраняется в файловом хранилище. Как мы видим из примера выше, в функциональном требовании используются сущности из предметной области веб-разработки: исчезли слова "сайт", "фотография", "аватар", появились слова "страница", "файл", "авторизация". Техническое задание - это описание конкретных шагов, с помощью которых разработчики должны реализовать функциональное требование. Для описания технического задания необходимо знать не только предметную область, но и технические детали реализации приложения. Важно: задача может быть взята в работу разработчиком только в состоянии технического задания. Бывают ситуации, когда разработчик самостоятельно преобразует функциональное требование в техническое задание, но в таких случаях он действует не как разработчик, а как системный аналитик - такие ситуации будут описаны ниже. Реализовать хранение данных в таблице users, включающей в себя следующие поля: Поле Обязательность Тип id true uuid login true varchar(512) password true varchar(512) description false text Пароль должен храниться в зашифрованном виде, метод шифрования SHA512. Техническая реализация - это описание конкретных изменений в коде, сделанных разработчиком в рамках выполнения технического задания. В рамках задачи было реализовано следующее: Созданы таблицы users, authorities. Создан эндпоинт: /users/login Реализована логика авторизации пользователя. Описание технической реализации является верхнеуровневым и обычно описывается разработчиком в комментарии к задаче. Теперь, когда мы разобрали компоненты жизненного цикла задачи, давайте обратим внимание на основные роли аналитика. Их две: бизнес-аналитик и системный аналитик. Бизнес-аналитик работает с бизнес-задачами и функциональными требованиями, на стыке предметной области продукта и общих понятий предметной области разработки. Например, если идёт речь о разработке интернет-магазина, бизнес-аналитик хорошо понимает, как работает интернет-магазин, как происходит оформление заказа, доставка, клиентская поддержка. Он знает основные категории товарной номенклатуры. В то же время, бизнес-аналитик поверхностно разбирается в разработке. Он понимает, что такое фронтенд, бэкенд, как они обмениваются информацией, что такое база данных и так далее. Бизнес-аналитик общается с заказчиком и получает от него бизнес-требования, которые он хорошо понимает в силу своих компетенций. Системный аналитик отлично разбирается во внутренней реализации приложения. Он знает создаваемый продукт изнутри: имена таблиц базы данных, наименования полей моделей API, применяемые алгоритмы. Как правило, у него есть специальное техническое образование. Роль системного аналитика зачастую исполняет разработчик уровня Senior. Теперь, когда мы поверхностно разобрали роли аналитиков, можно перейти к профессиональным уровням разработчиков. Существуют три профессиональных уровня разработчиков: Junior, Middle, Senior. Четвёртый уровень - Tech Lead - как правило, не участвует в выполнении задач, и его мы разбирать не будем. У каждого профессионального уровня своя глубина компетенций и, соответственно, круг обязанностей и полномочий. Профессиональные уровни разработчиков нас интересуют лишь применительно к тематике обработки и выполнения задач. Junior-разработчик выполняет самые простые и низкоуровневые задачи. От него не требуется детальное знание предметной области продукта. Задачи, назначаемые Junior-разработчику, должны быть описаны на уровне очень подробного технического задания. Middle-разработчику, в зависимости от своей квалификации внутри профессионального уровня (low, middle, high), ставятся технические задания разной степени детализации. Если для low middle нужно расписывать всё так же подробно, как и для junior, то для high middle достаточно описать верхнеуровнево. Middle-разработчик обычно слабо разбирается в предметной области продукта, и от него не требуется разбираться очень хорошо. Senior-разработчик способен не только выполнить задачи любой сложности, но и преобразовывать функциональное требование в техническое задание. Он обязан хорошо разбираться в предметной области продукта. Мы разобрались с ролями специалистов и можем перейти к самой главной части поста - трансформации задачи из одного состояния в другое. Функциональное требование - это детальное описание поведения системы, на основе бизнес-требований: функции приложения, с которыми взаимодействует пользователь (видит на экране, кликает, вводит данные и так далее). Функциональное требование делится на две части: функцию и поведение. Функция описывает, что делает система, поведение - как система исполняет эту функцию. Пример трансформации бизнес-требования в функциональное требование и декомпозиции его на функцию и поведение: Бизнес-требование: Я, как пользователь, хочу зайти на сайт, используя свои логин и пароль. Функциональное требование: Пользователь авторизуется в системе. Функция: Авторизация в системе. Поведение: Система получает от пользователя логин и пароль через специальную форму авторизации. После чего, система проверяет логин и пароль на наличие в базе данных. Если пара логин-пароль существует, система возвращает положительный ответ и авторизационный токен. Как мы видим из примера выше, функциональные требования включают в себя оба компонента: функцию и поведение. Функциональные требования описаны как можно более детально, но не выходя за границы общих понятий предметной области разработки. Техническое задание - это как можно более подробное описание будущей реализации функционального требования. Оно включает в себя описание всех компонентов, которые будут созданы или изменены в рамках работы над задачей - объекты, эндпоинты, имена полей, алгоритмы и т. д. Если в техническом задании описывается эндпоинт, нужно описать все его значимые атрибуты: HTTP-метод, иерархическую часть пути, переменные пути, параметры запроса, входящие и исходящие объекты. Если в техническом задании описывается объект / структура данных, то необходимо указать имена полей, их тип, обязательность, описание поля (что оно делает). Если присутствует алгоритм, его нужно описать предельно точно, чтобы у разработчика не возникло разночтений. Если описано преобразование из одного объекта в другой, то сопоставление нужно описать предельно чётко, по каждому полю, с их типами и обязательностью. Давайте возьмём функциональное требование из примера выше и преобразуем его в техническое задание: Функциональное требование: Пользователь авторизуется в системе. Функция: Авторизация в системе. Поведение: Система получает от пользователя логин и пароль через специальную форму авторизации. После чего, система проверяет логин и пароль на наличие в базе данных. Если пара логин-пароль существует, система возвращает положительный ответ и авторизационный токен. Техническое задание: Реализовать авторизацию пользователя, следующим образом: Создать таблицу users в базе данных, схема main: Имя поля Тип Описание id uuid primary key, генерация на стороне базы данных Идентификатор пользователя  login varchar(512), индексация поля Логин пользователя password varchar(128) Пароль, зашифрованный в формате sha256 Создать эндпоинт авторизации. HTTP-метод: POST Path: /users/login Тело запроса: Имя поля Обязательность Тип login да String password да String Ответ (в случае авторизации): HTTP-статус: 200 Объект AuthToken: Имя поля Обязательность Тип authToken да String refreshToken да String authTokenExpirationTime да Int refreshTokenExpirationTime да Int Алгоритм работы авторизации: При получении запроса на авторизацию, сервис ищет пользователя в таблице users по полю login. Если пользователь не найден, сервис возвращает статус 401 Unauthorized, с сообщением "Пользователь не найден". Если пользователь найден, сервис создаёт хэш-сумму полученного пароля и сличает с пользовательским паролем из базы данных. При несовпадении паролей, сервис возвращает HTTP-статус 401 Unaurhorized, с сообщением: "Указанный пароль не верен". При совпадении паролей, сервис генерирует авторизационный токен и рефреш-токен и возвращает объект AuthToken. Мы разобрались, какие бывают состояния задачи и как происходит трансформация из одного состояния в другое. Но кто будет этим заниматься? Чтобы организовать бесшовное и бесконфликтное движение задачи по всем стадиям от бизнес-требований до технической реализации, команда должна быть не только достаточно укомплектованной, но и, по возможности, не "переполненной" специалистами. Состав команды должен быть сбалансирован так, чтобы было кому брать задачу в текущем состоянии и трансформировать в следующее. Мы уже знаем, что: Senior-разработчик преобразует функциональное требование в техническое задание. Это значит, что он может брать на себя обязанности системного аналитика. бизнес-аналитик преобразует бизнес-требование в функциональное требование. Разработчик (любого уровня) реализует техническое задание. Таким образом, чтобы команда считалась укомплектованной, в ней должны быть специалисты со всеми тремя вышеописанными компетенциями. Идеальный вариант: Бизнес-аналитик + системный аналитик + разработчик. В этом случае, каждый на своём месте и каждый делает свою работу. Но может быть и такой вариант: Бизнес-аналитик + Senior-разработчик. В таком случае, Senior-разработчик будет брать на себя обязанности системного аналитика и сам же реализовывать полученное техническое задание. Да, объём обязанностей смещается в сторону разработчика, но такой вариант выглядит вполне рабочим. Впрочем, если аналитик может быть и бизнес-, и системным, то возможен и такой вариант: Аналитик (бизнес+системный) + разработчик не ниже уровня Middle. При любой из этих комбинаций, задача не подвиснет из-за разрыва в компетенциях, её всегда будет кому взять в текущем состоянии и трансформировать в следующее. Но как быть, если в команде есть и системный аналитик, и Senior-разработчик? Возникает риск конфликта компетенций: трансформировать функциональное требование в техническое задание под силу обоим специалистам, но у каждого будет разное видение. Я рекомендую отдавать приоритет разработчику, поскольку техническая реализация и её дальнейшая поддержка будет на его ответственности. Но тогда он должен подробно описать техническую реализацию, а системный аналитик - с ней ознакомиться, чтобы быть в курсе реализаций в коде и быть готовым перехватить задачи по системной аналитике, в случае необходимости. Итак, наша команда укомплектована всеми необходимыми специалистами в самом, пожалуй, распространённом составе. Есть представитель бизнеса - Владелец Продукта. Есть бизнес-аналитик. Есть Senior-разработчики (фронтэнд и бэкенд). Посмотрим, как они работают. Действующие лица: Владелец продукта (он же, скрам-мастер), Бизнес-аналитик, Senior Backend Developer, Senior Frontend Developer. Акт I. Груминг. Владелец продукта: Я хочу, чтобы в будущем спринте были реализованы фичи А и Б. Бизнес-аналитик: Я обсудила с владельцем продукта эти фичи заранее. Я создала две Stories, А и Б. Я описала в них функциональные требования. Коллеги-разработчики, посмотрите, пожалуйста, эти фичи и декомпозируйте их. Senior Backend Developer, Senior Frontend Developer (хором): Спасибо, берём в работу. Владелец продукта: Всем спасибо, увидимся через 3 дня. Акт II. Планирование. Владелец продукта: Коллеги-разработчики, как ваши дела? Senior Backend Developer, Senior Frontend Developer (хором): Мы обсудили каждую фичу, изучили функциональные требования и декомпозировали их в технические требования, создали подзадачи. Мы оценили каждую подзадачу в сторипоинтах и готовы к планированию. Владелец Продукта: Отлично, коллеги. Спасибо, что подготовились к планированию. Сейчас мы за 15 минут раскидаем подзадачи по исполнителям и пойдём работать дальше. Занавес. В этой пьесе нет сильной драматургии. В ней нет даже конфликта. Потому что большая часть работы была сделана исполнителями заранее, и они пришли подготовленными. Организация грумингов и планирований - хоть и напрямую касается жизненного цикла задачи, но всё же, тема для отдельного поста. Возможно, мы поговорим об этом позже.  backend.developer { java, kotlin } in Sber