[1/2] Developer Joy – How great teams get s% t done - Sven Peters - NDC Porto 2023 (Рубрика Management)

[1/2] Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 (Рубрика #Management)

Интересное выступление от Sven Peters из Atlassian на тему developer productivity, developer experience и developer joy:) Автор начинает с того, что возвращается в прошлое и вспоминает про Тейлора и его научный подход к менеджменту на заводе. Правда, там выполнялась однотипная работа на конвейере, но за счет измерения времени выполнения разных активностей Тейлор смог оптимизируя инструменты, время на отдых и другие вещи повысить эффективность завода в разы. Но сейчас в информационный век многие хотят научиться также повышать эффективность разработки, но разработка сейчас достаточно сложна и software development engineer должен уметь работать над quality, работать в облаке, деплоить и эксплатировать свое решение (you build it, you run it). Я говорил про эту же проблему в своем подкасте "Software development engineers в tech компаниях". Но автор предлагает уйти от термина developer productivity к developer joy и разобраться с тем, что делает работу разработчиков приятной и продуктивной и туда попадает

• Dev quality - качество кодовой базы, архитектуры, отсутствие техдолга
• Dev progress - темп разработки и поставки фичей
• Dev value - какую пользу приносят поставленные фичи Автор рассказывает на примерах из разных команд
• Команда Jira написала code of conduct для проведения ревью кода
• Команда Confluence, которая написала инструмент для поиска нестабильных (флакающих) тестов во время прогонов
• Команда Confluence написала бота для пушинга участвующих в code review - это уменьшило среднее время ревью PR с 3 дней до 1.2 дня

Дальше автор рассказывает про зависимости между командами, что тормозят разработку. Он делает это на примере того, как разные развязки на дорогах влияют на пропускную способность шоссе. Когда мы делаем нормальные развязки, которые позволяют машинам не мешать друг другу, то мы получаем максимальный traffic flow. Этим автор обосновывает стремление к автономным командам. А дальше он рассказывает про команду Trello, где на 1 qa инженера приходится 30 software development engineer. В итоге, сами sde забирают на себя большую часть стандартных функций qa-инженеров, а потому не ждут пока qa-инженеры протестируют их фичи. Плюс автор рассказывает про подход с блиц тестированием, когда вся команда тестирует критически важную функцию. Забавно, что оставшиеся qa-инженеры отвечают за qa-тулинг, тестовые данные, базы и так далее.

Продолжается история тем, что разработчикам надо понимать dev value

• Инженеры (sde) и продакт менеджеры должны работать вместе над одним и тем же делом
• Инженеры (sde) должны быть вовлечены в процесс создания и понимать проблему, которую нужно решить
• Стоит использовать демо, которые важны для всех команд, они помогают увидеть результат и ценность, которую создают для клиентов

Дальше идет речь про измерение производительности и улучшение показателей

• Как помним еще Тейлор говорил о важности измерения производительности труда
• Если у вас ничего нет, то стоит начать с метрик DORA
• А дальше стоит начать использовать свой собственный инструмент для базовых показателей отслеживания прогресса
• Раньше в офисах раньше были настенные панели и телевизоры, на которых можно было видеть состояние сборки и тестов.
• Сейчас используются проверки, которые помогают определить проблемы и улучшить показатели.

Автор рекомендует использовать разметку задач и оценивать время, которое команда тратит

• На change бизнеса
• На keep the lights on (поддержание работы)
• На поддержание эффективности разработки и улучшение developer productivity