1.3. Основные термины и определения

В настоящем документе используются следующие термины и определения:

• Заказчик/Пользователь — физическое или юридическое лицо, использующее результаты работы команды разработки.
• Бэклог продукта — упорядоченный список всего, что, как известно, необходимо в продукте, являющийся единым источником требований к любым изменениям.
• Scrum-команда — самоорганизующаяся команда, состоящая из Scrum-мастера, Владельца продукта и команды разработки.
• Смежные отделы — подразделения организации, взаимодействующие с командой разработки: отдел бизнес-анализа, отдел тестирования (QA), отдел эксплуатации (DevOps), отдел безопасности (InfoSec), отдел технической поддержки и отдел управления продуктом (Product Management).

2.2. Ожидаемые результаты работы

Разработчик должен обеспечивать:

• Своевременную и качественную реализацию пользовательских историй и задач из бэклога продукта.
• Стабильную и бесперебойную работу разработанных сервисов в продуктивной среде.
• Соблюдение стандартов кодирования, архитектуры и безопасности.
• Активное участие в улучшении процессов разработки и командной работы.
• Эффективную коммуникацию с командой и смежными отделами для быстрого снятия блокеров и согласования решений.

3.2. Матрица ответственности (RACI)

Взаимодействие со смежными отделами строится на основе матрицы ответственности RACI (Responsible, Accountable, Consulted, Informed):

• Ответственный за выполнение (R): Разработчик (исполнение задач).
• Утверждающий (A): Владелец продукта (утверждение требований и приоритетов), Тимлид (утверждение технических решений).
• Консультируемый (C): Бизнес-аналитик (пояснение требований), Архитектор (архитектурные вопросы), DevOps (развертывание и инфраструктура), QA (сценарии тестирования), InfoSec (безопасность решений).
• Информируемый (I): Менеджер проекта, Scrum-мастер, остальная часть команды, отдел поддержки.

3.3. Взаимодействие со смежными отделами

Разработчик взаимодействует со следующими отделами:

• Отдел бизнес-анализа: уточнение требований, формализация задач и согласование ожидаемых результатов.
• Отдел тестирования (QA): совместная отладка, передача функциональности на тестирование, согласование планов тестирования и обсуждение найденных дефектов.
• Отдел эксплуатации (DevOps): вопросы развертывания, управления конфигурациями, CI/CD, мониторинга и логирования.
• Отдел безопасности (InfoSec): аудит кода, проверка безопасности приложений и соответствие политикам безопасности.
• Отдел технической поддержки: передача знаний о реализованном функционале, помощь в расследовании инцидентов и документирование проблем.

4.1. Разработка и поддержка программного обеспечения

Разработчик обязан:

• Разрабатывать новый и поддерживать существующий код для продуктов компании на закрепленных технологических стеках (Java, Go, .Net, 1С).
• Проводить рефакторинг кода для улучшения его читаемости, производительности и поддерживаемости.
• Писать модульные и интеграционные тесты для обеспечения высокого качества кода.
• Участвовать в инцидентах и аварийных ситуациях для быстрого восстановления работоспособности сервисов.
• Документировать разработанный код, API и ключевые архитектурные решения.

4.2. Работа с требованиями и бэклогом продукта

Разработчик обязан:

• Активно участвовать в уточнении и оценке бизнес-требований на встречах по бэклогу (Backlog Refinement).
• Оценивать трудоемкость задач в story points или часах, аргументируя свою оценку техническими рисками и неопределенностями.
• Брать в работу только те задачи, которые готовы к реализации (содержат четкое описание, критерии приемки и согласованы с заказчиком).
• Своевременно информировать Scrum-мастера и Владельца продукта о проблемах с пониманием требований или возникших блокерах.

4.3. Участие в Scrum-церемониях

Разработчик обязан принимать участие во всех ключевых Scrum-церемониях:

• Планирование спринта (Sprint Planning): совместно с командой определять объем работ на предстоящий спринт.
• Ежедневный стендап (Daily Scrum): предоставлять отчет о проделанной работе, планах на день и фиксировать возникшие проблемы.
• Демонстрация результатов спринта (Sprint Review): демонстрировать готовый функционал заказчику и собирать обратную связь.
• Ретроспектива (Sprint Retrospective): анализировать прошедший спринт, предлагать улучшения в процессах разработки и взаимодействия.

4.4. Коммуникация в команде и смежными отделами

Разработчик обязан:

• Активно и конструктивно участвовать в обсуждениях технических и продуктовых решений.
• При возникновении вопросов, требующих экспертизы смежных отделов, самостоятельно инициировать встречи и коммуникацию.
• Привлекать бизнес-аналитиков для уточнения требований перед началом реализации сложных задач.
• Взаимодействовать с командой QA для обеспечения качества и согласования автоматизированных тестов.
• Взаимодействовать с командой DevOps для обеспечения плавного и автоматизированного развертывания в среду тестирования и продуктивную среду.

4.5. Передача знаний и наставничество

Разработчик обязан:

• Участвовать в код-ревью (Code Review) и проводить технические сессии для обмена знаниями внутри команды.
• Адаптировать новые компоненты системы и знакомить с ними отдел технической поддержки.
• Составлять и поддерживать актуальную документацию по разработанным функциям для коллег и смежных отделов.

5.1. Право на принятие решений

Разработчик имеет право на:

• Принятие технических решений в рамках задачи при условии соблюдения архитектурных стандартов.
• Запрос на изменение и уточнение требований у Владельца продукта в случае их неясности или противоречивости.
• Принятие самостоятельного решения о необходимости привлечения смежных отделов для согласования технических или продуктовых решений.

5.2. Право на доступ к ресурсам и информации

Разработчик имеет право на:

• Доступ к кодовой базе, документации, инструментам разработки и тестирования, необходимым для выполнения задач.
• Доступ к контактным данным и возможность коммуникации с любыми представителями смежных отделов для решения рабочих вопросов.
• Обращение к своему руководителю или к руководству смежных отделов с предложениями по улучшению процессов взаимодействия.

6.1. Ответственность за качество кода и продукта

Разработчик несет ответственность за:

• Качество, надежность и безопасность разработанного им кода и программного обеспечения.
• Соответствие кода принятым в организации стандартам кодирования и лучшим практикам.
• Своевременное выявление и исправление дефектов в собственном коде.
• Целостность данных и сохранность бизнес-логики при внесении изменений.

7.1. Образование и опыт работы

Для занятия должности разработчика необходимо:

• Высшее или среднее профессиональное образование в области IT, математики, физики или смежных дисциплин.
• Опыт коммерческой разработки от 2-х лет на соответствующих языках и технологиях (Java, Go, .Net, 1С).
• Знание принципов объектно-ориентированного программирования, паттернов проектирования и архитектурных подходов.

7.2. Профессиональные навыки

Разработчик должен обладать:

• Глубокими знаниями выбранного языка программирования и его экосистемы (фреймворки, библиотеки, утилиты).
• Навыками работы с системами контроля версий (Git).
• Знанием SQL и умением работать с реляционными и NoSQL базами данных.
• Пониманием принципов CI/CD, контейнеризации (Docker) и оркестрации (Kubernetes).
• Навыками написания тестов (Unit, Integration, E2E).
• Опытом работы в рамках Agile-методологий (Scrum, Kanban).

7.3. Надпрофессиональные компетенции (Soft Skills)

Разработчик должен обладать развитыми коммуникативными навыками для эффективного командного взаимодействия:

• Умение ясно и четко излагать свои мысли как в устной, так и в письменной форме.
• Способность конструктивно вести диалог и отстаивать свою точку зрения.
• Эмпатия и умение слушать коллег из смежных отделов для понимания их потребностей и ограничений.
• Навыки фасилитации и проведения технических встреч и обсуждений.

9.1. Скорость и качество разработки

KPI разработчика включают:

• Velocity (скорость команды): количество выполненных story points за спринт, вклад в общую скорость команды.
• Density (плотность дефектов): количество найденных дефектов в пересчете на 100 строк кода или на реализованную пользовательскую историю.
• Code Review Cycle Time: среднее время, затраченное на код-ревью и его успешное завершение.

9.2. Процессные и коммуникационные KPI

Ключевые показатели эффективности в области командного взаимодействия:

• «Дней без блокеров»: количество дней в спринте, когда разработчик не был заблокирован зависимостями от смежных отделов или неясными требованиями.
• «Время решения инцидента» (MTTR): среднее время, затраченное на диагностику и исправление критического инцидента, совместно с другими отделами.
• Выполнение обязательств по спринту (Sprint Commitment Accuracy): процент запланированных задач, успешно завершенных к концу спринта.
• Регулярное проведение технических сессий и передача знаний смежным отделам.

10.1. Процесс реализации новой функциональности

Стандартный сценарий работы над задачей:

• Шаг 1. Анализ: Изучение задачи в системе управления проектами (Jira). При необходимости — уточнение требований с бизнес-аналитиком.
• Шаг 2. Проектирование: Создание технического решения. Обсуждение с архитектором и тимлидом для крупных или архитектурно-значимых изменений.
• Шаг 3. Разработка: Написание кода, написание юнит-тестов. Проверка качества кода линтерами.
• Шаг 4. Код-ревью: Создание Merge Request (MR) в Git. Прохождение ревью минимум одним другим разработчиком.
• Шаг 5. Интеграция и развертывание: После успешного ревью и прохождения всех CI-проверок, код объединяется с основной веткой (main) и автоматически развертывается на стенде для интеграционного тестирования командой DevOps.
• Шаг 6. Тестирование: Передача задачи в QA с приложением всех необходимых артефактов. Совместная работа с QA по отладке.
• Шаг 7. Демо: Демонстрация функциональности на Sprint Review.
• Шаг 8. Выкатка в продуктив: После успешного тестирования и согласования с владельцем продукта, задача деплоится в продуктивную среду по расписанию релизного цикла.

10.2. Процесс взаимодействия с отделом эксплуатации (DevOps)

Типовой сценарий взаимодействия:

• Разработчик подготавливает код и добавляет в репозиторий необходимые файлы конфигурации (Dockerfile, docker-compose.yml, helm charts).
• Создает Merge Request. В описании указывает переменные окружения, необходимые для работы приложения.
• После успешного ревью, разработчик уведомляет DevOps-инженера в чате (например, #devops) о готовности к деплою на тестовый стенд.
• DevOps-инженер производит деплой с использованием внутреннего CI/CD (например, GitLab CI).
• В случае неудачного деплоя или проблем с инфраструктурой, разработчик совместно с DevOps проводит анализ логов и ошибок.
• После успешного развертывания на тестовом стенде разработчик запускает smoke-тесты для проверки критической функциональности.

10.3. Процесс взаимодействия с командой тестирования (QA)

Типовой сценарий:

• Разработчик завершает разработку задачи и переводит ее в статус «Ready for QA» в Jira.
• В комментариях к задаче разработчик описывает, что было реализовано, и дает инструкции для тестирования (логины, ссылки, данные).
• QA-инженер берет задачу в работу, проводит функциональное, регрессионное и интеграционное тестирование.
• В случае нахождения дефекта, QA создает баг-репорт с приложенными логами, скриншотами и четким описанием шагов воспроизведения.
• Разработчик получает уведомление о баге, берет его в работу, исправляет и возвращает задачу в QA для повторного тестирования.
• Цикл повторяется до тех пор, пока функциональность не будет полностью соответствовать критериям приемки.

10.4. Процесс взаимодействия с отделом бизнес-анализа

Типовой сценарий:

• На встрече по уточнению требований (Backlog Grooming) разработчик задает вопросы бизнес-аналитику для устранения неопределенностей.
• Для сложных технических задач, влияющих на архитектуру, разработчик может инициировать отдельную встречу с бизнес-аналитиком и Владельцем продукта.
• При разработке прототипа или сложного расчета, разработчик предоставляет бизнес-аналитику промежуточные результаты для проверки на соответствие бизнес-логике.
• После завершения задачи, разработчик совместно с бизнес-аналитиком проверяет соответствие реализованного функционала исходным бизнес-требованиям.

10.5. Чек-лист для ежедневного стендапа

Для эффективного участия в ежедневном стендапе разработчик должен быть готов ответить на три основных вопроса:

• «Что я делал вчера?» — перечислить выполненные задачи и достигнутые результаты.
• «Что я планирую делать сегодня?» — описать задачи на текущий день и ожидаемые результаты.
• «Какие есть блокеры или проблемы?» — указать любые препятствия, которые мешают работе и требуют помощи (например, ожидание ответа от смежного отдела, неясные требования, техническая проблема).

10.6. Чек-лист для ретроспективы спринта

Для эффективного участия в ретроспективе разработчик заранее готовит следующие пункты:

• «Что прошло хорошо?» — отметить успешные аспекты прошедшего спринта (например, удачное решение сложной проблемы, отличная работа в паре, эффективное взаимодействие с QA).
• «Что пошло не так?» — объективно указать на проблемы и ошибки (сложность внедрения новой технологии, задержки из-за нечетких требований, технический долг).
• «Что можно улучшить?» — предложить конкретные действия по улучшению процессов (например, чаще проводить демо, внедрить новый инструмент для анализа кода, улучшить коммуникацию с DevOps).
• Быть готовым предложить свой план действий для реализации этих улучшений в следующем спринте.

10.7. Чек-лист для демонстрации результатов спринта

Подготовка к демо:

• Проверка работоспособности — за несколько часов до демо убедиться, что все реализованные задачи работают на демо-стенде.
• Подготовка сценария — продумать и отрепетировать сценарий демонстрации, чтобы показать функциональность с точки зрения пользователя.
• Выделение ключевых фич — сфокусироваться на важных бизнес-фичах, а не на технических деталях (если это не техническое демо).
• Готовность к вопросам — быть готовым ответить на вопросы заказчика и смежных отделов о реализации и ограничениях.
• Помнить, что цель демо — получить обратную связь, а не просто отчитаться о работе.