Я думаю, что вопрос “А ты завершил свою задачу?” вы слышали и сами задавали неоднократно. К сожалению, понятие завершенности у всех разное. Это может причинить большие проблемы в процессе разработки. Задачи, закрытые с разным уровнем завершенности, зачастую становятся причиной найденных ошибок, проблемного кода, неверных дизайнерских решений и других неприятностей. Чтобы избежать такого рода ситуаций команде стоит собраться и обсудить командное определение завершенности (Definition of Done). Для разного типа задач такое определение может отличаться. Лучше всего оформить определение завершенности и поместить его в общедоступное место: на доску задач, на WiKi, на стол каждому члену команды. После определения критерия завершенности задача может считаться законченной только в случае полного удовлетворения всем пунктам критерия. Каждая команда может включать свои пункты, которые зависят от языка программирования, специфики проекта, состава команды и других факторов. Вот один из примеров определения завершенности:

• Код написан и добавлен в систему контроля версий
• Все части задачи выполнены и логика работы кода соответствует требованиям
• Весь код прошел обязательную процедуру Code Review
• Код не имеет проблем, найденных статическими анализаторами кода
• Unit-тесты для кода написаны в полном объеме
• Код и тесты прошли процедуру Refactoring и не содержат явных проблем
• Интеграционные тесты написаны
• Сборка с запуском всех тестов на Continuous Integration сервере завершилась успешно
• …

Но это еще далеко не все! В Agile подходах используется итеративный и инкрементальный стили разработки. Это значит, что заказчик в праве ожидать некоего набора завершенной функциональности к концу каждой итерации. Но ваше понимание завершенности может очень сильно отличаться от понимания заказчика. Чем больше разница, тем больше накапливается недоделанной работы. Очень хорошо, если вы демонстрируете завершенные задачи в конце каждой итерации, причем демонстрируете так, как просит вас заказчик. В этом случае проблема очень быстро вылезет наружу. Для того, чтобы избежать проблем, нужно добавить в определение завершенности пункты от заказчика (синхронизировать список с ним). В этом случае заказчик знает чего он в праве ожидать и как он может проверить готовность функционала.

Давайте рассмотрим небольшой пример. Ваша команда имеет отличный, продуманный критерий завершенности задач, но туда не входит интеграция и установка задач на рабочий сервер, а также регрессионное тестирование. Итерация заканчивается и вы радостно показываете новый функционал заказчику на специальном тестовом сервере. Все проходит отлично и заказчик задает вопрос: “Ну что с завтрашнего дня пользователи смогут оценить новую функциональность, а мы – получить больше прибыли?”. В ответ вы чешете голову и отвечаете, что нужно еще неделю для того, чтобы установить все на рабочий сервер, написать скрипты обновления базы данный, мигрировать данные с нескольких старых табличек, прогнать все регрессионные тесты. Естественно это может расстроить вашего заказчика и обмануть его ожидания. Синхронизация критерия завершенности на ранних этапах разработки поможет построить доверительные отношения и убережет от многих неприятностей.

Критерий завершенности можно использовать еще для одной интересной цели – выделение стадий, через которые проходит ваша задача. Это позволяет построить более правильную Kanban доску задач и расставить ограничения на объем работ, выполняемый одновременно. К примеру, можно придти к таким колонкам: “Написание приемочных тестов”, “Реализация”, “Code Review”, “Тестирование”, “Установка на сервер”. В этом случае у команды и заказчика будет общее понимание почему нужны все эти стадии и как далеко конкретная задача находится от состояния завершения. Гораздо легче отслеживать прогресс и анализировать проблемы.

Всегда старайтесь закончить задачу так, чтобы вы могли собой гордиться!