Разработка

Scrum подвел разработчиков

Но это не повод отказываться от него

Опубликовано

2 года назад

30.08.2022

Автор:

AppTractor

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

Scrum (и Agile в целом) обещал раскрепостить разработчиков. Предполагалось, что это будет новый способ работы, который порвет с традиционными подходами к доставке. Это было признанием того, что разработка программного обеспечения — это не то же самое, что строительство дома или автомобиля. Что она требует совсем другого подхода.

Но в наши дни многие разработчики ненавидят Scrum. Очень легко найти статьи о людях, которые пострадали из-за того, что они являются частью Scrum команды.

Как это может быть? Как Agile-фреймворк, такой как Scrum, может быть настолько вредным для стольких людей? Давайте поймем это вместе.

Содержание

Хорошие намерения

Scrum был одним из подходов, которые привели к Манифесту Agile. И всем обещания, которые он принес с собой. С такими принципами, как:

«Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им», — 5-й принцип Agile-манифеста

А также:

«Гибкие процессы способствуют устойчивому развитию. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно», — 8-й принцип Agile Manifesto

Но и:

«Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта», — 9-й принцип Agile-манифеста

А также:

«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд», — 11-й принцип Agile-манифеста

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

Суровая реальность

Перемотаем на 20+ лет вперед.

Agile сегодня везде. Он здесь, чтобы остаться. Подавляющее большинство разработчиков программного обеспечения работали с гибкими подходами. Большинство из них сталкивалось со Scrum. И многие из них презирают Scrum до глубины души.

Как это может быть?

Это длинная история. Я мог бы написать книгу об этом. На самом деле, я, возможно, уже сделал это. Потому что большинство статей, которые я написал за последние 4 года, посвящены ужасным реализациям Scrum, реальным причинам использования Scrum, тому, как правильно использовать Scrum, чтобы добиться успеха, и тому, как каждый в компании должен быть вовлечен в процесс.

Винтики в машине доставки

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

Он использовался как простой инструмент доставки. Как один из винтиков в машине доставки товаров — программного обеспечения — клиентам.

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

Неправильное использование Scrum

А между тем пострадали многие разработчики. Потому что люди с властью злоупотребляли Scrum, чтобы усилить давление на разработчиков. Давление на доставку в соответствии с планом в каждом спринте. Каждые две недели вам нужна переработка, чтобы убедиться, что спринт соответствует внешним ожиданиям. В старые добрые времена водопадных проектов командам приходилось сталкиваться с этим гораздо реже, в основном в конце проекта. В наши дни многие разработчики испытывают постоянное давление.

Для большинства команд цель стабильного темпа — иллюзия. Но другие принципы Манифеста Agile, которые я только что обсуждал, также давят на них. Как сохранить высокую мотивацию, когда вы находитесь в постоянном напряжении? Как поддерживать техническое совершенство, когда вам нужно все сделать «ПРЯМО СЕЙЧАС»? Как быть самоорганизующейся командой, когда все, на чем вам нужно сосредоточиться, — это все более быстрая доставка?

Некоторые из вас могут сейчас кивнуть в знак согласия. Другие могут не согласиться. Потому что то, что я описал, не имеет ничего общего с истинной природой и намерениями Scrum. Scrum — это открытие через доставку. Открытие является ключевым. Скрам-мастера должны следить за тем, чтобы Скрам использовался так, как предполагалось, помогая людям в команде и за ее пределами понять фреймворк.

Уровни неправильного использования Scrum

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

У других может быть автономия для работы в полноценной самоуправляемой Скрам-команде, которая принимает решения и имеет право сдерживать нежелательное внешнее давление. Это Agile-островки в преимущественно традиционной компании. Как только им приходится устранять препятствия, находящиеся за пределами их влияния, они заходят в тупик. Потому что компания не хочет меняться. Это ситуация, которую я видел чаще.

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

Скраму почти тридцать лет. Agile-манифесту уже более двадцати лет. Scrum и Agile везде. Но в основном они используются неправильно.

Люди страдают из-за Scrum. Вернее, неправильного использования Scrum. Это ужасная ситуация, в которой мы находимся.

Должны ли мы отказаться от Scrum?

Итак, Scrum подвел многих разработчиков. Он не сделал того, что было обещано. По общему признанию, это во многом связано с тем, что Scrum был неправильно понят. Но имеет ли это значение, в конце концов, неправильно ли Scrum понят или нет?

Что происходит, когда команды отказываются от Scrum? Существуют ли другие подходы или схемы, которые могут использовать команды, которые избавили бы их от проблем внешнего давления и искусственных сроков? Является ли Канбан ответом на это? SAFe, возможно?

Боюсь, что нет.

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

Настоящий путь вперед

Вместо того, чтобы отказываться от Scrum, можно сделать другое. Окружающая среда разработчиков и их команды должна получить понимание и оценку Scrum, как это всегда предполагалось. Они должны узнать, почему существует Scrum и какие проблемы он призван решить.

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

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

Только когда вы убедитесь, что заинтересованные стороны Scrum-команд понимают свою роль и выполняют ее, вы позволите командам извлечь максимум из Scrum. Что выгодно всем.

Это подводит меня к последнему пункту. Ответственность скрам-мастеров в этом вопросе часто упускается из виду, но очень важна. Они должны помочь Скрам-командам и их заинтересованным сторонам в этом путешествии:

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

А также

«Устранить барьеры между заинтересованными сторонами и Scrum-командами», — Руководство по скраму 2020.

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