Scrum и xp заметки с передовой
 Скачать 3.07 Mb.
|
|
Как мы готовимся к планированию спринта Не успеешь оглянуться – как наступил день планирования нового спринта. Мы не раз приходили к одному и тому же выводу: Вывод: Убедитесь, что product backlog находится в нужной кондиции, прежде чем начинать планирование. Что значит в нужной кондиции? Что все user story отлично описаны? Что все оценки трудозатрат корректны? Что все приоритеты расставлены? Нет, нет и ещё раз нет! Это значит: • Product backlog должен существовать! (Кто бы мог подумать?) • У каждого продукта должен быть один product backlog и один product owner. • Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать. o Не волнуйтесь, если задачи с низким уровнем важности имеют одинаковые значения, скорее всего, они не попадут в текущий спринт, а, следовательно, не будут обсуждаться. o Все user story, которые, по мнению product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности. o Уровень важности используется исключительно для упорядочивания историй. Т.е. если история А имеет уровень важности 20, а история Б важность 100, это означает что Б важнее A. Это не означает, что Б в пять раз важнее А. Если Б присвоить важность 21 – смысл не поменяется! o Полезно оставлять промежутки из целых чисел между значениями на тот случай, если появится история В, более важная, чем А, но менее важная, чем Б. Конечно, можно выкрутиться, присвоив ей уровень важности 20.5, но выглядит это коряво, поэтому для промежутков мы решили использовать только целые числа! • Product owner должен понимать каждую историю (чаще всего он их автор, хотя иногда другие члены команды тоже могут вносить предложения, и тогда product owner обязан назначить им приоритетность). Он не обязан знать во всех подробностях, что конкретно следует сделать, но он должен понимать, почему эта user story была включена в product backlog. Примечание: Хотя заинтересованные лица могут добавлять user story в product backlog, они не имеют права присваивать им уровень важности. Это прерогатива product owner’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды. Мы также попробовали: • Использовать Jira (нашу систему учёта дефектов) для хранения product backlog’а. Но для большинства product owner’ов навигация по Jira была слишком обременительна. В Excel’е манипулировать историями намного проще и приятней. Вы можете раскрашивать текст, переставлять пункты, добавлять, в случае необходимости, новые колонки, комментировать, импортировать и экспортировать данные и т.д. • Использовать программы, заточенные под Agile процесс, такие как VersionOne, ScrumWorks, Xplanner и т.д. Но толком до них руки так и не дошли, хотя, возможно, когда-нибудь мы их всё- таки попробуем. Scrum и XP: заметки с передовой 16 4 Как мы планируем спринт Как по мне, планирование спринта – наиболее важная часть Scrum’a. Плохо проведённое планирование может испортить весь спринт. Цель планирования заключается в том, чтобы, с одной стороны, дать команде достаточно информации для спокойной работы в течение нескольких недель, а с другой – убедить product owner’а в том, что команда сможет сделать свою работу. Хорошо-хорошо, это было весьма расплывчатое определение. Давайте лучше поговорим о том, что должно быть итогом планирования: • Цель спринта. • Список участников команды (и степень их занятости, если она не стопроцентная). • Sprint backlog (список историй, которые вошли в спринт). • Дата демонстрации. • Место и время проведения ежедневного Scrum’а. Почему без product owner'а не обойтись Иногда product owner с большой неохотой тратит своё время на планирование вместе с командой: “Ребята, я уже перечислил всё, что мне нужно. Я больше не могу тратить время на ваше планирование”. Это, между прочим, очень серьёзная проблема. Команде и product owner’у просто необходимо планировать вместе, потому что каждая user story имеет три параметра, которые очень тесно связаны между собой. Объём работ Важность Оценка Объём работ и приоритеты задач определяются product owner’ом. Зато оценка трудозатрат – это прерогатива команды. Благодаря взаимодействию команды и product owner’а в ходе планирования спринта вырабатывается оптимальное соотношение всех трех переменных. Чаще всего product owner начинает планирование следующего спринта с описания основных целей и наиболее значимых историй. После этого команда производит оценку трудозатрат всех user story, начиная с самой важной. В процессе у команды возникают очень важные вопросы по поводу объёма предстоящих Scrum и XP: заметки с передовой 17 работ. Например, “Подразумевает ли история “удалить пользователя” удаление всех его незавершённых транзакций?”. Иногда ответ на этот вопрос будет большим сюрпризом для команды и потребует пересмотра всех оценок для данной user story. В некоторых случаях время, которое понадобится на выполнение user story, не будет совпадать с ожиданиями product owner’а. Следовательно, он захочет пересмотреть приоритет для story или изменить объём работы. Это, в свою очередь, заставит команду выполнить переоценку и так далее, и так далее. Такая взаимная зависимость является основой Scrum’а, да, в принципе, и всего Agile’а. Но что если product owner всё-таки упорно отказывается выделить пару часов на планирование спринта? В таком случае я обычно пытаюсь последовательно применить следующие стратегии: • Попытайтесь донести до product owner’а, почему его участие крайне важно – а вдруг до него дойдёт. • Попробуйте найти в своих рядах добровольца, который смог бы стать представителем product owner’а. Скажите своему product owner’у: “У вас нет времени на планирование, Джеф будет исполнять вашу роль. У него будут все полномочия на изменение приоритетов и объёмов работ. Советую вам обсудить с ним как можно больше нюансов до начала планирования. Если вы против Джефа, тогда выберите кого-то другого, но только с условием, что он будет присутствовать на планировании от начала до конца”. • Попробуйте убедить менеджмент найти вам нового product owner’а. • Отложите начало спринта до того момента, пока у product owner’а не появится свободная минутка для совместного планирования. А пока не берите на себя никаких новых обязательств. Пусть в это время ваша команда займётся любой другой полезной работой. Почему качество не обсуждается В предыдущей главе я намеренно не показал на треугольнике четвертую переменную – качество. Попытаюсь объяснить разницу между внутренним качеством и внешним качеством. • Внешнее качество – это то, как пользователи воспринимают систему. Медленный и неинтуитивный пользовательский интерфейс – это пример плохого внешнего качества. • Внутреннее качество касается вещей, которые как правило не видны пользователю, но при этом оказывают огромное значение на удобство сопровождения системы. Это продуманность дизайна системы, покрытие тестами, читаемость кода, рефакторинг и т.д. По правде говоря, у системы с высоким внутренним качеством иногда может быть довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить что-то хорошее на прогнившем фундаменте. Я рассматриваю внешнее качество, как часть общего объема работ. Ведь с точки зрения бизнеса бывает весьма целесообразно как можно быстрее выпустить версию системы с немного корявым и медленным пользовательским интерфейсом, и лишь потом подготовить версию с доработками и исправлениями. Здесь право выбора должно оставаться за product owner’ом, так как именно он отвечает за определение объёма работ. И напротив – внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается. Никогда. (Ну ладно, почти никогда) Так как же нам различать задачи, связанные с внутренним и внешним качеством? Представьте, что product owner говорит: “Хорошо ребята, я понимаю, почему вы оценили эту задачу в 6 story point’ов, но я уверен, что, если вы чуточку помозгуете, то сможете по-быстрому “залатать” проблему”. Ага! Он пытается использовать внутреннее качество как переменную! Как я догадался? Да, потому что он хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово “заплатка” должно вызывать у вас тревогу. Scrum и XP: заметки с передовой 18 Почему же мы так жестко стоим на своем? По моему личному опыту, жертвовать внутренним качеством – это практически всегда очень и очень плохая идея. Сэкономленное время ничтожно мало по сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем, так и в перспективе. Как только качество вашего кода ухудшится, восстановить его будет очень тяжело. В этом случае я стараюсь перейти к обсуждению объема задач. “Раз вам так важно получить эту историю как можно раньше, тогда может быть стоит сократить объем задач, чтобы мы могли сделать её побыстрее? Возможно, стоит упростить обработку ошибок и сделать “Улучшенную обработку ошибок” отдельной историей оставив ее на будущее? Или может понизить приоритет остальных историй, чтобы мы могли сосредоточить все свои усилия на этой?”. Планирование спринта, которое никак не заканчивается Самая большая сложность при планировании спринта состоит в следующем: 1. Люди не расчитывают, что это займёт так много времени 2. … но так оно и происходит! В Scrum’е всё ограничено по времени. Мне очень нравится это простое правило, и мы всячески пытаемся его придерживаться. Так что же мы делаем, когда ограниченное по времени планирование спринта близится к концу, а цель спринта или sprint backlog всё ещё не определены? Просто обрываем планирование? Продлеваем на час? Или, быть может, мы завершаем собрание и продолжаем его на следующий день? Это случается снова и снова, особенно в новых командах. Как вы обычно решаете эту проблему? Я не знаю. А как решаем её мы? Ну, обычно, я бесцеремонно обрываю встречу. Заканчиваю её. Пусть спринт пострадает. Точнее, я говорю команде и product owner’у: «Итак, встреча заканчивается через 10 минут. Мы, до сих пор, полностью не спланировали спринт. Можем ли мы начать работать с тем, что у нас есть, или назначим ещё одно 4-х часовое планирование спринта на завтра в 8 утра?». Можете догадаться, что они отвечают… :o) Я несколько раз давал возможность совещанию затянуться, но обычно это, ни к чему не приводило. Главная причина этому – усталость участников встречи. Если команда не выработала подходящий план спринта за 2 – 8 часов (зависит от конкретно ваших ограничений по времени), они, скорее всего, не управятся с ним и в дополнительное время. Второй вариант, по правде, достаточно хорош: назначить новую встречу на следующий день. За исключением того, что люди обычно нетерпеливы и хотят быстрее начать спринт, а не тратить ещё пару часов на планирование. Итак, я урезаю продолжительность встречи. Да, спринт от этого страдает. Но с другой стороны, команда получила очень ценный урок, и следующее планирование спринта пройдёт более эффективно. Кроме того, когда вы в следующий раз предложите увеличить продолжительность встречи, люди будут возмущаться гораздо меньше. Учитесь оставаться в рамках установленного времени, учитесь давать реалистичные оценки. Это касается как продолжительности встреч, так и продолжительности спринта. Scrum и XP: заметки с передовой 19 Распорядок встречи по планированию спринта Наличие хотя бы примерного расписания значительно увеличит ваши шансы закончить планирование спринта в отведённое для этого время. Например, наше расписание выглядит так: Планирование спринта: с 13:00 до 17:00 (после каждого часа перерыв на 10 минут) • 13:00 – 13:30. Product owner разъясняет цель спринта и рассказывает про бизнес-процессы из product backlog’а. Обсуждается время и место проведения демо. • 13:30 – 15:00. Команда проводит оценку времени, которое потребуется на разработку бизнес- процессов и, при необходимости дробит их на более мелкие. В некоторых случаях product owner может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для наиболее важных заполняем поле «Как продемонстрировать». • 15:00 – 16:00. Команда определяет набор user story, которые войдут в следующий спринт. Чтобы проверить насколько это реально, вычисляем производительность команды. • 16:00 – 17:00. Договариваемся о времени и месте проведения ежедневного Scrum’а (если они изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story на задачи. Наличие расписания ни в коем случае не подразумевает наличия жестких ограничений. В зависимости от того, как проходит встреча, ScrumMaster может увеличить, или уменьшить продолжительность каждого этапа. Определяем длину спринта. Одна из основных задач планирования спринта – это определение даты демо. А это значит, что вам придётся определиться с длиной спринта. Какая же длина оптимальна? Короткие спринты – удобны. Они позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы. Короткий спринт = короткий цикл обратной связи = частые релизы = быстрые отзывы от клиентов = меньше времени тратится на работу в неправильном направлении = быстрое обучение, совершенствование и т.д. Но с другой стороны длинные спринты тоже хороши. У команды остаётся больше времени, чтобы набрать темп, больше пространства для манёвров, чтобы решить возникшие проблемы, а также больше времени для достижения цели спринта, а у вас меньше накладных расходов, таких как планирование спринта, демо и т.д. В основном короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Поэтому длина спринта – это всегда компромисс. Мы долго экспериментировали и выбрали нашу любимую длину: 3 недели. Большинство наших команд (но не все) используют трёхнедельный спринт. Достаточно короткий, чтобы предоставить адекватную корпоративную “гибкость”, но в тоже время достаточно длинный, для того чтобы команда смогла достигнуть максимальной производительности и успеть решить все вопросы, которые возникнут по ходу спринта. Мы пришли к важному выводу: экспериментировать с длиной спринта нужно на начальном этапе. Не тратьте слишком много времени на анализ, просто выберите подходящую длину и используйте её на протяжении одного или двух спринтов, после чего можете выбрать новую. Однако, как только вы найдёте подходящею длину, надолго зафиксируйте её. После нескольких месяцев экспериментов нам подошла длина в 3 недели, поэтому теперь мы следуем этому правилу и используем трёхнедельные спринты. Иногда спринт будет казаться слишком длинным, иногда – слишком коротким. Но сохранение фиксированной длины спринта позволяет выработать корпоративный ритм, в котором все чувствуют себя достаточно комфортно. К тому же исчезнут споры, насчёт даты релиза, так как все знают, что как ни крути, а выпуск новой версии продукта каждые 3 недели. Scrum и XP: заметки с передовой 20 Определение цели спринта Это случается практически всегда, когда в ходе нашего планирования я задаю вопрос: “Итак, какова же цель спринта?”. Все начинают смотреть на меня удивлёнными глазами, а product owner – морщить лоб, почёсывая свой подбородок. Почему-то сформулировать цель спринта бывает довольно непросто. Но я до сих пор убеждён, что усилия, потраченные на попытки сформулировать цель, оправдывают себя. Лучше паршивая цель, чем её отсутствие. Например, цели могут быть следующие: “заработать больше денег”, “завершить три истории с наивысшими приоритетами”, “удивить исполнительного директора”, “подготовить систему к бета- тестированию”, “добавить возможность администрирования” или что-нибудь в этом духе. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не в технических терминах. То есть языком, понятным даже людям вне команды. Цель спринта должна отвечать на главный вопрос “Зачем мы работаем над этим спринтом? Почему мы все просто не уйдём в отпуск?”. На самом деле, самый простой способ вытянуть цель спринта из product owner’a – напрямую задать ему этот вопрос. Целью должно быть что-то, что не было ещё достигнуто. “Удивить исполнительного директора” может быть неплохой целью. Но только не в том случае, когда он и так в восторге от текущего состояния системы. В этом случае, все могут просто собраться и пойти домой, а цель спринта всё равно будет достигнута. Цель спринта может показаться слегка глупой и надуманной на протяжении всего планирования. Но чаще всего, основная её ценность начинает проявляться к середине спринта, когда люди начинают забывать чего они хотят достичь в этом спринте. Если у вас работают несколько Scrum-команд (как у нас) над разными продуктами, очень полезно иметь возможность просмотреть список целей спринтов для всех команд на одной wiki-странице (или ещё где-нибудь), а также вывесить их на видном месте, чтобы все (а не только топ- менеджеры) знали, чем занимается компания и зачем! Выбор историй, которые войдут в спринт Основное в планировании спринта – процедура выбора историй, которые войдут в спринт. А точнее, выбор историй, которые нужно скопировать из product backlog’a в sprint backlog. Product backlog Спринт №1 backlog Взгляните на картинку. Каждый прямоугольник представляет собой историю, расположение которой соответствует уровню её важности. Наиболее важная история находится наверху списка. Размер истории (т.е. количество story point’ов) определяет размер каждого прямоугольника. Высота голубой скобки обозначает прогнозируемую производительность команды, т.е. количество историй, которое команда собирается завершить в следующем спринте. Scrum и XP: заметки с передовой 21 Честно говоря, sprint backlog – это выборка историй из product backlog'a. Он представляет собой список историй, которые команда обязалась выполнить в течение спринта. Именно команда решает, сколько историй войдёт в спринт. Ни product owner, ни кто-нибудь ещё. В связи с этим, возникают два вопроса: 1. Каким образом команда решает, какие истории попадут в спринт? 2. Как product owner может повлиять на их решение? Начну со второго вопроса. Как product owner может влиять на то, какие истории попадут в спринт? Допустим, на планировании спринта возникла следующая ситуация: А Б В Г Д Product backlog Прогнозируемая производительность Product owner’а разочаровал тот факт, что история “Г” не попадает в спринт. Что он может сделать в ходе совещания? Первый вариант – изменение приоритетов. Если product owner назначит истории “Г” более высокий приоритет, то команда будет обязана включить её в спринт первой (исключив при этом историю “В”). А Б В Г Д Вариант №1 Прогнозируемая производительность Второй вариант – изменение объёма работ: product owner начинает уменьшать объём истории “А” до тех пор, пока команда не решит, что историю “Г” можно втиснуть в спринт. Б В Г Д А Вариант №2 Прогнозируемая производительность Scrum и XP: заметки с передовой 22 Третий вариант – разбиение истории. Product owner может решить, что некоторые части истории “А” не так уж и важны. Таким образом, он разбивает историю “А” на две истории “А1 ″ и “А2″, а затем назначает им разный приоритет. А2 Б В Г Д А1 Вариант №3 Прогнозируемая производительность Итак, несмотря на то, что в большинстве случаев product owner не может контролировать прогнозируемую производительность, у него существует множество способов повлиять на то, какие истории попадут в спринт. Как команда принимает решение о том, какие истории включать в спринт? Мы используем два подхода: 1. на основе интуиции 2. на основе подсчёта производительности Планирование, основанное на интуиции |