Каковы главные составляющие agile организации. Agile

Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

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

(Управляющий партнер ScrumTrek Алексей Пименов в на Rusbase)

Слово экспертам

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

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

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

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

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

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

Agile методология что это?

Можно ли сказать, что эджайл это инструмент кризис-менеджмента и управления изменениями? Определено Да!

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

Как правильно внедрить Agile?

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

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

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

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

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

Когда нельзя внедрять Agile

Есть простое правило:

Agile методологию можно использовать, только тогда когда вы готовы платить за ошибки.

Agile методология дает не только результат:

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

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

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

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

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

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

Алгоритм внедрения Agile в компании

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

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

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

Построение Agile команды в компании

Сформировать Agile команду можно довольно быстро, на это может потребоваться несколько дней, но сколько времени потребуется на «притирку» участников команды?

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

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

Agile методология это:

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

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

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

Примером философии Agile является принцип работы известного завода «Toyota», где любой подчиненный мог остановить конвейер, и внести корректировки. ()

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

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

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

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

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

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

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

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

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

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

История Agile

в 1970 году, д-ром Уинстоном Ройсом была представлена методика «управление разработкой крупных программных систем». С тех пор, стало существовать понятие Agile. Полная история становления проектного управления описана в

Кое что про Scrum метод

Преимущества гибких методов разработки

• Повышение качества результатов
• Адаптация к изменениям
• Очень быстро и эффективно
• Более контролируемый график реализации проекта

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

1. Вовлечение пользователей имеет решающее значение;
2. Чтобы принимать решения, команды должны быть высокоэффективными;
3. Этапность и цикличность как основа;
4. Концентрируется на частых представлениях промежуточных результатах проектов;
5. Применяется правило работы 80/20;
6. Использование совместного подхода к реализации плана;
7. Завершения отдельного этапа, для перехода к следующему.

Также мы вывели 12 основных принципов Agile методологии в отдельную инфографику. Посмотреть можно

Характеристики методики:

• Итерационная
• Модульная
• Возрастающая
• Адаптивная
• ОбъединяющаяОшибки при внедрении гибких методов управления проектами описаны в статье

Зачем использовать Agile?

• Прирост денежного потока
• Контроль рисков
• Снижение времени и накладных расходов
• Повышение подотчетностиО том как использовать Agile для развития читайте в статье

Какая методология управления проектами подходит для вас?

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

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

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

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

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

Каскадная методология требует детального планирования в начале проекта

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

Преимущества каскадного метода управления проектами

• Лучше всего подходит для проектов, которые имеют дело с физическими объектами – от строительных проектов до проектов по установке оборудования
• Требования описываются в начале проекта
• Лучше всего для проектов с четко определенными задачами и этапами, которые необходимо выполнить в определенной последовательности (например, построить первый этаж здания до второго этажа)
• Не требуется участие заказчика в процессе разработки
• Графики проектов можно использовать в будущем, для идентичных или аналогичных проектов
• Полный объем требований заранее известен
• Определенные в ТЗ результаты снижают вероятность недоделок

Недостатки классической методологии проектного менеджмета

• Требует значительных трудозатрат на качественное планирование проекта и составление графика до начала работы
• Клиент видит результаты работы только в конце проекта и может быть недоволен
• Изменения объема проекта могут быть долгими и требует формального управления процессами изменений
• У клиента могут возникнуть проблемы с видением проекта в самом начале
• Поздние изменения ТЗ являются причиной превышения бюджета
• Поздние изменения ТЗ продлевают сроки реализации проекта
• Метод менее эффективен для проектов в сфере услуг, программного обеспечения, дизайна и прочих проектов в которых отсутствуют физические объекты.

Agile – методология управления проектами

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

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

Преимущества гибкой методологии проектного управления

• Лучшая методология для проектов, которые имеют дело с сервис- ориентированными и нефизическими результатами, например написание кода, копирайтинг или проектирование
• Проект прозрачен и понятен для клиента на всех этапах
• Отлично подходит для быстрого старта
• Обеспечивает быструю корректировку курса на основе обратной связи с заинтересованными сторонами
• Приоритеты фокусируются на выгоде для бизнеса клиента
• Проект дает команде свободу действий, для того чтобы работать творчески и эффективно
• Вовлечение клиента в проект дает сфокусированность разработки
• Включает в себя взаимодействие и сотрудничество со всеми членами команды проекта

Недостатки гибкой методологии проектного управления

• Команда все время вовлечена в проект
• Не подходит для проектов с четко определенными требованиями и объемами
• Неопределенность в объеме и сроках работ могут заставить нервничать Заказчиков и руководство (по началу)
• У клиента может не быть времени на вовлечение в проект
• Требует постоянного отслеживания работ и ведение документации по управлению задачами команды
• Заказчик может пересмотреть объем работ
• Быстрый запуск может привести к неполному выполнению задач

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

Удачи в проектах!

Совмещение Agile и поточной методологии

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

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

Процесс оказания услуг

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

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

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

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

4. Разработка решения
Команда разработчиков начинает проработку решения.

Гибкая методология разработки (agile-структура)

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

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

Уникальность совмещенной методологии:

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

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

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

Быстрое и частое прототипирование .

Подход, ориентированный на клиентов – ориентация на минимизацию общей стоимости владения (TCO) и максимизировать отдачу от инвестиций (ROI).

Постигая Agile

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 1

Agile - гибкий подход к разработке, включающий разные методологии (Scrum, Канбан, ХР, Lean и другие). Об этом знают многие. Но есть десятки мелочей и всяких интересных штук, которые не лежат на поверхности.

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

Большой взрыв проектов

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

Обычно процессы работают в рамках каскадной модели (или waterfall model) - все происходит поэтапно и последовательно. Проще говоря, «вижу цель - иду к цели». И если в какой-то момент требования к продукту, конечной цели меняются, иногда приходится переделывать заново. Как только превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

По мнению Джеффа Сазерленда, создателя Scrum, это напоминает модель поведения Политбюро ЦК КПСС в конце 1980-х годов, якобы верившему отчетам, которые оно получало накануне крушения Советского Союза.

Agile-методы же призваны бороться с этим за счет своей гибкости. Можно сказать, что Agile - сборная солянка нескольких подходов, призванная минимизировать всяческие риски при помощи набора принципов. Эти самые принципы и 4 основных идеи собраны в Agile-манифесте, датированном 2001 годом.

Манифест Agile

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

• Самое главное люди, а не вещи
• Документация (которую еще и никто не читает) не должна никому мешать работать
• Сотрудничайте, а не перечитывайте контракт
• Живите, дышите, меняйтесь - так быстро, насколько это возможно

Как устроены процессы

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

1. Выберите владельца продукта - это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой - от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

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

4. Составьте бэклог продукта - соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, - .

5. Запланируйте спринты - отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

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

7. Делайте обзоры - по итогам спринта команда рассказывает, что удалось сделать, и демонстрирует работоспособные части продукта. На обзоры может прийти кто угодно: владелец продукта, главный заказчик или даже потенциальные клиенты.

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

Более подробно о том, как внедрить скрам и повысить эффективность команды, читайте в этой статье .

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

Знать Agile в лицо

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

1. Минимизация рисков - это главная цель в рамках любого гибкого подхода.
2. Итеративная разработка - работа в коротких циклах.
3. Люди и коммуникация - самое важное.

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

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

• Команде на руку общение с заказчиком и коллегами (чтоб без этого: «Вы меня неправильно поняли - переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

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

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

Кому это может не понравиться?

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

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

P.S. Хотите каждую неделю получать полезные советы из самых интересных книг по бизнесу и маркетингу, узнавать о новинках и получать скидки? Подписывайтесь на нашу рассылку. В первом письме - подарок.

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

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

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

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

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

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

Ничего сверхъестественного, не так ли? Давайте пройдемся по пунктам и разберемся, почему вышеперечисленное важно, для того чтобы быть быстрыми и гибкими, и какими средствами в 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 и работают согласно им, - тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.