Agile технологии. Гибкая методология разработки (Agile)

Персонал

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

Agile, появившийся как метод разработки ПО в небольших командах лет 10-15 назад, сегодня становится новой культурой управления большими компаниями. Термин Agile входит в лексикон всех современных российских менеджеров.

Что же такое Agile и почему этот метод называют чуть ли не единственно правильным?

Существует классический подход к созданию продуктов и сервисов, характерный в первую очередь для ИТ-индустрии. Этот подход называется каскадная, или итеративная методология разработки. В английской терминологии такой подход называют waterfall development (от англ. - водопад). Почему его называют водопадом? Потому что при такой схеме разработки, однажды утвердив план программного продукта, вы не сможете этот план остановить или изменить до его создания.

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

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

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

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

Безусловно, есть организации, которым Аgile вовсе не нужен. Например, государственные ведомства. Их деятельность основывается на законодательстве. Мы не сможем взаимодействовать с государством, если правила игры меняются каждый день.
Таким образом, мы имеем две радикальные противоположности организационной инфраструктуры. С одной стороны - строжайшая бюрократическая заформализованная организация, которая применяется в тех или иных случаях и хорошо работает в определенных ситуациях. И полная диаметральная противоположность ей - молодые стартапы, команды единомышленников, которые действительно создают нечто новое, и Agile находится гораздо ближе к состоянию эмоционального коллектива, который работает на конечную цель, работоспособный качественный (программный) продукт. И поэтому проблемы, возникающие на любом этапе, - это проблемы всех людей, и все, кто способен их решить, вовлекаются в этот процесс.

Переход большого классического бизнеса (Enterprise) к Agile

Это крайне важный вопрос, и он очень интересен. Об этом говорит весь мир, об этом же сказал Герман Греф. Он сказал: «Ребята, мы - банк, наши конкуренты не банки, наши конкуренты - молодые компании, привносящие ""цифру"" в общество».
Передовой бизнес базируется на трех китах: опыт и знания в индустрии (в которой работает бизнес), разработка продуктов и сервисов по методологии Agile и самое главное - инновационная культура.

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

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

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

Гибкое планирование

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

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

Для современного цифрового предприятия должно быть три компонента: методология гибкой разработки (agile development), гибкая подстраиваемая под него инфраструктура (agile infrastructure) и аналитика больших данных. Вот какой случай произошел с моим коллегой из США. Он ехал на такси в аэропорт, опоздал на самолет, написал в твиттере, что из-за пробки опоздал на свой рейс. Когда он приехал в аэропорт, ему пришла SMS: «Перейдите, пожалуйста по ссылке - для вас готов электронный посадочный талон. Авиакомпании ХХХ перебронировала вас на следующий рейс».
Это реальный пример, когда система авиакомпании анализирует разрозненную информацию и на ее основе принимает решения с целью повышения качества услуг для своих клиентов.

Отдельный вопрос: хочу ли я, чтобы по каждому моему чиху во внешнем мире что-нибудь происходило?
Еще один пример - Sundance Institute, глобальная платформа для поддержки независимого авторского кинематографа.
За последние 30 лет Sundance Institute обзавелась большим объемом информации о фильмах, съемочных группах, активности зрителей. Чем больше накапливалось информации, тем сложнее было ее структурировать и соответственно использовать.

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

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

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

- И о стратегии внедрения и области применения Agile и SCRUM от Михаила Софронова**

Не потеряйте. Подпишитесь и получите ссылку на статью себе на почту.

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

Люди и их взаимодействие важнее, чем процессы и инструменты
Рабочее ПО важнее, чем документация
Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

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

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

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

Ключевые моменты в применении Agile

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

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

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

Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.

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

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

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

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

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Аспирант «Нетологии» Максим Пименов рассказывает про Agile — гибкую методологию разработки программного обеспечения.

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

Чтобы процесс создания программы шел правильно, программисты используют методологии. Методология — это набор стратегий и способов создания продукта. Их много и новичок не знает, что выбрать: RUP, XP, Waterfall или другой набор букв.

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

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

Пары «план — спринт» идут одна за другой, пока живет проект.

Команда работает как захочет

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

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

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

На самом деле не все любят Agile

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

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

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

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

Если забыть о философии, ничего не выйдет

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

Помните, в начале статьи я говорил про принципы? Несмотря на их наивность, принципы — самое ценное в Agile. Сначала нужно осознать их и только потом браться за инструменты и практики.

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

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

Agile — мировоззрение, а не набор советов. Примите Agile, и только потом беритесь за практику.

Agile («аджайл») - слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

Able to move quickly and easily.
Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать - это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

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

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

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

Фокусировка на нуждах и целях клиентов

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

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

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

Примеры подобных инструментов - Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

Один из краеугольных камней Agile - это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum - самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 - встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile - Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

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

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

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, - это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или , плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, и т.д.

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий - можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников - придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать - с этим тоже вряд ли кто поспорит.

И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.

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

Agile - это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом - путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

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

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

Общая информация

Первоначально давайте разберёмся с техническими моментами. Что собой представляет Agile? Перевод (дословный) этого слова с английского языка - «живой, подвижный», немногим реже упоминается «гибкий». И кстати, это сокращение. Полное название этого подхода это Agile software development. Но поскольку это слишком долго, то и было решено сократить. И сейчас говорят просто Agile. Перевод как «гибкий» используется из-за того, что он в наибольшей мере соответствует реальной ситуации.

Что же сюда включено?

Продолжаем рассматривать, что такое Agile. Здесь хочется сконцентрировать внимание на том, что это гибкий подход, в основе которого лежит множество различных ХР, "Канбан", Lean). Для того чтобы лучше разобраться в теме, давайте проведём параллели. Допустим, что Agile-технологии - это процесс зарождения Вселенной. Конечный продукт - непосредственно сам существующий мир. А большой взрыв - это наиболее болезненная проблема, с которой только приходится встречаться, - изменение перечня требований к продукту. Обычно процессы создания подразумевают использование каскадной модели. В этом случае всё идёт последовательно и по этапам. Такой подход можно выразить кратко: вижу цель - иду к ней. И если меняются требования к конечному результату, то иногда приходится переделывать заново едва ли не всё. Что еще усложняет такую ситуацию, так это попытка сделать вид, что всё нормально, и нужно двигаться вперед.

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

Главное - это люди, а не вещи.
Сотрудничайте, а не читайте контракт.
Документация не должна мешать работать.
Меняйтесь настолько быстро, насколько это возможно.

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

Устройство процессов

Рассматривая, что такое Agile, давайте обратимся к одной из самых популярных методичек, известной как "Скрам" (Scrum). Что же она предлагает? Для начала нужно:

Выбрать владельца продукта. На эту роль подходит человек, что видит, к какой цели нужно идти, и что будет в конечном итоге.
Определиться с командой. Для этого необходима группа, численностью от трех до десяти человек, что владеют навыками, позволяющими получать результат.
Выбрать ответственного специалиста. Это человек, что будет следить за развитием проекта и помогать команде обходить трудности.
Разобраться с трудностями. Следует собрать в одном месте все существующие требования к продукту и расставить приоритеты. Владелец продукта должен собрать здесь все свои пожелания. Потом команда их оценивает и разбирается, можно ли это реализовать, и сколько времени для этого нужно.
Следует разбить весь объем работ на отрезки времени, длиной в неделю или две, во время которых команда будет выполнять определённые наборы задач.
Ежедневно следует проводить встречи, длиной не более пятнадцати минут. На повестке следует обговаривать, что было сделано вчера, какие планы на сегодня, и преграды, мешающие брать высоту.
Делать обзоры по итогам недели (двух), во время которых командой рассказывается о том, что было сделано. При этом необходимо демонстрировать работоспособность частей продукта.
После каждого временного периода необходимо обсуждать проблемы и искать решения. Причем все наработки необходимо внедрять сразу.

Как опознать Agile?

Методология управления независимо от выбранного направления всегда обладает такими особенностями:

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

Давайте представим реку. На одном берегу заказчик. На втором - команда. В таком случае гибкая методология разработки имеет преимущества для всех:

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

Социальный фактор

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

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

Небольшой пример

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

Поскольку используется гибкая методология разработки, то пользовательские истории не копятся до большого релиза, а выпускаются сразу после завершения и как можно чаще. Количество обработанных обращений составляет пропускную способность команды на неделю. Чтобы не потерять темп и не увязнуть в ручном тестировании, команда должна работать над автоматизированной интеграцией. В чем она заключается? Для каждого рабочего момента пишется автоматический тест. Если историй слишком много, то может возникнуть спешка, потеря мотивации, снижение производительности и качества. На такие случаи предусмотрен метод «вчерашняя погода». Он заключается в том, что нужно установить жесткие рамки количества работы и тщательно выбирать, что именно будет реализовываться. Упомянутый ранее "Канбан" предлагает устанавливать лимит задач.

А что делать с очередью?

Ладно, вот команда решила, что она может обрабатывать четыре истории на неделю. Но как сориентироваться во всём, что есть? Допустим, пользователи подкидывают по десять историй на неделю. Обрабатывается четыре. Таким образом, очередь будет постоянно расти. На этот случай есть только один эффективный метод - слово "нет". Для владельца продукта это чрезвычайно важно. Сказать «да» не трудно. Значительно сложнее и важнее решить, что не нужно делать. Причем за это необходимо ещё и нести ответственность. Поэтому следует решать, чему уделять внимание сейчас, а что следует отложить. Чтобы правильно нужно чтобы владелец продукта понимал ценность и объем каждой истории.

Принимаем решения

Часть историй чрезвычайно нужна. Другие же просто представляют собой приятный бонус. Одни истории будут разрабатываться несколько часов. На создание других уйдут месяцы. Многие часто проводят соотношение между размером истории и её ценностью. Но это не всегда правильно. Больше - не равнозначно лучше. Петру правильно рассматривать приоритеты помогает сложность и ценность выполняемой задачи. Как определить эти характеристики в количественном значении? Да никак. Это настоящая игра в угадайку. И для большей эффективности в неё необходимо вовлекать достаточно много людей. Это и команда разработчиков, которая проинформирует про объем работ, и заинтересованные лица. Но следует понимать, что все данные, полученные таким способом, представляют собой приблизительные догадки. Здесь не бывает точных цифр. Первоначально будут промахи. Но по мере получения опыта их количество и масштаб будут понижаться.

Возможные риски

Для избегания проблем необходимо дать честные ответы на ряд вопросов. Это:

Правильные вещи ли мы делаем? Это бизнес-риск.
Можем ли мы реализовать то, что нужно?
Будет ли работать проект на данной платформе. Это технический риск.
Хватит ли денег, и успеем ли? Это риски сроков реализации и стоимости.

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

Как обучиться?

IT-индустрия чрезвычайно быстро развивается, и чтобы не проиграть в конечном итоге, необходимо постоянно учиться, повышать квалификацию и эффективность работы. Поэтому как никогда актуальны вопросы обучения и внедрения. С чего начать? Самый лучший вариант - это кооперация с компанией, где уже применяется Agile. Обучение в таком случае будет проводиться людьми, которые не по слухам знают, что собой представляет гибкая разработка. Но такое, увы, не всегда возможно. Чаще всего привлекается сторонний специалист, который знает, что собой представляет Agile. Внедрение этого подхода осуществляется под его надзором. Правда, услуги такого специалиста стоят денег. Но если залучить действительно знающего человека, то все траты окупятся сторицей. Ведь в современном мире эффективность сотрудников играет немаловажную роль.

Что ждёт в будущем?

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

В заключение

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