Scrum и XP: заметки с передовой. Конспект. Часть 1.

Очень понравилась «Scrum и XP: заметки с передовой» Хенрика Книберга в переводе Agile Ukraine. В ней Хенрик делится личным опытом ScrumMaster`ства в софтверных конторах. Никакой «воды», никаких лирических отступлений, только факты как работали они, как ещё можно работать, и как работать не нужно. Повествование от первого лица и встречающийся иногда юмор делают эту книгу интересным и лёгким чтивом.

Далее небольшой конспект перевода книги. Анонс перевода есть на Хабрахабре. Русский перевод книги можно взять на scrum.org.ua, а оригинал на infoq.com.

Product backlog и User story

Product backlog – это основа Scrum’а. С него все начинается. По существу, product backlog является списком требований, историй, функциональности, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке. Может хранится в екселе с публичным доступом.

Каждая история состоит из:

  • ID – уникальный идентификатор – просто порядковый номер. Применяется для идентификации историй в случае их переименования.
  • Название – краткое описание истории. Например, “Просмотр журнала своих транзакций”. Оно должно быть однозначным, чтобы разработчики и product owner (владелец продукта) могли примерно понять, о чем идет речь, и отличить одну историю от другой. Обычно от 2 до 10 слов.
  • Важность (Importance) – степень важности данной задачи, по мнению product owner’а. Например, 10. Или 150. Чем больше значение, тем выше важность (лучше не использовать термин “приоритет”, поскольку обычно в этом случае 1 обозначает наивысший приоритет. Если впоследствии вы решите, что какая-то история еще более важна, то нужен будет приоритет 0, -1, -2…)
  • Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах — некая относительная трудоёмкость. Приблизительно соответствует числу “идеальных человеко-дней” (фокус-фактор равен 100%). Оценивается разработчиками.
  • Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа “Сделайте это, сделайте то – должно получиться то-то”.
  • Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д. Обычно она представлена в форме кратких тезисов.

Дополнительные поля истории в помощь product owner`у:

  • Категория (track). Например, “панель управления” или “оптимизация”. При помощи этого поля  product owner может легко выбрать все пункты категории “оптимизация” и установить им низкий  приоритет.
  • Компоненты (components) – указывает, какие компоненты (например, база данных, сервер,  клиент) будут затронуты при реализации истории. Можно сделать checkbox’ами. Полезным при нескольких Scrum командах.
  • Инициатор запроса (requestor). Product owner может захотеть хранить информацию о всех  заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела  о ходе выполнения работ.
  • ID в системе учёта дефектов (bug tracking ID) – полезно хранить ссылки на все дефекты  которые к ней относятся.

Истории не должны отражать технических деталей (создать индексы), но должны описывать зачем это делается (ускорить поиск), и опционально в комментарии можно добавить совет про индексы. Так достигается ориентированность историй на бизнес.

Качество

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

У системы с высоким внутренним качеством иногда может быть довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить что-то хорошее на прогнившем фундаменте. Внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается.

Product owner говорит «… по-быстрому “залатать” проблему». Он пытается использовать внутреннее качество как переменную, хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово “заплатка” должно вызывать у вас тревогу.

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

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

Планирование спринта

Цель

  • дать команде достаточно информации для спокойной работы в течение нескольких недель
  • убедить product owner’а в том, что команда сможет сделать свою работу.

До и во время планирования

  • Product backlog должен существовать!
  • Product owner должен быть (или кто-либо доверенный выполнять его роль)
  • У каждого продукта должен быть один product backlog и один product owner.
  • Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать (нормально, если задачи с низким уровнем важности имеют одинаковые значения — скорее всего, они не попадут в текущий спринт, и, следовательно, не будут обсуждаться; уровень важности используется исключительно для упорядочивания историй, но не сравнения важности; полезно оставлять промежутки из целых чисел между значениями важности)
  • Product owner должен понимать каждую историю (чаще всего он их автор, хотя иногда другие члены команды тоже могут вносить предложения, и тогда product owner обязан назначить им приоритетность). Он не обязан знать во всех подробностях, что конкретно следует сделать, но он должен понимать, почему эта user story была включена в product backlog. Приоритет назначает только product owner.
  • Определение важности — работа product owner`а.
  • Оценка трудозатрат — работа команды.
  • Ограниченность во времени (не использовать на планирование времени более отведённого; через каждый час — перерыв)

В результате должно быть

  • Цель спринта (обязательна; определяется в терминах бизнеса)
    • сформулировать цель спринта бывает довольно непросто. Лучше паршивая цель, чем её отсутствие.
    • цель должна быть обозначена в терминах бизнеса, а не в технических терминах. То есть языком, понятным
      даже людям вне команды
    • цель спринта должна отвечать на главный вопрос “Зачем мы работаем над этим спринтом? Почему мы
      все просто не уйдём в отпуск?”. Цель определяет product owner
    • цель спринта может показаться слегка глупой и надуманной на протяжении всего планирования. Но чаще
      всего, основная её ценность начинает проявляться к середине спринта, когда люди начинают забывать чего
      они хотят достичь в этом спринте.
  • Список участников команды (и степень их занятости, если она не стопроцентная)
  • Sprint backlog (список историй, которые вошли в спринт из product backlog`а)
    • именно команда решает сколько историй войдёт в sprint backlog и никто другой
    • product owner может влиять на выбор историй в спринт: изменять приоритет; изменять объём истории, уменьшая объём работ: дробление истории на более мелкие с различным приоритетом
    • Истории включаются в спринт на основе интуиции(хорошо работает для маленьких команд и коротких спринтов) и подсчёте производительности
    • Не использовать дробные значения story-point`ов! Т.к scrum ориентирован на создание законченных, готовых к поставке продуктов. Ценность реализованной наполовину истории нулевая (а то и отрицательная).
  • Дата демонстрации
    • длина спринта определяется экспериментально; короткие спринты позволяют компании быть максимально “гибкой”, а значит готовой часто корректировать свои планы;
    • при длинных спринтах остаётся больше времени, чтобы набрать темп, больше пространства для манёвров, чтобы решить возникшие проблемы, и больше времени для достижения цели спринта;
    • короткие спринты больше нравятся product owner’у, а длинные – разработчикам. Длина спринта – это всегда компромисс
  • Место и время проведения ежедневного Scrum’а (выбирается компромиссом; наиболее важно то, что вы собираетесь делать, а не то, что вы уже сделали)
    • обеденный: утром вам надо попытаться вспомнить, чем вы обещали команде заниматься сегодня;
    • утренний: утром, вам надо попытаться вспомнить, чем вы занимались вчера, чтобы можно было отчитаться об этом.

Истории, написанные на стикерах наклеиваются на доску по убыванию приоритета. В ходе обсуждения порядок меняется. История дробится на задачи, стикеры с задачами клеятся под стикером соответствующей истории. Мы не добавляем задачи в product backlog в Excel’е потому, что:

  • Список задач обычно часто меняется (задачи могут изменяться и пересматриваться на протяжении sprint’а. Чтобы синхронизировать с ними product backlog в Excel’е нужно слишком много усилий);
  • Скорее всего, на этом уровне детализации product owner не будет участвовать в процессе.

Оптимальный объём истории — от двух до восьми человеко-дней. При средней производительности команды в 40 – 60 человеко-дней позволяет включать в спринт примерно по 10 историй. Иногда 5, а иногда 15.

Истории — это нечто, что можно продемонстрировать, что представляет ценность для product owner’а

Задачи — либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a.

Подсчёт производительности

Техника “вчерашней погоды”. Определения.

Производительность является мерой “количества выполненной работы”. Рассчитывается как сумма первоначальных оценок всех историй, которые были реализованы в течение спринта.

Доступные человеко-дни — сумма всех человеко-часов (полной и частичной занятости) с учётом отгулов и больничных каждого члена команды на протяжении спринта, делённое на продолжительность рабочего дня.

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

Реальная производительность — сумма первоначальных оценок завершённых за последний спринт историй. Единица измерения — story-point.

Расчёт производительности.

Фокус-фактор = Реальная_производительность / Доступные_человеко-дни

Прогнозируемая_производительность = Доступные_человеко-дни * Фокус-фактор

Критерий готовности

Product owner и команда совместными усилиями определяют критерий готовности. Например

  • “история готова к развёртыванию на живом сервере”
  • “развёрнуто на тестовом сервере и готово к приёмочному тестированию”
  • “история готова тогда, когда так считает тестировщик из нашей Scrum-команды” (проверка того, что пожелания product owner’а были правильно восприняты командой, остаётся на совести тестировщика)

Истории очень отличаются друг от друга. Таким образом невозможно определить общий критерий готовности. Поэтому здравый смысл часто лучше, чем формальный контрольный лист. Если вы часто путаетесь с определением критерия готовности, то вам, наверное, стоит ввести поле “критерий готовности” для каждой истории.

Критерий готовности можно определить:

  • уточнённым описанием истории (должно быть кратким и лаконичным)
  • игрой в planning poker
  • описанием, как продемонстрировать эту user-story.

Простое описание часто позволяют обнаружить разное понимание объёма работ для историй. Хорошо ведь узнать об этом заранее, не так ли?

Приоритеты процесса планирования

  1. Цель спринта и дата демонстрации
  2. sprint backlog
  3. оценки для каждой истории из sprint backlog`a
  4. «как продемонстрировать» для каждой истории sprint backlog`a
  5. расчёты производительности и ресурсов
  6. определённое время и место проведения ежедневного Scrum’а
  7. истории, разбитые на задачи (разбивать истории на задачи можно также и по мере их поступления в работу, совмещая это с ежедневным Scrum’ом, но не рекомендуется)

Технические истории (нефункциональные требования)

ТИ — это всё, что должно быть сделано, но невидимо для заказчика, не относится ни к одной user story, и не даёт прямой выгоды product owner’у. Для него приоритезировать ТИ в product backlog’е было всё равно, что сравнить тёплое с мягким. Поэтому они получают самый низкий приоритет. В некоторых случаях product owner действительно прав, но чаще — нет. Product owner не всегда компетентен, чтобы идти на компромисс по приотретизации ТИ. Что можно с этим сделать:

  • Стараться избегать ТИ. Искать способ превратить ТИ в нормальную историю с измеряемой ценностью для бизнеса;
  • Если не получается превратить техническую историю в обычную, попытаться включить эту работу в уже существующую историю (например, «рефакторинг доступа к данным» мог бы стать частью истории «редактировать пользователя», поскольку она подразумевает работу с данными);
  • Если оба подхода не сработали — отмечаем это как техническую историю и храним список таких историй отдельно. Пусть product owner видит список, но не редактирует. В переговорах с product owner’ом используем параметры “фокус-фактора” и “прогнозируемой производительности” и выделяем время в спринте для реализации технических историй.

Основополагающий принцип Scrum`а — прозрачность. Поэтому желательно информировать product owner`а о необходимых ТИ, а не просто ставить перед фактом определённого (заниженного ради ТИ) фокус-фактора. При этом product owner должен быть сообразительным и компетентным.

Баг-трекер

Варианты работы с БТ:

  • Product owner распечатывает самые высокоприоритетные задачи из БТ, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет).
  • Product owner создаёт истории, соответствующие задачам из БТ. Например, “Исправить самые критические ошибки отчётности в админке, #124, #126, и #180”.
  • Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50%), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в БТ.
  • Заносим product backlog в БТ (просто переносим из Excel’а). Считаем баги обычными историями.

Информация

Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или – что ещё хуже – придумывать всякие ужасы про вас. Для этого можно использовать “страницу с информацией о спринте”:

  • Название команды
  • Цель
  • Sprint backlog (истории и как продемонстрировать)
  • Расписание (интервал спринта, дата демо, место и время ежедневного scrum`а)
  • Состав команды

Эта страница помещается в вики (и список всех команд и спринтов), уходит рассылкой по почте, вывешивается в печатном виде в коридоре, при приближении демо уходит рассылка с напоминанием (это всё делает scrum master).

Sprint backlog

Доска (канбан) состоит из 4х колонок (в планах в процессе, готово, доп.инфо).  Каждая строка — отдельная user-story с задачами в порядке убывания приоритета (сверху вниз). По мере выполения задачи продвигаются из «в планах»  через «в процессе» в «готово». В информационной части фиксируется цель спринта, burndown-chart, незапланированные, но необходимые к выполнению задачи, не вошедшие в изначальный sprint-backlog и дополнительные user-story, которые желательно выполнить, если запланированные user-story будут закончены до окончания спринта.

Простота доски необходима. Усложнять незачем. Так же на карточке задачи можно фиксировать имя исполнителя и/или идентификатор в баг-трекере.

Burndown chart

По оси X отмечаются только рабочие дни до окончания спринта. По оси Y — прогнозируемый объём оставшейся работы (в story-point`ах). Изменения оставшейся работы фиксируются ежедневно. ScrumMaster несёт ответственность за то, чтобы команда принимала соответствующие меры при обнаружении первых тревожных симптомов (сильном отклонения кривой story-pointt`ов от линии нормального хода спринта).

Оценивание в днях или часах?

В большинстве источниках, посвящённых Scrum’у, время выполнения задач оценивается в часах, а не днях (например один эффективный человеко-день равен шести эффективным человеко-часам). Но так лучше не делать потому, что :

  • оценки в человеко-часах чересчур мелкие, что приводит к появлению большого количества крохотных задач по часу или два, и, как результат, к микроменеджменту (micromanagement);
  • оказалось, что всё равно все оценивают в человеко-днях, а когда нужно получить оценку в человеко-часах, просто умножают дни на шесть. «Хм, эта задача займёт примерно день. Ага, я должен дать оценку в часах. Что ж, значит шесть часов».
  • Две разных единицы измерения вводят в заблуждение. «Это оценка в человеко-днях или человеко-часах?»

Поэтому лучше использовать человеко-дни в качестве основной единицы при оценке времени (называть их story point’ами). При этом выбрать наименьшим значением 0.5. Т.е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто.

Ещё

Усадите команду вместе

  • В пределах слышимости (каждый в команде может поговорить с любым другим членом команды без крика и не вставая из-за своего стола)
  • В пределах видимости (каждый член команды может увидеть любого другого. Каждый может видеть доску задач. Не обязательно быть достаточно близко, чтобы читать, но, по крайней мере, видеть)
  • Автономно (если вдруг вся ваша команда поднимется и начнет внезапную и очень оживлённую дискуссию об архитектуре системы, никого из не-членов команды не окажется достаточно близко, чтобы ему это помешало. И наоборот. Автономно — не значит, что команда должна быть полностью изолирована. В пространстве, разделённом на секции, вполне может хватить отдельной секции для команды, с достаточно высокими стенами, чтобы не пропускать большую часть шума извне)

Не подпускайте

  • Pproduct owner’а слишком близко. Product owner должен находиться настолько близко к команде, чтобы в случае возникновения вопросов, команда могла бы спросить его лично, и чтобы он имел возможность на своих двоих подойти к доске задач. Но он не должен сидеть в одной комнате с командой. Потому что есть вероятность, что он не сможет не вдаваться в подробности, а команда не сможет правильно сработаться (т.е. не достигнет состояния полной автономности, самомотивации и сверхпродуктивности).
  • Менеджеров и тренеров слишком близко. Если вы Scrum-тренер (и возможно совмещаете эту роль с ролью менеджера), не бойтесь очень плотно работать с командой. Но только в течение определённого промежутка времени, а потом оставьте команду в покое и дайте ей возможность сработаться и самоорганизоваться. Время от времени контролируйте её (однако не очень часто). Это можно делать, посещая демо, изучая доску задач или принимая участие в ежедневном Scrum’е.

Ежедневный Scrum

Проводится для поддержания sprint backlog’a в актуальном состоянии. Лучше, чтоб этим занималась вся команда.

Лучше проводить встречу стоя (уменьшает вероятность затягивания «планёрки» более чем на 15 минут)

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

Либо все члены команды обновляют доску задач перед каждой встречей.

Как только рассказ касается какого-то незапланированного задания — для него клеится новый стикер.

При обновлении временных оценок, на стикере пишется новая оценка, а старая зачеркивается. Иногда стикерами занимается ScrumMaster, пока участники говорят.

Опоздания

Можно завести специальную копилку. Если вы опоздали, даже на минуту, вы кидаете в копилку определённую сумму. Даже если вы позвонили перед началом ежедневного Scrum’а и предупредили. Этот подход работает неплохо. Но пользоваться им нужно лишь в том случае, когда люди часто опаздывают.

Если кто-то не знает чем себя занять

  • Можно просто передать слово следующему. При этом взять его на карандаш .
    • После того, как все высказались, пробежаться вместе с командой по доске задач и проверить, что данные на доске задач актуальные и что все понимают смысл каждой истории.
    • Предложить каждому участнику команды приклеить новые стикеры.
    • Возвращаемся к тем, кто не знал, чем себя занять, с вопросом «после того, как мы прошлись по доске, не появилось ли у вас представление о том, чем заняться?» Обычно появляется.
    • Если же нет, можно выяснить есть ли возможность для парного программирования.
  • Обратиться к цели спринта
    • Попросить продемонстрировать цель спринта (выполнить то, что там написано).
    • В случае не готовности спросить, что нужно сделать для демонстрации.
    • Клеим новые стикеры, назначаем.
  • Просто наклеить новые стикеры.

Демо

Демо необходимо:

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

Подготовка и проведение демо:

  • Постарайтесь как можно более чётко озвучить цель данного спринта. Уделить пару минут, чтобы ввести всех в курс дела.
  •  Не тратьте много времени на подготовку демо или создание презентации. Выкиньте всё ненужное и сконцентрируйтесь на демонстрации только реально работающего кода.
  • Следите, чтобы демо проходило в быстром темпе. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо.
  • Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали. Сфокусируйтесь на том «что мы сделали», а не на том «как мы это делали».
  • Если это возможно, дайте аудитории самой попробовать поиграть с продуктом.
  • Не нужно показывать кучу исправлений мелких багов и элементарных фич. Вы можете упомянуть о них, но демонстрировать их не стоит, потому что это заберёт у вас много времени.

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

Ретроспективы

Ретроспектива — второе по важности действие в Scrum`е (после планирования). Ретроспектива важна, т.к. это самое подходящее время для начала улучшений.  Без ретроспектив вы обнаружите, что команда наступает на одни и те же грабли снова и снова.

Ретроспективы могут и не иметь чёткого плана проведения, но главная тема – всегда одна и та же: «Что мы можем улучшить в следующем спринте». В основном ретроспективу можно проводить так:

  • Выделяем 1-3 часа, в зависимости от того насколько долгая ожидается дискуссия.
  • Участвуют: product owner, вся команда и ScrumMuster.
  • Расположиться либо в отдельной комнате, либо на террасе. Хорошо, чтоб дискуссия проходила в спокойной и непринуждённой атмосфере.
  • Не проводить ретроспективы в рабочей комнате, так как это рассеивает внимание участников.
  • Выбрать кого-то в качестве секретаря.
  • ScrumMaster показывает sprint backlog и при участии команды подводит итоги спринта. Важные события, выводы и т.д.
  • Начинаем «серию» обсуждений. В этот момент каждый имеет шанс высказаться о том, что, по его мнению, было хорошего, что можно было бы улучшить и что бы он сделал по-другому в следующем спринте. При этом его никто не перебивает.
  • Мы сравниваем прогнозируемую и реальную производительность. Если имеются существенные расхождения, то пытаемся проанализировать и понять, почему так получилось.
  • Когда время подходит к концу, ScrumMaster пытается обобщить все конкретные предложения по поводу того, что мы можем улучшить в следующем спринте.

Доска ретроспективы делится на 3 колонки:

  1. Хорошо (если нужно было бы повторить этот спринт ещё раз, то мы бы сделали это точно так же).
  2. Могло бы быть и лучше (если нужно было бы повторить этот спринт ещё раз, то мы бы сделали  это по-другому).
  3. Улучшения (конкретные идеи о том, как в будущем можно что-то улучшить).

После окончания мозгового штурма по поводу всех этих стикеров, провести  «точечное голосование» для определения улучшений, которым следует уделить особое внимание в ходе следующего спринта. У каждого члена команды имеется три магнитика, которыми он может воспользоваться для голосования. Каждый член команды может лепить магнитики как ему вздумается, хоть все три сразу на одну задачу. Основываясь на этом голосовании выбрать 5 улучшений, которые попытаться внедрить в следующем спринте, а на следующей ретроспективе проверить, что вышло.

Важно учиться на ошибках. Возможные способы решения проблем, найденных командой на ретроспективе, могут оказаться
полезными для остальных. Роль связующего звена тут может выполнять ScrumMaster. Можно писать отчёт, но их никто не читает.  Сотрудник в роли связующего звена должен:

  • быть хорошим слушателем;
  • быть готов задать простой, но меткий вопрос, который подтолкнёт людей на дискуссию, если ретроспектива проходит очень вяло. Например: «Если бы можно было переделать этот спринт с самого первого дня, чтобы вы сделали по-другому?»;
  • согласен тратить своё время на посещение всех ретроспектив всех команд;
  • обладать необходимыми полномочиями, которые помогли бы ему взяться за выполнение предложенных командой улучшений, выходящих за пределы возможностей самой команды.

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

Отдых между спринтами

В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой. То же справедливо для Scrum’а и для разработке программного обеспечения в целом. Спринты очень изматывают. Мало кто может похвастаться: «Я потратил большую часть дня, положив ноги на стол, просматривая блоги и попивая капучино».

Ещё аргумент — после демо и ретроспективы команда и product owner будут переполнены информацией и всевозможными идеями, которые им следовало бы обмозговать. Если же они немедленно займутся планированием следующего спринта, то они не смогут упорядочить всё полученную информацию или сделать надлежащие выводы. К тому же у product owner’а не хватит времени для корректировки его приоритетов после проведённого демо.

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

Один из вариантов — инженерные дни. Это когда разработчикам разрешается делать по сути все, что они хотят. (читать о последних средствах разработки и API, готовиться к сертификации, обсуждать компьютерные занудства с коллегами, заниматься своим личным проектом, поддерживать актуальность своих знаний). Хорошо, если удастся проводить инженерный день для всех команд сразу (будут воспринимать более серьёзно). Может быть фиксированный (первая пятница каждого месяца), либо плавающий (в конце каждого спринта).

Оставшуюся часть книги законспектирую чуть позже.

Scrum и XP: заметки с передовой. Конспект. Часть 1.: 1 комментарий

  1. Отличная выжимка из книги в которой и так «воды» было мало! Тут же вовсе все по-сути! Спасибо.

Обсуждение закрыто.