Чтобы поддерживать уровень разработки на должном технологическом уровне, программисту требуется постоянное развитие.
Алексей Каменев, руководитель продукта «СервисМонитор»
Пользователям нужен функционал здесь и сейчас, они не готовы ждать. Соответственно, и методики разработки должны учитывать эту вариативность и бешеный темп изменений. Если использовать классические подходы, то к тому моменту, как мы все распланируем и подойдем к стадии реализации, продукт уже успеет устареть, а к моменту выхода продукта на рынок конкуренты, использующие Agile, успеют наработать клиентскую базу и будут лучше осведомлены о потребностях
клиента.
Сегодня в ИТ-мире ходит поговорка: «Если ты вывел продукт на рынок и тебе за него не стыдно, то ты уже опоздал». Пользователи готовы мириться с тем, что изначально им будет
доступен не весь функционал, а какая-то минимальная часть, но каждый месяц они будут получать обновления и видеть, как развивается продукт, особенно если в этих обновлениях будут учитываться их пожелания.
Agile возник в ИТ-сфере, и мы как ИТ-компания используем эту методику при разработке новых программных продуктов. Потому что Agile опирается на условия, которые меняются в
результате окружающей среды. Это помогает разработчикам экспериментировать, получать обратную связь и тем самым создавать уникальные продукты.
В нашем случае, работая над повышением стабильности ИТ-серверов, мы использовали стандартное планирование и практики классического проектного управления с фазами: инициация, планирование, реализация, подведение итогов. При планировании выяснилось, что детальная проработка невозможна, так как требуется провести большой объем исследований в условиях постоянно изменяющихся требований. Необходимо применениеметодики Agile. Благодаря ему можно приспособиться к постоянно меняющимся
условиям, держать плотный контакт с заказчиком и гибко управлять проектным треугольником «содержание — ресурсы — сроки». И теперь эта методология является основной в ИТ-компаниях.
Agile неприемлем, если вы компания, которая ориентирована на циклические процессы.
Например, хостер, интернет-провайдер или call-центр. Здесь не может быть Agile,
за исключением случаев внутренних проектов. Также это методология неприемлема, если ваша архитектура, технологии не предусматривают гибких изменений. Это касается производственных и строительных компаний. При начале строительства дома у вас, во-первых, должен быть проект, учитывающий все аспекты: геологические данные, материалы, вес конструкций.
А, во-вторых, у вас есть четкая последовательность и зависимость работ друг от друга: вначале готовим площадку и только затем занимаемся фундаментом и так далее. В таких случаях не может меняться последовательность работ, и Agile ничем не
может помочь.
Кому помогает AGILE?
Agile помогает там, у кого есть высокая степень неопределенности и возможность гибко изменять последовательность задач. Это область разработки новых программных продуктов.
Благодаря этой методике вы держите фокусировку всей команды на самой важной задаче — цели спринта, что позволяет поддерживать нужный темп разработки и избегать долгих задач,
которые грозят превратиться в болото, поглощающее время и силы команды. Ничто так не демотивирует, как задача, по которой не видно продвижения, осязаемых результатов, несмотря на потраченные усилия. Также Agile позволяет держать постоянную связь с пользователем, понимать, что ему именно нужно. Это очень важно в ИТ-сфере. Мало того, если правильно выстроить работу с клиентом, то у него возникнет ощущение сопричастности к созданию и развитию продукта, а постоянные обновления, которые достигаются за счет Agile, помогут укрепить это чувство и не дать ему остыть.
Ошибки в Применении AGILE
Agile и Scrum требуют ритмичной работы — необходимо выдавать результат по окончанию каждого спринта, который длится в среднем от двух недель до месяца. Это требует определенной специфики организации команды. Прежде всего, это стопроцентная вовлеченность человека в проект на время спринта. Многие компании пытаются оптимизировать использование дефицитных и дорогостоящих ИТ-специалистов, распараллеливая их работу на несколько проектов. И это самая главная ошибка при использовании Agile, так как у такого «распараллеленного» сотрудника теряется самое важное — фокусировка на цели спринта. Здесь компромиссом может быть ситуация, когда вы отдаете специалиста на другой проект на целое время спринта, то есть две недели он работает над одним проектом, а потом две следующие недели над другим, но ни в коем случае не одновременно. Но не забывайте, что переключение контекста и адаптация требует определенного времени и сил специалиста.
Бизнес-журнал | июнь | #6 2018
