Я думаю, что вопрос “А ты завершил свою задачу?” вы слышали и сами задавали неоднократно. К сожалению, понятие завершенности у всех разное. Это может причинить большие проблемы в процессе разработки. Задачи, закрытые с разным уровнем завершенности, зачастую становятся причиной найденных ошибок, проблемного кода, неверных дизайнерских решений и других неприятностей. Чтобы избежать такого рода ситуаций команде стоит собраться и обсудить командное определение завершенности (Definition of Done). Для разного типа задач такое определение может отличаться. Лучше всего оформить определение завершенности и поместить его в общедоступное место: на доску задач, на WiKi, на стол каждому члену команды. После определения критерия завершенности задача может считаться законченной только в случае полного удовлетворения всем пунктам критерия. Каждая команда может включать свои пункты, которые зависят от языка программирования, специфики проекта, состава команды и других факторов. Вот один из примеров определения завершенности:
Но это еще далеко не все! В 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 методологиями разработки позволит добиться успеха.
11 сентября в Харькове состоится очередная конференция IT-Jam. Данная конференция соберет множество разработчиков, тестировщиков, дизайнеров, менеджеров и просто интересных людей. На конференции кроме основных докладов будет множество открытых дискуссий, музыкальное представление, а также множество сюрпризов от организаторов. От нас на конференции выступит Алименков Николай с докладом «Применение практики ‘Code Review’ для улучшения качества продукта». В докладе будет рассмотрена одна из наиболее полезных инженерных практик, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке. Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением.
Дополнительно 12 сентября в Харькове состоится открытый тренинг “Планирование и оценивание в Agile проекте”. На тренинге будут рассматриваться вопросы сбора и управления требованиями в Agile проекте, планирования на различных уровнях, различные подходы и приемы оценки. Участники смогут на практике опробовать многие техники и убедиться в их эффективности. Регистрация на тренинг уже открыта и продлится до 7 сентября. Торопитесь, количество мест ограничено!
На тренингах, касающихся инженерных практик, нас часто спрашивают о применении “Code Review”. Об этой практике можно рассказывать очень долго и мы обычно упоминаем доклад, подготовленный нами для конференции Agile Base Camp 2, проходившей этой весной в Киеве. Наконец-то стало доступно видео с этой конференции, включая наш доклад “Применение практики “Code Review” для улучшения качества продукта”. Вы можете найти его в видео разделе на нашем сайте. Удачного просмотра!
