Гибкое управление проектами и продуктами - Борис Вольфсон Страница 13

Книгу Гибкое управление проектами и продуктами - Борис Вольфсон читаем онлайн бесплатно полную версию! Чтобы начать читать не надо регистрации. Напомним, что читать онлайн вы можете не только на компьютере, но и на андроид (Android), iPhone и iPad. Приятного чтения!

Гибкое управление проектами и продуктами - Борис Вольфсон читать онлайн бесплатно

Гибкое управление проектами и продуктами - Борис Вольфсон - читать книгу онлайн бесплатно, автор Борис Вольфсон

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

Необходимо отметить, что недоверие преодолеть очень непросто.

Оценка сроков методом PERT

Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.

Метод заключается в получении трех оценок:

• оптимистичной (Мин);

• вероятной (Сред);

• пессимистичной (Макс).

Вычислить наиболее вероятную дату завершения можно по формуле:


(Мин + 4 × Сред + Макс) / 6.


Отклонение высчитывается по формуле:


(Макс – Мин) / 6.

Оценка сроков релиза в Scrum-проекте

Для оценки сроков релиза в Scrum-проектах необходимы исторические данные либо из нескольких первых спринтов, либо из предыдущих проектов данной команды. После этого можно построить диаграмму сгорания для релиза целиком.


Гибкое управление проектами и продуктами

Диаграмма сгорания релиза показывает расчетную дату завершения проекта


Обратите внимание, что пунктиром построена линейная аппроксимация, с помощью которой можно вычислить, что проект завершится на 13-м спринте. Если необходима большая точность, истории пользователя можно оценить и вести подсчеты уже в «пунктах», потому что истории неодинакового размера.

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

Можно использовать и более изощренный подход: строить график добавления историй пользователя отдельно вниз, в отрицательные квадранты, и просчитывать вероятность завершения релиза в данном спринте (подробнее – в статье «Подвижная мишень и дрожащие руки» по адресу http://www.slideshare.net/Cartmendum/hitting-moving-target).

Преимуществом такого подхода является возможность выбрать величину риска, с которой мы готовы работать, что очень важно в условиях высокой конкуренции:

• если штрафные санкции по проекту велики, а вознаграждение – не очень, мы можем ограничиться кумулятивной вероятностью 96,6 % и возьмем обязательства по завершению проекта за 12 спринтов;

• при малых штрафных санкциях и большем вознаграждении можно использовать более мягкие кумулятивные вероятности завершения: 93,4 % за 11 спринтов и 87,2 % – за 10 спринтов;

• при отсутствии штрафных санкций (например, для внутренних проектов) можно поставить в качестве срока завершения 9 спринтов с кумулятивной вероятностью 75,9 %.


Гибкое управление проектами и продуктами

Данная диаграмма сгорания дополнительно показывает дифференциальную и кумулятивную вероятность даты релиза


Подчеркну, что у самого вероятного исхода (завершение за 8 спринтов) кумулятивная вероятность составляет всего 57,3 %.

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

Scrum в заказной разработке

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

Как продать Scrum заказчику

Первый вопрос, который обычно возникает, – как продать Scrum клиенту, ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:

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

• каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО;

• регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта.

Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте. Наилучшим вариантом здесь будет заключение контракта типа «время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но следует отметить, что при таком подходе и риски перекладываются на него. Еще скажу, что при таком варианте резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.

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

Нулевой спринт

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

Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т. д. Словом, он заменяет целый пакет документов, который принято использовать в тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы

Comments

    Ничего не найдено.