Мнение

Скрам без магии

Когда команда решает применить Agile, и в частности Scrum, слишком часто у них бывает такое отношение - что после выполнения всех магических ритуалов все волшебным образом сработает. Тогда этого не происходит.

Это правда, что Scrum иногда напоминает культ.

Даже встречи удобно называть «церемониями», как будто в Scrum нет встреч, а вместо этого есть магические ритуалы. А бесчисленные коучи и консультанты по Скраму выглядят и говорят как культисты.

Когда команда решает применить Agile и, в частности, Scrum, слишком часто у них возникает такое отношение - когда они выполнят все магические ритуалы, все волшебным образом заработает. Все проблемы исчезнут. И если они будут продолжать повторять заклинания, производительность также взлетит до небес.

Тогда этого не происходит. Люди разочаровываются и разочаровываются. Они идут и пишут бесчисленное количество статей в Интернете, утверждая, что Scrum - это мошенничество и просто не работает.

Что ж, Scrum - это не волшебство. Несмотря на все устрашающие слова и очаровательных тренеров, сам Скрам не имеет силы. Самостоятельно он не может решить никаких проблем.

Ну и что?

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

Существует целая вселенная Scrum: миллионы статей, курсов и книг, тысячи выступлений, сертификатов и инструкторов. Так много слов - но так мало действий.

Фреймворк

Давайте поговорим, как инженеры. Scrum не зря называют «фреймворком». Как и многие другие фреймворки, он не дает вам кода для решения вашей проблемы, он только дает вам структуру. Тогда ваша задача - как Скрам-мастера, руководителя группы или инженера - заполнить пробелы.

Как вы пишете этот код? У меня есть идея. Многим это может показаться странным, но вот оно: вместо всех разговоров делайте что-нибудь. На самом деле не имеет значения, как вы назовете то или иное, или насколько прекрасна ваша Burndown Chart. Важно то, дает ли ваш ввод правильный результат.

Спринт как функция

Ввод: задачи.

Вывод: Итерация.

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

Каждый спринт должен начинаться с пустой страницы. Хорошая функция идемпотентна.

Кроме того, Sprint не является метрическим инструментом для менеджера. Спринт измеряется только результатами, его результатом.

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

Если ваша работа не является итеративной - возможно, вы решаете только несортированные ошибки или строите сателлит, - вам не следует пытаться разделить процесс на спринты.

«Церемонии» как функции

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

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

Важность времени

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

Если ваш Scrum состоит из ритуалов, это имитация - никого не должно удивлять, когда люди начинают жаловаться, что это не работает.

Встаньте

Исходные данные: отчеты членов команды

Результат: План на день

О стендапах написаны миллионы слов. Обычно они сосредотачиваются на «людской» стороне вещей - отчитываются друг перед другом, не отвлекаются, придерживаются установленных временных рамок. Все эти пункты действительны. Но почему именно мы это делаем? Итак, «все знают, что делают». Но почему?

Они должны знать, чтобы планировать свой день.

Уточнение отставания

Ввод: Требования

Вывод: Четко определенные задачи, все записано

Уточнение бэклога берет необработанные требования и преобразует их в четко определенные задачи.

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

Если Уточнение непродуктивно, оно сделает непродуктивным Планирование.

Кроме того, Planning Poker - это не просто скучная игра. «Как» не важно. Важно то, что вы можете быстро коллективно решить, насколько сложна задача.

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

Планирование спринта

Исходные данные: Четко определенные приоритетные задачи.

Результат: План спринта.

Планирование спринта берет то, что было произведено уточнением бэклога, разделяет его и преобразует в спринт.

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

Ретроспектива

Исходные данные: мысли членов команды о спринте

Результат: Список действий для реализации

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

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

Ретроспектива должна собирать мнение каждого о рабочем процессе и составлять список действий. И тогда эти действия нужно предпринять.

Если ретроспектива не принесла никаких улучшений, это кажется пустой тратой времени.

Демо

Демо-версия Sprint существует, чтобы убедиться, что вы создали итерацию. Если вам нечего демонстрировать, может, это был не спринт?

Круг

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

… Улучшения - ›Уточнение бэклога -› Бэклог - ›Планирование спринта -› Спринт - ›Стендап -› - ›Демо -› Ретроспектива - ›Улучшения…

На самом деле это конвейер данных.

Правильная структура

Скрам не создает процесс для команды. В качестве основы он может только помочь со структурой. Писать «код» лежит в команде.

Чтобы это работало, нам не нужно заботиться о том, чтобы оставаться крутыми или делать что-то правильно. Мы должны заботиться о результатах.

Хотя много говорят о том, как круто и весело быть гибким, Agile действительно о дисциплине. Он был создан как платформа для навигации в хаосе постоянно меняющихся требований.

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

И да, иногда Скрам просто не лучший выбор для команды.