Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Было бы прекрасно, если бы все работало так, как вы ожидаете, до совершенства, от начала и до конца каждый раз. Этого не происходит в реальном мире. Одним из преимуществ scrum является то, что он не делает вид, что все всегда будет идеально. Скрам имеет встроенные проверки и противовесы, чтобы убедиться, что команда всегда адекватно реагирует на меняющиеся условия, и усиливает приемы схваток, чтобы убедиться, что они поддерживают свои цели.
Разрушения Скрама имеют тенденцию следовать знакомым шаблонам в организациях. Давайте посмотрим на некоторые из аспектов схватки, которые мы обсуждали, чтобы увидеть, где могут возникнуть проблемы и как их решить.
Неопределенные временные рамки
Когда команда начинает использовать scrum, они могут не понимать, сколько времени выделить на свои ритуалы. Определение временного интервала, в котором ритуал должен быть завершен, помогает сосредоточить внимание каждого и демонстрирует уважение к времени команды. У новых команд возникает соблазн, не зная, сколько времени выделить, чтобы оставить временной интервал неопределенным для различных аспектов ритуала.
Это особенно важно, когда команды начинают явно определять временные рамки для каждого аспекта ритуала. Иногда эти временные рамки могут быть просто предположениями, и команде нужно будет учиться, перебирая от спринта до спринта, сколько времени им нужно. Лучше предложить совершенно неправильный тайм-бокс и попытаться применить его, чем оставить его свободным. Упражнение по предложению и обеспечению соблюдения временных рамок демонстрирует уважение к времени команды и уважение к процессу.
Есть некоторые эксперты, которые рекомендуют сократить продолжительность временных рамок до минимально возможной, когда команды начинают последовательно превышать свои временные рамки, а затем тесно сотрудничать с командой, чтобы помочь им пройти все этапы каждого ритуала в течение очень ограниченного времени, которое были выделены. Это помогает установить важность определения и соблюдения временных рамок для каждого аспекта ритуала. И если команда на ретроспективе упоминает, что интервал времени был слишком коротким, он может быть расширен консенсусом для следующего спринта.
Оптимизация для спринтов
В конце многих ритуалов планирования наступает момент, когда команда соглашается на отставание в спринте. На этом этапе владелец продукта уже должен был упорядочить в порядке очередности оцененные истории и подумать, что могло бы принести ощутимый прирост для продукта в конце спринта.
По мере того, как предполагаемые истории переносятся в список заданий спринта, команда обсуждает, сколько работы, по их мнению, они могут выполнить за этот спринт. Зачастую последняя история, добавляемая в задел спринта, бывает недостаточно велика, чтобы довести команду до прогнозируемой скорости на основе их прошлых результатов. На этом этапе команда может попытаться договориться с владельцем продукта о порядке оставшихся историй, чтобы получить историю с оптимальным количеством очков, добавленных в список невыполненных спринтов, чтобы их приверженность точно соответствовала их ожидаемой скорости.
Это неразумное упражнение оптимизирует спринт и демонстрирует принципиальное недопонимание сути схватки. Приоритизация историй и цель работы с ними по порядку заключается в добавлении ценности к продукту, а не в продвижении повестки дня вокруг оптимизации скрам-процесса. Когда дело доходит до этого, работа важнее, а не количество очков, выполненных в спринте.
Лучше оставить это отставание спринта немного коротким и договориться с командой, что они могут начать работу над следующей историей с наивысшим приоритетом, как только будут закончены все истории, которые они посвятили этому спринту. После того, как обязательство по отложению спринта завершено, для команды совершенно нормально начать работу над историей любого размера, которая имеет следующий наивысший приоритет, даже если они не ожидают ее завершения в одном и том же спринте. В конечном счете, точечная скорость команды оценивается по нескольким спринтам, и она все усредняется.
Длинные, Ленивые Standups
Цель ежедневного застоя — захватить сердцебиение команды ради команды. Эти ритуалы коротки, чтобы уважать время каждого. Одна из первых ошибок, которую обычно совершают команды, — это относиться к ежедневному перерыву в работе так, как если бы это была командная встреча. Это может быть разыграно разными способами, включая сидение команды на ежедневной скамейке, планирование объявлений в начале тренировки и не ограничение перекрестных разговоров во время ожидания.
Ожидается, что все будут стоять во время ритуала, так что никто не склонен позволять ритуалу превышать свои временные рамки. Никакие устройства или другие отвлекающие факторы не должны находиться в чьих-либо руках, и никто не должен работать на своем ноутбуке или говорить о чем-либо, кроме обсуждаемой в настоящее время истории.
Это скользкий уклон, если вы начинаете позволять людям за пределами вашей команды включать объявления в начале или в конце заезда. Объявления, как правило, побуждают к дополнительным дискуссиям, и это может быстро привести к застою, который длится более 15 минут.
За один раз должен быть только один человек, и этот человек должен быть инженером, который обсуждает, что было сделано после предыдущего, что будет сделано в следующем, и есть ли какие-либо блокировщики. Будут возникать вопросы, которые требуют дальнейшего обсуждения, но это обсуждение необходимо отключить для последующего наблюдения после завершения подготовки. Каждый в команде должен почувствовать себя способным поддержать мастера схватки в прекращении других разговоров и сохранении сосредоточенности в стойке.
Перерывы в работе
Одной из предпосылок Scrum является то, что инженеры будут иметь возможность планировать заранее на время спринта, не беспокоясь о том, что их работа будет прервана отвлекающими и побочными проектами. Команда принимает участие в спринте, и каждый должен защищать его и не допускать дополнительной работы.
Реальность, особенно для команд веб-разработчиков и разработчиков мобильных приложений, заключается в том, что все происходит. Серверы отключаются. Особенности ломаются. Срочные объявления случаются. Пользователи запутываются в новых функциях, и их нужно настраивать. Необходимо решить неотложные проблемы, которые не ожидались, когда начался спринт.
В традиционной схватке любое изменение историй, внесенных в список заданий спринта, требует, чтобы команда прекратила спринт, прошла новый ритуал планирования и создала новое задание спринта. Это считается драконовской мерой, и было принято, чтобы отговорить кого-либо от нарушения целостности спринта.
Команды веб-разработчиков и разработчиков мобильных приложений должны учитывать определенную степень гибкости в своем процессе в связи с динамичным характером их работы. Было бы очень непрактично, если бы команде приходилось начинать новый спринт каждый раз, когда нужно было исправить поврежденную форму или отредактировать пресс-релиз. Но есть баланс, который нужно поддерживать. Было бы столь же неэффективно, если бы часть команды должна была отбросить все и начать работать над новой, неотложной функцией каждый раз, когда руководитель или клиент получал блестящую идею о новой функции.
По своей природе сетевая и мобильная работа заключается в том, что команда должна быть достаточно гибкой, чтобы справляться с чрезвычайными ситуациями, но они также должны быть строгими в отношении того, что представляет собой чрезвычайную ситуацию. Это то, что хозяин схватки, владелец продукта и команда должны явно определить как часть контракта команды на схватку.
Ожидается, что любая новая работа, запущенная в спринте, снизит скорость команды. Эта дополнительная работа не должна оцениваться, поскольку она не была частью обязательства команды по спринту. Если команда начнет регулярно допускать новые истории в спринт, это отвлечет их от обязательств по отставанию и отразится на их скорости.
Необходимо уделять время решению неотложных вопросов, понимая, что срочность — это концепция, с которой все члены команды должны согласиться. Если целостность спринта кажется нарушенной слишком регулярно или слишком случайно, это то, что команда должна обязательно обсудить во время ретроспективы.
Свободные демо
Каждая команда должна прийти с четким определением сделанного. Часть этого определения всегда должна включать в себя соответствие всем критериям приемлемости истории, как она была написана. Это проверено во время демонстрации. Важно быть последовательным в том, как истории принимаются на демонстрациях, и не допускать слишком гибких стандартов.
Общей проблемой, которая возникает, являются команды, которые позволяют принимать истории, когда критерии приемлемости не соблюдаются полностью. Иногда истории принимаются в виде спринта, но работа над ними затягивается в начале следующего спринта, потому что они были «почти завершены». Это путает конец одного спринта и начало следующего, усложняя процесс четко сказать, что было сделано в одном спринте, что нужно сделать в следующем, и какова реальная скорость команды.
Также очень важно, чтобы команды пришли на демонстрации, готовые продемонстрировать всю работу, которую они проделали в спринте. Часто команды сидят без дела, ожидая, пока разработчик завершит развертывание кода, или подгонят промежуточную среду для демонстрации. Хотя разумно ожидать, что иногда будут возникать непредвиденные ситуации, разработчик, который работал над историей, обязан убедиться, что она готова к демонстрации, и что владелец продукта знает, как пройти демонстрацию.
Некоторые команды придерживаются очень строгого подхода, не принимая никакой истории, которая не является точным выполнением всех критериев приемлемости и готова продемонстрировать в начале демонстрации. Хотя это может показаться суровым, важно помнить, что вхождение в спринт не так важно, как выполнение работы.
Команды могут быть такими же суровыми или такими же слабыми, как им нравится, в соответствии с критериями их демонстрации, если они последовательны. Нет ничего плохого в том, чтобы ошибиться на стороне серьезности и убедиться, что то, что было сделано в спринте, было выполнено в спринте. Важнейшая проблема — убедиться, что все согласны с процессом и понимают важность его следования.
Решение проблем во время ретроспективы
Без ретроспективы, Scrum не имеет возможности учиться на своих ошибках или извлекать выгоду из своих излишеств. Ретроспективы также служат сильной функции построения команды, поскольку они позволяют членам команды поделиться своим мнением с коллегами. В то время как наиболее распространенные проблемы, возникающие у групп с ретроспективами, вообще не удерживают их, следующей в списке будет попытаться решить проблемы, возникающие во время ретроспективы на самом ритуале.
Ретроспективы — это возможность для всех в команде рассказать о том, что, по их мнению, прошло хорошо или не очень хорошо во время предыдущей печати, и обсудить, как решать проблемы в будущем. Это касается потенциально деликатных тем и может вызвать много эмоций на поверхности. Для людей, которые считают, что могут быть на отрицательной стороне дискуссии, есть сильный импульс, чтобы попытаться решить проблему тут же.
- Некоторые проблемы могут включать в себя слишком много людей в комнате, и могут потребовать больше внимания, прежде чем каждый сможет согласиться с решением.
- Не всем будет удобно говорить открыто на ретроспективе о некоторых проблемах, которые могут быть деликатными, и которые могли бы быть лучше решены на небольших собраниях.
- Людям с более громким голосом или более сильным мнением также легко принимать участие в обсуждениях в больших группах, отвергая мнения, которые легче распознать в менее открытой форме.
- Кроме того, попытка решить проблему, которая не затрагивает всех в группе, является пустой тратой времени некоторых людей.
Мастер схватки должен напомнить всем, что ретроспектива — не повод для решения проблем, а скорее для признания того, что они существуют, и для последующего принятия решения для их решения во время предстоящего спринта.
Разумно позволить разговору вокруг проблемы продолжаться некоторое время, чтобы у людей была возможность полностью понять все стороны проблемы и взять на себя обязательство найти разумное решение во время спринта. Но если эта дискуссия слишком углубляется в детали того, как решить проблему, может быть, настало время прекратить дискуссии из уважения ко времени всех.
Резюме
В этой главе мы рассмотрели некоторые шаги, которые компания, возможно, захочет предпринять, когда она начнет внедрять scrum.
Мы говорили о том, чтобы получить бай-ин во всей организации, как из инженерных, так и внешних. Мы обсудили, как подготовить команду, и что должен делать тренер для команды. Мы говорили о кадровых вопросах и о том, как люди, которые уже работают в организации, могут адаптироваться, чтобы взять на себя функции финансового процесса. И мы говорили о важности отслеживания и измерения эффективности схваток. Мы также рассмотрели некоторые проблемы, которые могут возникнуть, когда команда привыкает к разборкам, и способы их решения.
В следующей главе мы снова свяжемся с людьми, с которыми встретились в Главе 2, теперь, когда они некоторое время работали в скрам-среде, и узнаем, насколько хорошо их проблемы были решены и как они Приспосабливаемся к схватке.