Yabbi SSP

Appearance

On this page

Регламент по работе с задачами ​

Общие положения ​

  • Наша команда работает в системе YouTrack на Kanban-доске
  • Задачи проходят полный поэтапный флоу согласно статусам на доске
  • Работа ведется по двухнедельным спринтам
  • В первую неделю спринта проводится наполнение PBR из Backlog
  • Во вторую неделю текущего спринта задачи в PBR подготавливаются к следующему спринту (описываются, декомпозируются)
  • По окончании спринта наполняется новый спринт из PBR
  • Задачи в Backlog заводятся в любое время по мере их появления
  • Ретроспективы проводятся по необходимости
  • Основная разработка ведется на основной доске проекта SSP+SSPE+SDK
  • Для задач команды SDK в спринте используется доска SDK Tech Specifications, для задач поддержки команды SDK — SDK Tech Support
  • Ответственность за перевод задачи из одного статуса в другой распределена среди членов команды в зависимости от роли и этапа работы над задачей.

Общий workflow по работе с задачами ​

  • Общие правила для разработчика

    1. Всегда одна задача в In Progress: В любой момент времени разработчик должен работать только над одной задачей, которая находится в статусе "In Progress".
    2. Задача в In Progress — это та, над которой разработчик работает: Если разработчик начинает работу над задачей, она должна быть переведена в этот статус.
    3. Задача должна быть оценена: Перед началом работы задача должна иметь оценку времени или сложности.
    4. Переключение задач: Если разработчик переключается на другую задачу, он обязан перевести текущую задачу в статус Pending, а новую — в In Progress
    5. Отсутствие задачи в In Progress: Если у разработчика нет задачи в статусе In Progress, это означает, что он свободен и доступен для работы.
    6. Переключение на более чем 1 час: Если разработчик переключается на что-то более чем на час, необходимо создать соответствующую задачу (ее может назначить менеджер или разработчик самостоятельно). Например: это может быть срочный баг, собеседование и пр.
    7. Подготовка перед переводом в In Progress: Перед переводом задачи в статус In Progress, разработчику следует задать все необходимые вопросы. Когда ему станет полностью понятно, что делать, задача переводится в "In Progress".
    8. Завершение задачи. После заверешения работы над задачей, разработчик меняется статус у задачи с In-Progress на Code Review и прикрепляет соответсвующую MR в комментариях к задаче. В некоторых случах статус задачи может быть изменен на другой, если ревью не требуется.

  • Работа разработчика с задачей

    Разработчик может переводить задачу:

    • Из статуса Open в статусы Pending, In-Progress
    • Из статуса In-Progressв Code Review и Ready for Test

    Open задача в очереди, перевод задачи в статус In-Progress означает, что разработчик приступил к выполнению задачи, перевод задачи в статус Code Review означает, что работа над задачей заверешена и ответственный куратор должен посмотреть и принять MR

  • Оценка задачи

    • Первичная оценка задачи (чаще всего эпика) проводится на планировании, она не является финальной, а всего лишь общим ожиданием
    • Перед началом работы разработчик оценивает и проставляет или корректирует оценку задачи после уточнения всех вопросов и понимания объема работы

  • Приоритет задачи

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

  • Работа с вопросами по задаче

    • Все вопросы и уточнения по задачам обсуждаются через комментарии в YouTrack
    • Если задача требует уточнений, участники проекта оставляют четко сформулированные вопросы в комментариях к задаче
    • Для быстрой коммуникации используется @тег ответственного за задачу или уточнение
    • Ответственный должен предоставить ответ или решение в комментариях, чтобы работа над задачей могла продолжиться
    • Если вопросы блокируют выполнение задачи, статус задачи должен быть сменен на Pending

  • Отсутствие задачи на доске

    • Если разработчик работает над чем-то, но эта задача не заведена на доске, необходимо сообщить об этом PM для добавления задачи в систему.
    • Если у разработчика закончились задачи в очереди, нужно уведомить PM для постановки новой задачи.

  • Почему это важно?

    • Учет времени: Важно понимать, сколько времени уходит на выполнение задач.
    • Понимание утечек времени: Легче отслеживать, где теряется время и как можно оптимизировать процесс.
    • Прогнозирование сроков: Четкое распределение задач помогает более точно прогнозировать сроки выполнения проекта.
    • Оценка скорости и производительности (capacity) разработки: Это помогает измерять производительность команды и понимать её загрузку.
    • Выстраивание потока и очередности задач: Подготовка задач заранее и правильное распределение позволяют обеспечить бесперебойную работу для разработчика.

  • Статусы

    1. Open / Analysis
      • Задача создана и/или находится на стадии анализа.
      • Ответственные: разработчик.
    2. Pending
      • Задача приостановлена или ожидает дополнительных данных для старта.
      • Ответственные: разработчик.
    3. In Progress
      • Задача активно выполняется.
      • Ответственные: разработчик.
    4. Code Review
      • Код задачи готов и находится на этапе ревью.
      • Ответственные: тех. лид или CTO
    5. Ready To Test / Ready For Dev
      • Задача прошла ревью и готова к тестированию или релизу в дев, в зависимости от типа задачи.
      • Ответственные: Ready To Test: тестироващик, Ready For Dev: тех. лид или CTO
    6. Testing
      • Задача находится в тестировании.
      • Ответственные: тестировщик
    7. Tested
      • Тестирование завершено, задача прошла проверку.
      • Ответственные: тестировщик
    8. Released
      • Задача развернута на продакшен или иную рабочую среду.
      • Ответственные: PM и CTO.
    9. Result-Review
      • Задача требует приемки от бизнеса или PMa
      • Ответственные: PM
    10. Done
      • Задача завершена, все работы полностью выполнены.
      • Ответственные: PM и CTO.

  • Процесс приемки MR и возврата на доработку

    1. Создание MR (Merge Request):
      • Разработчик завершает задачу и создает MR, который включает в себя все необходимые изменения
      • MR прикрепляется в комментариях к задаче по завершении задачи и создания MR
      • MR отправляется на код-ревью ответственному (Tech.Lead или CTO)
    2. Код-ревью:
      • Tech.Lead или CTO проверяет код на соответствие стандартам, качество и полноту реализации
      • Если код соответствует всем требованиям, он утверждается и сливается в основную ветку
      • Если возникают замечания, задача возвращается на доработку. Ответственный за MR оставляет комментарии с указанием, что необходимо исправить или улучшить
      • Разработчик вносит необходимые изменения и повторно отправляет MR на ревью
    3. Возврат на доработку:
      • Если задача возвращается на доработку, статус задачи снова меняется на In Progress, и процесс работы над ней продолжается до устранения всех замечаний

  • Определение задачи готовой к релизу

    1. После того как задача проходит успешное тестирование и меняет статус на Tested, она должна удовлетворять следующим критериям для готовности к релизу:
      • Все баги или дефекты, обнаруженные в ходе тестирования, устранены.
      • Тестировщик подтвердил, что задача прошла проверку без ошибок, и отметил ее как готовую к релизу.
      • Все необходимые изменения внесены в MR, который принят и слит в основную ветку.
      • Документация по задаче обновлена, если это требуется.
      • Задача имеет метки, указывающие на ее готовность для релиза: Ready For Work (для запуска разработки) или Released (после успешного релиза).
    2. После того как задача соответствует всем критериям, она переводится в статус Released, где её утверждают PM и CTO, и она считается готовой для выхода на продакшен.

Процесс заведения и описания задач ​

  1. Входящие задачи:
    • Все бизнес-задачи поступают через CTO и PM, которые добавляют их в Backlog
    • Перед началом спринта они переводят отобранные задачи в PBR (Product Backlog Refinement), где происходит их описание и распределение на разработчиков
  2. Теги задач:
    • Backend: задачи, касающиеся серверной части.
    • Frontend: задачи, связанные с пользовательским интерфейсом.
    • Tech.Debt: задачи по техническому долгу.
    • Need Description: задачи, требующие уточнения или описания.
    • Ready For Work: задачи, готовые к выполнению.
    • Need Confirmation: задачи, ожидающие подтверждения или дополнительной информации от бизнеса или CTO.
  3. Процесс описания задач:
    • Создается эпик, где описываются общие цели и содержание. Ответственный — PM
    • PM совместно с командой разработки декомпозирует эпик на логически связанные задачи
    • PM, CTO и Tech Lead предварительно проставляют оценку на реализацию этой задачи
    • CTO и/или Tech Lead дополняют техническими деталями задачи или описывают отдельно стоящие технические задачи на реализацию
    • Бизнес-задачи утверждаются с бизнесом после описания по необходимости
    • Технические задачи утверждаются с CTO или Tech Lead по необходимости

Типы задач ​

  • Epic: крупная цель или проект, который разбивается на подзадачи.
  • Feature: новая функциональность, реализуемая в продукте.
  • Task: техническая или организационная задача.
  • BR (Bug/Bug Report): задача, связанная с реализацией бизнес-требований.

Заголовки задач ​

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

  1. Сущность системы: указывается первая часть заголовка, чтобы указать, к какому компоненту относится задача (например, SSP, AdEx, Bridge и т.д.).
  2. Краткое описание задачи: четко и емко описывается суть задачи.

  • Список заголовков

    • SSP
    • SSPE
    • SDK
    • AdEx
    • Bridge
    • iFace

  • Пример формата заголовков

    • SSP // Добавить фильтр по датам
    • AdEx // Ошибка при расчете ставок
    • Bridge // Создать пиксель на показ
    • iFace // Сформировать карту страниц

    Этот формат помогает сделать заголовки короткими и понятными, но при этом информативными.