Эффективность – красивое слово. Удобно вставлять его в фразы типа: "я работаю максимально эффективно", "нужно найти эффективное решение", "повышаем эффективность процессов", "наша цель – эффективный код", "Вася – эффективный менеджер". Но что конкретно при этом мы имеем в виду?

У слова "эффективный" есть два значения:

1. дающий эффект, действенный, позволяющий достичь желаемого результата, далее в тексте – результативный
2. оптимальный, позволяющий достичь желаемого результата с минимальными затратами, наименьшими нежелательными эффектами/ошибками, рентабельный, организованный, с высоким КПД, далее в тексте – производительный

В английском языке – это два разных слова: effective и efficient.

• Being effective is about doing the right things, while being efficient is about doing things right.

Различиям между этими словами посвятили свои работы многие теоретики и практики менеджмента. Давайте посмотрим, что писали по этому поводу Питер Друкер и Ицхак Адизес.

Agile Манифест был опубликован в 2001 году. Он определил ценности и принципы, на основе которых всё множество практик, использовавшихся в разработке программного обеспечения, как новых, так и ранее существовавших, было разделено на две части – Agile практики и не-Agile практики.

Например, юнит-тестирование, покер планирования, ежедневные стендапы стали считаться Agile практиками.

С другой стороны, штрафование сотрудников, подготовка и подписание полного ТЗ проекта, разделение команд по функциональному признаку (отделы архитектуры, разработки, качества) в Agile список не попали.

Причины, по которым ту или иную практику считают Agile или наоборот, не всегда очевидны.

Данная статья – попытка переосмыслить известные мне Agile практики, сформулировать простые и четкие критерии того, какую практику можно считать Agile, а какую нет.

HR-специалист одной компании недавно сказал такую фразу: “разработчики не хотят к нам идти, как только узнают, что мы работаем по Agile”. И хотя я сам нередко слышу недовольство, высказываемое разработчиками в отношении Agile, такая категоричность меня удивила.

Ведь одна из целей Agile – создание комфортных условий для работы тех самых разработчиков. Agile-практики стремятся освободить разработчиков от рутины, поощряют творческий подход. Самоорганизация, минимизация бюрократии – всё это призвано упростить жизнь разработчиков. Happiness (счастье) разработчиков – одна из Agile-метрик, которую нужно повышать.

Почему же не стыкуются отзывы реальных разработчиков с декларируемыми целями Agile?

В agile-командах часто возникает спор, насколько детально должна быть проработана User Story, прежде чем ее следует передавать разработчикам.

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

Рассмотрим Agile-подход к решению этой проблемы.