Статьи

Эта статья - продолжение цикла статей об X-Driven Development: см. Часть 2: The Agile Bubble и Часть 1.

Рассмотрим следующий процесс: сбор требований → анализ → дизайн → выработка тест протокола → определение тестовых данных → кодирование → приемка → эксплуатация → поддержка. О чем мы говорим – об Agile или об Waterfall?

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

Это один из наших любимых вопросов, которые мы задаем на интервью кандидатам. Чего только не наслушаешься! Чаще всего указывают, что в Agile в любой момент можно менять требования. Даже системные? Задумываясь, отвечают неуверенным “да”. Тогда следующий вопрос: «этот как же: полгода писали сутки напролет на .Net под MSSQL, а буквально через две недели должно быть тоже самое, но на Java, Oracle, с развертыванием на Sun Fire»? Тут же поступает ответ, что так ничего не получится. Так что, полный ре-дизайн? – вопрос “в лоб” – такое же может случиться только с Waterfall-ом, не так ли? На этом месте разговор, как правило, заходит в тупик.

Не менее забавные перлы возникают там, когда приходится планировать бюджеты на проектных «people-оидов». Кто работал в крупный организациях знает, что чем больше времени уходит на выбивание и обоснование бюджета проекта, тем быстрее он распределяется туда, куда не надо. Где то даже так: «А бюджет… до сих пор не пойму в чем секрет. Если он есть – то его сразу нет!» Из реального разговора в 18.00 часов в четверг:

(Босс) Слушай, вот нам из проект-борда дали мандат посчитать, за сколько спринтов можно сделать проект и сколько «people-оидов» нам надо в команду. Надо подавать заявку на бюджет на этой неделе, т.е. завтра в 9ть утра.

(Я, про себя, конечно) Ага, значит все-таки решились опробовать на нас Scrum. Забавно. Только ответ согласно книжке “посадит тебя на коня”. Сказать правду-матку, или помучиться и ввязаться в эту безнадегу?

(Босс) А что по книжке?

(Я) По книжке этот вопрос не к нам – это к представителям пользователей.

(Босс) Да они вообще ничего не понимают в разработке ПО! Они уже три месяца не могут решить, как им отчеты генерить – а ты говоришь, проект им дать планировать!

(Я) Тем не менее, в Scrum-е они будут решать, что делать. Заметь, они, а не мы. А мы, значит, должны на себя взять ответственность, сколько на это уйдет времени и денег. И еще за то, что получится на выходе.

(Босс) Твоя позиция не решает проблемы!

(Я) Босс, поймите меня правильно, пожалуйста. Это не моя позиция – это позиция Scrum букваря. Ну что, перейдем к решению вопроса с бюджетом?

(Босс) И что ты предлагаешь?

(Я) Уверен на 99%, борд хочет увидеть ганнт-чарт, фазы так на три, спринтов по 5ть в каждой. В бюджетные ожидания укладываемся?

(Босс) А ну садись за мой комп, рисуй, как это выглядит!

В прошлом году вышла статья Джефа Сазерленда «Shock Therapy: A Bootstrap for Hyper-Productive Scrum», в которой он рассуждает о том, что менеджмент вмешивается в работу гиперпроизводительной команды, убивая «курицу, несущую золотые яйца». Лично нас заинтересовал вопрос: а почему так происходит? Ведь если компания имеет финансовый плюс, ей управляют далеко не идиоты. Менеджменту в общем случае очевидно, что отдача от гиперпроизводительной команды на порядок больше за те же деньги. Вряд ли это из-за желания платить больше за меньшую производительность.

Как всегда, все решают люди, ведь “жить в обществе и быть свободным от него — нельзя”. Возможная причина этого становятся более очевидной, если посмотреть на место команды в организации в целом. Исходя из нашего опыта, отдача от гиперпроизводительной команды очевидна не только менеджменту, она так же очевидна и для других команд. А вот это может породить (точнее, рано или поздно порождает) такие чувства как:

зависть (хочу делать Scrum, но “тупой” менеджмент не дает);

страх (уволят на следующем performance review, не доверят интересную работу);

ненависть (у них за три месяца получилось сделать то, с чем мы мучились три года).

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

Возвращаясь к зашедшему в тупик разговору. С точки зрения процессов и изменения требований на практике работает простой подход из двух шагов:

1. На бумаге фиксируем все, что фиксируется, под первую версию проекта или продукта;

2. Согласовываем с клиентом процесс внесения изменений — любой, который понятен обеим стороны и работает в текущих условиях.

И все

Ответ же на вопрос соискателям находится в Agile Manifesto: разница всего лишь в том, что является для команды более приоритетным. Даже если согласно модели корпоративного управления вам как менеджеру полагается делать нечто наподобие waterfall процесса, вряд ли что-то будет мешает вам ценить например живое взаимодействие с клиентом и получить у себя в команде «проворный водопад» (agile waterfall). Только вот если ваша команда будет слишком сильно выделяется в лучшую сторону относительно «среднего по больнице» показателя, рано или поздно вас «заменеджат».

А что вы думаете?