Что такое Agile, зачем и где используется, разница Scrum и Kanban

Что входит в методы:

1. 1992 – Crystal Methods. Позже в 1997 году упростили до Crystal. Скажем спасибо Алистеру Коберну, за его идеи в своём подходе, потому что именно они легли в основу начала движения Agile. В его методе мы также можем увидеть основы agile-манифеста, о нем чуть позже.

2. 1993 – Refactoring. Об этом методе можно прочитать в оригинале жми сюда

3. 1994 – Dynamic Systems Development Method (DSDM). Разработан консорциумом и отличнно раскрыт здесь

4. 1995 – Scrum and Pair Development. Вот он мой любимчик. Основан Джефом Сазерлендом и Кеном Швабером. Но здесь важно еще упомянуть одного человека — Майк Бидл (Mike Beedleв оригинале), который продвинул идеи SCRUM в массы. И по сути именно этот метод больше всего ассоциируется с Agile, а иногда даже считается синонимом.

5. 1997 – Feature Driven Development (FDD). Под эту методологию есть целая книга ссылочка.

6. 1999 – Adaptive Software Development и снова книга

Что такое agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile.

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах AgileManifesto[1]:

  1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
  2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
  3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
  4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
  5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
  6. постоянный темп работы всех участников проекта на протяжении всего его срока;
  7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
  8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
  9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
  10. самоорганизация и самоконтроль команды проекта;
  11. непрерывное улучшение профессиональных компетенций команды проекта;
  12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.
принципы Agile
Главные принципы Agile

Внутренняя работа

Единственный вопрос, на который я долго искал ответ: как же тогда происходит работа в agile-компании?

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

Вернемся к нашему любимому хлебозаводу. И к их старой задаче – выпустить новый сорт хлеба. Для реализации задачи у них была следующая последовательность:

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

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

  3. Тестирование. Все идеи и знания суммируются в тестовый рецепт. Данный рецепт выпекается небольшой пробной партией для получения по нему обратной связи на закрытой дегустации среди обычных покупателей (!!!).
  4. Сбор обратной связи. Покупатели едят хлеб и высказывают свои пожелания. На основании этого в тестовый рецепт вносятся изменения и доработки. Финал.

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

аджайл методология работает
Да, теперь все отлично

Где, как и кем используется agile

Сегодня эджайл применяется не только в управлении ИТ-проектами, а используется как эффективная практика организации труда небольших групп и творческих команд вместе с либеральными и демократическими методами менеджмента [1]. В частности, одной крупной телеком-компании благодаря внедрению Agile-практик в процессы кросс-функциональное взаимодействия всего за 3 месяца удалось достичь следующих результатов [6]:

  • рост от продажи устройств на 45%;
  • сокращение сроков запуска рекламных кампаний в 2 раза;
  • рост плановой ежемесячной выручки от разработки продуктов на 20%;
  • в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7].

Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9]. Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10].

Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

Источники

Гибкость против жесткости: agilevswaterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения.

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

Waterfall, водопад, водопадная каскадная модель разработки ПО
Waterfall — водопадная (каскадная) модель разработки ПО

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

гибкая итерационная разработка ПО, спринт
Гибкая разработка ПО серией итераций

Другие гибкие методологии разработки по

В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:

  • Разработка, управляемая функциональностью (FDD).
  • Crystal Clear. 
  • Метод разработки динамических систем (DSDM).
  • Разработка через тестирование (TDD).
  • Адаптивные рамки проекта (APF),
  • и другие.

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

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

Что это будет, классический Скрам из учебников или смесь Канбан и XP,  зависит целиком и полностью от вас. Главное, чтобы выбранный способ удовлетворял потребностям проекта. Гибкость приветствуется даже в выборе методологии этой самой гибкости.

Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).

Задайте себе 5 вопросов

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

И Вы думаете, что agile это то, что Вам так нужно. Ведь так можно создать что-то новое, поистине инновационный продукт.

Тогда сразу предупрежу Вас и отвечу на несколько вопросов, которые у Вас есть. Это топ-5 вопросов, которые задают себе все собственники, когда видят эту методологию.

1. Подходит малому бизнесу? Если Вы не выпускаете постоянно новые продукты или не реализуете постоянно новые проекты, а работаете на “старом”, то с большей долей вероятности НЕТ. 

2. Легко ли внедрить? Отвечу вопросом на вопрос: А легко выучить иностранный язык? Философию нельзя быстро внедрить в компанию. Ее нужно внедрять пошагово и в течение довольно долгого времени.

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

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

5. Кто должен быть начальником? Прозвучит непривычно, но в agile-компаниях нет начальников. Это кураторы-помощники, которые организовывают людей в совместные команды для более эффективной работы.

Инструменты agile

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

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

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

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

Существует множество цифровых аналогов этих инструментов с впечатляющим функционалом. Однако при перемещении красочных досок и флипчартов с графиками в диджитал-пространство обычно теряется эффект «радиации» информации.

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

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

Как внедрить

Agile нельзя внедрить. Agile — это трансформация процессов и культуры организации. 

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

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

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

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

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

Следующие шаги индивидуальны — кто-то запускает еще несколько команд. Другие запускают масштабную трансформацию, а некоторые вообще отказываются от Agile.

Как устроен scrum — самая популярная гибкая методика


Что такое Agile, зачем и где используется, разница Scrum и Kanban
Scrum

Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел ее, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта

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

2. Выберите команду

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

3. Выберите скрам-мастера

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

4. Создайте бэклог продукта

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

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

5. Уточните и оцените бэклог продукта

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

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

6. Планирование спринта

Это первое скрам-собрание. Команда, скрам-мастер и владелец продукта планируют спринт. Как правило, выбирают спринты длиной в одну или две недели. Команда смотрит в верхнюю часть бэклога и прогнозирует количество заданий, которое возможно выполнить за этот спринт. Скрам-мастер и команда должны в каждом спринте наращивать динамику.

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

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

7. Работа должна быть видимой

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

8. Проводите ежедневные собрания

Это пульс всего процесса Скрама. Каждый день в одно и то же время не более чем на пятнадцать минут команда и скрам-мастер встречаются и дают ответы на три вопроса.

1. Что ты делал вчера, чтобы помочь команде завершить спринт?

2. Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?

3. Какие препятствия встают на пути команды?

Вот и все. Вся встреча. Если на это требуется больше пятнадцати минут, значит вы что-то делаете неправильно.

9. Обзор спринта

Это встреча, на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта. Присутствуют владелец продукта, скрам-мастер, команда и любые заинтересованные лица: заказчик, представители руководства, потенциальные потребители. Это открытая встреча, где команда демонстрирует, что удалось переместить в колонку «Сделано» за время спринта.

10. Ретроспективное собрание

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

С методикой Скрам не слишком трудно удвоить производительность и в два раза приблизить время сдачи проекта. Если вы сделаете это вовремя, ваши доходы и стоимость акций удвоятся. Действуйте.

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

спринт, sprint , Scrum, скрам
Спринты в Scrum

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»).

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно.

Канбан, kanban, доска, эджайл-доска
Задачи на Канбан-доске

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Модель cynefin.

Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.

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

И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.

Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.

В модели описываются 4 вида систем с разной степенью неопределенности:

1. Упорядоченные простые

2. Упорядоченные сложные

3. Комплексные

4. Хаотичные

Упорядоченные простые.

Здесь понятны: цель, результат, ресурсы, есть опыт у команды, понятен контекст задачи.

Например: производство чего-то простого, например, мебели. Методы управления: каскадный, waterfalls.

Упорядоченные сложные.

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

Например: запуск ракеты, строительство многоквартирного дома.

Методы управления: PMBok, Prince2, PMI

Комплексные системы.

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

Пример: стартап

Методы: scrum, другие методы agile.

Хаотичные системы.

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

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

Общие практики agile

1. Работа над мини-блоками

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

2. Маленькие кросс-функциональные команды

Работа обычно выполняется в автономных кросс-функциональных микрокомандах. Каждая из них выполняет что-то потенциально ценное для потребителя. Размер команд варьируется. Одно из главных правил — «семь плюс-минус два». В одних компаниях команды состоят из 10–12 человек, в других они меньше.

3. Ограничение объема незавершенной работы

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

4. Автономность команд.

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

5. Достижение стадии готовности.

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

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

6. Беспрерывная работа.

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

7. Полная прозрачность и использование досок со стикерами.

Использование «бумажных источников информации» стало неожиданным открытием. Фактически любой мог попасть на рабочее место сотрудников и сразу узнать статус работы и источник потенциальных проблем.

8. Обратная связь от пользователей на каждом цикле.

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

По материалам книг «Scrum» и «Эпоха Agile».

Изображения: источник.

Первый — управленец из финансового сектора.

“Мы традиционно работали по каскадной модели, начиная с 90х годов. Имеем огромную ветвистую структуру. Где по большей части общаются на уровнях, middle менеджмент с middle менеджментом, линейные сотрудники с линейными. Данная структура позволяет достичь предсказуемого результата.

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

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

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

За полгода внедрения, по моим наблюдениям, продукты развиваются лучше, выросла скорость производства, повысилась ответственность. Безусловно из-за перестроения есть люди, которые уходят, они не готовы к изменениям. Приходят новые, с ними проще. Работаем”.

Предисловие.

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

Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.)

Главной задачей ставлю себе написать простым языком для начинающих знакомиться с миром Agile. Тем более я сейчас сам начинающий продакт-менеджер, учусь в product University. Когда буду давать ссылки на разную литературу и источники, увы много на английском. Зато прокачаете язык. Для будущего продакт-менеджера — это хороший навык.

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Примеры проектов и применение agile

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

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

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

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

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

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

Благодаря масштабируемости Скрама несколько команд могут работать на создание новых продуктов и каналов продвижения в диджитал-среде для страхования автомобиля.

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Сущность agile методологии

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

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Принципы, упоминающиеся в манифесте Agile. Просто прочтите, поймёте чуть дальше. 

  • Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
  • Частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще);
  • И много еще подобных.

“Что за чушь я только что прочитал? Ни слова не понял!”. Думаю, у Вас такие сейчас мысли.

Скажу честно, что такое Agile как методология (а также что написано в манифесте), я сам понял далеко не сразу. Книги и статьи давали поверхностное описание, пока я не увидел всё это на практике.

Поэтому я сэкономлю Вам огромное количество времени и расскажу коротко и по делу.

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

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

Финансовый сектор международный опыт.

“Работаю сейчас в международном проекте с полностью распределенной командой. Несколько человек в РФ, Украине, США, Доминикане. Мы работает по agile, некой адаптацией scrum. Dailly у нас превратился в weekly, длина спринта 1 месяц. Главная особенность, которую я заметил, очень большая и регулярная поставка бизнес-ценности.

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

Выводы. Все зависит от людей, а не методики. Scrum работает при условии, если вся компания этим живет. Если задача превышает 4 часа, значит, она не до конца декомпозирована”.

Добавлю свою историю. Во время работы на стыке ИТ и автобизнеса, собственник бизнеса называл меня бренд-директор, директор по развитию и т.д. А ИТ направление — product owner. Эта неопределенность позиции меня немного смущала. Все дело в том, что моя должность была точкой схождения двух методов управления.

Топ-менеджмент работал по каскадной системе, ИТ производство по agile. Скажу, что конфликтов на этой почве была масса. На 5часовых совещаниях ИТ директор под конец убегал с трясущимися руками и воплями «неучи тупые», «что я тут бисер мечу перед свиньями» или «прежде, чем сделать что-то автоматически, продумайте это логически», а управленцы других направлений сыпали “ИТшники криворукие, вся система работает через ж@ #у “. Тем не менее, компания была успешна и являлась лидером в своем сегменте. Вывод за меня озвучил мой собеседник выше.

Гибкие материалы:  ᐉ Что такое Agile • Как появился, плюсы и минусы ✓

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *