Agile Scrum-разработка ... Это как потная магазин!

Да ладно, человек

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

Это действительно работа SweatShop?

Что ж, сначала давайте взглянем на определение SweatShop в Google:

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

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

«Фабрика или мастерская, особенно в швейной промышленности»

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

«Где работники физического труда работают долгое время за очень низкую заработную плату»

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

«В плохих условиях»

Мое сравнение с плохими условиями вращается вокруг нескольких вещей;

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

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

Давайте посмотрим на это немного подробнее.

Многие компании (не все) используют базовую методологию разработки на основе Agile Scrum, используя двухнедельный спринт или очень близкую его версию. Это то, что популярно, и, честно говоря, это то, что лучше всего служит компании и клиентам, но не обязательно разработчику и даже дизайнеру, тестировщику (QA) и т. Д.

Компания и заказчик очень довольны тем, что они производят быстрее. Очевидно, что компания зарабатывает больше денег, а клиенты быстрее получают новые функции и исправления ошибок.

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

Методологии разработки

До появления Waterfall, Kanban, Lean, Agile и любых других методологий разработки, о которых вы только можете подумать, компании выпускали программное обеспечение только несколько раз в год или даже один раз в год. Тем не менее, сроки были установлены, и некоторое давление все еще существовало, но весь процесс разработки можно было применить. У нас было много времени на проектирование / архитектуру, разработку / тестирование и т. Д.

Техническая задолженность (серьезная техническая задолженность) была менее распространена, ошибки, конечно, все еще были распространены, но похоже, что с логической точки зрения это было не так много, как с точки зрения контента или пользовательского интерфейса, сползание объема не было такой большой проблемой и, что наиболее важно, разработчики не чувствовал такого давления. Даже в те дни, в зависимости от того, где вы работали и от типа выполняемой работы, наверняка существовали настоящие котельные, нагруженные давлением. Примером может служить программирование игр. Я могу только представить себе, что это за индустрия сейчас.

Так в чем ваша точка зрения? Что мы делаем?

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

Дело в том, что распространенная сегодня итеративная разработка на основе Agile Scrum - это машина, которая никогда не останавливается. Даже если отбросить давление, которое он оказывает на разработчиков, и просто взглянуть на сам продукт, он производит продукты худшего качества. Scope Creep вызывает спагетти-код, отсутствие документации или плохая документация приводит к более медленному набору новых разработчиков, технический долг не учитывается до тех пор, пока что-то действительно не сломается, а тестирование передается клиентам / пользователям. Это неполноценный продукт, и все во имя скорости. Это то, что Agile означает для меня в данный момент - скорость.

Как я уже упоминал выше, нам все еще нужна методология или процесс. Я очень ценю аспекты гибкой и итеративной разработки. Например, мы должны иметь возможность выпускать готовое к производству программное обеспечение более двух или трех раз в год. Мы можем это сделать, но я думаю, что было бы немного больше смысла в том, что машину нужно выключать после каждого спринта, по крайней мере, для того, чтобы соответствовать тому, что есть у вашего обычного спринта. Например, если вы запустите обычный двухнедельный спринт, когда он закончится, машина отключится на один спринт. Или даже запустите два спринта, а затем выключите машину на один спринт. Дело в том, что у разработчиков будет время расслабиться, время правильно спланировать следующий спринт, время пересмотреть предыдущий спринт и, что не менее важно, как и все остальное, время решить любую серьезную техническую задолженность.

Подводя итог, это начинает затягиваться!

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

Как бы важен ни был заказчик / пользователь, нам нужно, чтобы компании сделали шаг назад и серьезно посмотрели на благополучие разработчиков. Хотя некоторые компании хотят относиться к отделу разработки программного обеспечения как к производственной линии, это не так.

Спасибо за прочтение. Я знаю, что существует множество разных мнений и опытов. Я не предполагаю, что каждый разработчик испытал на себе то, что я здесь представил, но я знаю, что есть много людей, которые испытали именно то, что я представил. Не стесняйтесь предлагать мнения и идеи в разделе комментариев.