# Рабочие процессы

Для решения задач мы используем элементы Story Mapping, Scrum и Kanban:

  • Карты историй для стратегического планирования.
  • Ретроспективы (смотрите Company Call).
  • Kanban-доску для управления текущими задачами.

# Три уровня планирования

Весь наш процесс разработки проходит 3 уровня:

  1. Заводим карточки историй на карте историй в сервисе StoriesOnBoard. Запланированые истории выгружаются в Backlog.
  2. Берем истории/задачи/баги из Backlog'а. Истории декомпозируем.
  3. Все задачи взятые из Backlog'а появляются на Kanban доске.

# Карта историй

# Структура карты

Для знакомства с картами, можно почитать статью https://storiesonboard.com/user-story-mapping-intro.html В целом, структура карты подстраивается под специфику проекта, нет жестких ограничений.

# Рекомендации по работе с картами историй

  1. Все карточки историй заводятся изначально в на карте в Unscheduled блоке.
  2. При планировании создается следующий Релиз. Релизом тут может быть номер следующей версии, месяц или номер недели. В Jira релизы называются как Версии (Versions). Карточки можно добирать в релиз, если текущих оказалось недостаточно.
  3. Чтобы отправить карточку в Jira, нужно нажать "Push to Jira".
  4. После деплоя или завершения периода релиза, нужно зайти в детали версии и нажать "Release".
  5. Старые релизы отправляются в архив (нужно нажать на "Archive Release").

# Backlog

Задачи из Backlog'а берем в 2х случаях:

  1. При планировании следующего спринта.
  2. При завершении всех взятых ранее задач или появлении критически важных задач.

# Разработка Истории

Если вы начинаете разработку новой фичи, обязательно заведите в Slack тред для обсуждения. В случае, если это очень крупная фичи или даже новый проект, создаем RFC

  1. Поставьте себя как Assignee истории. Переведите в состояние Active.
  2. Декомпозируйте Историю:
    • Разбейте разработку истории на подзадачи.
    • Каждая должна занимать 2-4 часа, максимум 8 часов (1 рабочий день).
    • Подзадачи можно заводить постепенно, по мере работы над историей.
  3. Заведите ветку по идентификатору Истории. Если у истории назначена версия релиза, то ветка делается от ветки релиза, в ином случае от master.

Обратите внимание, что карточка с Историей не попадает на Kanban доску. На доске появляются только поздачи, которые переведены в состояние Planned.

# RFC

RFC (Request for changes) - это отдельный документ, который описывает почему нужны изменения и что потребуется изменить.

  1. Создайте файл docs/rfc/YYYY-MM-DD-название.md в репозитории проекта.
  2. Оформите блоки RFC. Рекомендуем к прочтению статью writing effective change rrequests. Описывайте лишь то, что считаете имеет смысл в конкретном случае.
  3. Сделайте MR этогоо документа и пригласите всех заинтересованных людей.
  4. RFC считается одобренным, если получено одобрение от Assignees. Лимитом на ответ считаем 1 сутки с момента создания MR, посче чего считаем одобренным.

Ревьюерам:

  1. Как можно быстрее реагируйте на новые RFC. Поомните, что прохождение ревью блокирует разработку.
  2. Если вы с чем-то несогласны, начинайте дискуссию.
  3. Если дискуссия закончена, жмите Resolve Discussion.

# Kanban доска

На доске всего 4 колонки, которые соответствуют статусам задач:

  • Planned — запланировано в работу на ближайшее время. Алиас статуса "Reopened".
  • In Progress — идет работа над задачей.
  • Review — задача выполнена и находится в состоянии Code Review или ожидания деплоя.
  • Deployed/Confirmed — изменения получили клиенты.

У карточек могут быть и другие статусы и такие карточки не видны на доске.

  • Backlog — задача в Бэклоге.
  • Delayed — отложена и находится в Бэклоге.
  • Closed — задача закрыта.
  • Cancelled — задача не актуальна, отменена.

# Как работать с карточками на Kanban доске

  1. Когда начинаете работать над задачей, переносите карточку в "In Progress".
  2. Если останавливаете работу или переключаетесь на другую, возвращайте карточку в первую колонку.
  3. После выполнения, переводите в "Review". Напишите коротко о том, что было сделано.

# Когда закрывать задачи и Истории (Confirmed/Deployed)

  • Bug - после деплоя или релиза новой версии.
  • Sub-task - после прохождения Code-Review. Сама История при этом может оставаться активной, с другими невыполнынными подзадачами.
  • Task - когда считаете, что задача полностью завершена и не требуется больше к ней внимание. Например, клиенту провели работы на сервер и клиент подтвердил, что проблема решена.
  • Story - если велась разработка, то переводим после деплоя. Если История друугого плана, то на усмотрение создателя Истории.

Задачи со статусами "Deployed/Confirmed" переводятся в Closed через на следующие сутки и вычищаются с Kanban доски.

Смотрите также Пятничный дайджест закрытых задач (WeeklyJiraDigest).

# Как выглядит разработка с точки зрения разработчика

Если над Историей работает один человек:

  1. Заводить ветки на каждую подзадачу не обязательно.
  2. Открываем канбан доску в Jira и перекидываем карточку задачи/подзадачи в колонку In Progress.
  3. После выполнения первой задачи в Истории, нужно оформить MR (Merge Request) ветки истории в ветку master или релизную ветку. В заголовке добавить спереди "WIP: " — это отметка Work In Progress.

Если над Историей работает несколько человек:

  1. Заведите новую ветку от ветки Истории по идентификатору задачи.
  2. Перекиньте карточку подзадачи в колонку In Progress.
  3. После завершения задачи, оформите MR в ветку Истории.
  4. Когда все подзадачи выполнены, оформляйте MR в master или ветку следующего релиза:

Читайте также страницу Apliteni git-flow.

# Специфика задачи с типом "Bug"

Если задача с типом "Bug":

  1. Заведите новую ветку от master. Если баг определенного релиза, то делаем сначала checkout этой версии по тэгу, и уже от него делаем ветку.
  2. После выполнения, оформите MR.
  3. После релиза новой версии, переводим задачу в Deployed и отписсываем клиенту, который зарепортил баг.

# Специфика задач в проекте SUPPORT

Задачи в проекте SUPPORT выполняем с наивысшим приоритетом. Такие задачи не должны занимать слишком много времени.
Если был выявлен баг во время выполнения этой задачи, заводим отдельной задачей c типом Bug. Ничего в рамках SUPPORT не предполагается чинить в коде, и особенно, создавать какие-то фичи.

Важно вести процесс решения добавляя комментарии, чтобы команда поддержки была в курсе процесса и могла поддерживать связь с клиентом. Например:

  • "Проверил диск сервера, проблем нет".
  • "Жду от клиента доступа более высокого уровня".
  • "Не удалось найти причину, передаю задачу Косте".

# Как выбирать задачи

  1. Сначала проверяем, нет ли еще подзадач у Истории, над которой вы работаете. Если есть, продолжаем.
  2. Берем из Backlog'а:
    1. Идем сверху-вниз. Задачи заранее расставлены так, что сверху наиболее важные задачи.
    2. Ищим задачу, которую в состоянии выполнить, и которая ним за кем не закреплена. Если описание задачи не понятно, ссмело запрашиваем более детального описания.
  3. Если в Backlog'е нет задач, идем в StoriesOnBoard (карта Историй):
    1. Идем сверху-вниз. Чем выше, тем более важная карточка.
    2. Выбираем карточку и нажимем Push to Jira.
    3. В наиболее подходящем канале, заведите новый тред формата "Обсуждение [НАЗВАНИЕ ИСТОРИИ]". Не начинайте разработку без обсуждения деталей.
    4. Переходим на страницу истории в Jira и переводим в Active (смотрите Разработка Истории).

Если у вас сомнения по выбору задачи, напишите через Slack в канале #workspace.

# Code Review

Качественное code review позволяет сократить вероятность прохождения багов и поддерживать качество кода, поэтому участие в code review является приоритетной задачей для каждого.

  • Code Review считается выполненным, если все threads отмечены как Resolved.
  • Если ваш запрос выполнил или не требует ответной реакции, ставьте Mark as Resolved на всех сообщениях в треде.
  • Когда по задаче требуется доработка, она переводится из состояния Review в состояние Planned или In Progress.

# Рекомендации по Code Review

  • Начинайте день с проверки текущих MergeRequest'ов, где вы отмечены как Assignee. Если все ок, ставьте Approve. Список MR можно найти на странице To-Do List
  • При появлении уведомлений о новом MR, старайтесь при первой же возможности посмотреть его.
  • Задавайте вопросы. Например, вместо "Здесь используй библиотеку iconv", пишите "Почему бы не использовать библиотеку iconv?"
  • Ваш опыт отличается от остальных. Если вам что-то кажется очевидным, не полагайте, что и другому тоже.
  • Будьте вежливы. Если код не достигает нужного уровня качества, вежливо предлагайте улучшения и не забывайте заворачивать в форму вопроса.

# Создание новых задач в Jira

  1. Для заведения задачи/истории слева по кнопке "+"

  2. Project

    • Выберите проект. Для решения задач поддержки, используйте SUPPORT.
  3. Тип:

    • Story — рекомендуемый. Рекомендуется начинать создание истории в StoriesOnBoard.
    • Task — микро-задача, которая не связана с существующими Историями. В проекте SUPPORT заводятся задачи именного этого типа.
    • Bug – если это подтвержденный баг.
  4. Priority:

    • Ставим High для критических багов или серьезной проблеме у клиента. В остальных случаях оставляем Medium.
    • Если задача метит на уровень Low и ниже, то подумайте, не завести ли ее только в StoriesOnBoard.
  5. Carrotquest URL (обязательное для проекта SUPPORT)

    • Пропишите ссылку на диалог клиента, который зарепортил баг.
  6. Заголовок:

    • Очень важно, чтобы заголовок максимально коротко описывал суть задачи. Это нужно, чтобы в бэклоге легко можно было понять о чем задача и регулировать порядок в очереди на выполнение.
  7. Описание:

    • Опишите более подробно цель задачи. Кладите сюда также доступы, ссылки на переписку или саму переписку с клиентом.
  8. Due Date:

    • Если клиенту назвали сроки выполнения, укажите его в этом поле.
  9. Исполнитель (Assignee) назначается, только если задача предназначена конкретному человеку.

После создания задачи, зайдите в Backlog и проверьте позицию созданной задачи. По умолчанию задачи размещаются в самом низу.

# Ивенты

::: info Все события должны быть заведены в общем календаре Apliteni. :::

# Company Call (каждую пятницу)

  1. В канале #coffee-talks публикуется ссылка на подключение к конфереции Zoom.
  2. Все участники заходят в конференцию, используя корпоративную почту при авторизации и свое полное имя.
  3. Если пятница выпадает на нерабочий день, переносим на четверг.

За 30 минут в Slack публикуется автоматической Jira Digest со списком всех закрытых задач за неделю.

Структура:

  1. Каждому дается 1-2 минуты, чтобы обощить и рассказать о своих закрытых задачах.
  2. Проходим по колонке In Progress и выявляем, нужна ли помощь по какой-либо из них.
  3. Проходим по запланированным задачам в Backlog. Проверяем актуальность задач.
  4. Проходим по незапланированным задачам в Backlog. Распределяем блокирующие истории без исполнителя.

# Bug Day (каждый четверг)

День совместного закрытия багов.

Схема простая:

  • Перенесите все текущуие задачи в Planned.
  • Берем одину задачу-баг из Backlog.
  • Чиним, берем следующую.
  • Когда баги кончились, возвращаемся обратно к задачам.

Критические баги чиним сразу, не дожидаясь четверга.

# Release Keynotes 🍻 (за несколько часов до релиза новой версии продукта)

Рассказываем об изменениях в новом релизе продукта.

  • 5-15 минут на рассказ об изменениях и 10 минут на вопросы.

# Frontend Checkpoints 😎 (каждый 2ой и 4ый вторник месяца)

Обсуждает разработку фронтенда на всех проектах, текущую разработку и планы.

  • Стараемся уложиться в 30 минут.
  • Заранее предлагаем и согласуем список тем.

# Devops Checkpoints 🔥

Обсуждаем нашу инфраструктуру, изменения и планы и развитию.

  • Стараемся уложиться в 30 минут.
  • Заранее предлагаем и согласуем список тем.

# Support Party 🕺 (каждая последняя среда месяца)

Обсуждаем самые задаваемые вопросы, запрашиваемые фичи и общие тренды области.

  • Стараемся уложиться в 30 минут.
  • Заранее предлагаем и согласуем список тем.

Видео Support Party рекомендуем смотреть всем разработчикам. Это важно, т.к. саппорт - это наш канал общения с клиентами, именно из саппорта мы узнаем о самых частых проблемах и болях наших клиентов, возможно, сможем корректировать свой курс, или поможем решить наиболее частые проблемы, с которыми обращаются пользователи. После выкладки видео нужно пингануть всех в тред упоминанием @team и попросить поставить галочки после просмотра.

# Backlog Zero (beta)

Это событие запускается, его какая-либо из Историй в Backlog висит 4 неделю подряд и приводит к мораторию на импорт новых историй из Stories On Board.

  • Все разработчики, которые закончили свою историю, подключаются к решению этой истории.
  • История декомпозируется так, чтобы одновременно могло работать несколько человек.
  • Backlog Zero завершается, когда все Истории завершены.

# FAQ

# В каких случаях заводить задачи

Задачи заводим всегда. Особенно, если сомневаете нужно ли ее заводить. Примеры:

  • Необходимо что-то проверить или проверсти настройку на сервере клиента.
  • Необходимо изучить что-либо для выполнения вашей текущей задачи. Заведите подзадачей к текущей Истории.
  • В вашей текущей задаче что-то не учли и на выполнение требуется больше времени. Заведите подзадачу в текущей Истории.

Почему полезно заводить задачи:

  1. Активное использование Jira делает вашу работу прозрачной.
  2. Выполненные задачи попадают в пятничный дайджест и вам не придется вспоминать, что было сделано на неделе.
  3. Сохраняется история решения, которую можно будет найти в будущем.

Для экономии времени заполняйте только Title, проект и тип задачи. Описание и другие поля сможете дополнить позже.

# Если задача требует больше 8 часов работы

Такую задачу лучше разбить на более мелкие (декомпозировать):

  • В случае, если это подзадача, нужно добавить подзадачи в ту же Историю.
  • Если это Task, необходимо перевести карточку в тип Story. Это делается через действие Move.

# Как не допускать старения карточек

На канбан доске, у каждой карточки есть индкатор "старости" - это ряд точек. Чем больше зарточка находится в одном состоянии, тем больше красных точек у карточки. Чтобы не допускать устревания, нужно держать в In Progress только те задачи, на которыми сейчас идет работа. В Planned держите только те задачи, которые собираетесь делать в ближайшие дни. В остальных случаях, лучше убрать в Backlog.

Случается, что задача оказалась крупнее, чем ожидалось. В таких случаях мы делаем разбивку на несколько - декомпозицию (смотрите раздел Уровень 2: Бэклог).