Что делают разработчики? Как проходит их день? Они вообще что-нибудь видят, кроме компьютерных мониторов ?!
Эта тема подходит для начинающих разработчиков, которые только делают первые шаги.
Бытует мнение, что единственное, что делают разработчики, - это они весь день жестко программируют, не отходят от компьютера, не общаются ни с кем и вообще не видят белого света. Почему-то так со стороны это выглядит для большинства людей, никогда не работавших в IT-компаниях.
На самом деле это не совсем так. И в этой статье я расскажу вам, что такое день разработчика. Как это планируется и выполняется, какие задачи определены и с какими отделами осуществляется коммуникация.
Конечно, у каждой команды свой рабочий процесс и он может отличаться. Но разберем эту проблему на примере нашего абстрактного общества. И я покажу вам, как это работает.
Чтобы правильно ответить на вопрос, как идут дела у разработчика, важно понимать, на каком этапе спринта мы находимся сейчас. Это зависит от того, как разрабатываются планы и приоритеты на день.
Часть первая - планирование
На этом этапе разработчик участвует в принятии технических спецификаций от отдела продукта, активно комментирует их, а принятые действия заносятся в список невыполненных работ. Затем разработчик должен разбить активы на jira и оценить каждый из них.
Также на этом этапе мы уделяем много времени общению. Как правило, это встречи и обсуждения в рабочих группах с отделом продуктов и между интерфейсной и серверной командами. Это чрезвычайно важно при планировании, так как помогает избежать недоразумений. Ведь необходимо согласовать детали технического задания, устранить все неясности и проработать спорные моменты.
Результатом этапа планирования является сбор данных о масштабах деятельности, необходимых для начала спринта. Команда берет на себя все задачи, которые она может выполнить в отведенное время.
Часть вторая - разработка
После планирования начинается активная фаза разработки. Это время, когда разработчик сосредотачивается на коде. В этот момент не стоит отвлекаться, это дорого для компании! :) Для этого в нашей команде даже введены часы тишины (первая половина дня до обеда). Время, в которое следует исключить прямую связь.
PM контролирует весь рабочий процесс. Он распределяет задачи между разработчиками, устанавливает их приоритеты и размещает их на доске Канбан. И разработчик уже переходит от задачи к задаче.
На этом этапе, если возникнет дополнительная необходимость в обсуждении, все коммуникации будут осуществляться на утреннем ежедневном митинге. Мы работаем со скрамом, и встречи утром - наш ежедневный ритуал. Тем временем команды обсуждают, что было сделано вчера, какие есть сложности, и рассказывают о планах на день.
Часть третья - проверка и тестирование
Это проверка всего проекта. Он начинается сразу после остановки разработки. На этом этапе формируется ветвь выпуска, этап со средой, максимально приближенной к производственной. Все, что добавили разработчики, вливается туда и в работу включается отдел QA.
Тестировщики проводят регрессионные тесты, тестируя все модули.
Основная задача разработчика на этом этапе - оперативно исправлять ошибки, обнаруженные QA.
В оставшееся время разработчик работает над списком задач по тех. долгу и занимается написанием самопроверки.
Кроме того, он уже начинает подготовку к следующему спринту и берет на себя работу по исправлению новых технических характеристик.
Часть четвертая - релиз
Это шаг к стадии производства.
На этом этапе разработчики также взаимодействуют с отделом контроля качества.
Тестировщики запускают smoke-тесты, и при обнаружении ошибок разработчики произведут быстрое обновление.
Кроме того, мы уделяем время обучению и развитию разработчиков. Команда регулярно собирается на внутренние встречи для изучения новых стековых технологий, совместного просмотра веб-семинаров и многого другого. Обычно эти встречи проводятся еженедельно.
В конце фазы разработчик приступает к планированию объема работ для следующего спринта.
Часть пятая - ретроспектива
Этап для того чтобы выговорится
Ведь разработчики тратят много времени на активную разработку без общения. Но ретро - это всегда диалог, в котором каждый может поговорить, поделиться своей болью и найти решение. Это также время для предложений и идей по улучшению, или для выражения благодарности команде, или для обмена мотивирующим контентом.
Чтобы создать позитивную атмосферу вначале, PM готовит игру или разминку - ломать лед. Это также позволяет команде немного расслабиться и лучше узнать друг друга.
Например, это может быть однословица. Менеджер проекта просит каждого разработчика одним словом описать свое состояние после спринта. Например, сравнивать себя с автомобилем - может, Mercedes Benz, а может, Лада Калина :)
Основная задача ретроспективы - проанализировать результаты спринта: диаграмму выгорания, что было сделано, что не сделано, а также обсудить проблемы и пути улучшения.
А для PM это еще и возможность увидеть настроение каждого разработчика и получить обратную связь.
Как видим получилось 5 основных этапов, конечно это не единственный вариант построения работы а один из возможных.
Если будет интересно разберем примеры работ крупных IT компаний и маленьких стартапов.
