Гибкое планирование от Enterprise Vision до Stand-Up Team Часть 1

Опыт, полученный при широкомасштабном внедрении концепций Agile в проектах программирования, учит нас тому, что популярные в настоящее время методы Agile-программирования (такие как Scrum http://www.scrumalliance.org/>) не масштабируются до уровня программ, продуктов и организаций без изменений. Основы изменений в этих методах содержатся в принципах Lean, т. Е. Будущее Agile-методов находится в его начале. В этом документе описывается структура планирования, которая успешно использовалась в крупных Agile-проектах, и исследуется влияние внедрения этой структуры на три основных принципа Lean: Muri, Mura и Muda.

Планирование в крупных гибких проектах

В Agile методах загрузка команды с работой выполняется путем планирования итераций. Из-за короткой итерации (обычно от одной до шести недель) план теряет важность, а планирование приобретает все большее значение. Для небольших проектов может быть достаточно запланировать только одну итерацию за раз. Опытным недостатком итеративного планирования при применении к проектам, длящимся более нескольких итераций или с несколькими командами, является потеря зрения на долгосрочные последствия итерационных операций. Другими словами: «весь» взгляд утрачен. Решение состоит в том, чтобы добавить уровни планирования для включения текущего «целого» представления.

В методологии, основанной на планах и водопадах, эта проблема решается заранее благодаря крупному проекту, цель которого состоит в том, чтобы точно предсказать, какой объем работы требуется для каждой задачи проектирования. Это приводит к значительным инвестициям на ранней стадии проекта, когда совсем нет уверенности в том, что разработанные функциональные возможности на самом деле являются функциональными возможностями, требуемыми владельцем продукта. Многоуровневый подход к планированию должен избегать повторного представления крупного проекта заранее.

Планирование масштабных мероприятий по развитию должно основываться на пяти уровнях:

о видении продукта

o План действий по продукту

o План выпуска

o план спринта

o Ежедневные обязательства

Уверенность в принятии мер на каждом из пяти уровней возрастает, поэтому количество подробной информации (вложенные деньги), количество вовлеченных людей и частота могут увеличиться без риска тратить деньги на функции, которые нельзя построить или можно построить по-разному. Каждый из пяти уровней планирования касается основных принципов планирования: приоритетов, оценок и обязательств.

Видение продукта — уровень 1
Самая широкая картина, которая может быть нарисована в будущем, — это видение владельца продукта. В этом видении он объясняет, как должна выглядеть организация или продукт. Он указывает, какие части системы должны быть изменены (приоритет) и какие усилия могут быть предприняты для достижения этой цели (оценки и обязательства).

Видение продукта — как это сделать
Возможные структуры упражнений по зрению включают создание заявления о лифте или окна видения продукта http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html>. Принцип обоих упражнений состоит в том, чтобы создать утверждение, которое описывает будущее с точки зрения желаемых характеристик продукта, целевых клиентов и ключевых отличительных особенностей от предыдущих или конкурирующих продуктов.

Джеффри Мур http://en.wikipedia.org/wiki/Geoffrey_Moore> использует следующую структуру в своем заявлении лифта: «Для (целевой клиент), который (заявление о необходимости) (название продукта) является (категория продукта), который (ключевое преимущество) продукт, действительная причина покупки). В отличие от (оригинальной конкурентной альтернативы) нашего продукта (окончательное утверждение об оригинальной дифференциации). «Видение продукта описывает желаемое состояние, которое должно составлять не менее 12 месяцев. Дальнейшие действия по планированию (дизайну) улучшат видение и могут отвернуться от видения, потому что будущее принесет нам измененный взгляд на рынок, продукт и необходимые усилия, чтобы воплотить видение в реальность.

Продуктовый план — уровень 2
Эра крупных проектов, приносящих результаты на протяжении многих лет, уже позади. Клиенты требуют более частых изменений, и типичные временные рамки для размещения продуктов на рынке измеряются неделями или месяцами. Более высокая частота и более короткие временные рамки заставляют владельца продукта задумываться о шагах, думать о пути к конечному продукту. Так же, как поездка запланирована заранее и передана другим путешественникам, создается карта продукта и передается другим поставщикам.

Для этого владелец продукта должен:

o Общайся целым

o Определите и сообщите, когда нужны издания

o Определите, какой функциональности достаточно для каждой версии.

o Сосредоточьтесь на стоимости бизнеса, полученной из проблем

С другой стороны, команда доставки будет:

o увидеть все

o Узнайте, как реализовать видение

o соответствовать приоритетам бизнеса

o Предоставление технической информации для дорожной карты

o Обеспечить прогнозы для функций, которые вы ожидаете

План продукта — как это сделать
Создание дорожной карты в большой степени зависит от владельца продукта (или команды владельца продукта). Этот этап программы имеет ограниченное влияние технологических ограничений. Во время встречи или серии встреч владелец продукта будет составлять дорожную карту. Это может быть буквально, через графическое представление изданий или более формально в письменном документе с указанием дат, содержания и целей ожидаемых изданий.

Журналы продуктов
В ожидании следующего этапа планирования (планирование выпуска) составьте список желаемых функций — продуктовый бэклог. В простейшей форме такое отставание представляет собой таблицу (электронную таблицу) требований к продукту, кратко описанную, чтобы группа доставки могла предоставить оценки каждой функции. Самое главное, список должен быть приоритетным. Успех проекта Agile Development зависит от скорейшего выполнения функций с наивысшим приоритетом. Поскольку успех проекта измеряется с точки зрения бизнеса, компания, то есть владелец продукта, отвечает за определение приоритетов в списке функций. Требуется взаимодействие с командами доставки. Не обсуждая функцию, группе доставки будет трудно предоставить оценки, которые имеют приемлемую неточность. Возможности продукта включают в себя:

o Один реестр продуктов для всех команд (см. все)

o Большие или очень большие функции (до 20 дней в день, чтобы обеспечить функцию)

o Приоритет функции на основе бизнес-приоритета (определяется на основе исследования рынка)

o Технологические функции (иногда называемые нефункциональными функциями, работа, необходимая для того, чтобы продукт работал желаемым образом, например, внедрение конкретной СУБД, чтобы гарантировать конкретную производительность системы), ограничены теми, которые непосредственно влияют на успех продукта на рынке.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *