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

Процесс

В этой части поста опишем активности во время разработки проекта и инструменты, которые помогают нам в этом.

С самого начала проекта мы привлекаем команду клиента (менеджера и заказчика) к активному взаимодействию.

Работу над проектами разбиваем на недельные отрезки. В начале и конце итерации назначаем контрольные точки с участием менеджера и заказчика клиента (встреча или звонок) для демонстрация результатов итерации и планирование задач на новую неделю

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

  • для демонстрации мы готовим релизную записку с описанием готового функционала, которую после демо отправляем клиенту
  • к планированию актуализируем содержание задач в бэклоге, которое уточнили в рамках текущей итерации; после планирования мы отправляем клиенту список задач на будущую неделю

Во время итерации продолжается активная коммуникация с менеджером клиента:

  • уточняем возникшие вопросы по задачам идущей итерации
  • сообщаем о готовности задач
  • собираем фидбэк
  • уточняем задачи на следующие итерации

Задачи описываем так, чтобы у разработчиков как можно реже возникала необходимость уточнять задачу и всегда были понятны условия готовности.

Изменение списка задач в ходе итерации возможно только в двух случаях:

  • обнаружен критический баг, который не даёт пройти один из основных пользовательских кейсов
  • у одной из будущих задач повысился приоритет исходя из бизнес-ценности, “хотелки” в данном случае не являются причиной изменения итерации; причины и изменённый список задач фиксируются письмом

Задачи в ходе итерации проходят через несколько статусов (одинаковые на большинстве проектов):

  • запланирована на неделю (plan)
  • в работе (in progress)
  • code review
  • тестирование (test) – демонстрация на тестовом сервере
  • готова к релизу (либо выкладывается сразу в production, либо ожидает остальных запланированных на неделю)
  • выполнена (done) – зарелизена в production

В зависимости от обратной связи статус задачи может перейти обратно на стадию «в работе». Задача считается окончательно выполненной только когда попадает в production.

После того, как пользователи клиента “пожили” пару недель с выпущенным функционалом, мы собираем от них фидбэк с помощью менеджера клиента — это позволяет учесть прошлые ошибки в будущих задачах и совершенствовать уже работающий функционал.

На разных шагах процесса мы используем разные инструменты:

  • Почта — для фиксации договорённостей
  • Календарь – для назначения звонков/встреч
  • Google Docs — для подробного описания функционала, релизных записок и подобных материалов
  • Trello – для управления задачами проекта (приоритеты, краткие описания, обсуждение)
  • GitHub — для хранения кода и истории изменений, используется разработчиками
  • Slack – для быстрой внутренней коммуникации
  • Skype / WhatsApp / Telegram – для решения оперативных вопросов с клиентом
  • Skype / Hangouts / Zoom — для демонстрации результатов итерации клиенту

В итоге, проект проходит необходимое число итераций до логического завершения — в случае успеха, до прекращения работ — в случае, если что-то пошло не так.

Данный workflow не является каноническим, его нельзя назвать правильным или не очень. Для каждой компании характерны свои особенности построения рабочего процесса, что делает многие it-компании уникальными. Благодаря многолетнему опыту работы в Evercode Lab мы сумели выстроить наш вариант, который используем при разработке программного обеспечения.