Эджайл

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

Что такое Аджайл

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

Буддисты верят, что могут достичь просветления. Они медитируют, стараются быть умеренными и не причиняют вреда другим.

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

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

Как появился Аджайл

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

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

Чтобы найти формулу успешных продуктов, в 2001 году 17 практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои способы разработки и сделали открытие: подходы у всех разные, но идеи совпадают. Эти идеи заложили в основу Аджайла, записали в Аджайл Манифесте и дополнили Принципами Аджайла.

В чём суть философии Аджайла

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

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

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

Шеф и технолог будут отчитываться перед владельцем пекарни. А он — хвалить или ругать за неудачу.

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

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

Аджайл — это быть командами профессионалов, которым не нужны начальники

Процесс работы тоже отличается. Строгое распределение функций в традиционной пекарне и совместные эксперименты Команды:

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

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

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

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

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

Аджайл — это работа вместе с клиентом, эксперименты и готовность изменить план

Результаты пекарен будут кардинально различаться. Непредсказуемый у одних и гарантированно хороший у других:

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

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

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

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

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

Чтобы выстроить работу в духе Аджайла, пекарня из нашего примера использовала в работе идеи Аджайл Манифеста:

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

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

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

Что даёт Аджайл

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

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

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

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

Комфортный режим работы и объём нагрузки. Команда должна быть в состоянии работать бесконечно долго. Аджайл запрещает авралы и пропагандирует комфортный ритм, в котором интересно работать и справляться с новыми профессиональными вызовами.

Аджайл помогает быть счастливее: видеть в работе дело жизни и получать от неё удовольствие

При чём здесь Скрам и Канбан

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

Чтобы применить философию на практике, используют фреймворки: Скрам, Канбан и другие.

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

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

Сами того не зная, вы разделяете философию Аджайла, хотя и не используете фреймворки.

Можно использовать фреймворки без Аджайла. Это беда большинства российских компаний, которые пробуют Аджайл.

Часто они вешают доски со стикерами, переименовывают планёрки в митинги, но по сути ничего не меняют. Это малоэффективно и похоже на культ карго.

Лучший вариант — соединить философию с практикой и получить предсказуемо хороший результат

Шпаргалка

Запомнить
Аджайл — это образ мышления со своей системой ценностей.

Фреймворк — это набор правил для переноса философии Аджайла в жизнь.

Вместе они дают результат.

Говорить правильно
быть аджайл
работать в духе Аджайла
работать по Аджайлу
аджайловый образ мышления

Узнать больше
Аджайл Манифест

Принципы Аджайла

Записаться на тренинг
Статьи хороши для первого знакомства с Аджайлом.

Разобраться в теме мы помогаем на базовом тренинге. Он полезен всем, кто всерьёз заинтересовался гибкими подходами. Объясняем тему понятным языком, поэтому специальная подготовка не нужна.

Записаться…

Текст: Люба Мамаева

Поделиться

Линкануть

Поделиться

Класснуть

Отправить

.

Ссылки

  1. Чем Agile-методологии нравятся маркетологам
  2. Что отличает настоящий Agile от фальшивого
  3. Agile: как сделать гибкой всю вашу компанию

Что такое гибкие методологии разработки

Гибкая методология разработки (Agile software development) – манифест, содержащий основные ценности и принципы, на которых базируются подходы к управлению проектами, который решает проблемы традиционного проектного менеджмента. Agile подходит для инновационных проектов. Гораздо меньше он подходит для процессной деятельности. Эти подходы подразумевают интерактивную разработку, с периодическими обновлениями требований от заказчика и их реализацию посредством самоорганизующихся команд, сформированных из экспертов разного профиля. Под термином «гибкая методология разработки» следует понимать подходы на основе данного манифеста, или фреймворки. Существует множество фреймворков, подходы которых базируются на Agile, например: Scrum, Extreme programming, FDD, DSDM… Данный манифест – разработка команды авторов. (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas).

Суть Agile

Методология Agile создана как противоположность традиционной линейной методологии «водопад», подразумевая итеративную и пошаговую разработку ПО, что минимизирует риски. Суть в том, что работа с применением гибкой методологии состоит из серии коротких циклов (итераций), длительностью 2-3 недели. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. По завершению каждой итерации команда предъявляет заказчику «осязаемые» результаты работы, например, первичную версию продукта или часть функционала, которую можно посмотреть, оценить, протестировать, а потом доработать или скорректировать. Итого заказчик контролирует разработку и может на неё сразу влиять. После каждого этапа, на основе проделанной работы, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки продукта.

Ценности и принципы манифеста

Манифест гибкой методологии определяет четыре основные ценности и 12 принципов для методологий, базирующихся на нем.
Ценности:

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

Основополагающие принципы Agile-манифеста:
1. Наивысшим приоритетом является удовлетворение потребностей заказчика.
2. Изменение требований приветствуется на любой стадии разработки. Изменения обеспечивают заказчику конкурентные преимущества.
3. Работающий продукт следует выпускать как можно чаще.
4. На протяжении всего проекта разработчики и заказчик должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные специалисты. Для этого необходимо создать условия, обеспечить поддержку и доверять.
6. Для эффективного обмена информацией с самой командой и внутри команды подходит непосредственное общение.
7. Основной показатель прогресса – работающий продукт.
8. Процесс разработки должен быть постоянным и устойчивым.
9. Внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10.

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

Когда использовать Agile?

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

Это заготовка энциклопедической статьи по данной теме.

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

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

Содержание статьи

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup).

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

  1. Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
  2. По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
  3. Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный  подход применяется в течение всего проекта (всех итераций).
  4. Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.

Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).

Принципы Agile-управления

Agile в управлении проектами как модель управления бизнес-процессом применяется тысячами команд во всём мире, и везде присутствуют следующие отличительные черты этого подхода:

  1. Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
  2. Для принятия решения команды должны быть высокоэффективными и сплочёнными.
  3. Поэтапная и цикличная работа становится основой процесса.

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

  4. Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
  5. В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
  6. Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые  отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

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

  • Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
  • Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
  • Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
  • Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

Формат Agile-управления проектами подходит не всем и не всегда. Государственные структуры, деятельность которых базируется на неизменном законодательстве и консервативна по своим целям и реализации, не нуждаются в такой оптимизации.

Характерные ошибки внедрения Agile и недостатки подхода

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

К распространённым ошибкам внедрения относятся следующие:

  1. Ограничение командной свободы со стороны руководства. Руководитель проекта не всегда готов отпустить команду, дав ей самостоятельно решать, что делать. Для эффективной работы необходимо реальное расширение возможностей и прав каждого участника процесса. Руководство не должно ставить мелкие задачи исполнителям и проверять выполнение каждого действия. Но иногда право решения передаётся исполнителю частично и в ограниченном виде, что снижает эффективность общего процесса.
  2. Отсутствие доверия внутри команды и старые привычки. При внедрении подхода Agile в уже сложившихся коллективах с классической иерархией команде сложно бывает отказаться от  патерналистских установок. Даже сознательно соглашаясь с новыми правилами игры, работники реализовываются в рамках ранее сформированных навыков взаимодействия. Чтобы изменить навыки, такие коллективы проходят специальные тренинги работы в команде. Но и это не застраховывает от мелких конфликтов. Нововведения редко проходят абсолютно гладко. Считается, что, в среднем, до 30% персонала так и не переходят на новый формат работы, что влечёт либо проволочки, либо серию увольнений.
  3. Нарушения в обратной связи. Иногда обратную связь от клиентов могут просто игнорировать, мотивируя это тем, что клиент хуже знает, что ему на самом деле надо.

    Тут важно отдавать себе отчёт в том, что именно заказчик – заинтересованная сторона.

  4. Недостаточное тестирование. Иногда тестирование прекращают после запуска первой рабочей версии продукта. Так же минуют стадию обсуждения в конце итерации.
  5. Отсутствие у топ-менеджеров чёткого понимания целей внедрения новой системы с гибким подходом и отсутствие методологий. Как правило, цели с цифрами заменяются лозунгами или слоганами (например, «Быть всегда впереди конкурентов»), а вместо методологий описываются идеи, а не операции.
  6. Внедрение подхода на одном участке. Для эффективности обычно советуют переформатировать деятельность всех сфер компании, начиная с бухгалтерии и отдела продаж и заканчивая производством и маркетингом.
  7. «Остывание». Процесс перехода на новую систему работы может занять несколько месяцев.

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

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

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

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

Закрыть меню