Четыре способа все испортить

• Заявите, что Agile – единственный вариант.

• Объявите, что все настолько очевидно, что любой дурак сможет справиться и не потребуется никакого обучения.

• Скажите, что гибкие подходы безошибочны, а причина неудач – недостатки отдельных людей.

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

Agile в массы!

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

Неофициальный пиар Agile работает так же и может помочь и вам. Есть целый ряд организаций, страстно приверженных Agile, так почему бы не упомянуть несколько названий? Как насчет Intel? Spotify? Google? Старых добрых Waitrose ^[3]? Сейчас сложнее будет найти организацию, которая не заинтересована в поиске новых способов улучшения производительности. Ну а Agile у себя внедряют хорошие компании.

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

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

 

 

Предзапуск Agile для начинающих

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

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

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

Дэвид Огилви

Не только для IT

Одно из самых распространенных заблуждений заключается в том, что Agile подходит только для проектов в области информационных технологий (IT). В действительности это далеко не так, и большая часть концепций, с которыми вы можете ознакомиться в этой книге, отлично подходит и для других сфер деятельности. Одним из основных исключений является экстремальное программирование (XP, eXtreme Programming), что, впрочем, неудивительно, учитывая название. Автоиндустрия в этом плане является лидирующей с их технологией бережливого производства, а практика показывает, что IT в этом плане несколько более консервативны. Нет никаких сомнений в том, что масса IT-команд использует гибкие подходы. Их опыт был бесценен для их совершенствования, но это не означает, что IT имеет эксклюзивное право на применение Agile.

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

 

Оценка успешности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Двоякая польза отчетов

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

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

Даже если люди, непосредственно вовлеченные в разработку, точно знают, как обстоят дела, все равно необходимо доносить информацию и до оставшейся части компании. Например, использование статусов по цветам светофора (RAG: Red, Amber, Green. Красный, желтый, зеленый) резко отличает Agile от традиционных методов управления, в которых людям, не участвующим в проекте, используемые метрики обычно непонятны. От Agile-команды ожидается, что она будет представлять плоды своих трудов в формате бизнес-ценности, по которому можно будет сделать прогноз о будущей производительности.

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

Доклады о ходе работы обычно используют систему цветов светофора или «RAG-статус» как визуальный сигнал для суммирования производительности для всех заинтересованных лиц:

Красный – серьезные проблемы, блокирующие дальнейшую разработку.

Желтый, или янтарный, – препятствия, которые могут быть устранены.

Зеленый – все в порядке.

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

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

Полезным инструментом для отслеживания прогресса является диаграмма сжигания задач. Она показывает прогресс выполнения проекта в наиболее распространенном варианте в виде двух линий на графике:

• общая работа – суммарная оценка сложности проекта – в динамике;

• выполненные задачи – в динамике.

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

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

Рис. 7.1. Блистательная диаграмма сжигания задач

 

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

 

Избегайте повторения ошибок

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

В разгар битвы за внедрение Agile важно сохранять реалистичность при предоставлении гарантий насчет «что» и «как». Не увлекайтесь идеей быстрее, дешевле, лучше. Будьте особенно осторожны в чрезмерно оптимистичных оценках преимущества внедрения Agile и не игнорируйте минусы. Блестящие результаты не нужны, если очень хороших более чем достаточно. Если вы ожидаете идеального результата, даже оценка 9 из 10 может разочаровать.

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

Блистательная мысль

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

• Нечеткие цели и задачи – начинайте всегда с понятным видением проекта.

• Неопределенные требования заказчика – пользовательские истории должны быть ясными.

• Недостаточное обучение – обеспечьте соответствующие тренировки и коучинг.

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

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

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

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

Хэлфорлд Лаккок (американский методист, министр и профессор)

Завершающие слова

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

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

Нет необходимости вовлекать вообще всех, это не крестовый поход. Но обращайте внимание и на не столь очевидных кандидатов.

Блистательный итог

• Ознакомьтесь с причинами, которые могут заинтересовать всех принимающих решения насчет введения Agile, – с каждым нужно говорить на его языке.

• Agile – больше чем термин из IT; не оставляйте без внимания ни один аспект.

• Отчеты, фокусирующиеся на выпуске продукта и конкретных достижениях, – это именно то, чего все хотят.

• Даже «старая школа» может пригодиться; она уже давно столкнулась с большинством проблем.

• Не переоценивайте себя; даже блестящий результат может разочаровать, если настроиться на идеальный.