Scrum и xp заметки с передовой
 Скачать 3.07 Mb.
|
|
ScrumMaster: “Ребята, мы закончим историю “А” в этом спринте?” (Показывает на самую важную историю в product backlog’е) Лиза: “Конечно, закончим. У нас есть три недели, а это довольно тривиальная функциональность”. ScrumMaster: “Хорошо. А как на счёт истории “Б”?” (Показывает на вторую по важности историю) Том и Лиза одновременно: “Легко!” ScrumMaster: “Хорошо. Как на счёт историй “А”, “Б” и “В”?” Сэм (обращаясь к product owner): “Нужно ли реализовывать расширенную обработку ошибок для истории “В”?” Product owner: “Нет. Пока хватит базовой”. Сэм: “В таком случае историю “В” мы тоже закончим”. ScrumMaster: “Хорошо, как на счёт истории “Г”?” Лиза: “Хмм…” Том: “Думаю, что сделаем”. ScrumMaster: “Вероятность 90% или 50%?” Лиза и Том: “скорее 90%.” ScrumMaster: “Хорошо, значит, включаем историю “Г” в этот спринт. Что скажете на счет истории “Д”?” Сэм: “Возможно”. ScrumMaster: “90%? 50%?” Сэм: “Ближе к 50%”. Лиза: “Сомневаюсь”. ScrumMaster: “В таком случае, не включаем историю “Д”. Обязуемся реализовать истории “А”,”Б”,”В” и “Г”. Конечно, если успеем, то реализуем и историю “Д”, однако не стоит на это расчитывать. Поэтому историю “Д” исключаем из плана спринта. Согласны?” Все: “Согласны”. Интуитивное планирование хорошо работает для маленьких команд и коротких спринтов. Планирование, основанное на методе оценки производительности Этот подход включает в себя два этапа: 1. Определить прогнозируемую производительность. Scrum и XP: заметки с передовой 23 2. Посчитать, сколько историй вы можете добавить без превышения прогнозируемой производительности. Производительность является мерой “количества выполненной работы”. Она рассчитывается как сумма первоначальных оценок всех историй, которые были реализованы в течение спринта. На следующем рисунке показан пример прогнозируемой производительности в начале спринта и реальной производительности в конце спринта. Каждый прямоугольник обозначает историю, число внутри прямоугольника – это его начальная оценка. 8 5 5 3 5 Начало спринта Прогнозируемая производительность = 26 8 5 5 3 5 Конец спринта Реальная производительность = 18 Готово! Готово! Готово! Почти готово Не начато Помните, что реальная производительность расчитывается на основании начальной оценки каждой истории. Любые изменения оценки в течение спринта игнорируются. Я уже слышу ваши возражения: “Какая от этого польза? Высокий или низкий уровень производительности зависит от миллиона факторов! Недалёкие программисты, неправильная начальная оценка, изменение объёма работ, незапланированные потрясения в ходе спринта и т.д.” Согласен, производительность – это приблизительная величина. Но, тем не менее, очень полезная. Она лучше, чем ничего. Производительность даёт нам следущее: “Независимо от причин, мы имеем разницу между запланированным и выполненным объемом работ”. А что, если история была почти закончена? Почему мы не используем дробные значения для таких историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck. Так каким же магическим способом мы оцениваем производительность? Проще всего оценить производительность, проанализировав предыдущие результаты команды. Какая производительность была в течение нескольких последних спринтов? Приблизительно такой же она будет и в следующем спринте. Этот подход известен под названием вчерашняя погода. Он оправдан для тех команд, которые уже провели несколько спринтов (т.е. имеются статистические данные) и планируют следующий спринт без существенных изменений, т.е. тот же состав команды, рабочие условия и т.д. Конечно, это не всегда возможно. Более продвинутый вариант оценки производительности заключается в определении доступных ресурсов. Допустим, мы планируем трёхнедельный спринт (15 рабочих дней). Команда состоит из 4-ёх человек. Лиза берёт два отгула. Дэйв сможет уделить проекту только 50% времени плюс берёт один отгул. Сложим всё вместе … Scrum и XP: заметки с передовой 24 Том Лиза Сэм Дэйв 15 13 15 7 50 доступных человеко-дней Доступные дни ... получаем 50 доступных человеко-дней на спринт. Получили ли мы прогнозируемую производительность? Нет! Потому что наша единица измерения – это story point, который, в нашем случае приблизительно равен “идеальному человеко-дню”. Идеальный человеко-день – это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни – редкость. Кроме того, нужно принимать во внимание, что в ходе спринта может быть добавлена незапланированная работа, человек может заболеть и т.д. Без всякого сомнения, наша прогнозируемая производительность будет менее пятидесяти. Вопрос в том, насколько? Для ответа на него введём определения фокус-фактора. Прогнозируемая производительность этого спринта (доступные человеко-дни) x (фокус-фактор) = (прогнозируемая производительность) Фокус-фактор – это коэффициент того, насколько команда сфокусирована на своих основных задачах. Низкий фокус-фактор может означать, что команда ожидает неоднократного вмешательства в свою работу или предполагает, что оценки слишком оптимистичны. Выбрать разумный фокус-фактор лучше всего, взяв его из последнего спринта (а ещё лучше – среднее значение за несколько последних спринтов). Фокус-фактор последнего спринта (фокус-фактор) = (доступные человеко-дни) (действительная производительность) За реальную производительность принимается сумма начальных оценок для тех историй, которые были завершены в ходе последнего спринта. Допустим, в ходе последнего спринта командой из трёх человек в составе Тома, Лизы и Сэма реализовано 18 story point’ов. Продолжительность спринта была 3 недели, что составляет 45 человеко-дней. Необходимо спрогнозировать производительность команды на будущий спринт. Слегка усложним задачу появлением Дэйва – нового участника команды. Принимая во внимание отгулы членов команды и другие вышеупомянутые обстоятельства, получим 50 человеко-дней. Прогнозируемая производительность этого спринта: 50 человеко-дней x 40 % = 20 story point’ов Фокус-фактор последнего спринта: 40 % = 45 человеко-дней 18 story point’ов Таким образом, наша прогнозируемая производительность будущего спринта – это 20 story point’ов. Это означает, что команде следует включать истории в план спринта до тех пор, пока их сумма не будет примерно равна 20. Scrum и XP: заметки с передовой 25 8 5 3 5 Начало спринта 19 story point’ ов добавлено в спринт 3 Не попали в спринт 3 В нашем случае команда может выбрать 4 наиболее важные истории (что составляет 19 story point’ов) или 5 наиболее важных историй (24 story point’а). Остановимся на четырёх историях, т.к. их сумма близка к 20. Если возникают сомнения, выбирайте меньше историй. Ввиду того, что выбранные 4 истории составляют 19 story point’ов, окончательная прогнозируемая производительность будущего спринта составляет 19. Техника “вчерашней погоды” очень удобна, однако использовать её нужно, полагаясь на здравый смысл. Если последний спринт был необычайно плохим вследствие того, что все члены команды болели в течение недели, это вовсе не означает, что подобная ситуация повторится в ходе следующего спринта. Таким образом, фокус-фактор может быть увеличен. Если команда недавно внедрила сверхбыструю систему непрерывной интеграции, фокус-фактор также может быть увеличен. В случае, если к команде присоединился новый участник, фокус-фактор нужно уменьшить, принимая во внимание время, необходимое ему на то, чтобы влиться в проект, и на обучение. И т.д. Для того, чтобы получать более достоверные оценки, по возможности используйте усредненные данные за последние несколько спринтов. Что если команда новая и не имеет никакой статистики? В этом случае можно использоать фокус-фактор других команд, которые работают в похожих условиях. Нет возможности взять данные других команд? Выберите фокус-фактор наугад. Хорошая новость состоит в том, что фокус-фактор придётся угадывать лишь для первого спринта. После первого спринта вы будете располагать статистическими данными и сможете непрерывно измерять и совершенствовать ваш фокус- фактор и прогнозируемую производительность. В качестве “значения по умолчанию” фокус-фактора для новых команд мы обычно используем 70%, т.к. это именно тот предел, которого нашим командам удавалось достичь за всё время их работы. Какую технику мы используем для планирования? Я упоминал несколько подходов подсчёта производительности: на основе интуиции, на основе “вчерашней погоды” и на основе определения доступных ресурсов с учётом фокус-фактора. Какой же подход используем мы? Обычно мы совмещаем все перечисленные подходы. На это не требуется много времени. Мы анализируем фокус-фактор и реальную производительность последнего спринта. И, проанализоровав доступные ресурсы, получаем фокус-фактор будущего спринта. Обсуждаем любые различия этих двух фокус- факторов и вносим необходимые коррективы. Как только станет известен приблизительный список историй на будущий спринт, мы проводим поверку с использованием подхода, основанного на интуиции. Я прошу команду на некоторое время забыть о цифрах и просто прикинуть, насколько реально реализовать эти истории в одном спринте. Если кажется, что их много, то исключаем одну-две истории. И наоборот. Scrum и XP: заметки с передовой 26 Вобщем, цель – принять решение о том, какие истории включать в спринт. А фокус-фактор, доступные ресурсы и прогнозируемая производительность являются лишь инструментами её достижения. Почему мы используем учетные карточки Большинство встреч по планированию спринта посвящены историям из product backlog’а: их оценке, расстановке приоритетов, уточнению требований, разбиению на части и т.д. Как это происходит у нас? Обычно команда включает проектор, который показывает backlog в Excel’е. Кто-то (обычно product owner или ScrumMaster) садится за клавиатуру, быстро зачитывает историю и начинает обсуждение. По мере того, как команда и product owner обсуждают приоритеты и детали, парень за клавиатурой обновляет историю прямо в Excel’е. Неплохо, да? А вот и нет! На самом деле это фигня. И что ещё хуже, команда обычно не замечает, что это фигня, аж до конца встречи, когда оказывается, что ещё куча историй не обработана! Есть способ получше – сделать учетные карточки и прикрепить их на стену (или на большой стол). Такой “пользовательский интерфейс” выигрывает по сравнению с компьютером и проектором, по следующим причинам: • Люди вынуждены вставать и ходить, поэтому они более сконцентрированы и не засыпают. • Каждый чувствует себя причастным к процессу (а не только парень за клавиатурой). • Можно редактировать несколько историй одновременно. • Изменить приоритеты очень просто – достаточно поменять местами учетные карточки. • После окончания встречи учетные карточки можно забрать в комнату, где работает команда, и использовать их на доске задач (см. стр. 38 “Как мы создаём sprint backlog?”). Вы можете заполнить учетные карточки собственноручно или (как мы обычно делаем) сгенерировать версию для печати прямо из product backlog’а, используя простой скрипт. PS – скрипт можно найти в моём блоге на http://blog.crisp.se/henrikkniberg Scrum и XP: заметки с передовой 27 Важно: После планирования спринта наш ScrumMaster вручную обновляет product backlog в Excel’е, чтобы учесть все изменения, которые были сделаны на карточках. Да, это определённая морока, но мы на это согласны с учетом того, насколько эффективнее проходят встречи по планированию спринтa с использованием бумажных учетных карточек. Несколько слов о поле “Важность” (Importance). Это значение “важности” из product backlog’а в Excel’е на момент распечатки карточки. Её обозначение на карточке помогает нам отсортировать карточки на стене. Обычно мы располагаем более важные элементы левее, а менее важные – правее. Однако, когда карточки уже на стене, можно забыть о значении поля “важность” и, вместо этого, использовать порядок, чтобы показать относительную важность истории. Если product owner меняет местами карточки, не тратьте время на обновление значений на бумажках. Просто после встречи убедись, что обновили значения степени важности историй в product backlog’е. Историю обычно можно оценить легче и точнее, если она разбита на задачи. На самом деле мы использует термин “действие” (activity), потому что слово “задача” (task) значит на шведском кое-что совершенно другое :o) [прим. переводчика – шведско-русский онлайн словарь находится по адресу http://lexin.nada.kth.se/swe-eng.html ] Использование карточек также упрощает процедуру разбиения историй на задачи. Можно разбить команду на пары, тогда они смогут одновременно разбивать истории на задачи – каждая свою. На нашей доске мы отображаем задачи в виде маленьких стикеров под каждой историей. Каждый стикер соответствует одной задаче в рамках этой истории. Other stuff Other stuff Более важно Менее важно 9д 14д 5д 12д 15д 12д Автомат. обновление Депозит Админка: вход Админка: Управление пользователями Дизайн для GUI (CSS) 1д Уточнить требования 2д Разраб. GUI 6д Покопаться в Tapesty 2д Приёмо чные тесты 2д Разраб. GUI 1д Приёмо чные тесты 3д Написать скрипт 8д Приёмо чные тесты 2д Спец. для GUI 2д DAO 3д Рефакто -ринг 1д Интегра- ционное тест-ие 2д Дизайн БД 1д Приёмо чные тесты 2д Интегра- ция с JBoss 2д Шифрование паролей Тест произво-ти Снятие со счёта Мы не добавляем задачи в product backlog в Excel’е по двум причинам: • Список задач обычно часто меняется: к примеру, задачи могут изменяться и пересматриваться на протяжении sprint’а. Чтобы синхронизировать с ними product backlog в Excel’е нужно слишком много усилий. • Скорее всего, на этом уровне детализации product owner не будет участвовать в процессе. Так же, как и учетные карточки, стикеры с задачами можно использовать в sprint backlog’e (см. стр. 38 “Как мы создаём sprint backlog?”). Scrum и XP: заметки с передовой 28 Критерий готовности Важно, чтобы и product owner, и команда совместными усилиями определили критерий готовности. Можно ли считать историю готовой, если весь код был добавлен в репозиторий? Или же она считается готовой, лишь после того как была развёрнута на тестовом сервере и прошла все интеграционные тесты? Где только это возможно, мы используем следующее определение критерия готовности: “история готова к развёртыванию на живом сервере”, однако, иногда мы вынуждены иметь дело с определением типа “развёрнуто на тестовом сервере и готово к приёмочному тестированию”. Поначалу мы использовали детализированные контрольные листы для определения того, что история готова. А сейчас мы часто просто говорим: “история готова тогда, когда так считает тестировщик из нашей Scrum-команды”. В этом случае проверка того, что пожелания product owner’а были правильно восприняты командой, остаётся на совести тестировщика. В его задачи также входит контроль того, что история достаточно “готова” для того, чтобы удовлетворить принятому критерию готовности. В конце концов, мы осознали, что нельзя все истории ровнять под одну гребёнку. История “форма поиска пользователей” будет очень сильно отличаться от истории под названием “руководство по эксплуатации”. В последнем случае “готово” может просто означать “принято отделом поддержки клиентов”. Поэтому здравый смысл часто лучше, чем формальный контрольный лист. Если вы часто путаетесь с определением критерия готовности (как это было поначалу у нас), то вам, наверное, стоит ввести поле “критерий готовности” для каждой истории. Оценка трудозатрат с помощью игры в planning poker Оценка – это командная работа, и, зачастую, все члены команды участвуют в оценке каждой истории. Почему? • Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть. • Реализация историй обычно требует участия различных специалистов (дизайн пользовательского интерфейса, кодирование, тестирование, и т.д.). • Для того, чтобы каждый участник команды мог выдать какую-то оценку, он должен более или менее понимать, в чём суть этой истории. Получая оценку от каждого члена команды, мы убеждаемся, что все понимают, о чём идёт речь. Это увеличивает вероятность взаимопомощи по ходу спринта. А также это увеличивает вероятность того, что наиболее важные вопросы по этой истории всплывут как можно раньше. • При оценке истории совместными усилиями разностороннее видение проблемы приводит к сильному разбросу оценок. Такие разногласия лучше выявлять и обсуждать как можно раньше. Если попросить всех оценить историю, то обычно человек, который понимает её лучше остальных, выдаст оценку первым. К несчастью это сильно влияет на оценки других людей. Но существует прекрасная практика, которая позволяет этого избежать. Она называется planning poker (придуманная Майком Коном, насколько я знаю). Scrum и XP: заметки с передовой 29 Каждый член команды получает колоду из 13-ти карт, таких же, как на картинке выше. Всякий раз, когда нужно оценить историю, каждый член команды выбирает карту с оценкой (в story point’ах), которая, по его мнению, подходит, и кладёт её на стол рубашкой наверх. Когда всё члены команды определились с оценкой, карты одновременно вскрываются. Таким образом, члены команды вынуждены оценивать самостоятельно, а не “списывать” чужую оценку. Если получается большая разница в оценках, то эту разницу обсуждают и пытаются выработать общее понимание того, что должно быть сделано для реализации этой истории. Возможно, они разобьют задачу на более мелкие. После этого команда оценит историю заново. Этот цикл должен повторяться до тех пор, пока оценки не сойдутся, т.е. не станут примерно одинаковыми. Очень важно напоминать всем членам команды, что они должны оценивать общий объём работ по истории, а не только “свою часть”. Тестировщик должен оценивать не только работы по тестированию. Заметьте, последовательность значений на картах – нелинейная. Вот, например, между 40 и 100 ничего нет. Почему так? Это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 20 story point’ов, то нет смысла обсуждать должна ли она быть 20, или 18, или 21. Всё, что нам нужно знать, это то, что её сложно оценить. Поэтому мы примерно назначаем ей оценку в 20. Если у вас возникло желание более детально переоценить эту историю, то лучше разбейте её на более мелкие части и оцените уже их! И, кстати, жульничать, выкладывая карты 5 и 2, чтоб получить 7, нельзя. Вы должны выбрать или 5 или 8 – семёрки нет. Есть ещё несколько специальных карт: • 0 = или “история уже готова” или же её оценка “пара минут работы”. • ? = “Я понятия не имею. Абсолютно”. • Чашка кофе = “Я слишком устал, чтобы думать. Давайте сделаем перерыв”. Уточнение описаний историй Нет ничего ужасней, чем ситуация, когда команда с пафосом демонстрирует новую функциональность продукта, а product owner тяжко вздыхает и говорит: “ну да – всё это красиво, вот только не то, что я просил!” Как убедиться, что product owner и команда понимают историю одинаково? Или что все члены команды понимают все истории одинаково? Да никак. Есть простые способы выявить разницу в понимании. Наиболее простая практика – всегда заполнять все поля для каждой истории (точнее, для всех историй, которые могут попасть в текущий спринт). Пример №1: Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут ScrumMaster говорит: “Минуточку! У нас нет оценки для истории “добавить пользователя”. Давайте-ка оценим!”. После пары сдач в planning poker, команда сходится на оценке в 20 story point’ов, на что product owner вскакивает с криком: “ЧЕГООО?!?”. Пара минут ожесточённых споров и вдруг выясняется, что команда имела в виду “удобный web-интерфейс для функций добавить, редактировать, удалить и искать пользователей”, а product owner имел в виду только “добавлять пользователей напрямую в базу данных с помощью SQL-клиента”. Команда оценивает историю заново и останавливается на 5-ти story point’ах. Пример №2: Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут Scrum master говорит: “Минуточку! Вот тут у нас есть история “добавить пользователя”… Как она может Scrum и XP: заметки с передовой 30 быть продемонстрирована?”. Народ пошепчется и через минуту кто-то встанет и начнёт: “ну, для начала надо залогиниться на сайт, потом…”, а product owner тут же перебьёт: “залогиниться на сайт?! Не-не-не-не… эта функция вообще к сайту не должна иметь никакого отношения – это будет просто маленький SQL-скрипт, только для администраторов”. Поле “как продемонстрировать” может (и должно) быть очень кратким! Иначе вы не успеете вовремя закончить планирование спринта. По сути, это лаконичное описание на обычном русском языке, как вручную выполнить наиболее общий тестовый пример: “Сделать это, потом это, потом проверить, что получилось так- то”. И я понял, что такое простое описание часто позволяют обнаружить разное понимание объёма работ для историй. Хорошо ведь узнать об этом заранее, не так ли? Разбиение историй на более мелкие истории Истории должны быть не слишком маленькими, но и не слишком большими (в смысле оценок). Если вы получили кучу историй в половину story point’а, то вы наверняка падёте жертвой микроменеджмента. С другой стороны, история в 40 story point’ов несёт в себе риск того, что к концу спринта её успеют закончить лишь частично, а незавершённая история не представляет ценности для вашей компании, она только увеличивает накладные расходы. Дальше – больше: если ваша прогнозируемая производительность 70 story point’ов, а две наиболее важные истории оценены в 40, то планирование несколько усложнится. Команда станет перед выбором: или расслабиться (т.е. включить в спринт только одну историю), или взять на себя невыполнимые обязательства (т.е. включить обе). Я считаю, что практически всегда есть возможность разбить историю на более мелкие. Однако, в этом случае нужно следить за тем, чтобы меньшие истории всё ещё представляли ценность с точки зрения бизнеса. Обычно мы стремимся получить истории объёмом от двух до восьми человеко-дней. Производительность нашей среднестатистической команды обычно находится в пределах 40-ка – 60-ти человеко-дней, что позволяет нам включать в спринт примерно по 10 историй. Иногда всего 5, а иногда целых 15. Кстати, таким числом учётных карточек достаточно удобно оперировать. Разбиение историй на задачи Секундочку… В чём разница между “задачами” и “историями”? Очень правильный вопрос. А различие очень простое: истории это нечто, что можно продемонстрировать, что представляет ценность для product owner’а, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a. Пример разбиения истории на более мелкие: Добавление и редактирование пользователя Управление пользователями Поиск пользователей Scrum и XP: заметки с передовой 31 Пример разбиения истории на задачи: Приёмочный тест Разработать пользовательский интерфейс Реализовать форму для запросов Найти инструмент для отчётов и разобраться с ним Реализовать вывод списка пользователей Интеграция Тестирование Отладка Рефакторинг Поиск пользователей Уточнить требования Несколько интересных наблюдений: • Молодые Scrum-команды не любят тратить время на предварительное разбиение историй на задачи. Некоторые считают это “водопадным” подходом. • Абсолютно понятные истории разбивать на задачи заранее так же легко, как и по мере их выполнения. • Такая разбивка часто позволяет выявить дополнительную работу, которая увеличивает оценку, чем обеспечивается более реалистичный план на спринт. • Такая предварительная разбивка заметно увеличивает эффективность ежедневного Scrum’а (см. стр. 46 “Как мы проводим ежедневный Scrum”). • Даже неточная разбивка, которая будет изменяться по ходу работ, всё равно даёт нам все перечисленные выше выгоды. Итак, чтобы успеть разбить истории на задачи, мы стараемся выделить достаточно времени на планирование спринта. Однако, если время поджимает, то разбиение на задачи мы можем и пропустить (см. следующую главу “Когда пора остановиться”). Примечание: мы практикуем TDD (разработку через тестирование), из-за чего первой задачей почти каждой истории является “написать приёмочный тест”, а последняя – “рефакторинг” (улучшение читабельности кода и удаление повторений кода). Выбор времени и места для ежедневного Scrum'а Все часто забывают, что на планировании спринта, помимо всего прочего, необходимо выбрать время и место проведения ежедневного Scrum'а. Без этого ваш спринт обречён на неудачный старт. Ведь первый ежедневный Scrum – это, по большей части, ввод мяча в игру, когда каждый решает с чего начать работу. Я предпочитаю проводить ежедневный Scrum утром. Хотя, должен признаться, мы особо и не пробовали проводить его в обед или ближе к вечеру. Недостатки обеденного Scrum'а: приходя на работу утром, вам надо попытаться вспомнить, чем вы обещали команде заниматься сегодня. Недостатки утреннего Scrum'а: приходя на работу утром, вам надо попытаться вспомнить, чем вы занимались вчера, чтобы можно было отчитаться об этом. Мне кажется, первый недостаток хуже, так как наиболее важно то, что вы собираетесь делать, а не то, что вы уже сделали. Мы обычно выбираем самое раннее время, которое не вызывает стонов ни у кого в команде. Обычно это 9:00, 9:30 или 10:00. Очень важно, чтобы все в команде искренне согласились на это время. Scrum и XP: заметки с передовой 32 Когда пора остановиться Ну вот, время заканчивается. Чем мы можем пожертвовать из всего того, что мы собирались сделать на планировании спринта, если время поджимает? У меня, например, приоритеты для встречи по планированию спринта такие: Приоритет №1: Цель спринта и дата демонстрации. Это тот минимум, с которым можно начинать спринт. У команды есть цель и крайний срок, а работать они могут прямо по product backlog'у. Да это нехорошо, и нужно запланировать ещё одну встречу по планированию sprint backlog'а на завтра, но если вам крайне необходимо стартовать спринт, то это, скорее всего, сработает. Хотя, если быть честным, я так никогда и не стартовал спринт, имея всего лишь цель и дату. Приоритет №2: Список историй, которые команда включила в sprint backlog. Приоритет №3: Оценки для каждой истории из sprint backlog'а. Приоритет №4: Поле "Как продемонстрировать" для каждой истории из sprint backlog'а. Приоритет №5: Расчёты производительности и ресурсов в качестве "испытания реальностью" для плана на спринт. Также нужен список членов команды с указанием их степени участия в проекте (без этого нельзя рассчитать производительность). Приоритет №6: Определённое время и место проведения ежедневного Scrum'а. Вообще, выбрать время и место можно за одну минуту, но если время собрания уже закончилось, то ScrumMaster просто выбирает их сам после собрания и оповещает всех по электронной почте. Приоритет №7: Истории, разбитые на задачи. Разбивать истории на задачи можно также и по мере их поступления в работу, совмещая это с ежедневным Scrum'ом, но такой подход слегка нарушает течение спринта. Технические истории А теперь ещё одна сложная проблема: технические истории. Это нефункциональные требования, или как их там ещё называют. Я имею в виду всё, что должно быть сделано, но невидимо для заказчика, не относится ни к одной user story, и не даёт прямой выгоды product owner'у. Мы называем это "техническими историями". Например: • Установить сервер непрерывной интеграции o Почему это надо сделать? Потому, что это сэкономит много времени разработчикам и снизит риск проблемы "большого взрыва" при интеграции в конце итерации. • Описать архитектуру системы o Почему это надо сделать? Потому, что разработчики часто забывают общую архитектуру и поэтому пишут несогласованный код. Нужен документ, предоставляющий всем одинаковую общую картину. • Рефакторинг слоя доступа к данным o Почему это надо сделать? Потому, что слой доступа к данным стал очень запутанным, и разработчики теряют много времени на то, чтобы разобраться и исправить возникающие дефекты. Рефакторинг сохранит время всей команды и повысит устойчивость системы. • Обновить Jira (систему учёта дефектов) o Почему это надо сделать? Текущая версия очень нестабильная и медленная: обновление сохранит время всей команде. Scrum и XP: заметки с передовой 33 Имеют ли смысл эти истории? Или это задачи не связанные ни с одной историей? Кто задаёт приоритеты? Нужно ли вовлекать сюда product owner'а? Мы попробовали различные варианты работы с техническими историями. Мы пробовали считать их самыми обычными user story. Это была неудачная идея: для product owner'а приоритезировать их в product backlog'е было всё равно, что сравнить тёплое с мягким. По очевидным причинам технические истории получали самый низкий приоритет с объяснением: "Да, ребята, несомненно, ваш сервер непрерывной интеграции – очень важная штука, но давайте сперва реализуем кое-какие прибыльные функции? После этого вы можете прикрутить вашу техническую конфетку, окей?" В некоторых случаях product owner действительно прав, но чаще все-таки нет. Мы пришли к выводу, что product owner не всегда компетентен, чтобы идти на компромисс. И вот что мы делаем: 1. Стараемся избегать технических историй. Ищем способ превратить техническую историю в нормальную историю с измеряемой ценностью для бизнеса. В таком случае у product owner'а больше шансов найти разумный компромисс. 2. Если мы не можем превратить техническую историю в обычную, смотрим нельзя ли включить эту работу в уже существующую историю. Например, "рефакторинг доступа к данным" мог бы стать частью истории "редактировать пользователя", поскольку она подразумевает работу с данными. 3. Если оба подхода не прошли, отмечаем это как техническую историю и храним список таких историй отдельно. Пусть product owner видит список, но не редактирует. В переговорах с product owner'ом используем параметры “фокус-фактора” и “прогнозируемой производительности” и выделяем время в спринте для реализации технических историй. Пример (диалог очень похож на то, что случилось во время одного из наших планирований спринта). Команда: “У нас есть кое-какие внутренние технические работы, которые должны быть сделаны. Мы бы хотели заложить на это 10% всего времени, т.е. снизить фокус-фактор с 75% до 65%. Это возможно?” Product owner: “Естественно, нет! У нас нет времени!” Команда: “Хорошо, давайте посмотрим на наш последний спринт (все бросают взгляд на график производительности на белой доске). Наша прогнозируемая производительность была 80, но реальная производительность оказалась 30, верно?” Product owner: “Именно! У нас нет времени на внутренние технические работы! Нам нужен новый функционал!” Команда: “Хорошо. Но причина ухудшения нашей производительность в том, что мы тратим слишком много времени на создание полной сборки для тестирования”. Product owner: “Ну и что?” Команда: “А то, что производительность и дальше будет такой низкой, если мы ничего не сделаем”. Product owner: “Да ... и что вы предлагаете?” Команда: “Мы предлагаем выделить примерно 10% следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов как минимум на 20%!” Product owner: “Серьёзно? Почему же мы это не сделали на предыдущем спринте?!” Команда: “Хм... потому что вы не захотели, чтобы мы это сделали...” Product owner: “О! Ммм..., ладно, тогда логично, если вы это сделаете сейчас!” Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже не попытаться достичь компромисса. Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность – это один из основополагающих принципов Scrum'а, верно? Scrum и XP: заметки с передовой 34 Как мы используем систему учёта дефектов для ведения product backlog'а Есть ещё одна непростая задача. С одной стороны, Excel очень хороший формат для product backlog'а. С другой стороны, вам всё равно нужна система учёта дефектов, и Excel здесь явно не тянет. Мы используем Jira. Итак, как мы переносим задачи из Jira в планирование спринта? Не можем же мы просто их проигнорировать и сосредоточиться только лишь на историях. Мы пробовали следующие подходы: 1. Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет). 2. Product owner создаёт истории, соответствующие задачам из Jira. Например, “Исправить самые критические ошибки отчётности в админке, Jira-124, Jira-126, и Jira-180”. 3. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50%), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в Jira. 4. Заносим product backlog в Jira (просто переносим из Excel'а). Считаем баги обычными историями. Мы ещё не определились, какой подход для нас самый лучший; в действительности он может отличаться в разных командах и меняться от спринта к спринту. Я больше склоняюсь к первому подходу: он прост и понятен. Свершилось! Планирование спринта закончено! Ух, я и не думал, что глава по планированию спринта будет такой длинной! [прим. переводчика: я, если честно, тоже :)] Полагаю, этот факт отражает моё мнение: планирование спринта – самая важная вещь в Scrum'е. Вложите побольше усилий в планирование – и всё остальное пойдёт как по маслу. Планирование спринта прошло успешно, если все (и команда, и product owner) с улыбкой завершают встречу, с улыбкой просыпаются следующим утром и с улыбкой проводят первый ежедневный Scrum. Затем, конечно, всё может пойти криво, но вы, как минимум, не сможете списать всю вину на планирование спринта :o) Scrum и XP: заметки с передовой 35 5 Как мы доносим информацию о спринте до всех в компании Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или – что ещё хуже – придумывать всякие ужасы про вас. Мы для этой цели используем “страницу с информацией о спринте”. • Релиз, готовый к бета-тестированию! Команда ”Джокер”, спринт №15 Цель спринта Sprint backlog (в скобках – оценки) • Депозит (3) • Автоматическое обновление (8) • Админка: вход (5) • Админка: управление пользователями (5) Прогнозируемая производительность: 21 Расписание • Спринт: с 2006-11-06 по 2006-11-24 • Ежедневный scrum: 9:30 – 9:45, в главной комнате • Демонстрация: 24/11/2006, 13:00, в кафетерии Команда • Джим • Эрика (ScrumMaster) • Том (75%) • Ева • Джон Иногда мы также добавляем к названию истории поле ”как продемонстрировать” Сразу же после встречи по планированию спринта эту страницу создаёт ScrumMaster. Он помещает её в wiki, и тут же спамит на всю компанию: |