НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Про ФБР и 25 млрд. долл. на ветер

Сергей Бобровский
27.09.2011 10:43:09

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

Вот например оценки Standish Group из отчета CHAOS 2009 (обсуждение на сайте альянса scrum-мастеров).
Процент провальных проектов в 2004 г. вырос с 18% до 24% в 2009-м, хотя процент неудачных проектов (превышение сроков, увеличение бюджета) несколько снизился, с 53% до 44%. То есть суммарный объем неудачных проектов остался примерно тот же, но доля провальных проектов растет. Спасение -- только в аджайлах!

Горячая новость в тему: на прошлой неделе стало известно о закрытии провального проекта автоматизации британской Национальной службы здравоохранения, которая (система) сама по себе считается образцом качественного массового сервиса. 12,7 млрд. фунтов стерлингов (!) израсходовано впустую, а сроки затянуты на годы.

Хотя, казалось бы, в чем тут может быть сложность? Рядовая учетная система, не такая уж и масштабная. База данных, middleware для кэширования нагрузки, и клиентский софт для доступа к ней. Как можно ухитриться не сделать такую систему?

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

"It is not possible to identify a documented business case for the whole of the programme".

Другой пример. В начале 2000-х ФБР задумало систему документооборота Virtual Case File, но реализовать проект не удалось -- исполнитель SAIC фактически впустую потратил 170 млн. долл. Более того, даже переделке то, что получилось, не подлежало -- типичный пример последствий "водопада". В 2005-м стартовал новый проект Sentinel, автоматизация управления следственными делами, веб-доступ аналитиков к оцифрованным уликам, и т. п., подрядчиком стала Lockheed Martin. Технологии -- от Adobe, IBM, Microsoft и Oracle, бюджет -- 451 млн. долл.

Подрядчик быстро освоил 400 млн., но проект добрался только до середины. Разъяренные чиновники из американского правительства вызвали прошлой осенью руководителей ФБР на ковер, и тем пришлось поклясться, что из рамок 451 млн. они не выйдут, и обязательно Sentinel доделают. И хотя по оценкам корпорации Mitre, бюро требовалось израсходовать на завершение еще 351 млн. долл., ФБР нашло единственно реалистичный выход: был объявлен переход на agile methodology, число задействованных в проекте людей сократилось с 250 до 50, а оставшуюся половину работы было обещано завершить за год, к текущему сентябрю, и всего за 20 млн. долл.!

Промежуточные итоги по-пионерски гибких трудов ФБР над "Стражем" были оценены сенатом США на прошлой неделе. Сроки, судя по всему, снова затягиваются, но вот результаты обнадеживают -- функциональность реализуется в рамках бюджета, и чиновники даже пригрозили рьяно взявшимся за дело фэбээровцам: освоить весь бюджет они не дадут, и если общая сумма назначена в 451 млн. долл., это совсем не означает, что надо потратить всю сумму. То есть появился реальный шанс с помощью аджайлов реализовать объем работ на порядок эффективнее в сравнении с классическими методиками, и даже еще и сэкономить.

Следствие: если проектная методология А дает выигрыш в сравнении с методологией Б в разы, то использование подхода Б при реализации государственных проектов неплохо бы cчитать экономическим преступлением. Ведь, получается, не меньшие в сравнении с пресловутой коррупцией, если не гораздо большие суммы сегодня расходуются впустую из-за неверных проектных подходов.

Так, в отношении проектов, где например спутники падают в океаны, можно с уверенностью предположить, что используется в них "водопад", который, мягко говоря, подходит плохо для современных, все более усложняющихся задач в условиях непрерывно меняющихся требований и сокращения сроков жизни технологий. Сегодня "водопад" -- это признак высокого проектного риска уже просто по факту его использования.

В этом году Elizabeth McGrath, зам. chief management officer МО США, заявила, что министерство начинает активно внедрять аджайлы (реально этот процесс стартовал в июне). Прежде всего будет внедряться итерация, отказ от крупных проектных фаз,
разделение проектов на малые части, а также акцентированное повсеместное тестирование (а в перспективе, видимо, и TDD).

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

Комментариев: 3

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

Дмитрий Менщиков
15.10.2011 14:33:11

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

18.10.2011 10:49:30

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

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

Дмитрий Менщиков
18.10.2011 12:01:18

Да, надо почитать, что там министерство обороны США придумало делать с agile.

Спасибо.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии