Agile: что это и как внедрить в свою компанию

Как внедряется и применяется метод

Итак, каким образом правильно осуществить переход от обычной каскадной модели, используемой большинством организаций, к системе Agile Project Management с набором собственных методов, приемов и способов? Для безболезненного процесса рекомендуется осуществить изменения с помощью нескольких шагов:

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

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

На стадии укоренения системы и трансформации работы команды необходимо дополнительно привлекать специалистов, имеющих сертификацию и опыт работы с Agile Project Management. Они помогут сформировать проектную группу, внедрить методологию, подобрать инструменты, осуществить первую аналитику.

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

***

Обучили Product Owner

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

Положение Product Owner в бизнес-процесса и в команде

Ключевые навыки Product Owner:

обладает видением продукта;

является владельцем бэклога продукта;

умеет расставлять приоритеты;

управляет ожиданиями заинтересованных лиц;

представляет пользователя;

взаимодействует с командой;

принимает продукт.

Отличия методологии Agile от Waterfall

Если говорить кратко, то последовательная разработка по каскадной методологии, или Waterfall, использовавшаяся до Agile, выглядит таким образом:

1. Формируются требования к продукту, создается техническое задание или ТЗ.
2. Задачи воплощаются в коде.
3. Проводится тестирование.
4. Готовый продукт внедряется в работу.

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

Если сравнивать методологии проектного управления Waterfall vs Agile, то во второй актуальные потребности пользователя важнее, чем исходные установки. ТЗ может корректироваться даже в разгар разработки, так как гибкость предполагает отсутствие предварительного генерального плана, а ПО пишется экспромтом.

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

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

Обязанности проджект-менеджеров в Аgile-проектах.

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

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

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

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

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

‍

Каким образом осуществляется управление проектами в Agile?

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

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

• Больше возможностей для управления меняющимися приоритетами.
• Сокращение времени на разработку программного обеспечения.
• Повышение производительности команды.
• Улучшение согласованности между бизнес-требованиями и ИТ-решениями.
• Повышение качества программного обеспечения.

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

‍

Scrum.

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

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

‍

Канбан.

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

‍

Экстремальное программирование или XP.

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

‍

Функционально-ориентированная разработка (FDD).

Фреймворк FDD разбивает проект на двухнедельные отрезки времени, в течение которых команда работает над определённой функцией продукта. Процесс разработки включает в себя пять видов деятельности: 

• Разработка общей модели
• Составление списка функций
• Планирование работы над каждой функцией
• Проектирование функции
• Реализация функции.

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

‍

Метод разработки динамических систем (DSDM)

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

Среди всех Agile-методологий самой популярной является Scrum. По данным отчёта State of Agile, по этому фреймворку работают 66% опрошенных и ещё 15% респондентов используют производные Scrum, такие как ScrumBan и Scrum/XP.   

Давайте подробнее рассмотрим основные принципы Scrum. 

‍

Про инструменты визуализации

Доска — это всего лишь инструмент, который помогает все максимально визуализировать.

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

Но самое важное то, чтобы она улучшала взаимодействие между членами компании или команды

Выбор доски зависит от команды, бюджета, ситуации, количества участников. Если говорить про электронные доски, то из бесплатных или условно бесплатных можно выделить Trello и Redmine, каждая со своими особенностями. Из известных компаний VersionOne или Jira. Из украинских компаний выделю Worksection, которая недавно выпустила доску задач. Очень надеюсь, что у данного продукта появятся киллер-фичи, которых нет у большинства досок. Например, ограничения по количеству задач в столбике или на человека. Или срочная полоса задач (когда владельцу данной задачи необходимо, чтобы ее выполнили раньше других), но во многих инструментах этой функциональности нет.

История Agile

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

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

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

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

Вот четыре фундаментальные ценности Agile-философии:

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

Как же именно эти принципы изменили управление проектами? 

‍

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

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

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

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

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

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

ЛидерТаск — приложение для проектного управления

Онлайн-сервисы, специальные программы помогают оперативнее и проще работать с проектами по методологии Agile Project или Scrum. Одним из самых эффективных приложений данного формата является ЛидерТаск — особый планировщик задач с поддержкой методологии Agile Project Management. Это уникальный софт, которые легко и с полной отдачей работает с задачами, ставит цели для команды, оценивает готовый результат.

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

***

«Подводные камни» Agile-методологии

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

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

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

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

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

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

Про внедрение

Частый вопрос: «Что нужно, чтобы Scrum заработал?» Открываю секрет — серебряной пули не существует. Культурные изменения всегда происходят сложнее и дольше всего. Можно прийти на работу и сказать: «Сегодня у нас тренинг по Scrum и через три дня мы начинаем работать по Scrum». Нет, это так не работает. Agile — это не переключатель, который можно нажать у себя в компании и сказать: «Мы стали Agile».

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

Agile команда в российском бизнесе

У небольших компаний очень большое преимущество при внедрении Agile, так как эджайл создан для небольших команд: 7-10 человек идеальный состав для Agile команды.

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

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

Agile изменяет мышление и мировоззрение, фокусируясь на достижении цели, используя коммуникации, а не командно-административную структуру.

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

Ошибочно также полагать, что Agile может увеличить результативность вашей компании моментально, все зависит от двух факторов:

1. от ваших сотрудников
2. и ваших бизнес-процессы,

а они уникальны в каждой компании!

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

Суть методологии Agile

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

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

Данный подход позволяет решить ряд неудобных вопросов:

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

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

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

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

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

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

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

Тогда как благодаря цикличности доработок появляются функции, на которые не хватило бы ресурсов при плановой работе.

Спринты: таймменеджмент по Agile

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

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

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

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

Команда методологии разработки Agile

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

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

В системе существуют такие роли:

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

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

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

Ресурсы для менеджеров Agile-проектов.

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

• На сайте AgileAlliance есть обширный раздел со статьями, видео и презентациями. 
• Project Management Institute предлагает публикации и руководства по различным подходам к управлению проектами, включая Agile. 
• Множество статей, видеоматериалов и тематических исследований для изучения концепции Scrum можно найти на сайте ScrumAlliance.
• На платформе LeadingAgile есть статьи, подкасты и видеоролики по различным аспектам управления Agile-проектами.
• На сайте Scrum.org есть отличная подборка статей и видео по темам, связанным со Scrum. 
• ‍

Методы Agile – Scrum, Kanban, Lean

Среди всех методов гибкой разработки сегодня активно используются Scrum, Kanban, Lean. Также существует Scrumban, интересный метод, созданный на основе Scrum и Kanban.

Нередко приходится сталкиваться с мнением, что методология Agile и метод Scrum – это практически одно и то же.

Термин «scrum» пришел из регби, где обозначает борьбу за мяч. Здесь разработка делится на спринты, продолжительностью от недели до четырех. Каждый спринт включает в себя несколько стадий. Первой являются ежедневные встречи по 15–20 минут, на которых члены команды обсуждают, что сделано и что планируется, а также возникшие проблемы.

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

Kanban в рамках Agile-методологии зародился в Японии и является продолжением философии бизнеса Кайдзен и «Тойоты».

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

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

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

Если сравнивать гибкие методологии Agile Scrum и Kanban, то последний метод имеет такие отличия:

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

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

Это не метод в чистом виде, а способ мышления, свод правил, рекомендаций. Данная философия бизнеса и подхода к разработке, созданная в рамках Agile-методологии описана в книге Эрика Риса «Lean startup» и Масааки Имаи «Кайдзен».

Lean предполагает:

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

Отдельно стоит сказать о Scrumban. Это сочетание Scrum и Kanban в рамках методологии разработки Agile. С одной стороны, группа реализует спринты, а с другой использует канбан-доску с целью визуализации процессов.

Создание Agile

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

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

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

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

Agile команды объединяют

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

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

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

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

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