Definition of Ready. Что это?

На днях нам написал создатель Telegram-канала «Санёчек если что». Под этим смелым названием скрывается Александр Гоманов, и пишет он об IT, саморазвитии и просто о жизни.

Александр зашёл к нам с козырей и написал, что применил бы пару идей из этого блога, чтобы наконец-то начать выполнять обещания, а обещал он всерьёз взяться за канал. Настрой у него был действительно решительный, и потому в этом посте мы рассказываем о его канале, а он в своём посте напишет о нашем.

Но просто сказать «читайте вот такой-то клёвый канал» показалось нам занятием неинтересным. Не тому нас учили великие властители подписчиков Telegram'а! Потому мы решили освоить эту задачу вдумчивее. Слово за слово зашёл разговор о том, что Александр несколько месяцев вёл домашнее хозяйство по Scrum — гибкую методологию организации рабочих процессов и решения различных задач. У этого способа разработки продукта есть как поклонники, так и отрицатели, но не признать его значительное влияние на индустрию IT нельзя. И потому для начала...

Что команде необходимо знать о методологии Scrum

Итак, мы говорим о совокупности подходов к совместной работе в команде, созданных Кеном Швабером и Джеффом Сазерлендом. Прежде всего Scrum использовался для разработки программного обеспечения, но вскоре он завоевал все ниши, где требовался комплексный подход к решению бизнес-задач. Scrum превзошел многих своих конкурентов и заслужил невероятный успех, поскольку был создан для реализации разных продуктов именно через конечную пользовательскую бизнес-ценность.

Проще говоря, разработчики ориентировались не столько на техническое задание, которое требовалось создать самому заказчику - они отталкивались от так называемых User Story (или US) — историй пользователя, которые близки для понимания и заказчикам, и создателям.

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

Сам этот процесс выполнения называется «спринт» — то есть конкретный отрезок времени, в течение которого User Story будет отрабатываться, реализовываться. Но какие задачи стоит брать команде в работу (в спринт), а на какие не стоит тратить силы и время? Здесь могут помочь критерии готовности.

Критерии готовности формируются самой командой, что обеспечивает прозрачность и понимание задач всеми участниками. А это и есть наш сегодняшний главный герой, тот самый Definition of Ready.

Definition of Ready (DoR): кое-что про критерии готовности

Начнем с важного пояснения: в Scrum используются два инструмента — Definition of Ready (DoR) и Definition of Done (DoD). В русском переводе книги Scrum [1] от одного из создателей этого фреймворка Джеффа Сазерленда они называются «готовность» и «выполненность» соответственно. Но что это значит на деле? Разбираемся.

Как мы говорили, в какой-то момент разработчики программного обеспечения, создатели пользовательских продуктов и других проектов сталкиваются с вопросом, какие задачи можно и нужно брать в работу, то есть в спринт. При этом важно оценить объем работ, необходимый для выполнения задач, и определить, когда задача может перейти из бэклога в активную работу.

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

В этом посте мы ведем речь именно о критериях «готовности» задач к работе, Definition of Ready. По всему интернету разбросано множество вторичных материалов на тему определения готовности, информация иногда разнится, но мы, чтобы не путать вас и не путаться самим, обратимся к первоисточникам. В качестве таковых мы выбрали Scrum Guide [2], книгу Кена Швабера, одного из соавторов методологии. Также мы заглянули в книги Джея Сазерленда, сына первого создателя, Джеффа Сазерленда; он тоже писал о Scrum.

Удивительно, но об этом важном списке хоть сколько-либо внятно написано лишь в одном источнике из упомянутых — как раз в книге Джефа Сазерленда Scrum. Поехали разбираться!

Acceptance criteria: как создать рабочие критерии приемки

Итак, команда приступила: разработка стартовала, заказчик в ожидании. Важным элементом рабочего процесса становится именно оценка задач. Каковы же критерии подготовленности задачи, которую можно взять в разработку? Существует ли где-то перечень, на который можно ориентироваться? Оказывается, да: Джеф Сазерленд имеет в виду вполне конкретный список, рекомендованный для проверки готовности пользовательской истории (той самой User Story) к разработке.

Список этот составил «вдумчивый исследователь и серьёзный программист Билл Уэйк». Первые буквы его пунктов ловко ложатся в аббревиатуру INVEST, «инвестируй». Модель INVEST помогает создавать качественные элементы рабочего процесса, такие как задачи или требования, определяя для них чёткие критерии оценки готовности и ценности.

Вот как она расшифровывается: Independent, Negotiable, Valuable, Estimable, Small, Testable. Далее последует описание каждого критерия в виде прямой цитаты из книги Scrum с пояснениями каждого пункта:

— Завершенность, выполнимость, независимость (Independent). История должна быть: абсолютно завершенной; осуществимой на практике; независимой от разных обстоятельств.

— Открытость (Negotiable). История до своего завершения должна быть открыта для общего обсуждения; любой участник группы должен иметь возможность внести в нее свои поправки.

— Ценность (Valuable). История должна приносить реальную пользу и увеличивать ценность проекта для заказчиков, пользователей и любых заинтересованных лиц.

— Оценочность (Estimable). История должна быть удобна для оценки объема работы.

— Лаконичность (Small). История должна быть краткой, компактно изложенной и конкретной, чтобы можно было просто и быстро планировать работы. Если история получилась слишком расплывчатой, перепишите ее, а лучше разбейте на мелкие функциональные фрагменты.

— Тестируемость (Testable). История должна пройти проверку - тестирование - на практике, чтобы считаться завершенной. Составьте заранее список критериев, которым должна соответствовать законченная история.

В своей практике построения команд разработки мы сталкивались со списком INVEST и даже пытались его применить. Какой совет можно дать тому, кто захочет использовать этот подход и у себя в команде?

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

Более того, не надо стремиться к скорому принятию непонятных команде критериев: помните, у каждой компании свои представления о том, что значит тот или иной критерий, и представления эти могут разниться в разном контексте. Как же собрать воедино все интерпретации?

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

Зачем это делается? Дизайн не ограничивается только пользовательским интерфейсом или только кодом. Грамотный дизайн, в частности проектирование изменений важны и для вашей команды, для построения удобных для работы процессов. Вываливать на команду разом все критерии — это неграмотный дизайн.

Помните: важно вовлекать всю команду в процессы формирования критериев готовности и достижения целей — это повышает ответственность и эффективность команды. Так шаг за шагом и получится ввести инструмент DoR в работу.

Definition of Done (DoD): а это для чего?

А что же в финале спринта, когда мы команда ощутила пользу от DoR, и user story, соответствующая всем критериям, завершена? А завершена ли на самом деле? Здесь вступает в игру Definition of Done — список критериев, которые оценивают выполненность задачи.

Но об этом чуть позже — про критерии приёмки для уже сделанной разработки рассказано во второй части статьи.

Спасибо за прочтение, а также спасибо Александру, автору канала «Санёчек если что», за вдохновение на её написание. Переходите в его канал читать несколько постов про методологии разработки, завершающиеся постом про Scrum. Подписывайтесь, ведь надо поддержать человека, твёрдо решившего регулярно публиковаться на IT-темы.

Список ссылок

[1] Джефф Сазерленд, «Scrum. Революционный метод управления проектами», ISBN 978-5-00057-722-6
[2] The 2020 Scrum Guide с сайта Scrum Guides