Мифы об Agile. Миф №5: Agile означает быстро и дешево

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

Миф звучит так: «Я менеджер проекта. Руководство поручило мне большой проект. Я мог бы сделать это методом Водопада (Waterfall), как обычно. Но все крутые ребята сейчас используют Agile. Agile означает быстрее и дешевле, чем медленный и дорогой Waterfall. А заинтересованные стороны хотят быстрее и дешевле. Так что я собираюсь взять этот большой проект и выполнить его с Agile!». Здесь есть целый ряд ошибок. Давайте рассмотрим их все по очереди.

1. Agile отвергает большие неуклюжие проекты

Здесь есть проблема в самой исходной посылке: «Я возьму свой существующий большой проект и выполню его с помощью Agile, вместо Waterfall». Разработка программного обеспечения по Agile, в первую очередь, не позволяет делать большие неуклюжие проекты. Agile-разработка не любит большие проекты. Agile-разработка вообще не любит проекты. Вместо всего этого:

Agile поощряет переход от мышления проекта к мышлению продукта. Agile поощряет переход от большого к маленькому размеру партии. Agile поощряет постепенное и итеративное развитие.

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

Попытка «применить» Agile к вашему большому проекту, в котором некоторые «заинтересованные стороны» заранее определили содержание, теряет смысл. Это попытка втиснуть квадратный колышек в круглое отверстие. И это еще не все.

2. Agile ориентируется на клиентов, а не на руководство

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

Agile-мышление вместо этого пытается взглянуть на вещи с точки зрения клиента. Какое программное обеспечение хотят клиенты? Какое программное обеспечение клиенты найдут ценным? Как нам поставить какую-то часть (не все) им раньше? И как нам быстрее извлечь уроки из программного обеспечения, которое мы создали и поставили? Как нам улучшить себя, чтобы мы смогли поставить еще более ценное программное обеспечение для клиента?

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

3. Agile использует другой «железный» треугольник

Обычный треугольник

Традиционное «железный» треугольник управления проектами – это содержание (объем), затраты (бюджет) и сроки. Бюджет, как правило, зависит от времени (мы обычно платим людям за то, как долго они работают, то есть за время и материалы, если мы не делаем проект с фиксированной ставкой). А время обычно является функцией содержания (чем больше функций вы должны создать, тем больше времени для этого потребуется).

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

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

В своей выдающейся книге «Agile Project Management» Джим Хайсмит рассказал о другом треугольнике. Agile-треугольник имеет другие вершины: ценность, качество и ограничения. И вот точка ограничения на треугольнике сама по себе является треугольником: тот самый исходный железный треугольник управления проектами (содержание, затраты, сроки). Итак, как этот новый треугольник связан с исходным?

Новый треугольник

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

Любой здравомыслящий человек создаст. Любой разумный бизнес создаст. Так вы меняете свои ограничения на ценность. Или, если вы обнаружите дефект в вашем продукте, который может навредить или даже убить клиентов, вы приложите усилия для его исправления? Даже если это означает, что вы нарушите сроки, или вам придется отказаться от этой функции? Конечно, вы исправите его. Так вы меняете ограничения на качество.

Таким образом, Agile-фокусировка на ценность и качество, а не на ограничения, не просто оправдана, это самая честная и разумная позиция. Руководитель проекта Waterfall с гордостью делает упор на контроле затрат и времени, потому что он рассказывает эту историю руководству, а не клиентам, использующим программное обеспечение.

4. Agile может быть немного медленнее, и это нормально

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

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

Тем не менее, даже если Agile может создавать отдельные функции медленнее, он дает огромное преимущество перед проектами Waterfall: раннюю поставку. Что вы предпочтете: проект, который завершится за пять месяцев и предоставит клиентам все шесть функций через эти пять месяцев, или проект, который завершится через шесть месяцев и предоставит шесть функций по одной в месяц, начиная с первого месяца?

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

Agile означает маленький и ранний, а не быстрый и дешевый

Возможно, лучший набор слов для описания Agile – «маленький и ранний», а не «быстрый и дешевый», в отличие от «большой и поздний» для Waterfall. А что вы думаете?

Автор: Leon Tranter
Источник
Business photo created by yanalya — www.freepik.com

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.