Культура разработки: как оценивают производительность и эффективность

(c)

Практически с появления технологической отрасли в ней велась охота за «Белым китом» — метриками труда разработчиков. Возможно, само желание посчитать KPI программистов родилось из фразы, распространенной в традиционном бизнесе: «Вы не можете планировать, если не можете измерить».

Вслед за сотнями различных KPI, которыми пытались обвесить программистов, появилось множество различных методов анализа рабочих данных — от отслеживания направления взгляда на монитор до Scrum и Kanban. Измерения качества труда настолько хорошо работали во многих отраслях, что казалось вполне логичным перенести данный опыт на разработку программного обеспечения. Результат оказался обескураживающим.

Измерения и управление продуктивностью разработчиков не привели к появлению единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики… отдельные из них практически невозможно сравнить с традиционными KPI в других сферах деятельности.

В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.

Уже трудно найти (по крайней мере, в открытых источниках) информацию об использовании в качестве метрики количества отработанных часов, числа строк в тексте исходного кода (SLOC), Function Points или количества багов, создаваемых каждым разработчиком.

В публичном дискурсе удалось прийти к консенсусу, что работать больше — не значит работать лучше, что решение с 200 строками кода может быть быстрее или производительнее, чем решение с 1 тыс. строками, а метрика Function Points, созданная в 1979 году, безнадежно устарела.

Но что вообще произошло с желанием все измерить и посчитать? Судя по всему, оно никуда не исчезло.

Netflix

(c)

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

Стриминговая платформа тестирует новые идеи в реальных масштабах и измеряет статистически значимые различия во взаимодействии пользователей с продуктом. При этом ошибки на этапе тестирования гипотез вполне допустимы — «единственная реальная ошибка, которая неприемлема в Netflix, — это неспособность к инновациям».

Разработка продукта в Netflix начинается с гипотезы, которая выглядит примерно так:

Алгоритм / функция / дизайн (×) увеличение взаимодействия подписчиков с сервисом и, в конечном счете, их удержание.

Гипотеза может заключаться в том, чтобы повысить релевантность результатов поиска, использовать новый дизайн для пользовательских интерфейсов или новую функцию — например, показывать участникам то, что их друзья из соцсетей смотрят на Netflix. Интуиция и представление о том, как более качественно предоставлять услуги подписчикам, становятся основой подхода к разработке.

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

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

Даже провал гипотезы считается достигнутым результатом. Следовательно, вероятность того, что следующая гипотеза окажется лучше, только возрастает. Команда разработчиков имеет большую свободу в применении к продукту идей на продолжительном отрезке времени.

IBM

(c)

Самая старая и наиболее «очевидная» метрика для разработки программного обеспечения — подсчет числа строк, произведенных отдельным разработчиком или командой, и количества времени, потраченного на это. Впервые эту метрику использовали в IBM. В документальном фильме «Triumphof the Nerds: The Rise of Accidental Empires» Стив Баллмер заметил, что в 1980-х годах IBM, похоже, сделала из этого показателя «религию».

В 2011 году IBM представила инструмент для автоматического анализа исходного кода на производительность, безопасность и техническую сложность. Разработчики, чей код имел самую высокую оценку, получали от системы наивысший балл. Низкие же показатели производительности служили сигналом для того, что следует обратить внимание на обучение сотрудников (в IBM утверждали, что низкий итоговый балл не использовался в качестве наказания).

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

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

SpaceX

(c)

Информации о работе разработчиков в SpaceX крайне мало, что связано с общей секретностью проектов этой не публичной компании. Но по косвенным сведениям можно понять примерные очертания общей картины. И картина эта говорит о важности тестов.

В ракетостроении тесты — основа основ конструирования. В программировании софта для ракет используются те же принципы. Например, если ракета благополучно приземлилась, то KPI выполнили все команды, ответственные за разработку. Без предварительных тестов успешно выполнить такой проект не представляется возможным.

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

В SpaceX пытаются распараллелить код между разными проектами — при такой парадигме разработки исправление ошибок для одного проекта (условно говоря, ракеты) автоматически распространяется и на другие проекты.

В качестве основного языка программирования в компании выбрали C++. Во-первых, это позволяет нанимать много высококлассных разработчиков, поскольку язык все еще относительно популярен. При этом выбор часто делается в пользу выходцев из геймдева, привыкших писать код и работающих в средах с ограничением на память и вычислительные мощности.

Во-вторых, они получают выгоду от большой экосистемы C++. Нет необходимости создавать специальный софт, когда можно использовать давно знакомые инструменты, такие как gcc и gdb.

И, наконец, в разработке огромное внимание уделяется метрикам тестирования. Разработчикам и инженерам рекомендуется проверять на безопасность и отказоустойчивость всё, о чём только можно подумать.

Собранные в процессе тестирования данные хранятся вместе с исходным кодом, который работал во время тестов. Если во время испытаний ракеты случится какой-либо сбой, SpaceX сможет воссоздать точную среду запуска, воспроизвести проблему и устранить её.

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

Amazon

Amazon обладает одной из самых интересных стратегий, изложенной в этом 40-минутном интервью с директором AWS Developer Tools.

Ключевая идея формирования команд разработки — митотическое масштабирование. Команды разбиваются на более мелкие группы, полностью сохраняющие преемственность и функции «материнских» команд.

Джефф Безос, генеральный директор AWS Developer Tools, считает, что идеальная команда не должна включать больше людей, чем можно насытить двумя пиццами.

В небольших командах общение гораздо эффективнее, они остаются децентрализованными, независимыми, быстрее развиваются и внедряют инновации.

Изначально Amazon имела монолитную структуру и архитектуру программного обеспечения (Perl/Mason/C++). Затем архитектура была декомпозирована на службы, а структура организации — на пицца-команды. Так облачный сервис Amazon Elastic Compute Cloud (Amazon EC2) был сформирован группой, состоящей всего из двух «пицца-команд».

Amazon стремится к полной автоматизации всех процессов (сборка, деплой, перенос коммитов и т.д.). В рамках каждого деплоя используются несколько различных видов тестирования: интеграционное, браузерное, веб и нагрузочное. Таким образом, контролируется и измеряется всё.

Безопасность отслеживается на протяжении всего процесса запуска продукта, поэтому в культуре Amazon совершенно нормально на любой должности «думать как инженер по безопасности». При запуске нового проекта разработчики в первую очередь работают над архитектурой и моделью угроз.

Проверки встроены во все пайплайны посредством сочетания локальных и глобальных доверительных политик. Руководитель может самостоятельно устанавливать политику проверок для своей команды (например, перед деплоем каждый новый коммит на 70 % должен быть охвачен юнит-тестированием).

При этом существуют и общие правила Amazon, охватывающие каждый деплой (к примеру, запрет на единовременное развертывание в каждом регионе).

Именно разработчики в команде, а не архитектор, отвечают за архитектуру проекта. И лишь потом она рассматривается архитектором или главным инженером. Такая же ситуация с безопасностью и тестированием: команда управляет всем процессом. Хотя у этого подхода есть минус, который заключается в длительном периоде обучения.

Ежегодно команды готовят операционный план на шести страницах (такие «бизнес-планы» представлены на всех уровнях Amazon). В плане указывается, что будет выполнено в следующем году при фиксированных ресурсах и чего удастся достичь с помощью дополнительных ресурсов. Менеджеры собирают шестистраничные документы со всех команд, которыми они управляют, создают свои собственные шестистраничные документы и представляют их своему руководству — и так вплоть до Джеффа Безоса. В обратную сторону командам распределяются ресурсы.

Что там у стартапов

Благодаря опросам, проведенным Stackify (облачная платформа для мониторинга и выявления неисправностей в веб-приложениях), удалось выяснить отношение к метрикам в некоторых известных стартапах и в компаниях «средней руки».

CircleCI — популярный, в том числе и в России, Continuous Integration-сервис с гибкой настройкой для веб и мобильных приложений. Роб Зубер, CTO CircleCI, считает, что лучшей метрикой для измерения производительности и эффективности разработки программного обеспечения является показатель времени, необходимого для перехода кода от коммитинга к развертыванию — Commit-to-Deploy Time (CDT).

Цель измерения CDT — «выследить» барьеры на пути к развертыванию. В идеале, если вы используете автоматизацию и/или тесты хорошего качества, вы можете перейти к деплою в считанные минуты (или даже секунды) для микросервиса. Если же у вас используется в основном процесс ручного контроля качества, то, вероятно, это будет означать, что развертывание займет больше времени.

Анализ CDT по данным CircleCI показывает, где найти возможности для улучшения. Усовершенствования могут быть в большей степени техническими (например, сделать тесты более эффективными), более ориентированными на процессы, или комбинацией того и другого. Чем меньше ваши коммиты, тем быстрее они могут быть запущены, соответственно, тем быстрее вы сможете исправить ситуацию, если что-то пойдет не так.

Adeva — компания, осуществляющая подбор персонала и формирующая готовые команды разработчиков для стартапов. Чтобы предложить клиентам более качественное обслуживание, она на протяжении нескольких лет исследовала метрики эффективности программистов. Вывод прост: не существует формального и объективного измерения эффективности и продуктивности разработки программного обеспечения.

Вместо того чтобы использовать KPI, в Adeva организуют короткие встречи с разработчиками, на которых менеджмент внимательно слушает рассказы о достижениях и неудачах. Для определения эффективности отдела в целом разработчикам задаются вопросы о полезности и осведомленности остальных членов команды. На этих встречах каждый может озвучить идеи, которые могли бы помочь как им самим, так и другим членам команды.

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

Scorchsoft, английский разработчик веб и мобильных приложений, оценивает время выполнения проектов. Поскольку большинство клиентов Scorchsoft ожидают получить продукт по фиксированной цене, в компании должны сразу определить четкую, недвусмысленную спецификацию. Производительность измеряется с точки зрения времени разработки на основе инструментов Toggl (тайм-трекер) и Jira.

Проект считается успешным, если клиент остался доволен, а команда уложилась в заданное время.

Заключение

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

Когда главный показатель успеха — конечный клиент, гораздо легче применять метрики, пришедшие из маркетинга: коэффициент конверсии, поведение пользователей или оценка отзывов. В этой сфере успех во многом зависит от менеджмента, который может принять неверное решение. Например, разработка не нужной клиенту функции оказывает на бизнес гораздо более негативное воздействие, чем выбивающийся из «стандартов» разработчик.