[spoiler]Вот например оценки 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).
Ведь при качественно организованном тестировании и спутники бы не упали, и несправные самолеты бы не взлетели -- при недоливе топлива или неприваренном газовом кране система просто не прошла бы стандартные наборы тестов.
По-моему, как раз вот в таком случае, когда разработка идет итерациями, а проектирование идет параллельно - вот тогда и придется все многократно переделывать...
А тестирование при любой методологии важно, это не преимущество agile.
В agile тестирование буквально возведено в культ -- в том смысле, что проектирование немыслимо без добавления повсеместных тестов. Понятно, что и в обычных проектах без тестирования никуда, но ему не уделяется такого первоочередного внимания, как в аджайлах.
Спасибо.