Недавно я думал об «устойчивом развитии» и о том, что это значит. Я работал во многих местах и ​​над многими проектами, которые, по моему мнению, имели неустойчивую практику. Возможно ли устойчивое развитие? В Agile Manifesto есть принцип, основанный на идее устойчивого развития:

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

Я не собираюсь обсуждать в этом посте «спонсоров» и «пользователей», а вместо этого сосредоточусь на инженерной стороне устойчивого развития. Я разбил его на три разные области.

  1. Поддержание гибкости разработки
  2. Поддержание продуктивности разработчиков
  3. Поддержание конкурентного преимущества

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

Поддержание гибкости разработки

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

Рефакторинг — ключ к поддержанию гибкости. У Мартина Фаулера есть отличный доклад о гибкости и рефакторинге, где он говорит:

[Рефакторинг] является очень важной техникой для всего гибкого мышления, потому что он полностью соответствует тому, как мы можем создавать программное обеспечение таким образом, чтобы оно могло легко изменяться. Мне всегда нравилась фраза Мэри Поппендик: «Позднее изменение требований — это конкурентное преимущество». Но для этого вам нужно программное обеспечение, разработанное таким образом, чтобы оно могло реагировать на такого рода изменения. Рефакторинг занимает центральное место в этом, потому что рефакторинг — это дисциплинированный способ внесения изменений. Ужасно, когда кто-то пишет в Твиттере что-то вроде: «Сейчас я занимаюсь рефакторингом нашего программного обеспечения, поэтому оно будет сломано в течение следующих двух недель».

Как вы можете это измерить?

  1. Метрики качества кода дадут представление о том, написана ли ваша кодовая база с учетом лучших практик.
  2. Показатели тестового покрытия помогут вам понять, насколько уверенно разработчики могут вносить изменения в код, не создавая ошибок.
  3. Вы также можете измерить количество изменений, которые различные части вашей кодовой базы меняют с течением времени в качестве индикатора того, где, вероятно, необходимо выполнить работу по рефакторингу.
  4. Обзоры архитектуры — это еще один способ узнать, считают ли разработчики, что ваша кодовая база со временем соответствует архитектурным стандартам.

Поддержание продуктивности разработчиков

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

Как вы это измеряете?

Что ж, погуглив, оказалось, что Инвентаризация выгорания Маслаха (MBI) — это стандартный способ измерения выгорания. Я нашел исследование, которое описывает MBI как:

Самая распространенная мера выгорания… хорошо проверенная, широко используемая мера самоопроса. МБИ включает три шкалы: 1) эмоциональное истощение (девять пунктов), состояние хронического эмоционального и физического истощения; 2) деперсонализация (пять пунктов), чувство оторванности от коллег и клиентов; и 3) снижение личных достижений (восемь пунктов), негативное чувство собственной ценности и способностей.

Это дорогой тест, но в этом исследовании также говорится, что вы можете получить в значительной степени те же результаты, что и MBI, задав один вопрос и попросив участников ответить по шкале от 1 до 5: «Я чувствую себя измотанным из-за моя работа."

Вы также можете найти более простую версию MBI здесь.

Поддержание конкурентного преимущества

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

Как мы можем это измерить?

  1. Accelerate и Отчет о состоянии DevOps — самые четкие исследования того, как выглядят лучшие отраслевые практики. Такие показатели, как время цикла и время, необходимое для реагирования на сбои, — хорошие способы сравнить себя с лучшими командами в отрасли.
  2. Если есть определенные инструменты или методы, которые вы определили как передовые, то сравнение себя с их использованием в отрасли — это еще один способ измерить, не отстаете ли вы от конкурентов. Например, увидеть, как быстро индустрия внедряет Docker и сравнить себя с ним.
  3. Еще один простой индикатор — измерить, насколько актуальны ваши инструменты, библиотеки и фреймворки. Их новые версии часто обеспечивают оптимизацию рабочего процесса, а постоянное обновление позволяет избежать необходимости приостанавливать другую работу, пока вы обновляете несколько версий одновременно.
  4. Более сложной мерой было бы оценить, есть ли у вашей команды установка на рост. Без установки на рост команды не смогут адаптироваться к задачам идти в ногу с изменениями в отрасли. Измерить, демонстрирует ли команда характеристики мышления роста, сложно, и поиск в Google не привел меня к чему-либо конкретному о том, как это сделать. Возможно, в качестве индикатора будет достаточно простого опроса о том, считают ли команды, что обучение на ошибках ценится так же, как обучение на успехах.

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