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

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

Блистательный пример

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

• принятие гибкой философии перед началом проекта – включая сегментированный подход, сотрудничество и все итерации разработки;

• принятие решений внутри команды – расширение полномочий участников команды;

• заинтересованность представителя заказчика в постоянном участии в проекте – гарантированный доступ к нужному ресурсу;

• согласие на инкрементную поставку – принятие того, что это желаемый и практичный вариант;

• постоянный доступ ко всем участникам команды – предпочтительно работающим на доступном расстоянии друг от друга или при налаженной системе связи;

• постоянный состав команды – на протяжении всей работы над проектом;

• правильно подобранные специалисты с гибким мышлением – команда профессионалов с коммуникативными навыками;

• необходимый размер – маленькая команда для обеспечения наилучшего взаимодействия и сотрудничества;

• благоприятная коммерческая база – сначала доверие и сотрудничество, а потом уже любые оговорки.

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

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

Гибкая революция в реализации метрик показателей эффективности и тут перевернула все с ног на голову. Любые характеристики принадлежат команде и используются ими для выполнения работы. Из-за этого сдвига акцентов показатели эффективности лучше воспринимаются, поскольку команды могут теперь посмотреть, как именно идет работа. Без этих характеристик гибкие подходы – особенно Скрам и Канбан – не смогут функционировать должным образом.

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

Блистательное определение

Основные принципы 1–2-3 для определения метрик показателей эффективности:

• определите важнейшие процессы или требования заказчика;

• определите специфический, измеримый результат работы;

• установите цели, по которым можно измерить результаты.

Мантра любых метрик: измерь, проверь и улучши. Без измерения ничего не выйдет.

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

Поскольку гибкие подходы сосредоточены на бизнес-ценности, показатели всегда должны быть понятными для заинтересованных сторон. Процесс расчета выполняется для команды, и значение скорости будет разниться, однако конечный результат вполне точен. Это субъективное значение может быть использовано для вычисления того, что именно и через какое время может быть выпущено. Например, «Agile-команда A реализует функции A, B и C через X недель». Заказчик точно знает, чем занята команда в этот период времени и на что именно уходят его денежки.

Блистательный пример

Краткое пособие по использованию скорости работы команды в Agile.

• Согласуйте шкалу от одного до пяти для измерения масштабов работы (например, 1 = незначительная, 5 = большая).

• Оцените по этой шкале все задачи, которые должна выполнить команда в определенный временной промежуток (например, две недели).

• Сосчитайте общее количество баллов реализованных задач (скорость работы команды).

• Определите минимальные и максимальные значения, чтобы определить предельные значения скорости для команды.

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

• Планируйте выполнение будущих задач на основе средней скорости. Повторяйте до тех пор, пока запланированное и фактическое значения скоростей не будут совпадать.

Вы можете использовать это значение для прогнозирования выполнения задач.

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