ru
сегодня
Евгений Молев
Как не ошибиться с методологией разработки IT-проекта?
Каждый проект уникален, но хаос в управлении — болезнь универсальная для большинства компаний. В нашем проектом офисе припасены инструменты для борьбы с хаосом. И один из них — методология ведения проекта. Выбор «водопад» или «эджайл» — это не дань моде, а практический инструмент, с помощью которого мы можем влиять на бюджет, сроки и невосстанавливающиеся нервные клетки заказчика и прожект-менеджера.
Если бы мы строили мост через реку, мы бы не смогли сначала построить одну половину до середины реки и показать её заказчику: «Ну как? Продолжаем?». Мост либо выдержит испытательную нагрузку, либо нет. Все расчеты, чертежи, согласования делаются заранее. Здесь подходит Waterfall. Если бы мы пекли вкусные пирожки с повидлом или с мясом на заказ, мы бы сначала испекли один с повидлом и один с мясом и дали бы вам попробовать. «Добавить больше корицы в следующую партию? Сделаем!» — тут работает итеративный, интерактивный гибкий Agile.
Специфика проектов в IT — в разнообразии: от четкого ТЗ с точными сроками и суммами, до «давай быстрее, делай как в ТикТоке». Выбор методологии у нас часто сводится к противостоянию каскадной модели (Waterfall) и гибких фреймворков (Agile/Scrum/Kanban). Но что выгоднее для заказчика и разработчиков?
Когда выгоднее разработчику?
Waterfall выгоден, когда задачи типовые, а требования кристально ясны (например, интеграция по протоколу, миграция баз данных по чек-листу). Мы любим водопадную модель за предсказуемость: «я точно знаю, что делаю сейчас, и точно знаю, что буду делать через полгода». Меньше стресса и внезапных «хотелок» заказчика.
Agile выгоден, когда проект сложный и требует творческого подхода. Но для команды это всегда более высокая стоимость изменений. Разработчик в Agile должен быть универсалом, готовым к переключению между разноплановыми задачами. Это выгодно профессионалам с сильным инженерным подходом, которые хотят сами влиять на продукт, и невыгодно тем, кто хочет поменьше переживать.
Когда выгоднее Заказчику?
Waterfall выгоден заказчику с фиксированным бюджетом и жесткими регуляторными требованиями (например, госсектор, банки, космос). Заказчик платит за результат «под ключ» и спит спокойно, зная, что бюджет не расползется. Но если это коммерческая компания, через полгода готовый продукт может быть уже никому не нужен.
Agile выгоден заказчику-стартаперу или бизнесу в состоянии высокой неопределенности. Прозрачность движений по проекту не только позволяет ему менять приоритеты «на лету», но даёт возможность остановить проект на любой итерации, получив работающий продукт, а не просто кипу проектной документации. Главный минус в менее предсказуемом бюджете и сроках.
В реальности при разработке сложных IT-продуктов, Agile или Waterfall в чистом виде встречаются редко. Обычно мы используем комбинированный подход, применяя различные методологии, иногда в зависимости от стадии или этапа проекта, иногда в зависимости от вида работ.
На пример в проекте с жесткой архитектурой и нестандартным интерфейсом бэкенд будем «пилить» по ТЗ и спецификациям с Waterfall, а фронтенд и UI/UX можем «выкатывать» спринтами, собирая фидбек в Scrum. Комбинированные методологии позволяют сделать интерфейс удобным, не затрагивая лишний раз ядро системы.
Применим также формат MVP с последующей поддержкой. Первые 2-3 месяца ведётся разработка по канбану с жёстким бэклогом продукта, чтобы уложиться в бюджет MVP. После запуска продукта и получения первых денег переходим на Scrum с двухнедельными спринтами.
Критические по уровню безопасности модули лучше вообще вынести в отдельный проект с водопадной методологией, двойными код-ревью и полной документацией, параллельно с основной командой разработки.
Мы стараемся брать лучшее из доступных принципов проектной деятельности: дисциплину водопадной модели для рискованных частей системы и гибкость эджайл для пользовательских сценариев. Именно такой симбиоз методологий позволяет нам и бюджет для клиента сэкономить, и пользователей программного продукта порадовать.
Если бы мы строили мост через реку, мы бы не смогли сначала построить одну половину до середины реки и показать её заказчику: «Ну как? Продолжаем?». Мост либо выдержит испытательную нагрузку, либо нет. Все расчеты, чертежи, согласования делаются заранее. Здесь подходит Waterfall. Если бы мы пекли вкусные пирожки с повидлом или с мясом на заказ, мы бы сначала испекли один с повидлом и один с мясом и дали бы вам попробовать. «Добавить больше корицы в следующую партию? Сделаем!» — тут работает итеративный, интерактивный гибкий Agile.
Специфика проектов в IT — в разнообразии: от четкого ТЗ с точными сроками и суммами, до «давай быстрее, делай как в ТикТоке». Выбор методологии у нас часто сводится к противостоянию каскадной модели (Waterfall) и гибких фреймворков (Agile/Scrum/Kanban). Но что выгоднее для заказчика и разработчиков?
Когда выгоднее разработчику?
Waterfall выгоден, когда задачи типовые, а требования кристально ясны (например, интеграция по протоколу, миграция баз данных по чек-листу). Мы любим водопадную модель за предсказуемость: «я точно знаю, что делаю сейчас, и точно знаю, что буду делать через полгода». Меньше стресса и внезапных «хотелок» заказчика.
Agile выгоден, когда проект сложный и требует творческого подхода. Но для команды это всегда более высокая стоимость изменений. Разработчик в Agile должен быть универсалом, готовым к переключению между разноплановыми задачами. Это выгодно профессионалам с сильным инженерным подходом, которые хотят сами влиять на продукт, и невыгодно тем, кто хочет поменьше переживать.
Когда выгоднее Заказчику?
Waterfall выгоден заказчику с фиксированным бюджетом и жесткими регуляторными требованиями (например, госсектор, банки, космос). Заказчик платит за результат «под ключ» и спит спокойно, зная, что бюджет не расползется. Но если это коммерческая компания, через полгода готовый продукт может быть уже никому не нужен.
Agile выгоден заказчику-стартаперу или бизнесу в состоянии высокой неопределенности. Прозрачность движений по проекту не только позволяет ему менять приоритеты «на лету», но даёт возможность остановить проект на любой итерации, получив работающий продукт, а не просто кипу проектной документации. Главный минус в менее предсказуемом бюджете и сроках.
В реальности при разработке сложных IT-продуктов, Agile или Waterfall в чистом виде встречаются редко. Обычно мы используем комбинированный подход, применяя различные методологии, иногда в зависимости от стадии или этапа проекта, иногда в зависимости от вида работ.
На пример в проекте с жесткой архитектурой и нестандартным интерфейсом бэкенд будем «пилить» по ТЗ и спецификациям с Waterfall, а фронтенд и UI/UX можем «выкатывать» спринтами, собирая фидбек в Scrum. Комбинированные методологии позволяют сделать интерфейс удобным, не затрагивая лишний раз ядро системы.
Применим также формат MVP с последующей поддержкой. Первые 2-3 месяца ведётся разработка по канбану с жёстким бэклогом продукта, чтобы уложиться в бюджет MVP. После запуска продукта и получения первых денег переходим на Scrum с двухнедельными спринтами.
Критические по уровню безопасности модули лучше вообще вынести в отдельный проект с водопадной методологией, двойными код-ревью и полной документацией, параллельно с основной командой разработки.
Мы стараемся брать лучшее из доступных принципов проектной деятельности: дисциплину водопадной модели для рискованных частей системы и гибкость эджайл для пользовательских сценариев. Именно такой симбиоз методологий позволяет нам и бюджет для клиента сэкономить, и пользователей программного продукта порадовать.