Не всегда технологии или качество разработки становятся стимулом для заказчика при выборе ИТ-компании. Некоторые компании готовы нанимать только команды, которые умеют правильно организовать процесс разработки. Мы спросили у экспертов, можно ли продать Agile, как дополнительную опцию при разработке и способен ли этот подход стать проблемой.
Александр Казеннов, руководитель корпоративной практики ДКИС ALP Group.
Спрос на Agile есть, причем с радостью отмечаем, что команды проекта (разработчик + заказчик) всё чаще применяют этот подход не ради хайпа, маркетинга и «следований моде», а с реальным пониманием – зачем, почему и как. Это не может не радовать. Команды экспериментируют с различными методологиями и находят для себя оптимальный способ комфортного и эффективного сотрудничества.
Самый главный смысл – нивелирование бюрократических проволочек в интересах делу и достижению результата, лучшая обратная связь по сравнению со стандартными для РФ принципами корпоративной разработки и, как следствие, лучшее понимание поставленных задач и требований Бизнеса. Как итог – лучший продукт для Заказчика. Правда, есть нюанс. Сами Заказчик и Разработчик должны быть готовыми к такому взаимодействию. Часто встречаются истории, когда Agile «не взлетает» по причине номинального перехода на него, без реального перестроения проектных команд.
Можно ли за счет Agile получить дополнительный профит при разработке, и в чем он будет заключаться?
Да, как и в любой методологии проектного управления. Здесь дополнительный профит в скорости разработки и реакции на изменения, лучшем понимании бизнес-задач. При условии, что команды не забывают о контроле и фиксации результатов.
Может ли Agile стать проблемой для разработчика и почему?
Да, может. В практике часто встречаются ситуации, когда грань между разработчиком и заказчиком в agile-разработках размывается и появляется некое панибратство между членами команды. Это хорошо до первой серьёзной ошибки или критической ситуации, при возникновении которых возникают излишние эмоциональные проблемы взаимодействия сторон. А поскольку разработчик – исполнитель, это становится в большой степени головной болью исполнителя, т.е. — разработчика. Также в таких случаях разработчики часто начинают пренебрегать стандартами разработки и подходам к оценке задач, что негативно сказывается на исполнении обязательств по договору.
Данила Фетисов, Technical Product Manager, Yandex
Если говорить в целом, то от данной методологии пользу получают все, так как в текущей картине мира очень сложно на старте продумать детали и особенности бизнес реализации задач для достижения поставленной цели. Если бы мы работали не по итеративному Agile, то заказчик с большой долей вероятности получал совсем не тот результат, который ожидал. Допускаем, что у него есть 2 точки взаимодействия с командой: постановка требований и проверка реализации. Все, что между — темный лес, в который нет доступа.
Следовательно, в процессе разработки функциональности может произойти все что угодно: обнаружились особенности работы системы, в связи с ними в команде доработали реализацию, плюс ко всему неправильно поняли заказчика на старте, и последний на выходе получил совсем не то решение, которое хотел изначально. В то время как в Agile все идет итерациями: требования — реализация — проверка (демо). Таким образом, заказчик оплачивает работу постепенно, имеет возможность корректировать курс разработки и в конечном счете получает именно то, что предполагал изначально.
Но вопрос, как Agile влияет на разработку? Если говорить про небольшие системы, которые спокойно поддерживаются командой из 2 -3 человек, то тут особой пользы не заметим. Самое интересное начинается при увеличении объема команды. Конечно же, никто из разработчиков не хочется писать код, в котором в итоге появится много ошибок. Но на старте, как и с требованиями у заказчика, достаточно сложно придумать идеальное решение, покрывающие все требуемые сценарии работы системы (при этом, учитывающее существующую функциональность). Таким образом, Agile приходит в разработку в виде следующего процесса:
- Разработчик изучает требования — задачу
- Придумывает архитектуру системы и обсуждает ее с командой (начался цикл итераций)
- Пишет код для реализации пунктов 1 и 2
- Отдает на ревью коллегам — разработчикам, где могут подсказать про сценарии работы системы, оставшиеся без внимания (еще 1 цикл итераций)
- После ревью отдает коллегам — тестировщикам для проверки стабильности решения (и тут цикл итераций)
Таким образом, двигаясь итеративно по реализации требований в конечном счете получается желаемое и стабильное решение.
Но в чем подвох, все же выглядит идеально? Бывают моменты, когда требуется выделить одну команду на поддержку какой — то части основного продукта. Еще ее называют кроссфункциональной командой, так как туда входят: дизайнер, разработчики для Android / IOS, разработчик фронтенда (web), разработчик бэкенда (сервер) и т.п. Не всегда задачи равномерно распределяются по всеми, в связи с чем может образоваться простой конкретного сотрудника. Для этого придумали «T-shaped» формат специалиста: он глубоко знает одну область, при этом может реализовать функциональность и в смежных. Например, есть сильный фронтенд разработчик, который также может помочь с IOS. Но проблем тут может быть 2:
- Политика компании. Бывают, компания навязывает историю с погружением в смежную область, в связи с чем разработчик замедляет свое развитие, как специалиста фронтенда, чтобы удовлетворять требованиям бизнеса и помогать с задачами для IOS, хотя сам этого не особо желает
- Так как разработчик будет слабо погружен в смежную тему, качество его решений будет соответствующим — низким. От этого, конечно же, падает удовлетворение работой, следовательно, возможна история с моральным выгоранием.
Анастасия Гусакова, ГК «КОРУС Консалтинг».
Большая ценность Agile и для заказчика, и для разработчика – это возможность ускорить time-to-market — скорость вывода продукта или отдельной его функциональности на рынок. Команда внедряет систему с более высокой частотой выпуска релизов, периодами от одной до нескольких недель в зависимости от сложившейся в команде практики. В противовес практике Waterfall, , не нужно ждать завершения проекта или длительного этапа, можно запускать продукт итерационно или даже по мере готовности фичи.
Другое преимущество Agile – быстрая реакция на отраслевые изменения, инновации и лучшие практики. Иногда появление каких-то новых технологических возможностей, которые нельзя было спроектировать сразу, может поменять целевую архитектуру будущей системы. Особенно часто такие изменения происходят при внедрении e-commerce продуктов, чьи пользователи – бизнес или конечные потребители – очень требовательны, а новые технологии появляются каждый месяц. В случае Waterfall такая гибкость и скорость отклика на потребности пользователя и клиента невозможна.
Более того, подобная методика позволяет экспериментировать прямо в продуктиве: проводить A/B-тестирование, проверять гипотезы и выбирать из нескольких альтернативных вариантов тот сценарий, который получит положительную реакцию пользователей. Если компания привлекает для разработки стороннюю команду, то большую роль в этом процессе играет, насколько оперативно бизнес даёт обратную связь на каждом этапе внедрения.
В Agile легко внедрять изменения вслед за пожеланиями пользователей, и экономический эффект от их появления тоже можно увидеть еще до полного завершения проекта. К примеру, внедрение даже небольшой функциональности в личном кабинете интернет-магазина способно снизить долю отказов из-за более простой процедуры оформления заказа, а значит, повысить выручку компании. Agile позволяет сразу увидеть этот рост.
Может ли Agile стать проблемой для разработчика и почему?
Сам по себе Agile не может стать проблемой. Трудности могут появиться, если участники проекта не договорятся о качестве: насколько детально прорабатывать требования, каковы будут критерии приемки результата, какими средствами будет обеспечиваться качество (автотесты, нагрузочное тестирование и пр.), какие метрики использовать для отслеживания качества продукта уже во время его эксплуатации и так далее. В перспективе из-за таких недочётов будет накапливаться технический долг, релиз тех или иных функций будет задерживаться, качество продукта и удовлетворённость пользователей будут падать.
Также есть устойчивый миф о том, что Agile-команды очень эффективны и их продуктивность со временем только растет. Однако вера в этот миф также может стать источником сложностей. Действительно, какое-то время в течение нескольких спринтов, пока команда срабатывается, эффективность повышается – за штормом следует период нормализации и продуктивного функционирования, это характерно не только для Agile. В проекте состав специалистов чаще всего стабилен от начала и до конца, при разработке продукта все немного не так. Жизнь продукта существенно длиннее проекта, и в реальной практике сработавшиеся Agile-команды в течение 1-2 лет распадаются, переформируются, люди растут, хотят новых задач, смены обстановки, происходит ротация. И тогда процесс командообразования начинается заново. Как следствие – снижение эффективности и скорости разработки. Это абсолютно нормальная ситуация, главное – учитывать это при планировании развития продукта.
Есть ли особенности в использовании подхода Agile с заказчиками из США и России?
Главная особенность – это различие договорных отношений между заказчиком и подрядчиком. В США компании разрабатывают программное обеспечение по договору Time&Material. То есть заказчик берёт на аутстафф команду подрядчика и оплачивает её часы, контролируя результат в коротких итерациях. А в России большинство компаний все еще работает по фиксированной цене, то есть платят за конечный результат. Это может провоцировать сложности на отечественных Agile-проектах с субподрядом. Однако это не проблема самой методологии, а лишь следствие противоречия подходов. Поэтому для минимизации рисков, при составлении договора надо детализировать план разработки ПО и обсуждать сроки выполнения этапов и всего цикла разработки.
Сергей Раков, Руководитель направления в Ростелеком ИТ.
Давно уже известно — кто первый выпустит новый продукт на рынок, тому проще стать номером один на нем. Таких примеров масса. А вот чтобы выпустить ИТ продукт в короткие сроки и удовлетворить потребность клиентов нужна скорость и гибкость. Дарвин однажды сказал: “Выживает не самый сильный и не самый умный, а тот, кто лучше всех приспосабливается к изменениям.” Именно гибкость команды и возможность подстраиваться под изменения требований позволяют получить в итоге продукт, который будет нужен пользователям в тот момент.
Согласно PMBoK Существует 4 подхода к разработке программного обеспечения:
— Предиктивный (водопадный)
— Итеративный
— Инкрементальный
— Адаптивные (Agile)
Важно понимать, что нет универсального подхода к любому проекту. Где-то лучше работает предиктивный, а в каких-то проектах лучше использовать адаптивные подходы.
Например, строить дом используя гибкие подходы я бы не стал. Я хочу расставить мебель на плане, а потом заливать фундамент. Это 100% водопадный подход. Да, выйдет скорее всего по срокам дольше, но я точно сэкономлю средства на переделывании и придумывании обходных решений во время строительства. Да и образ результата я буду четко понимать уже на этапе проектирования дома.
Если говорить про разработку ПО, то скорее всего, лучше зайдут гибкие методологии. Подчеркну, что “скорее всего”, т.к. есть проекты, где другие подходы дадут лучший результат.
Основным преимуществом agile является то, что изменения там приветствуются и благодаря ним, мы можем сделать продукт, который максимально удовлетворяет текущие потребности пользователей.
Для заказчика это означает, что он получит максимально релевантный продукт, а благодаря коротким итерациям, продукт не будет содержать ненужных лишних функциональных возможностей. Пользователи быстрее выскажут свое мнение о продукте и заказчик сможет скорректировать ближайший план работ и сфокусироваться на решении тех задач, которые ждут пользователи.
Для разработчиков использование гибких методологий позволяет не тратить время на аналитическую проработку всего продукта целиком, а начать прорабатывать и реализовывать только то, что нужно пользователям. Ведь часто бывает, что многими фичами пользователи и не пользуются, т.е. их можно было вообще не делать и ничего не изменилось.
Но если заказчик будет злоупотреблять гибкостью команды и набрасывать задачи в текущий спринт, то тогда это может стать серьезной головной болью как менеджера проекта, так и всей команды. Такое “добавлясити” ведет к снижению качества продукта и срыву сроков, т.к. команда не сможет успеть сделать хорошо то, что изначально запланировала в спринт и также не сможет сделать хорошо то, что прилетело в спринт, т.к. времени на проработку новых фичей совсем нет.
В итоге, определяющим фактором успеха будет не модный подход к разработке проекта, а грамотно подобранный с учетом всех особенностей проектного окружения.
Дмитрий Кичко, генеральный директор ГК «Эдит Про».
На начальном этапе проекта у заказчика обычно есть высокая доля неопределенности в отношении требований к системе. Невозможно заранее предусмотреть все нюансы: в процессе выполнения работ появляются новые идеи, возможно, происходят изменения в процессах заказчика. Поэтому требования могут меняться и дополняться по ходу реализации проекта. Agile позволяет вносить изменения практически на любой его стадии.
Проблемой в этом подходе может стать неопределенность конечного результата и сроков завершения проекта для разработчиков. Это может привести к их выгоранию, повышению текучки кадров.
Подход Agile в чистом виде не подходит крупным российским госкорпорациям. Его использование предполагает отсутствие определенных сроков и стоимости на старте проекта. Однако специфика государственных контрактов требует четкого планирования графика и бюджета еще на этапе проведения закупки. Поэтому руководители проектов вынуждены адаптировать стандарт под российские реалии.
Игорь Бочкарев, технический директор Open Solutions.
Цель применения agile подходов — управление нечеткими и изменяющимися требованиями к разработке продукта. Разработчики постоянно фокусируются на самых важных задачах проекта, и с каждым новым этапом выбирают и выполняют наиболее приоритетные задачи.
Заказчик и команда разработки тесно трудятся над проектом совместно: формирование бэклога, планирование спринтов, ретроспективы, демонстрации, частые релизы, перепланирования и уточнения — все это требует большой вовлеченности заказчика в проект.
Преимущество подхода в том, что можно начать работу, пропустив долгий этап
технического проектирования, в процессе работы определить вектор развития продукта и быстрее запустить его. При этом agile может означать отсутствие фиксированного срока, заранее известного результата и бюджета.
Agile подходы не имеют различий для разных стран. Наша практика показывает, что agile часто используют коммерческие организации как в РФ, так и worldwide. Подход популярен из-за скорости и прозрачности результатов, которые заказчик получает каждые 2 недели. Государственные или крупные Enterprise компании в основном применяются «водопадные» — классические подходы, так как циклы разработки в таких проектах дольше, цена ошибок выше, а заказчики могут позволить себе тратить достаточно времени на этапы предпроектных исследований и проектирования.
Ринальд Садыков, Terabit Digital.
Agile – это гибкая методология разработки и эффективна она только тогда, когда продукт планируется разрабатывать на протяжении длительного периода времени (очень большой или сложный).
На небольших проектах и проектах, которые разрабатываются в течение года, Agile сильно переоценен – здесь более эффективным будет Waterfall (модель «Водопад»).
На проектах с длительным сроком реализации Agile позволяет продукту быть гибким и подстраиваться под изменения на рынке. Сейчас это особенно актуально: достаточно вспомнить 2020 год, когда с приходом пандемии поменялось все.
Также Agile может быть актуален для распределенных команд, которые находятся в разных странах и часовых поясах.
На практике, в большинстве проектов Agile попросту не нужен – он может стать бесполезной надстройкой, только усложняющей и даже удорожающей процесс работы.
Анастасия Гусакова, ГК «КОРУС Консалтинг».
Большая ценность Agile и для заказчика, и для разработчика – это возможность ускорить time-to-market — скорость вывода продукта или отдельной его функциональности на рынок. Команда внедряет систему с более высокой частотой выпуска релизов, периодами от одной до нескольких недель в зависимости от сложившейся в команде практики. В противовес практике Waterfall, , не нужно ждать завершения проекта или длительного этапа, можно запускать продукт итерационно или даже по мере готовности фичи.
Другое преимущество Agile – быстрая реакция на отраслевые изменения, инновации и лучшие практики. Иногда появление каких-то новых технологических возможностей, которые нельзя было спроектировать сразу, может поменять целевую архитектуру будущей системы. Особенно часто такие изменения происходят при внедрении e-commerce продуктов, чьи пользователи – бизнес или конечные потребители – очень требовательны, а новые технологии появляются каждый месяц. В случае Waterfall такая гибкость и скорость отклика на потребности пользователя и клиента невозможна.
Более того, подобная методика позволяет экспериментировать прямо в продуктиве: проводить A/B-тестирование, проверять гипотезы и выбирать из нескольких альтернативных вариантов тот сценарий, который получит положительную реакцию пользователей. Если компания привлекает для разработки стороннюю команду, то большую роль в этом процессе играет, насколько оперативно бизнес даёт обратную связь на каждом этапе внедрения.
В Agile легко внедрять изменения вслед за пожеланиями пользователей, и экономический эффект от их появления тоже можно увидеть еще до полного завершения проекта. К примеру, внедрение даже небольшой функциональности в личном кабинете интернет-магазина способно снизить долю отказов из-за более простой процедуры оформления заказа, а значит, повысить выручку компании. Agile позволяет сразу увидеть этот рост.
Может ли Agile стать проблемой для разработчика и почему?
Сам по себе Agile не может стать проблемой. Трудности могут появиться, если участники проекта не договорятся о качестве: насколько детально прорабатывать требования, каковы будут критерии приемки результата, какими средствами будет обеспечиваться качество (автотесты, нагрузочное тестирование и пр.), какие метрики использовать для отслеживания качества продукта уже во время его эксплуатации и так далее. В перспективе из-за таких недочётов будет накапливаться технический долг, релиз тех или иных функций будет задерживаться, качество продукта и удовлетворённость пользователей будут падать.
Также есть устойчивый миф о том, что Agile-команды очень эффективны и их продуктивность со временем только растет. Однако вера в этот миф также может стать источником сложностей. Действительно, какое-то время в течение нескольких спринтов, пока команда срабатывается, эффективность повышается – за штормом следует период нормализации и продуктивного функционирования, это характерно не только для Agile. В проекте состав специалистов чаще всего стабилен от начала и до конца, при разработке продукта все немного не так. Жизнь продукта существенно длиннее проекта, и в реальной практике сработавшиеся Agile-команды в течение 1-2 лет распадаются, переформируются, люди растут, хотят новых задач, смены обстановки, происходит ротация. И тогда процесс командообразования начинается заново. Как следствие – снижение эффективности и скорости разработки. Это абсолютно нормальная ситуация, главное – учитывать это при планировании развития продукта.
Есть ли особенности в использовании подхода Agile с заказчиками из США и России?
Главная особенность – это различие договорных отношений между заказчиком и подрядчиком. В США компании разрабатывают программное обеспечение по договору Time&Material. То есть заказчик берёт на аутстафф команду подрядчика и оплачивает её часы, контролируя результат в коротких итерациях. А в России большинство компаний все еще работает по фиксированной цене, то есть платят за конечный результат. Это может провоцировать сложности на отечественных Agile-проектах с субподрядом. Однако это не проблема самой методологии, а лишь следствие противоречия подходов. Поэтому для минимизации рисков, при составлении договора надо детализировать план разработки ПО и обсуждать сроки выполнения этапов и всего цикла разработки.
Андрей Бушуев, СЕО, A17.
Когда я работал менеджером ИТ-проектов, старался склонить заказчика к Agile-подходу при первых намёках на неясность требований и нежелание ключевых пользователей запереться на месяц в переговорной комнате для написания идеального технического задания. Сами пользователи соглашались легко — им обычно импонирует возможность участвовать в проекте иногда и понемногу (читай на интервью и на демо).
Руководители ИТ со стороны заказчика как правило не проявляли энтузиазма, ведь гораздо проще договориться на «фикс» и потом спрашивать с подрядчика за четко очерченный объем работ. Но и до них стало понемногу доходить, что окружающий мир и бизнес меняется слишокм быстро, чтобы планировать этапы внедрения хранилища данных длительностью по 5-7 месяцев. Формально проект может и будет исполнен, но заказчик пользы не получит, нужно уже совсем другое через полгода.
В роли собственника компании я настаиваю на Agile-подходе еще чаще. Во-первых, регулярная поставка результатов (отчетов, витрин данных, дэшбордов) позволяет начать получать пользу от аналитической системы уже в первом месяце ее создания. Инвестиции в такую систему окупаются быстрее, больше не надо ждать полгода. Во-вторых, гибкий подход отлично ложится на парадигму BigData — данных много, они разные и до конца не понятно, какие из них действительно могут быть полезны, а какие нужно просто сохранить на будущее. А за 2-х недельные спринты удается проверить их полезность, проведя по всей вертикали от сбора и моделирования до интерактивной аналитики. Нет ничего ценного? Окей, идем дальше и не тратим больше время.
Конечно, риски для проектной команды при таком подходе тоже есть. Очень многое зависит от качества коммуникации с заказчиком и пользователями. Уже не поработаешь спокойно проектируя базу данных неделями без звонков и встреч. На работу внутри команды Agile, конечно, тоже влияет драматически. Без отлаженного процесса и четкой передачи результатов в нем даже пробовать не стоит —— потеряете итерацию и лицо перед заказчиком.
В управлении данными и аналитике Agile проявляется как и в большинстве других областей —- мощный инструмент, которым нужно владеть. Или он разрушит ваш проект.
Екатерина Шарова, ADCI Solutions.
Если не углубляться в манифест Agile и его принципы (https://agilemanifesto.org/iso/ru/principles.html), философию Agile можно сформулировать как гибкий подход к разработке без фиксации спецификаций и бюджета, но с обозначением конечной цели, к которой мы должны прийти. Процесс характеризуется частыми релизами софта и, хотелось бы, последующей радостью клиента от такого видимого прогресса. Для разработчиков Agile обещает меньше фиксации на конкретных технических требованиях, для клиента — активное участие и учет его мнения.
Можно ли за счет Agile получить дополнительный профит при разработке, и в чем он будет заключаться?
Если меняется скоуп проекта (объем работ), и на счет падают приятные рубли или другие валюты, конечно, это плюс для исполнителя. Он же может обернуться непредвиденными расходами для клиента. Участие в проекте — палка о двух концах: некоторые клиенты обожают микроменеджмент, некоторые просят избавить их от обсуждения реализации и хотят видеть наши варианты.
В контексте технической реализации, разработчик всегда может предложить более релевантное решение — ведь он не клялся на крови реализовать платежи через Stripe, а не PayPal
Может ли Agile стать проблемой для разработчика и почему?
— Agile в чистом виде – довольно редкий кейс; немногие, исходя из практики нашей компании (мы на рынке с 2007 года) и лично моего 3-летнего опыта на текущей позиции (аккаунт и ресурс-менеджмент), понимают, что такое Agile и как ему следовать. Поэтому в работе мы сталкиваемся с чем угодно, кроме Agile. Все проблемы вытекают из переосмысления подхода заказчиком, его «доработок», а также сочетания несочетаемого: фиксированного бюджета и нефиксированного объема работ.
Евгений Иванов, руководитель проектов в iD EAST.
Что в принципе может принести гибкая модель взаимодействия заказчику и исполнителю, если конечно все процессы построены грамотно:
— быстрая обратная связь (возможность на более раннем этапе скорректировать действия и удешевить ошибку)
— минимизировать бюрократию: выявили проблему → обсудили варианты → выбрали лучший → побежали делать
— вся команда работает в одном темпе, что дает чувство ритма и предсказуемость сроков реализации каждого этапа
Теперь попробуем спроецировать это на наши реалии…
Те категории заказчиков, которые представляют госсектор, либо коммерческие организации с закоренелой бюрократией, порой действительно проявляют активный интерес работать с исполнителем по гибкой модели, и такой порыв вызывает уважение. Но во многих случаях все упирается в то, что с их стороны невозможно соблюдать все правила игры.
Например, на стороне заказчика находится реализация бекенда (серверной часть приложения), с которым должны взаимодействовать фронтенд-приложения (веб-сайт, Android, iOS), реализуемые на стороне исполнителя. Если на сервере требуется добавить новый API-метод или доработать текущий, то задача может сильно растянуться во времени по многим причинам:
— разработчики бекенда принадлежат другому подразделению компании Заказчика и приоритетность их задач определяет локальный руководитель, которому сыпятся подобные запросы от всех отделов;
— разработчики бекенда являются сотрудниками третьей стороны, и по условиям контракта с ними задачи ставятся только на следующий месяц и т.п..
Еще бывает ситуации, когда для утверждения какого-нибудь вопроса (банально — кнопку перекрасить в интерфейсе), менеджеру проекта со стороны заказчика приходится запрашивать одобрение более вышестоящих коллег, которые не всегда оперативно доступны и вообще процесс согласования с ними требует подписания кучи бумаг.
Проблемы бывают и на стороне исполнителя, но на практике такое бывает не так часто.
Как итог, преимущества гибких методологий определенно есть и трансформироваться это может в более высокую скорость разработки, дешевизне ошибок за счет более ранней обратной связи, хорошему климату внутри команды за счет прозрачности процессов, а может и всему сразу, если за управлением команды стоит грамотный менеджер проекта (или скрам-мастер, называйте как угодно). Важно будет перед стартом работ договориться о правилах взаимодействия, а также их следованию на всем жизненном цикле проекта.
Максим Петриков, Senior Software engineer в компании EPAM Systems
Agile или иначе гибкие методологии разработки пришли на замену водопадной модели. Водопадная модель — сначала выясняются все требование, составляется детальное технической задание, после этого работают программисты, пока не получится продукт. В книге Крега Лармана «Применение UML 2.0 и шаблонов проектирования» приводится статистика Министерства обороны США на конец 80-х годов, когда еще не было гибких методологий: 50% проектов поддерживаемых этим министерством были закрыты или привели к получению непригодных результатов.
Основная идея agile — общение с заказчиком на протяжении всего проекта, и на основании этой обратной связи, изменение вектора развития программного продукта.
Конечно agile не серебряная пуля, и для выпуска качественного, коммерчески успешного продукта требуется огромное количество действий и решений. Agile позволяет вовремя повлиять на развитие проекта, в отличие от каскадной модели, где на момент завершения продукта, он может стать абсолютно ненужной поделкой, не нужной никому, ни заказчику, ни рынку.
Для разработчика упрощенно процесс разработки может выглядеть примерно вот так(scrum):
— Проводится планирование спринта, который будет длиться от 1 недели до 2-х месяцев, обычно 2 недели. Вырабатывается цель спринта и разработчику накидываются задачи, которые ожидают что он сделает за этот период времени
— Разработчик уходит работать, ежедневно проводятся встречи всей команды, на которой обсуждают как продвигаются задачи, планируют свой день, координируют работу и делятся проблемами
— В конце спринта проводится ретроспектива, на которой одна из важных тем — что можно улучшить, чтобы повысить производительность команды
После этого цикл начинается сначала
Цель спринта остается неизменной, задачи могут меняться, но, скорее всего, незначительно. Такая парадигма agile обычно применяется когда продукт еще не выведен на рынок и нет обратной связи от пользователей. Разработчику работается в таких условиях более спокойно, он понимает что его не будут дергать «срочно, всё бросай, надо делать вот это».
Подход с задачами и планированием дисциплинирует, но это зависит от разработчика, кому-то размытые задачи на словах приятнее решать.
Можно ли за счет Agile получить дополнительный профит при разработке, и в чем он будет заключаться?
В некоторых вариациях agile один из этапов работы — оценка сложности задачи в некоторых абстрактных единицах (story point). Со временем появится усредненная оценка, сколько story point может сделать команда за спринт, на основании этой оценки можно строить долгосрочные планы, но с оглядкой на изменения, которые скорее всего появятся.
На ежедневных встречах команда синхронизируется, можно попросить помощи, понятно чем занимаются коллеги и куда движется проект. Программисты чувствуют себя частью команды, повышается вовлеченность, а за счет этого качество продукта.
Может ли Agile стать проблемой для разработчика и почему?
Есть сработанные команды, которые показывают стабильный и хороший результат, например применяя kanban. В kanban обычно не применяются оценки сроков, и разработка носит довольно непредсказуемый характер. Бизнес и менеджеры, конечно же любят более предсказуемые истории и могут пытаться загнать такие команды в более предсказуемые формы agilе, с оценками, планированием. Это может привести к разрушению микроклимата в коллективе, формальному выполнению задач, увольнению разработчиков.
Нарушение принципов может также стать проблемой. Например, оценка story points может проводиться менеджером, а не командой, из-за чего будет занижение оценки на этапе оценки. Также руководство может пытаться понять задачи и сильно возмущаться, когда простая по их мнению задача делается в разы дольше.
Голицын Сергей, разработчик.
Agile это гибкая методология. И она должна быть действительно гибкой и удобной. Должна быть понятна как бизнесу, так и разработчикам. Но такое встретишь далеко не везде. Обычно бизнес старается подстроить разработку под себя и сделать все в минимальные сроки, потому что это несет за собой минимальные затраты (хотя в длительной перспективе это не так). И неопытный руководитель будет планировать спринты (итерации, после которых должен быть определенный результат) не учитывая опыт команды, а только учитывая пожелания заказчика. Чаще всего такое терпит крах и потерю всей команды разработки.
Так, а в чем смысл Agile для разработчиков и заказчиков? Разработчики могут своевременно предупреждать заказчика о сдвиге сроков. Показывать заказчику план работ (road map), постоянно коммуницировать с заказчиком и, вероятнее всего, менять ТЗ в процессе, предлагая более оптимальные решения, и избавляясь от ненужных задач. В результате мы получим продукт, который заказчик ожидает в оговоренные сроки. Да, на такое сложно убедить бизнес, но это возможно.
Но можно ли за счет Agile получить дополнительный профит при разработке, и в чем он будет заключаться? Я считаю, что дополнительный профит получить можно, но на короткой дистанции. Например, можно выдавить максимум из команды разработки за 1-2 недели (спринт). Можно давить сроками, давить на внутреннюю ответственность, говорить, что ведь ты сам подписался на эти задачи. Это ужасный метод, но работает. Работает, но не сильно долго. Если такое практиковать постоянно, то никакой отпуск или повышение зарплаты, не спасет от ухода разработчиков. Готовы ли вы пожертвовать коллективом? Так же скорее всего будет страдать качество кода, но если поддержка не обязательна, то про это можно забыть. В целом если делать такое не часто, то можно выжать дополнительные возможности из команды в самый нужный момент.
Именно поэтому Agile может стать проблемой для разработчика. Если вдруг разработчик переоценил свои силы, не досмотрел за тем сколько задач на него взяли в спринт, не учел время на тестирование, деплой, исправление багов, то его можно давить сроками и выжимать по максимуму. Также менеджер может специально резать сроки проекта на старте и давать жесткие сроки, что бы подстраховаться. А так же при планировании специально занижать сроки, что бы команда овертаймила. Все это приводит к ужасным последствиям, но да, такое бывает.
Но везде ли такой Agile? Есть ли особенности в использовании подхода Agile с заказчиками из США и России? В США и Европе очень ценится work and life balance. Менеджеры контролируют переработки. Следят за тем, что бы сотрудники вовремя уходили домой. В целом нет ничего страшного если сроки чуть-чуть сдвинутся, зато команда будет довольной счастливой и продуктивной и в долгосрочной перспективе принесет больше профита. В России же ситуация кардинально другая. Особенно с огромными заказчиками типа гос сектора или фабрик/заводов. Им нужна сиюминутная прибыль, скорее закрыть проект и начать эксплуатацию. Им не важно что будет с проектом через несколько лет. Поэтому обычно даются урезанные сроки и команды овертаймят и разбегаются по другим компаниям, где ритм работы намного спокойнее. Я практически на каждом собеседовании слышал от кандидатов вопрос: “А часто перерабатываете?” — это ли не показатель того как работает Agile в России?
Все выше сказанное исходит лично из моего опыта и не является неопровержимым фактом, вероятно кому-то посчастливилось работать в совершенно других компаниях и он имеет противоположный опыт. Могу сказать точно, что Agile в каждой команде должен быть свой и должен помогать достигать поставленных целей.
Олег Бурко, эксперт в области системного и бизнес-анализа, сертифицированный бизнес-тренер Luxoft Training.
Как тренер учебного центра Люксофт, я регулярно общаюсь с большим количеством аналитиков в рамках тренингов по системному и бизнес-анализу и вижу возрастающую популярность AGILE-подходов. Работа в SCRUM-командах стала уже обыденным делом для российских компаний. Классические проекты, предполагающие позднюю поставку ценности, перестали устраивать бизнес. Это хорошо отражено в цитате Германа Грефа, который сказал, что «те, кто не освоят Agile сегодня в текущих процессах, лузеры завтра».
Согласно 14-му ежегодному отчёту о состоянии AGILE во всём мире (State of Agile, https://stateofagile.com/) за 2020 год, в котором приняло участие более 40 000 руководителей, практиков и консультантов со всего мира, три наиболее популярных ожидания от AGILE-трансформации – это быстрая поставка бизнес-ценности, возможность управлять меняющимися приоритетами и повышение производительности.
Это именно те выгоды, которые ожидает получить бизнес, и его ожидания оправдываются на 71% (быстрая поставка бизнес-ценности), на 63% (возможность управлять меняющимися приоритетами) и на 51% (повышение производительности).
Однако, если обратиться к руководству по SCRUM, которое обновилось в ноябре 2020 года, там много говорится о теории, команде, событиях и артефактах SCRUM, но практически ничего не говорится о том, как необходимо работать с требованиями в AGILE-контексте (слово «требование» упомянуто в руководстве по SCRUM только 2 раза). И понятно почему. SCRUM — это фреймворк, который «не предоставляет людям подробных инструкций, а вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей». Предполагается, что компания, внедряющая ту или иную гибкую методологию, сама определится, какой подход выбрать: пользовательские истории с эпиками, варианты использования со сценариями или классическую спецификацию требований.
Работа с требованиями исключительно важна в любом проекте. AGILE здесь не является исключением. Более того, с учётом высоких ожиданий бизнеса по срокам и ценности решения, умение AGILE-команды выявлять реальные потребности и через профессиональную работу с требованиями регулярно поставлять ценный продукт становится важным конкурентным преимуществом. И, как автор тренинга, который посвящён специфике управления требованиями, в условиях проектов, ведущихся по гибким методологиям, в т.ч. по SCRUM, отмечу. что интерес к этому направлению продолжает расти.
- Психология азартных игр: что побуждает людей играть? - 03/12/2024 18:46
- Купить мобильные прокси ФБ: кому и зачем они нужны - 03/12/2024 14:42
- Подтверждено лабораторное происхождение коронавируса COVID-19 - 03/12/2024 13:50
