Планирование в Agile - общее видение
Для многих людей работа в стиле Agile означает отсутствие планирования, малое количество планирования или планирование в самый последний момент (например, написание пользовательских историй к предстоящей итерации прямо на совещании по ее началу). Хотя это может работать на очень маленьких проектах, в сплоченной, высокоэффективной команде, для проектов побольше это может перерасти в проблему. Вопреки распространенному суждению, проектам Agile требуется столько же планирования, сколько и при любой другой методике. Что отличается - это время планирования и стремление к минимизации напрасных усилий. В этой статье мы попробуем осветить разные уровни Agile-планирования и их использование на текущем проекте. Все проекты имеют разные уровни требований, представленных в различных формах в зависимости от типа принятого проектного подхода. Обычно эти уровни представляют собой отдельные события, затрагивающие разных людей. Однако мы должны убедиться, что поток знаний течет от одного уровня к другому (и обратно) настолько гладко, насколько это возможно, иначе основная мысль легко может быть утрачена или понята не так. Мы начнем с обзора общей картины проектного планирования. Заметим, что это нечто иное, как формальный план проекта, который, возможно, находится в качестве артефакта у руководства проекта. Первый уровень планирования: общее видениеЭто самый высокий уровень возможных требований, который описывает в общих чертах, какую бизнес-проблему пытается решить проект. Это делается в первую очередь заказчиками проекта, но они должны работать в сотрудничестве с технической организацией, чтобы удостовериться, что доступны все необходимые технологии, навыки и люди. Описание проекта на данном этапе может быть таким: «Увеличить продажи при помощи электронной платформы», «Перевести систему ERP на другую платформу» или же, как в примере, которым я буду пользоваться на протяжении данной статьи, «Продавать билеты на самолет через новый вебсайт.» Это видение должно быть измеряемым - таким образом мы будем определять окупаемость инвестиций (ROI) проекта и выяснять, успешным ли получился проект. Если цель проекта - окупаемость инвестиций, коэффициент ROI помогает убедиться, что наши инвестиции в новый проект меньше, чем результаты текущего. В других проектах могут быть другие критерии успешности, например, соответствие государственным стандартам или экономия средств на уменьшении ручного труда. Люди, вовлеченные на данном этапе планирования, - это, как правило, спонсоры, менеджмент продукта, исполнительный директорат и старший технический персонал, включая технического и бизнес-архитекторов, дизайнеров бизнес-решения и других руководителей схожего профиля со стороны бизнеса и технической компании. В дополнение к определению общего видения, я хочу обозначить, как будет выглядеть успех в осмысленных, измеряемых терминах. Для этого я выбираю два или три параметра измерения, которые действительно отражают ценность продукта. Вполне вероятно, что у технической команды, осуществляющей проект, нет никакого контроля за этими показателями - скорее, мы используем их в качестве ориентира, насколько хорошо бизнес принимает решения, и чтобы помочь бизнесу определить, в какой момент мы считаем проект «достаточно успешным». Эти параметры должны отвечать на несколько вопросов:
Вот тут мы и начинаем раскрывать, что мы в действительности хотим от нашего проекта, пусть и на очень высоком уровне. И снова здесь главный движущий элемент - это бизнес, но в сотрудничестве с технической компанией. Иногда проект реализует какую-то одну бизнес-возможность, но это редкость и относится чаще к коротким (в 2-3 итерации) проектам. Обычно же в проекте заложено множество бизнес-возможностей. Продолжая представленный выше пример с авиакомпанией, эти возможности можно сформулировать так: «Купить билеты онлайн», «Искать полеты между двумя аэропортами» и «Управлять моим аккаунтом частого путешественника онлайн». Выясняя эти возможности, мы должны также начать выявление рисков и определение, существует ли архитектура базового уровня. Эти элементы позволяют нам рассмотреть ограничения, в которых, возможно, будет проходить проект, и принимать решения на основе более полной информации в дальнейшем. Мне нравится нравится осознанный пошаговый подход к получению историй и дроблению бизнес-возможностей на мелкие части. Я использую термин «тема», чтобы описать большие элементы, то есть то, что нужно разбить на меньшие куски функциональности. Таким образом мы фиксируем эту начальную функциональность и используем ее позже, чтобы уточнить общие направление и определение проекта. Темы и особенности позволяют углубиться в детали по каждой возможности, внося свою лепту в наше знание, как должно выглядеть конечное решение. Это то самое место, где бизнес и техническая компания действительно начинают вместе работать над содержанием продукта. В то время, как темы в основном диктуются бизнесом, технической компании есть что сказать о текущих особенностях, технических возможностях и т.д. Мы хотим убедиться, что наши инвестиции оправданны, поэтому нужно рассмотреть и стоимость, и ценность каждой темы. Среди тем должны быть расставлены приоритеты, с тем, чтобы убедиться, что мы создаем ценность для бизнеса. Часто очень полезно разрабатывать темы, опираясь на понимание, кто будет пользоваться данным решением, при помощи техники, называемой «персонификацией». В нашем примере темами, которые мы, возможно, захотим разработать, могут стать «Ввести коды аэропорта вылета и прилета и определить самый быстрый маршрут», «Принять платеж про кредитной карте», «Показать стоимость выбранного перелета», «Показать баланс баллов» и «Разрешить выбор места в самолете». Начальное планирование проекта не должно заходить дальше этих пределов, поскольку теперь для понимания, что и каким образом должно быть разработано, нам нужно собрать команду (разработчиков, аналитиков, тестировщиков и т.д.). Это должно быть сделано на следующем этапе - планировании релиза. На данном уровне полезно произвести оценку. Такой подход позволяет нам сфокусироваться на относительной сложности, трудоемкости и временных ожиданиях по каждой теме и не должен использоваться в качестве ориентира, сколько времени в действительности займет разработка. Скорее, мы можем задним числом использовать эту оценку как основу для реалистичных ожиданий трудоемкости разработки. К примеру, если и «Показать стоимость выбранного перелета», и «Определить самый быстрый маршрут» оцениваются в восемь единиц, при этом мы знаем, что разработка функции «Определить самый быстрый маршрут» ранее заняла четыре итерации, то стоит ожидать, что и «Показать стоимость выбранного перелета» тоже займет четыре итерации. Второй уровень: планирование релиза
-- Автор: Пол Элларби Оригинал: http://www.agileconnection.com/print/article/five-levels-agile-planning Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
