Самый знаменитый список разработки ПО. Часть 1, Definition of Ready

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

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

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

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

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

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

Хотя я и знал о существовании DoR до написания этой статьи, я не помнил, что Джеф Сазерленд имеет в виду вполне конкретный список, который он рекомендует для проверки готовности пользовательской истории к разработке. Пользовательской историей в Scrum называют такую работу для команды, которая в результате окажется заметным для пользователя изменением продукта.

Список этот составил «вдумчивый исследователь и серьёзный программист Билл Уэйк». Первые буквы его пунктов ловко ложатся в аббревиатуру INVEST, «инвестируй». Вот как она расшифровывается: Independent, Negotiable, Valuable, Estimable, Small, Testable. Далее будет цитата из книги Scrum с пояснениями каждого пункта:

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

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

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

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

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

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

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

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

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

Во второй части статьи будет рассказано про критерии приёмки для уже сделанной разработки, про Definition of Done.

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

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