В Древнем Египте нервно посмеялись бы: почему по Scrum разрабатывают софт, но не строят ракеты и даже автомобили

История Agile берет свое начало в феврале 2001 года, когда был опубликован документ под названием Agile Manifesto. Текст документа состоит из очевидных философских формул («простота — искусство не делать лишнюю работу») и ряда спорных утверждений (лучшие технические требования, дизайн и архитектура получаются у самоорганизованных команд).

Документ странен не только содержанием, но и последовавшими изменениями в области разработки программного обеспечения. В кратчайшие сроки на его основе построили методики «гибкой» методологии разработки, которые начали свой путь по всему миру, захватывая исполнителей и заказчиков.

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

Я предлагаю вам рассмотреть и разобрать вместе со мной причины и следствия этого на примере самого распространенного фреймворка — Scrum. Для начала давайте постараемся понять, что же нового скрывается под красивой оберткой.

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

Scrum в Древнем Египте

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

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

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

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

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

• достаточно компетентны для проектирования конечного результата;
• достаточно компетентны для контроля процесса реализации;
Онлайн-курс "Предметний дизайн" від Skvot.
Навчіться створювати функціональні, трендові та ергономічні дизайни меблів та предметів інтер’єру.
Детальніше про програму курсу і лекторів
• имеют достаточно власти над участниками процесса;
• соотношения срока, стоимости и качества не являются догмой и могут пересматриваться при необходимости;
• и самое главное — конечный результат и процесс, к нему приводящий, находятся в одних руках и преследуют один интерес.

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

Scrum сегодня

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

По своей сути, манифест и вся аргументация выбора Scrum — чистой воды пропаганда интереса Исполнителя, завуалированная под борьбу добра со злом, в которой в качестве зла выступает Заказчик. Гениальность решения, которое предлагают гибкие методики, — убедить Заказчика пожертвовать результатом ради процесса.

Исполнитель — добро, Заказчик — зло. Scrum на стороне добра

Что же происходит, если product owner является сотрудником сторонней компании? Во-первых, конечный результат и процесс его достижения оказываются в разных руках. Во-вторых, теперь появляется вторая заинтересованная сторона процесса со своим коммерческим интересом.

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

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

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

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

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

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

Здравомыслящий человек, хоть немного разбирающийся в проектировании или планировании чего-либо, вряд ли с легкостью согласится на это. Но IT-заказчики соглашаются, что логично, — ведь они падают под давлением компетентных исполнителей, которые умными словами заявляют: «вы попали на бабки».

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

Древнеегипетский фараон узнал, как сейчас применяют Scrum

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

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

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

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

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

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

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

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

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

Занимательный факт: гибкие разработки не прижились нигде, кроме контрактных разработок ПО. По Scrum не строятся космические корабли, ракеты и самолеты, даже автомобили.

Космонавт против Scrum

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

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

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

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