Definition of Done
Вы это уже сделали?
Что отвечать на такой вопрос рядовому сотруднику? Варианта два, но оба они данному работнику могут и не понравиться. Если он отвечает «да», то это означает, что он может взять ещё работу на исполнение. А вдруг потом окажется, что ему нужно доделать старую? Также если он отвечает «нет», то его могут посчитать медлительным и обвинить в том, что он тормозит процесс.
Такой вопрос обычно задается бесчисленное количество раз при разработке какого-либо программного продукта, да и в целом во время рабочего процесса. В этих моментах, как и в любых других, должна быть оптимизация, способная минимизировать или исключить полностью негативные стороны этого процесса. Вообще выражение Definition of Done в полной мере понятно людям, знакомыми с философией Scrum. Определенно, сделанная задача – это та задача, которая не нуждается в доработках. Но тут встаёт закономерный вопрос: а как определить, что задача действительно выполнена?
Изначально подобный вопрос может поставить в тупик. Ну что значит, как определить? Выполнена – значит выполнена, не выполнена – значит не выполнена.
Давайте посмотрим банальный пример про разработку чего-нибудь, например, части программы. Скажем, мы написали какой-то функционал и вроде как закончили, однако мы понимаем, что наш функционал может иметь баги (ошибки), которые, например, сейчас не могут быть проверены, так как не готовы другие модули, позволяющие протестировать его. Получается, ставя напротив этой задачи «Выполнено», мы немного лукавим, ведь нам к ней так и так придётся возвращаться. Даже если есть модули для тестирования, необходимо ли тестировать? Может следует поставить «Выполнено» только после результатов Code Review? Как мы видим, у нас очень много вопросов, которые мешают нам правильно построить работу. Из-за нашей неопределенности возникают очень большие проблемы. Мало того, что мы сами можем не понять, сделали ли мы до конца, а уж другие члены группы точно не смогут разобраться. Как вы уже, наверное, догадались Definition of Done и призвана исправить это, чтобы не дать нам повода для беспокойства!
Definition of Done на страже нашего спокойствия
На самом деле, на страже общего спокойствия. Мы, действительно, не всегда можем понять до конца, закончена ли наша задача. Однако оповестить команду о том, что же мы всё-таки сделали – обязаны. Definition of Done, как и всё в Scrum, должно быть лаконично, поэтому, зачастую, отводится для этого лишь одно предложение. Но это не единственный вариант.
Для примера приведём несколько выполненных задач с использованием Definition of Done:
- done = функционал оплаты реализован, проведено тестирование с тестировщиком Алексеем;
- done = разработан документ по спецификации, проведено обсуждение с клиентами;
- done = модуль авторизации разработан полностью, протестирован, продемонстрирован на Sprint Review Meeting
- done = модуль полностью реализован и выгружен для использования.
Как видно, любое описание начинается с «done =», что даёт понять, на что обращать внимание. Вообще, принято в листе писать такие результаты, которые можно проверить. Нет смысла описывать мысли, ведь, скажем «done = придуман внешний вид интерфейса корзины» звучит странно, и проверить это никак нельзя.
Желательно изначально разработать список правил, которые будут описывать Definition of Done, чтобы все в команде писали в одном стиле. Это приведёт к более быстрому пониманию того, что хотел передать коллега.
Ещё одним из знаменитых способов записи Definition of Done является простой список.
В заключении хочется сказать, что не стоит пренебрегать Definition of Done, ведь это приводит не только к осознанию того, что было сделано, но и к тому, как это нужно сделать в будущем. Благодаря использованию Definition of Done все будут стараться делать задачи более чёткими и конкретными, чтобы потом гордо сказать: «Точно сделано!» Помимо этого, набор рейтинга в Velocity будет гораздо выше.
Sprint Review Meeting
Обзор продукта происходит на Sprint Reviews Meeting. Как раз все исполненные задачи с их расшифровками в виде Definition-of-Done будут продемонстрированы на данной встрече.
Velocity
Разгон команды - интересный показатель, от которого часто отталкивается Product Owner в составлении своего Product Backlog. Слаженность команды и четкие задачи разгоняют показатели Velocity.