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

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

Одной из отправных точек создания Agile-методологии можно считать 1930-е годы, когда физик и статистик Уолтер Шухарт начал применять циклы «план – дело – исследование – действие» для улучшения продуктов и процессов. 

Шухарт обучил этой методологии развития своего подопечного Уильяма Эдвардса Деминга. Деминг, в свою очередь, начал использовать такую систему в Японии в годы после Второй мировой войны. Возрождающаяся тогда компания Toyota наняла Деминга для обучения менеджеров компании и в конечном итоге использовала его опыт для разработки знаменитой производственной системы Toyota — основного источника сегодняшнего «бережливого» мышления. Но к этому мы вернемся чуть позже.

А вот основной толчок в развитии Agile-система получила во времена первых разработок компьютерной техники и программного обеспечения. 

Так, первое электронное устройство или прототип компьютера разрабатывался в период 1942–1945 годах в США. Программировали его вручную, переключая тумблеры и штекеры. Людей, которые занимались программированием, было еще очень мало. А это значит, что и подходов к менеджменту разработки программ не существовало в принципе. 

Начало массовой разработке ПО было положено в 1957 году. Тогда компания IBM представила первый язык программирования высокого уровня Fortran (Formula Translator).

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

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

В этот период в 1970 году ученый-компьютерщик Уинстон Ройс представил концепцию «каскадной модели».

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

После появилась усовершенствованная модель «Sashimi» Питера Де Грэйса.

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

В 1965 году компания IBM выпускает серию компьютеров IBM/360, на которых можно было запускать программы общего назначения, а не только научные и инженерные. Во всей линейке компьютеров использовался один набор команд и одинаковые устройства: клавиатура, монитор и т.д. Было выпущено десяток моделей, и на каждой из них можно было запускать одни и те же программы без необходимости их переписывать.

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

В 1972 году подразделение IBM Federal Systems Division занялось разработкой системы управления и контроля для первой американской подводной лодки, оборудованной новейшими баллистическими ракетами «Trident» для Министерства обороны США.

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

 В 1986 году вышла статья японских ученых Хиротака Такеучи и Икуджиро Нонака. В ней были представлены результаты исследований успешного опыта по созданию новых продуктов на примере компаний 3M, Fujitsu-Xerox, Honda, Xerox, Canon, Epson, NEC, Brother.

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

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

Авторы статьи проводили аналогию с игрой в регби, когда у команды есть общая цель – донести мяч до другого конца поля, на половину противника. Цель общая, а значит все объединены в общий процесс. Так, в мире появился новый подход управления проектами, который позже назовут Scrum.

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

80-е годы XX века стали эпохой массового распространения персональных компьютеров. В этот период исследователи из Массачусетского Технологического Университета стали изучать японские производственные системы, особенно систему Toyota.

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

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

Происходило это так:

- с 1991 года — RAD или быстрая разработка приложений. Здесь результат добивался в максимально короткие сроки и в условиях ограниченных ресурсов;

- с 1994 года — метод разработки динамических систем (DSDM). Быстрые результаты достигались при помощи участия пользователей в создании и тестировании продукта;

- с 1995 года — Scrum. Здесь реализация проекта делится на короткие промежутки – спринты с представлением заказчику достигнутых на каждой стадии результатов;

- с 1996 года появилась гибкая методология разработки Crystal Clear, делающая упор на количестве участников разработки проекта. Также внедрено экстремальное программирование XP - разработка ПО с учетом меняющихся запросов заказчиков;

- а с 1997 года — создание итеративной методологии FDD («разработка, управляемая функциональностью»).

Началом повсеместного распространения Agile как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли стал 2001 год. Тогда семнадцать разработчиков ПО встретились на курорте Сноуберд в штате Юта, чтобы обсудить проблемы, возникающие при управлении проектами.

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

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

Были выделены 4 основных ценности:

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

Все эти идеи раскрылись в 12 принципах Agile-манифеста:

1.   Наивысшим приоритетом является удовлетворение запросов заказчика.

2.   Изменения допустимы на любой стадии.

3.   Новые функциональные продукты нужно выпускать по возможности чаще.

4.   В ходе проекта разработчики и заказчики должны работать сообща.

5.   Для профессионалов следует создать условия, обеспечить поддержку и доверять их профессионализму.

6.   Лучший способ коммуникаций – это непосредственное общение.

7.   Если продукт работает – это и есть основной показатель правильного направления усилий.

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

9.   Необходимо постоянно уделять внимание качеству и совершенствованию.

10. Простота как искусство минимизации излишней работы является важным условием достижения результата.

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

12. Команде следует постоянно искать способы повышения эффективности.

На данный момент методология Agile широко распространена в IT-сфере и начинает осваивать деловую сферу: маркетинг, менеджмент, обучение и т.д. Метод гибкого управления проектами используется многими компаниями и госструктурами как за рубежом, так и в России. Подходы, основанные на Agile, компании выбирают в зависимости от своих миссии и ценностей.  Так, за последнее время большую популярность приобрели Scrum и Kanban.

Напомним, что метод Scrum впервые описали Хиротака Такэути и Икудзиро Нонака — сравнивая этот подход с регби, в котором Scrum — это борьба за мяч. А значит, что главная ставка здесь делается на качественном контроле процесса работы.

Обычно над проектом работает целая команда специалистов, где расписаны все роли: аналитик, программист, тестировщик, администратор.  Их работу координируют владелец продукта (product owner) и модератор (scrum-мастер). Product owner объединяет бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания, мотивирует и поддерживает команду.

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

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

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

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

Если посмотреть на примере компаний в России, то к примеру, Банк России начал внедрять практики Agile с 2017 года. В июле 2018 года был опубликован доклад, в котором руководитель проектного офиса Банка рассказала о результатах внедренного процесса. Изначально были запущены три Scrum-команды. Стандартные продукты, которые выпускаются в рамках этих команд – это ИТ-сервис, нормативный документ и комплексное изменение бизнес процесса. Также запущено 7 Kanban-команд. Были отмечены и первые результаты. Повысилась вовлеченность сотрудников, они были нацелены на получение результата. Также повысилась прозрачность и управляемость изменений, увеличилась скорость поставки продукта и внедрения изменений. Результат теперь достигался примерно на 40-50% быстрее.

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

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

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

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

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

В офисе есть лекторий на 200 человек. Там предусмотрена также зона VR — сотрудники могут побывать на реальных индустриальных объектах и АЗС в виртуальной реальности. 

Кроме того, в рамках государственных проектов цифровизации, идеи и принципы Agile начинают внедрять в правительственных организациях. К примеру, США. Чтобы справляться с огромным объемом работ, в информационной службе штата Вашингтон используют методику Scrum. Были сформированы scrum-команды и даже снесены внутренние стены в помещении. Главная их задача - каждую неделю снабжать учреждения штата пригодными для использования практическими директивами. Каждую неделю они что-то меняют и используют пошаговый подход. Как результат они еженедельно выдают потенциально готовый к поставке продукт, который учреждения могут опробовать на практике. «Готовый к поставке продукт» в их случае означает некие изменения в директивах, которые могут быть применены на практике. Это не обязательно должно быть нечто материальное. Важно, чтобы это было что-то, создающее ценность.

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