Методологии гибкой разработки (Agile) прижились и в IT, и в не-IT, обросли своими приметами, стереотипами, суевериями и мифологией. Редакция блога Mail.Ru Cloud Solutions решила поговорить об этой мифологии с Agile-коучем Василием Савуновым из ScrumTrek.

Agile — философия гибкой разработки, основы которой описаны в «Agile-манифесте разработки программного обеспечения». В фундаменте концепции лежат четыре базовых ценности:

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

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

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

Миф 1. Agile — это только для IT

Уже нет. Достаточно посмотреть на список компаний, от лица которых выступают спикеры на конференциях Agile Days и Agile Business Conference: «Газпромнефть», «Ростелеком», «Северсталь», PTG-Group, 12Storeez. Эти и масса других организаций, не относящихся к IT-индустрии, более чем успешно используют Agile-подходы.

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

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

Миф 3. Agile — панацея для бизнеса и разработки: внедри, что-нибудь да улучшится

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

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



Agile окажется вреден там, где стоимость «переработки» или «доработки» продукта колоссальна или даже может быть сопряжена с человеческими жертвами. Скажем, при строительстве атомной электростанции – очевидно, что мы не можем строить ее итеративно-инкрементально, как нам диктует Agile.

Миф 4. Scrum, Lean, Kanban не пересекаются между собой

Следует разделять методологии и инструменты. Методология — это алгоритм построения рабочего процесса. Инструменты – это те «кирпичики», которые в этом алгоритме используются.

Разные методологии могут включать в себя одни и те же инструменты, но в разной компоновке. Часто можно увидеть, как при реализации Scrum прибегают к инструментам XP (экстремального программирования) или Kanban. И это нормально, так как все они отвечают ценностям Agile, и позволяют сделать рабочий процесс создания продукта гибким.

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

Миф 5. Scrum — это как быстро и дёшево сделать продукт

Насчёт «быстро» всё верно, а вот насчет «дёшево» — нет. Судите сами: вам нужно сформировать полноценную команду, выделив в неё на 100% нужные компетенции. Эти люди будут заняты только разработкой вверенного им продукта и ничем другим, а значит, придётся либо нанять таких специалистов, либо «оторвать» их от какого-то отдела. То же самое касается бизнес-части: хочешь, не хочешь, а потребуется выделить владельца продукта, который 50–80% своего времени будет уделять только этой команде и её продукту.

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


Спринт включает 4 обязательных встречи: планирование, реализация, релиз, спринт-ревью с ретроспективой. Кроме того, каждый день проводятся короткие встречи (stand-up meetings), на которых члены команды в едином формате «сверяют часы» и согласуют свои действия. Добавлять новые задачи в открытый спринт нельзя — это приучает команду к планированию и страхует от возникновения управленческого хаоса.

Миф 6. Канбан — это доски с вывешенными на них задачами

Вовсе нет! Доски — это лишь первый, самый простой шаг в Канбане. Но им дело не ограничивается. В основе Канбана — сложный математический аппарат, основанный на статистических данных. Поэтому приравнивать Канбан к доскам — значит не заглядывать дальше его фасада.

Если в двух словах, то главный смысл Канбана — в том, чтобы:

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

Миф 7. Scrum и Канбан можно насадить в любых проектах и компаниях

Мне не нравится слово «насаждение», всё-таки Agile — про работу с людьми. Правильнее будет говорить о том, чтобы «прививать» команде новую философию мышления.

При этом, алгоритм прививания Scrum и Канбан — разный.

Степень успешности использования Scrum зависит от главенствующей в компании корпоративной культуры. В жёсткой иерархической структуре, где на каждый чих нужна бумажка, никакие усилия по «выращиванию» Scrum не увенчаются успехом без поддержки топ-менеджмента. Придётся встраивать новую, параллельную структуру, основанную на командном подходе. Своего рода «заповедник Agile», который будет защищать кто-то из управленцев высшего эшелона. В таких условиях есть возможность показать быстрый результат за три-четыре месяца. Но впереди будет задача посложнее — распространить эту культуру на всю организацию. Сколько это продлится, оценить крайне сложно. Но, по моему опыту, если новый подход охватил 30 % компании, то дальше он начинает распространяться сам, и ему больше не нужна защита сверху.

Внедрение Scrum вообще требует больших изменений, как в структуре организации, так и в контрактовании с подрядчиками (нужен контракт time & material), и в бюджетировании (поэтапное бюджетирование), и во всём остальном.



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

Миф 8. Scrum рассчитан только на проекты, которые делаются с нуля

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

Например, один из создателей Scrum Джефф Сазерленд в своей книге «Scrum: The Art of Doing Twice the Work in Half the Time» рассказывал, как он применил Scrum для разработки автоматизированной системы учёта данных ФБР. Когда он взялся за проект, разработка шла четвёртый год, ни одну функцию не довели до релиза и ни конца, ни края проекту не было видно. Джеффу удалось радикально ускорить разработку и сделать её прозрачной для заказчиков. Через полгода увидела свет первая рабочая версия продукта, а в течение двух лет разработка была успешно завершена.

Миф 9. При внедрении гибких методологий неизбежны конфликты с представителями традиционной иерархии

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

А о том, кто такой Scrum-мастер, вы узнаете в следующей серии. Ждите во второй части рассказ Василия о внедрении гибких методологий разработки: сложности, выгоды, подводные камни и бомбы замедленного действия.

UPD. А вот и продолжение: Все дело в Agile — 2: особенности внедрения гибкой разработки

Нет времени объяснять, материал бескорыстно и с любовью подготовила команда Mail.Ru Cloud Solutions.