Scrum - Как мы планируем спринт

Как по мне, планирование спринта – наиболее важная часть Scrum’a. Плохо проведённое планирование может испортить весь спринт.

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

Хорошо-хорошо, это было весьма расплывчатое определение. Давайте лучше поговорим о том, что должно быть итогом планирования:

• Цель спринта.
• Список участников команды (и степень их занятости, если она не стопроцентная).
• Sprint backlog (список историй, которые вошли в спринт).
• Дата демонстрации.
• Место и время проведения ежедневного Scrum’а.

Scrum - Как мы готовимся к планированию спринта

Не успеешь оглянуться – как наступил день планирования нового спринта. Мы не раз приходили к одному и тому же выводу:

Вывод: Убедитесь, что product backlog находится в нужной кондиции, прежде чем начинать планирование.

Что значит в нужной кондиции? Что все user story отлично описаны? Что все оценки трудозатрат корректны? Что все приоритеты расставлены? Нет, нет и ещё раз нет! Это значит:

• Product backlog должен существовать! (Кто бы мог подумать?)
• У каждого продукта должен быть один product backlog и один product owner.
• Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать.

1. Не волнуйтесь, если задачи с низким уровнем важности имеют одинаковые значения, скорее всего, они не попадут в текущий спринт, а, следовательно, не будут обсуждаться.
2. Все user story, которые, по мнению product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности.
3. Уровень важности используется исключительно для упорядочивания историй. Т.е. если история А имеет уровень важности 20, а история Б важность 100, это означает что Б важнее A. Это не означает, что Б в пять раз важнее А. Если Б присвоить важность 21 – смысл не поменяется!
4. Полезно оставлять промежутки из целых чисел между значениями на тот случай, если появится история В, более важная, чем А, но менее важная, чем Б. Конечно, можно выкрутиться, присвоив ей уровень важности 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 - Как мы ориентируем product backlog на бизнес

Если product owner – технарь, то он вполне может добавить историю вроде “Добавить индексы в таблицу Events”. Зачем ему это нужно? Да потому, что реальной целью этой истории, скорее всего, будет “ускорение поиска событий в панели управления”.

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

Когда я вижу технические истории подобные этой, я обычно задаю product owner’у вопросы вроде “Да, но зачем?”. Я делаю это до тех пор, пока не проявится истинная причина появления истории (в приведенном примере – повысить скорость поиска событий в панели управления). Первоначальное техническое описание проблемы можно поместить в колонку с примечаниями: “Индексирование таблицы Events может решить проблему”.

Scrum - Дополнительные поля для user story

Иногда мы используем дополнительные поля в product backlog’е. В основном для того, чтобы помочь product owner’у определиться с его приоритетами.

• Категория (track). Например, “панель управления” или “оптимизация”. При помощи этого поля product owner может легко выбрать все пункты категории “оптимизация” и установить им низкий приоритет.

• Компоненты (components) – указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений. Поле “компоненты” окажется особенно полезным, если у вас несколько Scrum команд, например, одна, которая работает над панелью управления и другая, которая отвечает за клиентскую часть. В данном случае это поле существенно упростит для каждой из команд процедуру выбора истории, за которую она могла бы взяться.

• Инициатор запроса (requestor). Product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.

• ID в системе учёта дефектов (bug tracking ID) – если вы используете отдельную систему для учёта дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.


Книга: Scrum и XP: заметки с передовой (Хенрик Книберг)

Scrum - Как мы работаем с product backlog'ом

Product backlog – это основа Scrum’а. С него все начинается. По существу, product backlog является списком требований, историй, функциональности, которые упорядочены по степени важности. При этом все требования описаны на понятном для заказчика языке. Элементы этого списка мы будем называть "историями", user story, а иногда элементами backlog'а. Описание каждой нашей истории включает в себя следующие поля:

• – уникальный идентификатор – просто порядковый номер. Применяется для идентификации историй в случае их переименования.

• Название – краткое описание истории. Например, “Просмотр журнала своих транзакций”. Оно должно быть однозначным, чтобы разработчики и product owner (владелец продукта) могли примерно понять, о чем идет речь, и отличить одну историю от другой. Обычно от 2 до 10 слов.

• Важность (Importance) – степень важности данной задачи, по мнению product owner'а. Например, 10. Или 150. Чем больше значение, тем выше важность. o Я предпочитаю не использовать термин “приоритет”, поскольку обычно в этом случае 1 обозначает наивысший приоритет. Это очень неудобно: если впоследствии вы решите, что какая-то история еще более важна, то какой "приоритет" вы тогда ей поставите? Приоритет 0? Приоритет -1?

• Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу “идеальных человеко-дней”. o Спросите вашу команду: “Если собрать команду из оптимального количества людей, то есть не слишком большую и не слишком маленькую (чаще всего из двух человек), закрыться в комнате с достаточным запасом еды и работать ни на что не отвлекаясь, то, сколько дней тогда понадобится на разработку завершённого, протестированного продукта, готового к демонстрации и релизу? “. Если ответ будет “Для трёх человек, закрытых в комнате, на это потребуется 4 дня”, это значит, что изначальная оценка составляет 12 story point’ов.

o В этом случае важно получить не максимально точные оценки (например, для истории в 2 story point’а потребуется 2 дня), а сделать так, чтобы оценки верно отражали относительную трудоёмкость историй (например, на историю, оцененную в 2 story point’а потребует примерно в два раза меньше работы по сравнению с историей в 4 story point’а).

• Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа “Сделайте это, сделайте то – должно получиться то-то”. o Если у вас практикуется Test Driven Development (разработка через тестирование или кратко TDD) , то это описание может послужить псевдокодом [пр. Переводчика: в программировании специальный способ записи любого алгоритма] для приемочного теста.

• Примечания – любая другая информация: пояснения, ссылки на дополнительные источники информации, и т.д. Обычно она представлена в форме кратких тезисов.

Product backlog (пример)
ID	Название	Важность	Предварительная оценка	Как продемонстрировать	Примечания
1	Депозит	30	5	Войти в систему, открыть страницу депозита, положить на счет €10, перейти на страницу баланса и проверить, что он увеличился на €10.	Нужна UML диаграмма последовательности. Пока что не стоит беспокоиться про шифрование данных.
2	Просмотр журнала личных транзакций	10	8	Войти в систему; перейти на страницу транзакций; положить деньги на счет; вернуться на страницу транзакций; проверить, что новая транзакция появилась в списке.	Чтобы избежать больших запросов к базе данных, стоит воспользоваться постраничным выводом информации. Дизайн такой же, как и у страницы просмотра пользователей.

Мы экспериментировали и с другими полями, но в итоге именно эти 6 оказались для нас самыми применимыми.

Обычно product backlog хранится в Excel таблице с возможностью совместного доступа (несколько пользователей могут редактировать файл одновременно). Хотя официально документ принадлежит product owner’у, мы не запрещаем другим пользователям редактировать его. Ведь разработчикам довольно часто приходится заглядывать в product backlog, чтобы что-то уточнить или изменить оценку предполагаемых трудозатрат.

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

Книга: Scrum и XP: заметки с передовой (Хенрик Книберг)

Scrum - начало

Собираетесь начать практиковать Scrum у себя в компании? Или вы уже работаете по Scrum’у пару месяцев? У вас уже есть базовые понятия, вы прочитали несколько книг, а, возможно, даже получили сертификат Scrum Master'а? Поздравляю!

Однако, согласитесь, какая-то неясность всё равно остаётся.

По словам Кена Швебера, Scrum – это не методология, это фреймворк. А это значит, что Scrum не дает готовых рецептов, что делать в тех или иных случаях. Вот незадача!

Но у меня для вас есть хорошая новость: я расскажу, как именно я практикую Scrum... очень подробно и со всеми деталями. Однако, и без плохой новости не обойдётся: я расскажу всего лишь о том, как практикую Scrum я. Это значит, что вам не обязательно делать всё точно так же.

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

Моё видение Scrum’а формировалось на протяжении целого года и стало результатом экспериментов в команде численностью около 40-ка человек. Одна компания попала в крайне сложную ситуацию: постоянные переработки, авралы, серьёзные проблемы с качеством, проваленные сроки и прочие неприятности. Эта компания решила перейти на Scrum, но внедрить его толком у неё не получалось. В итоге эта задача была поручена мне. К тому времени для большинства сотрудников слово «Scrum» было просто набившим оскомину термином, эхо которого звучало время от времени в коридорах без какого-либо отношения к их повседневной работе.

Через год работы мы внедрили Scrum на всех уровнях компании: поэкспериментировали со всевозможными размерами команд (от 3 до 12 человек), попробовали спринты различной длины (от 2 до 6 недель) и разные способы определения критерия готовности, разнообразные форматы product и sprint backlog'ов (Excel, Jira, учетные карточки), разные стратегии тестирования, способы демонстрации результатов, способы синхронизации Scrum-команд и так далее. Также мы опробовали множество XP практик: с разными способами непрерывной интеграции, с парным программированием, TDD (разработкой через тестирование), и т.д. А самое главное – разобрались, как все это дело сочетается со Scrum'ом.

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

Ой, простите, я совсем забыл про новичков в Scrum'е и XP. Если вы к ним относитесь, вам не мешало бы посетить следующие веб-ресурсы:

• http://agilemanifesto.org/
• http://www.mountaingoatsoftware.com/scrum
• http://www.xprogramming.com/xpmag/whatisxp.htm

Книга: Scrum и XP: заметки с передовой (Хенрик Книберг)