Scrum и XP: заметки с передовой

но тут ScrumMaster говорит: «Минуточку! У нас нет оценки для истории „добавить пользователя“. Давайте- ка оценим!». После пары сдач в planning poker, команда сходится на оценке в 20 story point’а, на что product owner вскакивает с криком: «ЧЕГООО?!?». Пара минут ожесточённых споров и вдруг выясняется, что команда имела в виду «удобный web-интерфейс для функций добавить, редактировать, удалить и искать пользователей», а product owner имел в виду только «добавлять пользователей напрямую в базу данных с помощью SQL-клиента». Команда оценивает историю заново и останавливается на 5-ти story point'ах.

Пример № 2:

Команда и product owner вполне довольны планом на спринт и уже готовы закончить планирование, но тут Scrum master говорит: «Минуточку! Вот тут у нас есть история „добавить пользователя“… Как она может быть продемонстрирована?». Народ пошепчется и через минуту кто-то встанет и начнёт: «ну, для начала надо залогиниться на сайт, потом…», a product owner тут же перебьёт: «залогиниться на сайт?! Не- не-не-не… эта функция вообще к сайту не должна иметь никакого отношения — это будет просто маленький SQL-скрипт, только для администраторов».

Поле «как продемонстрировать» может (и должно) быть очень кратким! Иначе вы не успеете вовремя закончить планирование спринта. По сути, это лаконичное описание на обычном русском языке, как вручную выполнить наиболее общий тестовый пример: «Сделать это, потом это, потом проверить, что получилось так-то».

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

Разбиение историй на более мелкие истории

Истории должны быть не слишком маленькими, но и не слишком большими (в смысле оценок). Если вы получили кучу историй в половину story point'a, то вы наверняка падёте жертвой микроменеджмента. С другой стороны, история в 40 story point'oB несёт в себе риск того, что к концу спринта её успеют закончить лишь частично, а незавершённая история не представляет ценности для вашей компании, она только увеличивает накладные расходы. Дальше — больше: если ваша прогнозируемая производительность 70 story point'oB, а две наиболее важные истории оценены в 40, то планирование несколько усложнится. Команда станет перед выбором: или расслабиться (т. е. включить в спринт только одну историю), или взять на себя невыполнимые обязательства (т. е. включить обе).

Я считаю, что практически всегда есть возможность разбить историю на более мелкие. Однако, в этом случае нужно следить за тем, чтобы меньшие истории всё ещё представляли ценность с точки зрения бизнеса.

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

Разбиение историй на задачи

Секундочку… В чём разница между «задачами» и «историями»? Очень правильный вопрос.

А различие очень простое: истории это нечто, что можно продемонстрировать, что представляет ценность для product owner'a, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner'a.

Пример разбиения истории на более мелкие:

Пример разбиения истории на задачи:

Несколько интересных наблюдений:

• Молодые Scrum-команды не любят тратить время на предварительное разбиение историй на задачи. Некоторые считают это «водопадным» подходом.

• Абсолютно понятные истории разбивать на задачи заранее так же легко, как и по мере их выполнения.

• Такая разбивка часто позволяет выявить дополнительную работу, которая увеличивает оценку, чем обеспечивается более реалистичный план на спринт.

• Такая предварительная разбивка заметно увеличивает эффективность ежедневного Scrum'а (см. стр. 46 «Как мы проводим ежедневный Scrum»).

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

Итак, чтобы успеть разбить истории на задачи, мы стараемся выделить достаточно времени на планирование спринта. Однако, если время поджимает, то разбиение на задачи мы можем и пропустить (см. следующую главу «Когда пора остановиться»).

Примечание: мы практикуем TDD (разработку через тестирование), из-за чего первой задачей почти каждой истории является «написать приёмочный тест», а последняя — «рефакторинг» (улучшение читабельности кода и удаление повторений кода).

Выбор времени и места для ежедневного Scum’а

Все часто забывают, что на планировании спринта, помимо всего прочего, необходимо выбрать время и место проведения ежедневного Scrum'а. Без этого ваш спринт обречён на неудачный старт. Ведь первый ежедневный Scrum — это, по большей части, ввод мяча в игру, когда каждый решает с чего начать работу.

Я предпочитаю проводить ежедневный Scrum утром. Хотя, должен признаться, мы особо и не пробовали проводить его в обед или ближе к вечеру.

Недостатки обеденного Scrum'a: приходя на работу утром, вам надо попытаться вспомнить, чем вы обещали команде заниматься сегодня.

Недостатки утреннего Scrum'a: приходя на работу утром, вам надо попытаться вспомнить, чем вы занимались вчера, чтобы можно было отчитаться об этом.

Мне кажется, первый недостаток хуже, так как наиболее важно то, что вы собираетесь делать, а не то, что вы уже сделали.

Мы обычно выбираем самое раннее время, которое не вызывает стонов ни у кого в команде. Обычно это 9:00, 9:30 или 10:00. Очень важно, чтобы все в команде искренне согласились на это время.

Когда пора остановиться

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

У меня, например, приоритеты для встречи по планированию спринта такие:

Приоритет № 1: Цель спринта и дата демонстрации. Это тот минимум, с которым можно начинать спринт. У команды есть цель и крайний срок, а работать они могут прямо по product