Выбор показателей разработки программного обеспечения

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

Читайте больше интервью с некоторыми из лучших разработчиков мира в нашем блоге или подписывайтесь на нас в Twitter.

Проблемы с показателями развития

«На самом деле я не считаю, что показатели являются интересной темой, - говорит Николетт. «Но я считаю, что это необходимая вещь. Это часть необходимых накладных расходов на доставку. Если мы сможем обнаружить возникающие риски при доставке на ранней стадии, то сможем с ними справиться. Если мы не обнаружим их до позднего времени, мы останемся в тупике и проекты могут провалиться ».

За время своей работы Николетт работал с бесчисленным количеством технических менеджеров, но он заметил, что «многие менеджеры, руководители команд и им подобные не знают, что измерять». Обычно происходит следующее: «когда люди перенимают новый процесс или метод», обычно происходит одно из двух, - говорит Николетт. Либо они «используют процесс только по названию, либо пытаются использовать его, но еще не привыкли, а показатели не совсем работают». Или, несмотря на изменение методов, они продолжают проводить измерения таким же образом: «люди склонны использовать измерения, к которым они привыкли. Они всегда измеряли определенным образом, а теперь внедряют новый процесс. Они продолжают измерять то же самое, что и раньше ». Таким образом, показатели не совсем соответствуют процессу и неправильно интерпретируют проблему в самом процессе.

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

Факторы, которые следует учитывать при выборе показателей

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

«Первый фактор - это подход к доставке», - говорит Николетт. Есть традиционный, когда вы «пытаетесь заранее определить все риски ... составляете генеральный план, и вы следуете этому плану». Или есть другой тип, адаптивный, когда «вы начинаете с направления и идеи, как действовать. Затем вы часто запрашиваете обратную связь, чтобы внести поправки в курс ». По словам Николетт, тип доставки «традиционный или адаптивный… имеет наибольшее влияние на то, какие показатели будут работать».

Николетт говорит, что «второй фактор, на который следует обратить внимание, - это модель процесса». «Никто ничего не делает в чистом виде, но если вы все усложните, я думаю, что мы можем рассмотреть в основном четыре эталонные модели. Один из них линейный… канонические шаги, которые мы проходим от требований до поддержки. Он говорит, что «следующий будет итеративным, когда вы пересматриваете требования несколько раз и что-то с ними делаете. Третий, который я определяю, ограничен по времени. Сейчас это очень популярно с такими процессами, как Scrum и так далее. Четвертый - это непрерывный поток. Сейчас это популярно с методом Канбан, и его также довольно часто адаптируют в Scrum-команды. И именно здесь мы действительно заинтересованы в бесперебойной работе ».

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

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

Примеры сценариев

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

Метрики для гибких команд

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

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

Метрики для гибридных команд Waterfall-Agile

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

«Чтобы узнать, что можно доставить, вы можете использовать диаграмму сжигания, сжигать или сжигать по своему усмотрению», - предлагает Николетт. Это поможет им увидеть, «в зависимости от скорости работы, какой объем они могут предоставить к заданной дате». И наоборот, вы могли видеть, к какой приблизительной дате они могут доставить заданный объем. Это зависит от гибкости. В проектах такого типа, как правило, ни один из них не является гибким, но, по крайней мере, вы можете получить раннее предупреждение о риске доставки ».

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

Оптимизация процессов Канбан

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

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

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

Накопительные метрики для управления развитием

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

Николетт рекомендует, чтобы измерить, «как работают команды, вам нужны измерения, сопоставимые по командам и сопоставимые по проектам». С этой целью он рекомендует «отслеживать пропускную способность, время цикла» и «эффективность цикла процесса» как «те, которые хорошо складываются». Однако он предупреждает, что «некоторые другие показатели не так хорошо работают» - «например, agile-показатели, особенно скорость, которая действительно различается для каждой команды».

«Другой вопрос о качестве кода, я думаю, должен быть обязанностью команды. Затем они могут использовать показатели, но им не нужно сообщать о них вне команды. Обычно то, что они могут извлечь из инструментов статического анализа кода, помогает им выявить потенциальные проблемы с качеством, но я бы не стал делиться подробными вещами, такими как статический анализ кода ... вне команды, потому что тогда члены команды будут чувствовать, что они чтобы их оценили, и они начнут играть в цифры ».