Scrum в древнем Египте и сейчас

История Agile берет свое начало в ферале 2001 года, когда был опубликован документ под названием Agile Manifesto. Текст документа состоит из очевидных философских формул (простота – искусство не делать лишнюю работу) и ряда спорных утверждений (лучшие технические требования, дизайн, архитектура получаются у самоорганизованных команд). Документ является странным не только содержанием, но и последовавшими изменениями в области разработки программного обеспечения. В кратчайшие сроки на его основе были построены методики “гибкой” методологии разработчки, которые начали свой путь по всему миру захватывая Исполнителей и Заказчиков. Адепты преподносят манифест как “серебряную пулю” от всех проблем. В особо крайних случаях простому программисту стыдно признаться на публике, что он работает в компании с традиционной методологией разработки (водопад). В этой статье я предлагаю вам рассмотреть и разобрать вместе со мной причины и следствия этого явления, на примере самого распространенного фреймворка – SCRUM.

Для начала давайте постараемся понять, что же нового скрывается под красивой оберткой Agile и в частности Scrum.

Scrum древнего Египта

Гибкие методологии существовали и до публикации манифеста Agile, просто тогда они так не назывались. Они вообще не имели какого-либо отдельного названия, а были естественным эффективным способом вести руководителям того времени внутренние проекты (ключевое слово – внутренние).

Раз мы говорим о древнем Египте, то в качестве примера проекта возьмем строительство пирамиды. Итак, древнеегипетский фароан решил, что пора ему обзавестись собственной пирамидой (product). Он начинает обсуждение идеи проекта со жрецами (stakeholders) и назначает своего виночерпия ответственным за проект (product owner). Виночерпий находит толкового каменщика (scrum master). Каменщик в свою очередь начинаем подбор помощников (scrum team), которые отправляются на невольничий рынок и набирают рабов (scrum tools: ПК, сервера, софт и т.д.).

Фараон приказывает чтобы ежемесячно ему подавали отчеты о ходе строительства и каменщик с помошниками каждый месяц проводит показ стройки (demo) для виночерпия. Тот в свою очередь на основании увиденного делает доклад фараону. Во время показа каменщик и виночерпий обсуждают уже выполненный объем строительства (retrospective), и обсуждают работы на следующий месяц (sprint). Вместе с этим виночерпий регулярно общается со жрецами касательно их требований (user stories), которые чтобы не забыть записывает на отдельно заведенных свитках пергамента (backlog) из которого он и берет информацию для обсуждения будущих работ с каменщиком. Ну и так далее. Вникать глубже в то как тогда выглядели стикеры, скрам-доска и burndown-диаграммы мы не будем. Любой грамотный специалист подбирает себе наиболее удобные для него инструменты чтобы контролировать и управлять проектом, и проводить аналогии с инструментарием того времени в нашем случае не имеет смысла. Излишние детали (привет, манифет гибких методологий) не важны, посколько уже сейчас видно, что методика работала уже в те времена.

Это дает возможность предположить, что во все времена грамотные руководители использовали гибкую методологию при реализации внутренних проектов, потому что:

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

Но к внешнему Заказчику неприменим ни один из пунктов этого списка, поэтому для заказной работы гибкие методики не использовались. Ведь народ в то время был простым и нетолерантным, за превышение срока могли вполне лишить головы.

Scrum сегодня

Единственная новизна которую Scrum обрел в наши дни является факт его использования для реализации внешних (заказных) проектов. Это сторону истории фреймворка стараются не освящать, ведь тогда если кто-либо захочет потянуть за ниточку, то откроется истинная мотивация участников рынка собравшихся в феврале 2001 года для составления пресловутого манифеста. По своей сути манифест и вся аргументация выбора Scrum, чистой воды пропаганда интереса Исполнителя, завуалированная под борьбу добра со злом, в которой в качестве зла выступает Заказчик. Гениальность решения которое предлагают гибкие методики – убедить Заказчика пожертвовать результатом ради процесса.

Что же происходит если product owner является сотрудником сторонней компании? Во-первых, конечный результат и процесс его достижения оказываются в разных руках. Во-вторых теперь появляется вторая заинтересованная сторона процесса со своим коммерческим интересом. В довершении всего Заказчику важен результат, а Исполнителю – процесс (ведь когда процесс окончится прекратиться поступление финансов). И с этим ничего не поделаешь, так как здесь срабатывает еще одна философская формула – “Ничего личного, только бизнес”.

Agile выгоден игрокам на рынке со стороны Исполнителей, поскольку позволяет им:

• зарабатывать на процессе без ответственности за результат;
• сократить расходы на грамотных управленцев (зачем платить дорогим внутренним специалистам, если манифест позволяет использовать для этого Заказчика);

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

Представим себе как бы выглядел процесс постройки пирамиды для современного фараона. Виночерпий приступает к поиску бригады каменщиков и пытается получить сроки и стоимость строительства, но бригадир ему заявляет:

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

Здравомыслящий человек хоть немного разбирающийся в проектировании или планировании чего-либо вряд-ли с легкостью согласится на это. Но ИТ-Заказчики соглашаются, что логично, ведь они падают под давлением компетентных Исполнителей, которые умными словами заявляют “вы попали на бабки”.

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

Последствия поклонению Agile

Качество программных продуктов обратно пропорционально широте распространения Agile в ИТ-отрасли. Откуда может появиться качество, если процесс разработки заточен на решение задачи самым простым, быстрым и дешевым способом из возможных, а планировать на перед официально запрещено методологией!

В результате мы получаем программые продукты похожие на “лоскутные одеяла”, в которых разделы одного и того же ПО сделаны совершенно разными людьми. На одном программном экране происходит смешение нескольких стилей оформления, различные подходы к эргономике, и вишенкой на торте разные алгоритмы работы аналогичных элементов. А это и логично, ведь ТЗ на продукт нет, и каждый делает кому как привычно и удобно, а преподносимый персонал тестировщиков зажат жесткими рамками сроков спринтов.

Зачем это все написано?

Вышеизложенное может заставить думать, что я являюсь заклятым противником Agile. Однако это не так. Как говорил Парацельс “Всё есть яд, и ничто не лишено ядовитости; только количество делает делает вещество неядовитым.”.

Гибкие методологии пригодны для внутренних малых и средних проектов. Размер проекта ограничивается только способностью конкретного руководителя “видеть лес среди деревьев”, то есть умением держать в уме: все подробности работы, желаемый результат, систематизируя это.

Гибкие методологии ограничены в применении для внешних проектов. В этом случае к Заказчику должны применяться те же требования которые выдвигаются к внутреннему руководителю проекта. То есть Заказчик должен быть ИТ-профессионалом, а не секретарем выполняющим эту работу по-совместительству. Он должен быть в состоянии проверить квалификацию нанятой команды и постоянно контролировать качество разрабатываемого продукта. Кроме того, сам разрабатываемый продукт должен позволять замену команды разработчиков. Только так можно рассчитывать, что не будет обидно за потраченные силы.

У Agile-методологий есть место под солнцем, но оно сильно ограничено в сфере контрактных ИТ-разработок. Но что делать если ваш проект не попадает в категорию Agile-пригодных?

Занимательный факт, гибкие разработки не прижились нигде кроме контрактных разработок ПО. По Scrum не строятся космические карабли, ракеты и самолеты, даже автомобили. Мудрость наших предков дает нам знание, что даже скворечник нельзя сделать без проектирования (пускай даже карандашного наброска с указанием размеров) и подготовки ТЗ (пусть это будет просто перечень инструментов и материалов). Все что вы видите вокруг себя создается благодаря старому проверенному “водопаду”. Так почему бы и вам не использовать его? Вы не поверите, но все будет хорошо.

Вместо заключения

Вышеизложенное является следствием моих наблюдений за все 10 лет работы в области контрактной веб-разработки с использованием как традиционного подхода так и прогрессивного. Мотивацией для написания этой статьи послужило переполнение чувств при получении в свои руки проект сделанный следуя заветам доктора Франкенштейна.

Применяйте методологии разработки, как и лекарства – по их назначению)