Независимо от того, какой формат sprint backlog'a вы используете, пытайтесь вовлечь всю команду в поддержание sprint backlog'a в актуальном состоянии.

Недостатки этого подхода в том, что:

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

• Члены команды не в курсе состояния спринта, поскольку им не нужно заботиться о sprint backlog'e.

Допустим, Джо и Лиза не знают, чем сегодня заняться.

Если я выступаю в роли ScrumMaster'а, я просто передаю слово следующему. При этом беру на карандаш тех, кто не знает, чем ему заняться.

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

Если же нет, то я выясняю, есть ли возможность для парного программирования.

Хорошо выполненное демо оказывает огромное воздействие, даже если оно не показалось захватывающим.

• Положительная оценка работы воодушевляет команду.

• Все остальные узнают, чем занимается ваша команда.

• На демо заинтересованные стороны обмениваются жизненно важными отзывами.

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

• Проведение демо заставляет команду действительно доделывать задачи и выпускать их (даже если это всего лишь на тестовый сервер). Без демо мы постоянно оказывались с кучей на 99 % сделанной работы. Проводя демо, мы можем получить меньше сделанных задач, но они будут действительно закончены, что (в нашем случае) намного лучше, чем куча функционала, который «типа» сделан и будет болтаться под ногами в следующем спринте.

Наиболее важная вещь в отношении ретроспектив — это их проведение. И это самый подходящий момент для начала улучшений!

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

Основываясь на этом голосовании, мы выбираем 5 улучшений, которые мы попытаемся внедрить в следующем спринте,

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

Если ретроспектива проходит очень вяло, он [scrum master] должен быть готов задать простой, но меткий вопрос, который подтолкнёт людей на дискуссию.

Например: «Если бы можно было повернуть время вспять и переделать этот спринт с самого первого дня, чтобы вы сделали по-другому?».

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

как и при планировании спринта, колонка «как продемонстрировать» — отличное средство, чтобы избежать недопонимания.

Scrum решает вопросы управления и организации, тогда как XP специализируется на инженерных практиках.

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

TDD — это непросто, но что действительно сложно, так это пытаться применять TDD для кода, который изначально не был спроектирован для применения этого подхода!

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

сделайте всё для облегчения процесса ручного тестирования. А уже после этого можно подумать и про автоматизацию.

Кроме того, что тестировщик — обычный член команды, он ещё и выполняет очень важную функцию. Он — человек, за которым всегда «последнее слово». Ничто не может считаться готовым в спринте, пока он не подтвердит, что это действительно так.

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

Разбиение на команды — это действительно одна из самых сложных задач в Scrum'е. Не пытайтесь копать очень глубоко или заниматься очень сложной оптимизацией.

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

Мы решили проблему вводом роли «тимлид». Человека в этой роли можно описать как «Scrum-of-Scrums master», «босс» или «главный ScrumMaster». Ему не нужно возглавлять какую-либо команду, но он отвечает за вопросы, не входящие в компетенцию команд, такие как, например, «кого назначить ScrumMaster'ом», «как распределить людей по командам» и т. д.

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

наличие в Scrum-команде участников с частичной занятостью — не очень хорошая идея.

Scrum-of-scrums — это регулярные встречи, цель которых — обсуждение различных вопросов между Scrum-мастерами.

На самом деле повестка дня Scrum-of-Scrums не так уж и важна — важнее, чтобы эта встреча проводилась регулярно.

Задачей Scrum-команды (с благословления Product owner’а) была стабилизация системы и предотвращение потенциальных пожаров. А «пожарная» команда (её мы назвали «командой поддержки») выполняла две задачи:

1. Тушить пожары.

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

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

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

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

И всё-таки, мы стараемся делать так, чтобы большую часть времени команда проводила вместе.