Методологии гибкой разработки (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, очень велик.

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

Спринт включает 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 для разработки автоматизированной системы учёта данных ФБР. Когда он взялся за проект, разработка шла четвёртый год, ни одну функцию не довели до релиза и ни конца, ни края проекту не было видно. Джеффу удалось радикально ускорить разработку и сделать её прозрачной для заказчиков. Через полгода увидела свет первая рабочая версия продукта, а в течение двух лет разработка была успешно завершена.

Пара слов о книге Джеффа Сазерленда
Scrum: The Art of Doing Twice the Work in Half the Time. В русском переводе — «Scrum: революционный метод управления проектами». Впервые изданная в 2014 году, книга описывает предпосылки к созданию методологии, её базовые принципы, инструментарий и примеры внедрения. За 20 лет, прошедшие с тех пор, как автор книги Джефф Сазерленд и Кен Швайбер системно описали концепцию Scrum, они приложили немало усилий к тому, чтобы распространить методологию за пределы IT-отрасли и поставить её на службу нетехнологическим компаниям — финансовым, промышленным и так далее.

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


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

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

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

Комментарии (7)


  1. halted
    27.11.2018 10:41

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


  1. anonymous
    27.11.2018 12:32
    +1

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

    И что имеем формально Agile, по факту таже самая бюрократия и узколобость только вид сбоку. Ну и миллион прикольных аббревиатур и иностранных словечек

    Я это к тому, что помимо хайпа, люди должны понимать зачем это нужно и менять старые формации ведения бизнеса.


    1. halted
      27.11.2018 12:41
      +1

      Вы повторили тезис Неймана о том, что «людям нужно обьяснять». Без регулярной разъяснительной работы любая идея будет искажена и опошлена. Людям натурально надо напоминать, что они делают и зачем, как бы это не было похоже на пропаганду.


  1. aosja
    27.11.2018 13:33

    Без регулярной разъяснительной работы любая идея будет искажена и опошлена

    Это точно. Вот, например, из стать по ссылке на Agile-манифест:
    «Во время перекура дизайнер пошутил, что вместо сбора грибов Марио бы принцесс спасать. Идея хорошая, у конкурентов такого нет. Что сделали команды?

    Обычная команда
    Отложила идею на будущее и продолжила работу по первоначальному плану.

    Аджайловая команда
    Добавила в игру принцессу Пич, которую постоянно похищает злодей.»

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


    1. rai
      28.11.2018 11:39
      +1

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


      1. aosja
        28.11.2018 14:32

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


  1. otchgol
    28.11.2018 11:39

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