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

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

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

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

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

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

В последнее время появляется все больше и больше новых методологий разработки, технических инструментов, языков программирования и библиотек компонентов, которые позволяют разрабатывать быстрее, надежнее и с меньшими усилиями. Но это не помогает ответить на главный вопрос: «Что разрабатывать?». Какой функциональностью должен обладать продукт? Для кого он будет предназначен? Как продукт будет конкурировать на рынке? С появлением Agile подходов и их быстрым распространением большая часть команд хотят сразу начинать разрабатывать и «приносить прибыль» заказчику. Тем более что в большинстве Agile методологий не уделяется должного внимания анализу и исследованию разрабатываемого продукта. Концепция пользовательских историй (User Stories) слишком проста и не помогает в процессе планирования продукта в полной мере. Намекаю ли я на то, что нужно вернуть стадию анализа из классических методологий или генерировать огромное количество артефактов перед фазой реальной разработки? Вовсе нет. Вместо этого стоит использовать более легковесные подходы и практики. Самое главное не забывать о том, что данная предварительная фаза нужна и поможет в будущем разработать «правильный продукт». Инженерные практики, итеративная и инкрементальная разработка, методологии и прочие инструменты помогут разработать «продукт правильно». Только сочетание этих двух целей (разработать «правильный продукт» и разработать «продукт правильно») приведет к успеху.

Данная тема давно меня интересовала и на конференции Agile Base Camp я выступил с докладом «Путь Agile проекта до первой итерации». Я постарался рассказать о том, какие активности необходимы в Agile проекте до начала реальной разработки и каким образом эти активности могут быть организованы. Правильная подготовка к разработке продукта может помочь сэкономить средства, избежать реализации никому не нужной функциональности, начать использовать продукт на ранних стадиях и получать от него прибыль. Слайды доклада доступны в разделе ресурсов на нашем сайте.

Jeff Patton – один из представителей Agile сообщества, который уделяет теме исследования и анализа продукта много времени в своей практике. Именно он придумал подход Story Mapping для сбора и управления требованиями, неоднократно выступал на различных конференциях с концепцией Pragmatic Personas и делился опытом того, как избежать неопределенностей в Agile проектах. Недавно я посмотрел еще одно его выступление на тему использования идей Agile для успешной разработки продукта. Jeff рассматривает пример проваленного проекта, в котором вроде бы все было сделано правильно, но владелец недостаточно инвестировал в исследование продукта. Из выступления вы сможете узнать зачем нужна фаза исследования продукта, какие практики и инструменты помогают организовать ее максимально эффективно и добиться успеха в последующей разработке.

Agile подходы не помогут вам разработать правильный продукт, если вы не будете инвестировать свои усилия в его исследование и анализ на протяжении всего процесса разработки. Использование идей и принципов Agile может облегчить процесс анализа продукта и его эффективность, а в сочетании с Agile методологиями разработки позволит добиться успеха.