Рассмотрим следующий процесс:

сбор требований → анализ → дизайн → выработка тест протокола → определение тестовых данных → кодирование → приемка → эксплуатация → поддержка.

О чем мы говорим – об 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).

Только вот если ваша команда будет слишком сильно выделяется в лучшую сторону относительно «среднего по больнице» показателя, рано или поздно вас «заменеджат». А что вы думаете?