Scrum: результат в условиях неопределенности
Гибкие (agile) методики реализации ИТ-проектов — иногда, в зависимости от контекста, встречается вариант перевода «скорые» — получают все большее распространение. 84% ИТ-департаментов, опрошенных VersionOne, ответили утвердительно на вопрос, применяют ли они гибкие методики разработки. Среди них 54% заявили об использовании методики Scrum. Более того, компетенции в Scrum, наряду с технологиями in-memory и предсказательной аналитикой, входят в рейтинг наиболее востребованных ИТ-навыков, составленный Foote Partners.
Гибкие методики соответствуют изменившимся требованиям рынка: устранить риски и увеличить скорость разработки, снизить вероятность провала проекта. По данным The Standish Group, число неудач в Scrum-проектах втрое меньше, чем при традиционном подходе, а число успешно законченных проектов вдвое больше.
Гибкие подходы избавляют от многих рисков благодаря более активному взаимодействию команды разработчиков между собой и с заказчиками. За двухнедельные интервалы разработок — «спринты» — гораздо проще создать продукт, отвечающий базовым требованиям пользователей, и затем дорабатывать его на основе полученной обратной связи, чем ждать реализации крупного функционала, который в итоге не будет соответствовать бизнес-требованиям.
Главным барьером, мешающим внедрению гибких методик разработки, становятся потребности в изменениях, причем не только в ИТ-отделах, но и в рамках организаций в целом. Крупные структуры сложно изменить, и они гораздо медлительнее. Кроме того, возникает и кадровый вопрос. Привлечение талантливых разработчиков уже давно стало большой проблемой на разогретом рынке ИТ-кадров, но выделение из их числа тех, кто способен к гибкой разработке и, помимо технической экспертизы, имеет соответствующие коммуникационные навыки, добавляет рекрутерам головной боли.
Гибкие методики являются крупным изменением для компаний, стремящихся уйти от традиционного «водопада». Такие методики подразумевают принципиально иное управление проектами. Для этого требуются специалисты, чей стиль работы, опыт и мировоззрение соответствуют методикам гибкой разработки. Проблема не в том, чтобы найти хороших разработчиков, а в том, чтобы увидеть у них «гибкий» образ мышления. Нужен определенный профиль человека: помимо коммуникабельности, это любопытство, умение решать проблемы, способность работать в команде. Старое представление о программисте как об «одиноком волке», работающем соло, ушло в прошлое — сейчас такой подход не является предпочтительным.
С учетом роста фактора мобильности компаниям придется переходить на гибкие методики разработки приложений. В Gartner утверждают, что традиционные методы, используемые для создания корпоративных систем, не будут эффективными в случае создания мобильных приложений. Мобильная разработка имеет ряд специфических особенностей — например, потребность в многоплатформенности приложений. Кроме того, пользователи часто не могут четко описать, что мобильное приложение должно делать. Традиционная работа системных аналитиков по сбору требований успехом не заканчивается. С этой точки зрения правильнее идти небольшими шагами.
Как отметил Михаил Петров, заместитель директора департамента проектов по информатизации Министерства связи и массовых коммуникаций РФ, в рамках дискуссии «Мы за скрам!» на портале Global CIO, любая методология имеет область адекватного применения. «Scrum подразумевает намного большую квалификацию исполнителя — как с точки зрения управления объемом и ресурсами, бюджетом, рисками, так и в плане управления ожиданиями заказчика, требует вовлечения заказчика в процесс и создания определенного партнерства», — подчеркивает он. «Классически» воспитанный ИТ-менеджер к такому не привык, но для некоторых проектов (когда делать надо в четко определенный срок, но что — до конца не понятно) такая методология становится единственным выходом. Иногда традиционный подход дает вполне приемлемые результаты, но в ситуации, когда среда меняется, Scrum будет все более и более востребован.
«Традиционная методология разработки ПО «водопад» перестала соответствовать требованиям заказчиков. Эти требования меняются настолько динамично, что то видение, которое было в начале проекта, становится кардинально иным к его концу», — констатирует Тагир Яппаров, председатель совета директоров «АйТи». «Водопад» при таком положении дел дает плохие результаты, ведет к неудачам или превышению по бюджетам и срокам. Поэтому начали активно применяться более динамичные методологии, и Scrum стал элементом крупных проектов. Даже у SAP появились методологические изменения, которые отражают видение таких подходов.
«Мне кажется, что все эти разговоры про быстро меняющиеся процессы — просто фиговый листочек, прикрывающий слабую осознанность бизнесом собственных операционных процессов», — говорит Евгений Алешин, директор службы ИТ компании «Монт». Младший персонал, как правило, понимает процессы на уровне нажимания кнопок, а менеджеры не хотят знать ни про эти кнопки, ни про системы в целом — их интересует отчет о прибыли и убытках. Итеративный подход просто дает возможность постепенного понимания командой разработки предметной области. Гибкие подходы работают, тем более что они в себе содержат элементы самоорганизации команды (ежеутренние собрания) и элементы работы с заказчиком (демонстрация после каждой итерации). А вот с архитектурой систем в гибкой разработке есть определенные проблемы.
«В 90-е годы я сам использовал методологию Scrum — правда, не зная об этом: прямой контакт с заказчиком, реализация с его слов, короткие циклы, постоянные презентации», — вспоминает Александр Огнивцев, руководитель управления сервисной поддержки «АльфаСтрахования». Разница в том, что в те годы заказчик, как правило, точно знал, чего хочет, но не знал, что это можно реализовать через ИТ. Теперь заказчик точно знает, что с помощью ИТ реализовать можно все, но не знает, чего хочет. Ситуация неопределенности воспроизвелась: теперь на новом витке и в иной ситуации, — и конечно, гибкие технологии становятся востребованными.
«Мне кажется, что на открытом конкурентном рынке заказчики вряд ли примут решение в пользу Scrum, потому что основной его минус — неясные результаты за непонятный бюджет», — признает Георгий Давыдов, архитектор интеграционных решений R-Style Softlab. — Покупатель, понятное дело, предпочтет определенные сроки и цифры. Из-за этого приходилось даже скрывать свой «внутренний» Scrum от заказчика, хотя сейчас его элементы используются даже на «водопадных» проектах».
Преимущества этой методики управления прямо проистекают из ситуаций, когда ее выгодно применить. Например, заказчик не знает, что ему нужно; говоря более обобщенно — нет технического задания, что позволяет вообще исключить такой обязательный для «водопада» этап. «С одной стороны, экономия налицо, с другой стороны, привязка к партнеру становится катастрофической, да и сам исполнитель «подсаживается» на ключевых сотрудников. Как вы думаете, полетел бы Гагарин в космос, если бы ракету строили по Scrum?» — задается вопросом Давыдов. Другими примерами могут быть ситуации, когда по каким-либо причинам не получается оценить сроки и бюджет проекта, нужны быстрые результаты или когда исполнитель, не зная инструментов, изучает технику и предметную область на ходу. Наконец, возможен вариант, когда команда устала от однообразия и нужно привнести драйва, а текущая эффективность никого не устраивает.
«Как человек, имеющий команды разработчиков в штате и работающий с аутсорсерами, согласен, что по Scrum хорошо работать, когда обладаешь штатной командой, а запросы от подразделений меняются по два раза на день», — говорит Дмитрий Тепляков, ИТ-директор компании «Донбасс Арена». Тогда работа спринтами имеет смысл: заказчику сразу выдается небольшой работающий кусок, а он корректирует направление работ. Если заказчику результат не нравится — потеря времени на переделки небольшая.
Но ситуация совершенно иная, когда крупный проект заказывается у аутсорсера. «Как заказчика меня совершенно не устраивает работа по принципу открытого бюджета. Точнее, меня-то она, может, и устроит, но вот финансовый директор будет против», — отмечает Тепляков. В итоге нужно получить хотя бы рамочное понимание затрат, а это по Scrum сделать практически невозможно. А потому приходится идти по стандартной методике, составляя детальное техническое задание и создавая прототип, — по сути классический «водопад».
«Противопоставление фиксированной для реализации задачи («водопад») и нефиксированной (scrum) в корне неверно», — уверен Алексей Лапшин, руководитель проектного сервиса «АйТи». Ни та ни другая методология не отвечают на вопрос, что будет реализовано, а отвечают на вопрос, как будет реализовано и кто для этого нужен. Это как с геометриями Лобачевского и Евклида — вторая является предельным случаем первой. Если установить продолжительность «спринта» во время, отведенное на весь проект, то Scrum превратится в «водопад».
Scrum позволяет лучше контролировать ход проекта и отслеживать проблемы в нем, быстрее получать обратную связь от заказчика и не делать пустую работу. «Водопад» тоже позволяет все контролировать, отслеживать и получать, но для этого требуется много больше усилий и времени.
«Сама методика «водопада» никаким образом не препятствует внедрению гибких методов разработки», — согласен Борис Позин, технический директор «ЕС-Лизинг». Скорее, ему препятствует модель Fixed Price, которая применяется в большинстве случаев, и в госзаказах прежде всего. Таким образом, не надо путать экономику, менеджмент и технику.
Следует рассматривать проекты еще и в таких измерениях, как сложность, масштаб, суммарная трудоемкость. Авторы COCOMO и других методик оценки проектов экспериментально выявили, что производительность труда сильнее всего зависит от опыта работы программистов в конкретной прикладной области и технологической среде, от размера или сложности создаваемого ПО. Подобные важные обстоятельства при обсуждениях гибких методов почти не принимаются в расчет.
