И хотя коллаборация с клиентом намного важнее этого контракта — он все же есть в методологии, и польза его не вызывает сомнений. Мне кажется, это именно потому, что соглашение по поводу базовых терминов является основой здоровой buyer definition of done что это collaboration. Чтобы фраза «it’s done» не вызывала в будущем боли несоответствия ожиданиям, а вызывала приятную улыбку взаимопонимания. И мне кажется, что это важный момент в понимании смысла и назначения DoD. Потому что тут может случайно произойти подмена.
Умные ребята говорят, что неплохо бы договориться о том, когда работа считается выполненной. Очень важно, говорят, одинаково понимать, что это означает – работа выполнена. Не стремиться создать жёсткий стандарт, запрещающий всё, что в него не вписывается. Для отдельных фичей требуются дополнительные acceptance standards, которых нет в общем DoD? Там должны быть минимальные требования к тому, что можно считать готовым. Возможно, проект так и не вышел на желаемый уровень качества кода; по сроку должна бы уже быть зрелая стадия развития, а по факту ещё нет.
Важно не забывать про часть работы, оставшуюся в Undone, и стараться делать эту часть максимально прозрачной для всех участников процесса разработки. Также важно следить чтобы у Undone Work были ответственные люди. Чем больше Undone Work, тем больше у нас расходятся взгляды на готовность фичи/задачи между менеджерами и разработчиками. Из этого следует, что чем сильнее у нас Definition of Carried Out, тем ближе мы к состоянию Doubtlessly shippable.
Это не более, чем внутренний чеклист команды, позволяющий убедиться, что принятный на проекте техпроцесс соблюдён. Definition of Accomplished — полезный инструмент, с помощью которого можно повысить производительность и прозрачность процессов, сократить время на выполнение и сделать все работы однозначными. Но его нужно использовать с умом и адаптировать под нужды проекта, команды и клиентов. Например, Definition of Carried Out (DoD) в IT для одного разработчика может выражаться в завершении основной фазы работы, но до тестов и код-ревью.
Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц. Так как же Команде разработчиков договориться https://deveducation.com/ с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done) — это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать «Готово». Этим команда заверяет, что продукт сделан правильно. Строго говоря, помогать отбиваться от неудобных вопросов — не то, чтобы самое прямое назначение DoD.
А уже если клиент захочет вставить туда своих 5 копеек, то нужно с ним договориться и принять общее решение. Определение выполненности — это стабильный список критериев приёмки, которому должен соответствовать каждый результат работы команды. Часто бывает удобно, когда список принимает форму чек-листа. Перед завершением задачи команда проходится по его пунктам и отмечает удовлетворённые требования к качеству.
«Done» на этом уровне может относиться к стратегическому приоритету организации или другому набору функций, удовлетворяющих потребности рынка. Использование Definition of Carried Out снижает количество переделок, предотвращая продвижение пользовательских историй, не соответствующих определению, в среды более высокого уровня. Это предотвращает поставку нововведений, которые не соответствуют определению, клиенту или пользователю.
К примеру, если у вас стори на разработку модуля оплаты (извините за совершенно заезженный кейс), то Acceptance standards будет, скажем, успешная оплата картами Visa и Mastercard. Только клиент решает сделан функционал или же нет. Ему в этом могут помочь acceptance criteria, что в свою очередь он должен подписать их кровью перед началом разработки.
Только после составления такого соглашения всем будет понятно, что на фразе «ужин готов» пора садиться за стол. Данное соглашение позволяет нам минимизировать наш Undone Work и максимально приблизиться к состоянию Potentially shippable. Так же оно помогает структурировать ту работу, которую инженеры выполняют в Development процессе. При таком DoD, в рамках Undone Work у нас могут быть активности за рамками инженерной части, например, подготовка маркетинговых материалов. Когда вас в следующий раз спросят, как дела с разработкой в целом, вспомните про DoD.
Здесь речь идёт о возвращении ветерана к мирной жизни. Не в смысле физического его возвращения домой, а в смысле обретения спокойствия в мирной деятельности. Общее у этого отрывка и у определения выполненности состоит в том, что и командам, строящим процесс по Scrum, необходимо самостоятельно определить для себя, что такое выполненная задача. Если клиента не расстраивают, как Винни-Пуха, длинные слова, всегда лучше донести до него наш подход. И показать, что мы занимаемся качеством системно.
Думаю, ни один проект не будет успешен, если не привести бизнес и технологию к общему знаменателю, и в этой связи Definition of Accomplished выглядит одним из критически важных инструментов такого приведения. Еще один важный инструмент обучения — регулярно проводить обсуждения Definition of Carried Out и готовность продукта. На таких собраниях каждый сотрудник может высказать свое мнение, почувствовать ответственность за продукт и выполнение всех пунктов DoD, которые от него зависят.
Более того, старается его минимизировать, и как раз считает, что DoD — это путь к минимизации коммуникаций (еще бы, она названа Болью в статье!). Каменщик ведь не пытался построить оперный театр вместо дельфинария, он просто соблюдал технологию процесса. Вот мы и подобрались к главному вопросу, на который значительная часть Команд отвечает неправильно. Прямо или косвенно спрашивает разрешения на включение в оценку по времени, к примеру, код ревью или юнит-тестов. Или другими словами, просит Клиента участвовать в формировании содержания Definition of Done Веб-программирование.
© Copyright. Tutti i diritti riservati.