Привет читатели Хабра!
Введение
Мы успешно подготовили ТЗ и дали ему предварительную оценку, определили выгоды (я считаю определение выгод ключевой частью ТЗ – это наш маяк и проверка, а не напрасно ли мы работаем). Вот и настал радостный миг перехода в производственный ад.
Постоянные встречи, обсуждения, реализация, тестирование, написание документации, вывод в продуктовую среду, сопровождение – все это нас ждет на производстве, как своеобразный вечный двигатель. Нам важно не утонуть в пучине событий и не погрузить в уныние команду реализации, а также нельзя допускать цейтнот.
Постановка задачи
Самое сложное – это организация эффективного производственного процесса. Об этом написано много трудов. Идут постоянные споры о том, какой подход, концепция, framework лучше. Мы не будем их пересказывать или выбирать какой-то конкретный метод, а рассмотрим инструмент, который позволит нам при любом подходе не погрузиться в вечный спор «правильности» организации эффективного производственного процесса.
Суть подхода
Заранее предупрежу, что использую наработки из разных подходов. На мой взгляд, вне зависимости от подхода, данные, которые мы сформируем, нам необходимы для реализации ТЗ (да, даже при продуктовом подходе).
Шаг 1 – структура задач
Я предлагаю взять theme, Epic, Story, Task (их рассмотрим в шаге 2) – эти обозначения большинству из вас известны, я лишь предлагаю наполнить их данными из нашего ТЗ. Позволю себе напомнить, что у каждого процесса обязательно должны быть параметры входа и выхода, без этого хаос вернется в ваш backlog.
Them – это глобальная цель проекта/продукта. Можно применять, когда у вас несколько не связанных друг с другом продуктов.
Epic – принимаем, что это сквозной бизнес-процесс. Такой процесс, который обеспечивает взаимодействие с пользователем от точки входа до выхода, обеспечивая удовлетворение его потребностей.
Story – бизнес-процесс, который отвечает за определенную часть Epic.
Пример 1. Them – домашний быт (тема прям необъятная). Возьмем Epic «Приготовление пищи». Замечу, что с точки зрения процесса не имеет значения, для чего мы готовим пищу – завтрак, обед, полдник, ужин, званый ужин. С точки зрения реализации он сквозной.
Epic включает в себя набор Story:
Определение типа приема пищи
Выбор меню
Оценка потребностей в продуктах для приготовления
Заказ продуктов
Приемка продуктов (процесс необходим, в противном случае оценку потребностей в продуктах будет сделать невозможно)
Выдача продуктов (например, из холодильника)
Приготовление пиши
Сервировка стола
Прием пищи
Эти шаги начинаются как раз от момента принятия решения, что необходимо принять пищу, и идут до самого момента приема. Уверен, многие уже заметили потенциал для фич: оценка калорий, сезонность меню и т.д.
Шаг 2 – обозначение обязательных задач
Для полноценного инструмента нам необходим определенный набор из Task, который позволит связать все в единые цепочки с деревом целей, ТЗ и построением обратной связи.
Пример 2. Список задач я опишу с минимальным количеством артефактов. Прошу учитывать, что это только мое видение, которое позволяет сформировать инструмент для непопадания в производственный ад. На сам подход или распределение ролей это никак не влияет. Нам необходимы следующие задачи, в скобках примеры артефактов:
Бизнес-анализ (CJM, макеты, use case, описание бизнес-процесса)
Системный анализ (ER-диаграмма, Sequence-диаграмма, описание методов взаимодействия, описание событийной модели и брокера)
Инфраструктурные работы (разворачивание стендов и ПО на них)
Разработка DB
Разработка Back
Разработка Front
Тестирование
Документирование (руководство пользователя, руководство администратора)
Приемка (прием функционала и его последующая демонстрация)
Повторюсь, подобные задачи необходимы для построения инструмента, который избавит нас от производственного ада.
Шаг 3 – необходимые связи и смыслы
Этот шаг позволяет скрепить все наши задачи с ТЗ. При внесении изменений такой шаг позволит нам с минимальной корректировкой данных подготовить обновленную документацию.
На каждом этапе мы используем одни и те же use case. Именно они являются источником данных для бизнес-анализа, описания диаграммы последовательностей (sequence), тестирования (на основе use case тестировщик проверяет работоспособность функционала), документирования, демонстрации.
Именно use case отражает последовательность действий.
Шаг 4 – построение обратной связи
Важным шагом при передаче результатов в продуктивную среду является поддержка и сопровождение реализации. Особенно важны связи. Все должно быть связано, а из любой задачи должна быть возможность перейти в компонент и конкретную цель. Многие подходы к организации производства как раз и предлагают постоянную сверку с целями.
Также данный подход позволит оценить не только качество организации производственного процесса, но и качество реализации. Это отдельный многогранный вопрос, который не является предметом рассмотрения в этой статье.
Выводы
Для достижения понятного производственного процесса нам необходимо реализовать структуру задач (отличная статья на хабре как структура помогает), которая будет соответствовать нашему ТЗ. Требуется выстроить систему сверки задач и целей. Так же я обычно добавляю таблицу по контракту в confluence (знаю они ушли, уверен наши люди смогут сделать, как минимум не хуже)
Таким образом мы избежим производственного ада, а каждый участник команды будет понимать, что происходит.
Надеюсь, мне удалось предложить инструмент, который не вызовет новый спор о подходах и практиках организации производственного процесса. Мы рассмотрели лишь инструмент для формирования данных о ходе реализации с выверкой по целям реализации. Как именно организовывать процесс работы, зависит уже от команды, ее опыта и сложившейся в компании практики. Прислушивайтесь к коллегам, и всё будет хорошо!
