Закабалить: Скажите им: «Вы сможете помочь команде, исполняя роль прислуги сегодня. Готовьте кофе, делайте массаж, вынесите мусор, приготовьте обед: делайте всё, о чём вас может попросить команда». Вы будете удивлены, насколько быстро Джо и Лиза найдут для себя полезные технические задачи: o)
Если у вас есть человек, который часто заставляет вас заходить так далеко, возможно, вы должны отвести этого товарища в сторонку и культурно объяснить ему, что он не прав. Если и после этого проблема не решится, нужно понять, важен ли этот человек для команды или нет?
Если он не очень важен, постарайтесь исключить его из своей команды.
Если же он важен для команды, попробуйте найти ему напарника-«наставника». Джо может быть классным программистом и отличным архитектором, просто он предпочитает, чтобы ему другие люди говорили, что он должен делать. Отлично. Назначьте Никласа наставником Джо. Или будьте сами им. Если Джо действительно важен для команды, такой будет цена достижения цели. У нас были похожие ситуации, и этот подход более-менее срабатывал.
Как мы проводим демо
Демонстрация спринта — очень важная часть Scrum’а, которую многие все же недооценивают. «Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!» «У нас нет времени на подготовку разных &%$# демо!» «У меня куча работы, не хватало еще смотреть чужие демо!»
Почему мы настаиваем на том, чтобы каждый спринт заканчивался демонстрацией
Хорошо выполненное демо оказывает огромное воздействие, даже если оно не показалось захватывающим.
• Положительная оценка работы воодушевляет команду.
• Все остальные узнают, чем занимается ваша команда.
• На демо заинтересованные стороны обмениваются жизненно важными отзывами.
• Демо проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы. Это ценный опыт.
• Проведение демо заставляет команду действительно доделывать задачи и выпускать их (даже если это всего лишь на тестовый сервер). Без демо мы постоянно оказывались с кучей на 99 % сделанной работы. Проводя демо, мы можем получить меньше сделанных задач, но они будут действительно закончены, что (в нашем случае) намного лучше, чем куча функционала, который «типа» сделан и будет болтаться под ногами в следующем спринте.
Если команду заставлять проводить демо, когда у них ничего толком не работает, им будет не по себе. Команда будет запинаться и спотыкаться, показывая функциональность, и хорошо, если в конце вы услышите жиденькие аплодисменты. Людям будет жаль эту команду, а некоторых может даже разозлить то, что они только потеряли время на этом вшивом демо.
Это очень неприятно. Но это действует, как горькая пилюля. В следующем спринте команда действительно постарается все доделать! Они будут думать «ладно, может, в следующем спринте стоит показать всего две вещи вместо пяти, но, черт возьми, в этот раз они будут РАБОТАТЬ!». Команда знает, что демо придется проводить не смотря ни на что, и благодаря этому шансы увидеть там что-то пристойное значительно возрастают. Я несколько раз был этому свидетелем.
Памятка по подготовке и проведению демо
• Постарайтесь как можно более чётко озвучить цель данного спринта. Если на демо присутствуют люди, которые ничего не знают о вашем продукте, то не поленитесь уделить пару минут, чтобы ввести их в курс дела.
• Не тратьте много времени на подготовку демо, особенно на создание эффектной презентации. Выкиньте всё ненужное и сконцентрируйтесь на демонстрации только реально работающего кода.
• Следите, чтобы демо проходило в быстром темпе. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо.
• Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали. Сфокусируйтесь на том «что мы сделали», а не на том «как мы это делали».
• Если это возможно, дайте аудитории самой попробовать поиграть с продуктом.
• Не нужно показывать кучу исправлений мелких багов и элементарных фич. Вы можете упомянуть о них, но демонстрировать их не стоит, потому что это заберёт у вас много времени и снизит внимание к более важным историям.
Что делать с «недемонстрируемыми» вещами
Член команды: «Я не собираюсь демонстрировать эту задачу, потому что её невозможно продемонстрировать. Я говорю про историю 'Улучшить масштабируемость системы так, чтобы она могла обслуживать одновременно 10 000 пользователей'. Я, по-любому, не смогу пригласить на демо 10 000 пользователей».