X Driven Development, Часть 3: Agile Waterfall, корпоративный Анти-Scrum

Рассмотрим следующий процесс: сбор требований → анализ → дизайн → выработка тест протокола → определение тестовых данных → кодирование → приемка → эксплуатация → поддержка. О чем мы говорим – об 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). Только вот если ваша команда будет слишком сильно выделяется в лучшую сторону относительно «среднего по больнице» показателя, рано или поздно вас «заменеджат». А что вы думаете?
RSS-материал подписаться на рассылку

Опрос

Какой тренинг Вам наиболее интересен?:
 

Яндекс.Метрика