Одним из важных преимуществ X-driven разработки часто указывают следующее: проектная команда получает полную уверенность в том, что выпускаемый продукт будет работать именно так, как ожидается. В жизни же грань между уверенностью и  иллюзиями весьма тонка. Уверены, каждый проект-менеджер с опытом корпоративных боев за плечами расскажет немало баек плана «все было замечательно до момента, когда пользователи наотрез отказались эксплуатировать продукт». Или же «вывели несколько абсолютно прозрачных изменений – легла половина систем». Самая же курьезная история, которую нам доводилось слышать, случилась с проектом, который должен был продемонстрировать практическую пользу от использования TDD. У этого проекта был только один баг: через несколько часов работы что-то случалось с драйвером базы данных, и… безо всяких симптомов до сервера БД переставали доходить апдейты.

Здорово, не правда ли? Несколько недель назад смежной группе понадобилось запустить разработанный ими компонент на нашей инфраструктуре. Для написания этого компонента наняли молодого специалиста только что из науки. Поскольку сроки жмут со всех сторон, делаем, естественно, Agile. А поскольку в Agile думать об эксплуатации тоже надо, получив первую версию компонента решил поинтересоваться:

• Слушай, какой у нас план на запуск и сопровождение?
• В смысле?
• В том смысле, как мы удостоверимся, что ваш компонент работает в эксплуатации?
• Э-э-э… У нас же весь код покрыт тестами! Посмотри сюда…
• Я не спрашиваю тебя, как вы тестировали ваш компонент – за это вы отвечаете. Что мы должны делать, чтобы удостоверится, что компонент работает?
• Не понимаю, почему ты спрашиваешь. Мы же все протестировали!
• Хорошо, перефразирую вопрос. Как нам удостовериться, что заказчик получает value, за которой он заплатил?
• То есть?
• Что то есть? Насколько я знаю, ваш софт должен решить вот такую бизнес-задачу. Как нам понять, что задача действительно решена в эксплуатации?
• Но ведь мы же все протестировали!

Недавно попался блог одного программера,  в котором тот с немалым удивлением для себя открывает, что код, покрытый автоматическими тестами на 100%, может оказаться неработоспособным. Вот и вернулись к песне десятилетней давности, что если «на моём компьютере все работает», еще не факт, что будет работать у пользователя.

* * *

Давайте посмотрим на главную проблему ИТ проектов – то, что они выходят за сроки и бюджет. Представим себе, что сейчас 1е февраля, вам надо сделать проект объемом, скажем, 200 story-points. Вы используете Scrum, длина спритна 2 недели. За спринт оптимальная проектная команда делает 10 поинтов. Таким образом, проект займет 20 итераций закончится к концу года. Не забываем, что люди болеют и уходят в отпуск. Все было бы хорошо, если бы:

• бизнес-менеджеры клиента не настаивали на том, что проект должен быть закончен к 31 августа, и что все пожелания пользователей должны быть сделаны – иначе на проект не выделят бюджет;
• пользователи продолжают выдавать нагора новые идеи, жить без которых они не могут.

В итоге выйдет, что к 31 августа та же команда должна выполнить проект с конечной трудоёмкостью где-то в 500 story-points. На все-про-все 14 спринтов, и в каждом спринте надо делать 35 поинтов. Где найти такой вот Х, чтобы увеличить производительность команды в 3,5 раза? Х в этом случае – это понимание того, что максимум, который может сделать команда к указанной дате – это 140 поинтов. Экспериментируя с различными «повышающими» методами это число можно понизить – но никак не повысить. Собственно, в этом мы не оригинальны.

Agile тем хорош для проектной команды, что во-первых перекладывает ответственность за порядок реализации и потребительские свойства функционала на пользователей, и во-вторых дает команде микро-контролируемую среду – итерацию. Однако вернемся к нашей ситуации, которую Йордон назвал бы безнадежной. Поскольку хочется кушать, за проект придется взяться. Чем может тут помочь Agile? В принципе, ничем: согласно Agile надо как можно скорее объявить о провале проекта. Что никак не помогает нашему проект менеджеру, которому надо что-то как-нибудь работающее показать 31 августа. Иначе увольняем людей. С нашей точки зрения решать эту проблему нужно оторвавшись от рамок проектной команды. Поднять за короткий срок производительность проектной команды в разы невозможно. Значит, для того, чтобы унести бонус 31 августа надо смотреть в другую сторону. Но об этом уже в другой серии блогов.