agile мифы про agile управление проектами agile

9 мифов про Agile

Mykola Sarry

• 5 min read

Методологии гибкой разработки (Agile) работают и в IT, и не в IT. За время прошедшее с выпуска манифеста они обросли приметами, стереотипами, суевериями, легендами и мифами.

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

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

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

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

Миф №1. Agile работает только для IT-продуктов/компаний.

Это не так. Например, Kanban пришел в IT-индустрию из компании Toyota, которая применяла его для повышения скорости и качества выпуска новых автомобилей. Существует большое количество не IT-компаний, которые успешно применяют Agile-подходы. Посмотрите на список спикеров Agile Business Conference 2019, среди которых руководители банков, производителей автомобилей, руководители телекоммуникационных компаний.

Миф №2. Agile не подходит для проектов с фиксированным бюджетов.

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

Миф №3. Внедрение Agile даст моментальное улучшение.

Такой подход очень вредный. Все случаи и бизнесы разные. И к каждому нужно подбирать подход, который будет эффективен в конкретном случае.

Agile не приживется там, где:

  • для достижения успеха нужно следовать четкому детально прописанному алгоритму действий;
  • там где не существует пространства для экспериментов;
  • там где стоимость переработок и доработок колоссальна или сопряжена с человеческими жертвами.

Например, строительство электростанции, самолета, космического корабля. Эти вещи не могут выполнять итеративно-инкрементально, как того требует Agile,

Миф №4. Agile-методологии не пересекаются между собой.

Следует разделять методологию и инструмент. Методология – это алгоритм рабочего процесса. Инструмент – составляющая часть используемая в алгоритме. Различные методологии могут содержать одинаковые инструменты, но по-разному их комбинировать. Например, при использовании Scrum прибегают к некоторым инструментам Kanban или XP. И это не является ненормальным, поскольку все они отвечают ценностям Agile и позволяют сделать рабочий процесс более гибким. Но не нужно думать что нельзя совмещать Agile-методологию с элементами водопада. Это тоже является нормальным – если позволяет вам получить на выходе гибкий рабочий процесс.

Если говорить о конкретных Agile-подходах, которые сейчас наиболее распространены, то наиболее часто применяются Scrum и Kanban. FDD, XP, RUP используются крайне редко, либо применяются не целиком, а только частично в связке с другим фреймворком. На сегодняшний день в компаниях можно встретить применение в полном, частичном или гибридном виде следующие методологии:

Миф №5. Scrum помогает быстро и дешево делать продукты.

Насчет скорости поспорить сложно, а вот стоимость – весьма и весьма спорный момент. Давайте посмотрим, что требует Scrum:

  • сформировать полноценную scrum-команду;
  • обеспечить ее на 100% необходимыми компетенциями;
  • команда должна заниматься разработкой только одного выделенного ей продукта;
  • нужно выделить владельца продукта, который сможет уделять от 50 до 80 процентов своего времени только этому продукту и только этой команде.

Помимо этого вам понадобится собрать их вместе, выделить отдельное помещение, обеспечить необходимым реквизитом для командных активностей и т.д. Также нужно понимать, что как минимум 8 часов каждого спринта будет потрачено на коммуникации, поскольку Scrum предполагает ряд обязательных встреч.

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

Спринт – фиксированный промежуток времени, в течении которого команда реализует часть продукта имеющую ценность для заказчика. За каждый спринт команда делает очередной шаг к достижению цели проекта. Чаще всего спринт длится 2 недели.

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

Миф №6. Kanban – это доска с задачами

Отнюдь. Доска – всего лишь первый и самый простой элемент Канбана. В основе этой методологии лежит математический аппарат, который основывается на статистических данных. Говорить о Канбане только как о доске – не смотреть, что это такое на самом деле. Главный смысл Канбана, если коротко:

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

Миф №7. Agile можно применить в любой компании и любом проекте.

Во первых здесь следует вспомнить, то о чем мы говорили в Мифе №3. Во-вторых Agile это не про административную часть процесса, а про работу с людьми. Алгоритм внедрения зависит от выбранного фреймворка.

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

Но внедрение Scrum требует также и изменений во взаимодействии с подрядчиками, подходе к бюджетированию и т.п.

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

Миф №8. Scrum применим только к созданию продукта с нуля.

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

Создатель Scrum Джефф Сазерленд в своей книге “Scrum: The Art of Doing Twice the Work in Half the Time” рассказывает как он применил Scrum для автоматизированной системы учета данных в ФБР. В момент когда он принял этот проект, разработка длилась уже 4 года и ни одна из функций не была доведена до состояния пригодного к какому-либо использованию. Ему удалось ускорить разработку и сделать ее прозрачной для заказчиков. Через полгода была выпущена первая работоспособная версия продукта, а в течении двух лет разработка успешно завершилась.

За 20 лет прошедших с выхода книги и описании концепции Scrum Джеффом Сазерлендом и Кеном Швайбером этот фреймворк распространился за пределы IT-отрасли и стал на службе у нетехнологических компаний.

Миф №9. Внедрение гибкой методологии приводит к конфликтам с представителями классической иерархии.

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