Scrum и xp заметки с передовой
 Скачать 3.07 Mb.
|
|
ScrumMaster: "Так, и кто хочет продемонстрировать нам готовую бета-версию?" (предполагая, что выпуск бета-версии – цель спринта) Команда: недоумевающая тишина ScrumMaster: "Мы что – не готовы?" Команда: "ммм... нет". ScrumMaster: "Почему? Что ещё осталось незаконченным?" Команда: "Так у нас даже нет тестового сервера. Кроме того нужно починить билд-скрипт". ScrumMaster: "Ага" (наклеивает два новых стикера). "Джо и Лиза, вам всё еще нечем заняться сегодня?" Джо: "Хм... Думаю, что я попробую раздобыть тестовый сервер". Лиза: "... а я постараюсь починить билд-скрипт." Если повезёт, кто-то действительно сможет продемонстрировать готовый к выпуску бета-версии релиз. Отлично! Цель спринта достигнута. Но что делать, если прошла только половина времени, отведённая на спринт. Всё просто. Поздравьте команду за отличную работу, возьмите одну-две истории из стопки "Следующие" и поместите их в колонку "В планах". После этого повторно проведите ежедневный Scrum. Уведомите product owner'а о том, что вы добавили несколько новых историй в спринт. Что же делать, если команда не достигла цели спринта, а Джо с Лизой всё ещё не могут определиться с тем, какую пользу они могут принести? Я обычно пользуюсь одной из нижеперечисленных методик (все они не очень хорошие, но всё же это последнее средство): • Пристыдить: "Ладно, если не знаешь, как принести пользу команде, иди домой, почитай книгу и т.д. Или просто сиди здесь, пока кому-то не потребуется твоя помощь". • По старинке: Просто назначить им задачу. • Моральное давление: Скажите им: "Джо и Лиза! Не смею вас больше задерживать. А мы все просто постоим тут, пока у вас не появятся идеи, как помочь нам в достижении цели". • Закабалить: Скажите им: "Вы сможете помочь команде, исполняя роль прислуги сегодня. Готовьте кофе, делайте массаж, вынесите мусор, приготовьте обед: делайте всё, о чём вас может попросить Scrum и XP: заметки с передовой 47 команда". Вы будете удивлены, насколько быстро Джо и Лиза найдут для себя полезные технические задачи :o) Если у вас есть человек, который часто заставляет вас заходить так далеко, возможно, вы должны отвести этого товарища в сторонку и культурно объяснить ему, что он не прав. Если и после этого проблема не решится, нужно понять, важен ли этот человек для команды или нет? Если он не очень важен, постарайтесь исключить его из своей команды. Если же он важен для команды, попробуйте найти ему напарника-"наставника". Джо может быть классным программистом и отличным архитектором, просто он предпочитает, чтобы ему другие люди говорили, что он должен делать. Отлично. Назначьте Никласа наставником Джо. Или будьте сами им. Если Джо действительно важен для команды, такой будет цена достижения цели. У нас были похожие ситуации, и этот подход более-менее срабатывал. Scrum и XP: заметки с передовой 48 9 Как мы проводим демо Демонстрация спринта – очень важная часть Scrum'а, которую многие все же недооценивают. "Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!" "У нас нет времени на подготовку разных &%$# демо!" "У меня куча работы, не хватало еще смотреть чужие демо!" Почему мы настаиваем на том, чтобы каждый спринт заканчивался демонстрацией Хорошо выполненное демо оказывает огромное воздействие, даже если оно не показалось захватывающим. • Положительная оценка работы воодушевляет команду. • Все остальные узнают, чем занимается ваша команда. • На демо заинтересованные стороны обмениваются жизненно важными отзывами. • Демо проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы. Это ценный опыт. • Проведение демо заставляет команду действительно доделывать задачи и выпускать их (даже если это всего лишь на тестовый сервер). Без демо мы постоянно оказывались с кучей на 99% сделанной работы. Проводя демо, мы можем получить меньше сделанных задач, но они будут действительно закончены, что (в нашем случае) намного лучше, чем куча функционала, который "типа" сделан и будет болтаться под ногами в следующем спринте. Если команду заставлять проводить демо, когда у них ничего толком не работает, им будет не по себе. Команда будет запинаться и спотыкаться, показывая функциональность, и хорошо, если в конце вы услышите жиденькие аплодисменты. Людям будет жаль эту команду, а некоторых может даже разозлить то, что они только потеряли время на этом вшивом демо. Это очень неприятно. Но это действует, как горькая пилюля. В следующем спринте команда действительно постарается все доделать! Они будут думать "ладно, может, в следующем спринте стоит показать всего две вещи вместо пяти, но, черт возьми, в этот раз они будут РАБОТАТЬ!". Команда знает, что демо придется проводить не смотря ни на что, и благодаря этому шансы увидеть там что-то пристойное значительно возрастают. Я несколько раз был этому свидетелем. Памятка по подготовке и проведению демо • Постарайтесь как можно более чётко озвучить цель данного спринта. Если на демо присутствуют люди, которые ничего не знают о вашем продукте, то не поленитесь уделить пару минут, чтобы ввести их в курс дела. • Не тратьте много времени на подготовку демо, особенно на создание эффектной презентации. Выкиньте всё ненужное и сконцентрируйтесь на демонстрации только реально работающего кода. • Следите, чтобы демо проходило в быстром темпе. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо. Scrum и XP: заметки с передовой 49 • Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали. Сфокусируйтесь на том "что мы сделали", а не на том "как мы это делали". • Если это возможно, дайте аудитории самой попробовать поиграть с продуктом. • Не нужно показывать кучу исправлений мелких багов и элементарных фич. Вы можете упомянуть о них, но демонстрировать их не стоит, потому что это заберёт у вас много времени и снизит внимание к более важным историям. Что делать с "недемонстрируемыми" вещами Член команды: "Я не собираюсь демонстрировать эту задачу, потому что её невозможно продемонстрировать. Я говорю про историю 'Улучшить масштабируемость системы так, чтобы она могла обслуживать одновременно 10 000 пользователей'. Я, по-любому, не смогу пригласить на демо 10 000 пользователей". ScrumMaster: "Так, ты закончил с этой задачей?" Член команды: "Ну, конечно". ScrumMaster: "А как ты узнал, что оно потянет?" Член команды: "Я сконфигурировал нашу систему в среде, предназначенной для тестирования производительности, и нагрузил систему одновременными запросами с восьми серверов сразу”. ScrumMaster: "Так у тебя есть данные, которые подтверждают, что система может обслужить 10 000 пользователей?" Член команды: "Да. Хоть тестовые сервера и слабенькие, однако, в ходе тестирирования они всё равно справились с 50 000 одновременных запросов". ScrumMaster: "Так, а откуда у тебя эта цифра?" Член команды (расстроенный): "Ну, хорошо, у меня есть отчёт! Ты можешь сам глянуть на него, там описано как всё это дело было сконфигурировано и сколько запросов было отослано!" ScrumMaster: "О, отлично. Это и есть твоё "демо". Просто покажи этот отчёт аудитории и вкратце пробегись по нему. Всё же лучше, чем ничего, правда?" Член команды: "А что, этого достаточно? Правда он выглядит как-то корявенько, надо бы его немножко шлифануть". ScrumMaster: “Хорошо, только не трать на это слишком много времени. Он не обязан быть красивым, главное – информативным”. Scrum и XP: заметки с передовой 50 10 Как мы проводим ретроспективы Почему мы настаиваем на том, чтобы все команды проводили ретроспективы Наиболее важная вещь в отношении ретроспектив – это их проведение. По некоторым причинам команды не проявляют должного интереса к проведению ретроспектив. Без небольшого давления со стороны многие команды часто пропускают ретроспективу и сразу переходят к следующему спринту. Может быть, это особенность шведского менталитета, в чём я не уверен. Хотя при этом все вроде соглашаются, что ретроспективы крайне полезны. Я бы даже сказал, что ретроспектива является вторым по значимости мероприятием в Scrum'e (первое – это планирование спринта), потому что это самый подходящий момент для начала улучшений! Конечно, чтобы возникла хорошая идея, вам не нужна ретроспектива, она может прийти к вам в голову, когда вы дома в душевой кабинке! Но поддержит ли команда вашу идею? Может быть, но вероятность значительно выше, если идея рождается внутри команды, то есть, во время ретроспективы, когда каждый может сделать свой вклад в обсуждение идеи. Без ретроспектив вы обнаружите, что команда наступает на одни и те же грабли снова и снова. Как мы проводим ретроспективы Хотя основной формат немного варьируется, но в основном мы делаем так: • Выделяем 1-3 часа, в зависимости от того насколько долгая ожидается дискуссия. • Участвуют: product owner, вся команда и я собственной персоной. • Располагаемся либо в отдельной комнате с уютным мягким уголком, либо на террасе, либо в каком-то другом похожем месте, поскольку нам нравится вести дискуссию в спокойной и непринуждённой атмосфере. • Зачастую мы стараемся не проводить ретроспективы в рабочей комнате, так как это рассеивает внимание участников. • Выбираем кого-то в качестве секретаря. • ScrumMaster показывает sprint backlog и при участии команды подводит итоги спринта. Важные события, выводы и т.д. • Начинаем "серию" обсуждений. В этот момент каждый имеет шанс высказаться о том, что, по его мнению, было хорошего, что можно было бы улучшить и что бы он сделал по-другому в следующем спринте. При этом его никто не перебивает. • Мы сравниваем прогнозируемую и реальную производительность. Если имеются существенные расхождения, то пытаемся проанализировать и понять, почему так получилось. • Когда время подходит к концу, ScrumMaster пытается обобщить все конкретные предложения по поводу того, что мы можем улучшить в следующем спринте. Вообще-то, наши ретроспективы не имеют чёткого плана проведения, но главная тема – всегда одна и та же: "Что мы можем улучшить в следующем спринте". Scrum и XP: заметки с передовой 51 Вот вам пример доски с нашей последней ретроспективы: У нас есть три колонки: • Хорошо: Если нужно было бы повторить этот спринт ещё раз, то мы бы сделали это точно так же. • Могло бы быть и лучше: Если нужно было бы повторить этот спринт ещё раз, то мы бы сделали это по-другому. • Улучшения: Конкретные идеи о том, как в будущем можно что-то улучшить. Таким образом, первая и вторая колонки относится к прошлому, тогда как третья – направлена в будущее. После того как команда закончил свой мозговой штурм по поводу всех этих стикеров, они проводят "точечное голосование" для определения улучшений, которым следует уделить особое внимание в ходе следующего спринта. У каждого члена команды имеется три магнитика, которыми он может воспользоваться для голосования. Каждый член команды может лепить магнитики как ему вздумается, хоть все три сразу на одну задача. Основываясь на этом голосовании, мы выбираем 5 улучшений, которые мы попытаемся внедрить в следующем спринте, а на следующей ретроспективе мы проверим, что у нас вышло. Очень важно не переоценить свои возможности. Выберите всего несколько улучшений для следующего спринта. Как учиться на чужих ошибках Информация, которая всплывает в ходе ретроспектив, обычно крайне важна. Для команды настали нелёгкие времена, потому что менеджеры по продажам начали забирать программистов с работы на свои встречи, чтоб те играли роль "технических экспертов"? Это очень важная информация. Возможно, что и у других команд точно такие же проблемы. Может быть, нам стоит провести специальные тренинги по нашему продукту для отдела маркетинга, чтобы они самостоятельно смогли отвечать на все вопросы клиентов? Возможные способы решения проблем, найденных командой на ретроспективе, могут оказаться полезными не только для неё самой, но и для остальных. Как же собрать все эти результаты? Мы выбрали достаточно простой способ. Один человек (в этом случае я) принимает участие во всех ретроспективах в роли "связующего звена". Без всяких формальностей. В качестве альтернативного варианта можно предложить каждой команде составлять отчёт о проведённой ретроспективе. Мы пробовали и этот способ, но поняли, что немногие читают такие отчёты, а ещё меньше тех, кто делают выводы из прочтённого. Поэтому мы остановились на самом простом способе. Наиболее важные требования для человека, который будет "связующим звеном": Scrum и XP: заметки с передовой 52 • Он должен быть хорошим слушателем. • Если ретроспектива проходит очень вяло, он должен быть готов задать простой, но меткий вопрос, который подтолкнёт людей на дискуссию. Например: "Если бы можно было повернуть время вспять и переделать этот спринт с самого первого дня, чтобы вы сделали по-другому?". • Он должен быть согласен тратить своё время на посещение всех ретроспектив всех команд. • Он должен обладать необходимыми полномочиями, которые помогли бы ему взяться за выполнение предложенных командой улучшений, выходящих за пределы возможностей самой команды. Такой подход работает достаточно хорошо, но это не значит, что нет подходов намного лучше. Как только найдёте что-то новенькое, дайте мне знать. Изменения. Быть или не быть Предположим, команда пришла к выводу, что "мы слишком слабо общались внутри команды, поэтому мы постоянно мешали друг другу и переделывали архитектурные решения". Что нам с этим делать? Организовать ежедневные встречи для обсуждения архитектуры? Внедрить новые средства, чтобы упростить общение? Создать больше страниц в wiki? Может, и да. А может, и нет. Оказалось, что достаточно всего лишь четко определить проблему, и она часто решается сама собой в следующем спринте. В особенности, если на стене в рабочей комнате повесить записи по ретроспективе спринта (что, к нашему стыду, мы так часто забываем сделать!) Имейте в виду, что каждое изменение имеет свою цену, поэтому перед тем как его внедрять, подумайте, может, стоит ничего не делать вообще и надеяться, что проблема станет меньше или исчезнет совсем. Пример, приведенный выше ("мы так слабо общались внутри команды...") – это классический пример того, что решается лучше всего бездействием. Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными. Типичные проблемы, которые обсуждают на ретроспективах В этой главе я постараюсь описать стандартные проблемы, которые всплывают в ходе ретроспектив, и возможные пути их решения. «Нам надо было больше времени потратить на разбиение историй на подзадачи» О, это классика жанра. Каждый день на Scrum'е можно услышать, как люди произносят избитую до боли фразу: "Я не знаю, что мне сегодня делать". И вам приходится изо дня в день тратить кучу времени для того, чтобы после Scrum'а найти задачи для этих ребят. Мой совет – делайте это заранее. Стандартные действия: никаких. Возможно, команда сама решит эту проблему на следующем планировании. Если же это повторяется из раза в раз, увеличьте время на планирование спринта. «Очень часто беспокоят извне» Стандартные действия: • Попросите команду уменьшить фокус-фактор на следующий спринт, чтобы у них был более реалистичный план. • Попросите команду более подробно записывать случаи вмешательства (кто и как долго). Потом будет легче решить проблему. • Попросите команду переводить все внешние запросы на ScrumMaster'а или product owner'а. • Попросите команду выбрать одного человека в качестве "голкипера" и перенаправлять на него все вопросы, которые могут отвлечь команду от работы. Это позволит остальной части команды Scrum и XP: заметки с передовой 53 сконцентрироваться на своих задачах. В это роли может выступать, как ScrumMaster, так и любой член команды, которого нужно будет периодически менять. «Мы взяли огромный кусок работы, а закончили только половину» Стандартные действия: никаких. Скорее всего, в следующий раз команда не станет браться за нереальный объём работ. Или, по крайней мере, поскромнее оценит свои возможности. «У нас в офисе бардак и очень шумно» Стандартные действия: • Попробуйте создать более благоприятную атмосферу или перевезите команду на другое место. Куда угодно. Можете снять комнату в отеле (см. стр. 43 "Как мы обустроили комнату команды"). • Если это возможно, попросите команду уменьшить фокус-фактор на следующий спринт с чётким описанием причины: шум и бардак в офисе. Может быть, это заставит product owner'а начать пинать вышестоящий менеджмент насчёт вашей проблемы. Слава Богу, мне никогда не приходилось перевозить команду в другое место. Но если придётся – я это сделаю. :o) Scrum и XP: заметки с передовой 54 11 Отдых между спринтами В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой. То же самое наблюдается в Scrum'е, да и в разработке программного обеспечения в целом. Спринты очень изматывают. Как у разработчика, у вас никогда нет времени, чтобы расслабиться, каждый день вы должны стоять на этом проклятом Scrum-митинге и рассказывать всем, чего вы добились вчера. Мало кто может похвастаться: "Я потратил большую часть дня, положив ноги на стол, просматривая блоги и попивая капучино". Помимо собственно отдыха, есть ещё одна причина для паузы между спринтами. После демо и ретроспективы, как команда, так и product owner будут переполнены информацией и всевозможными идеями, которые им следовало бы обмозговать. Если же они немедленно займутся планированием следующего спринта, то есть риск, что они не смогут упорядочить всё полученную информацию или сделать надлежащие выводы. К тому же у product owner'а не хватит времени для корректировки его приоритетов после проведённого демо и т.д. |