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

Для решения задач мы используем элементы 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. При завершении всех взятых ранее задач или появлении критически важных задач.

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

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

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

# 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 не должны занимать много времени, это какие-то небольшие действия, связанные с поддержкой клиентов.

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

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

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

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

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

Если у вас сомнения по выбору задачи, напишите через 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 и проверьте позицию созданной задачи. По умолчанию задачи размещаются в самом низу.

# День совместного закрытия багов (Bugs Day)

Каждый четверг мы переключаемся на совместную починку багов.

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

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

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

# Пятничный Jira-дайджест (WeeklyJiraDigest)

Каждую пятницу публикуется дайджест выполненных задач. В него попадают все задачи, которые были выполнены: в состояниях Review,ConfirmedилиDeployed`.

# FAQ

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

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

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

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

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

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

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

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

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

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

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

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