Гибкое управление проектами и продуктами - Борис Вольфсон
Шрифт:
Интервал:
Закладка:
Ограничение по срокам возникает как институт, который призван снизить риски заказчика. Однако на практике получается наоборот, жесткие давящие сроки приводят к деструктивной позиции обеих сторон: исполнитель запрещает заказчику менять требования, даже если для этого имеется реальная бизнес-необходимость, а клиент жестко требует исполнения сроков, порой в ущерб качеству, ведь масштаб проекта также фиксируется.
Необходимо отметить, что недоверие преодолеть очень непросто.
Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.
Метод заключается в получении трех оценок:
• оптимистичной (Мин);
• вероятной (Сред);
• пессимистичной (Макс).
Вычислить наиболее вероятную дату завершения можно по формуле:
(Мин + 4 × Сред + Макс) / 6.
Отклонение высчитывается по формуле:
(Макс – Мин) / 6.
Для оценки сроков релиза в Scrum-проектах необходимы исторические данные либо из нескольких первых спринтов, либо из предыдущих проектов данной команды. После этого можно построить диаграмму сгорания для релиза целиком.
![Гибкое управление проектами и продуктами Гибкое управление проектами и продуктами](https://pbnuaffirst.storageourfiles.com/s18/51826/img/i_055.jpg)
Диаграмма сгорания релиза показывает расчетную дату завершения проекта
Обратите внимание, что пунктиром построена линейная аппроксимация, с помощью которой можно вычислить, что проект завершится на 13-м спринте. Если необходима большая точность, истории пользователя можно оценить и вести подсчеты уже в «пунктах», потому что истории неодинакового размера.
Отмечу, что в число оставшихся историй пользователя нужно включать и истории, которые владелец продукта добавил в журнал пожеланий продукта после очередного спринта.
Можно использовать и более изощренный подход: строить график добавления историй пользователя отдельно вниз, в отрицательные квадранты, и просчитывать вероятность завершения релиза в данном спринте (подробнее – в статье «Подвижная мишень и дрожащие руки» по адресу http://www.slideshare.net/Cartmendum/hitting-moving-target).
Преимуществом такого подхода является возможность выбрать величину риска, с которой мы готовы работать, что очень важно в условиях высокой конкуренции:
• если штрафные санкции по проекту велики, а вознаграждение – не очень, мы можем ограничиться кумулятивной вероятностью 96,6 % и возьмем обязательства по завершению проекта за 12 спринтов;
• при малых штрафных санкциях и большем вознаграждении можно использовать более мягкие кумулятивные вероятности завершения: 93,4 % за 11 спринтов и 87,2 % – за 10 спринтов;
• при отсутствии штрафных санкций (например, для внутренних проектов) можно поставить в качестве срока завершения 9 спринтов с кумулятивной вероятностью 75,9 %.
![Гибкое управление проектами и продуктами Гибкое управление проектами и продуктами](https://pbnuaffirst.storageourfiles.com/s18/51826/img/i_056.jpg)
Данная диаграмма сгорания дополнительно показывает дифференциальную и кумулятивную вероятность даты релиза
Подчеркну, что у самого вероятного исхода (завершение за 8 спринтов) кумулятивная вероятность составляет всего 57,3 %.
В отличие от классических методов определения срока завершения проекта или релиза при гибком планировании мы имеем дело не с конкретной датой, а с вероятностными распределениями. Владелец продукта должен сознательно принимать решение о мере риска, на которую он и команда готовы пойти.
В этом разделе я расскажу об особенностях Scrum в заказной разработке, которая отличается от тепличных условий внутренней разработки, и можно ли применять Scrum в таких условиях, а также на что надо обратить внимание прежде всего.
Первый вопрос, который обычно возникает, – как продать Scrum клиенту, ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:
• каждые две недели получать новый функционал, который можно попробовать и выпустить на рынок для зарабатывания денег;
• каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО;
• регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта.
Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте. Наилучшим вариантом здесь будет заключение контракта типа «время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но следует отметить, что при таком подходе и риски перекладываются на него. Еще скажу, что при таком варианте резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.
Традиционным для нашей страны является подход по заключению контрактов с фиксированной стоимостью, который, казалось бы, переносит многие риски на исполнителя. В действительности исполнитель старается все эти риски заложить в стоимость контракта. Этот подход трудно назвать гибким, так как обе стороны пытаются победить друг друга вместо того, чтобы искать решение Win-Win, основанное на взаимном доверии.
О нулевом спринте обычно многие молчат или пишут совсем немного. Буквально год или два назад наконец-то начали активно обсуждать эту фазу проекта, причем на данный момент в основном разбирается продуктовая часть.
Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т. д. Словом, он заменяет целый пакет документов, который принято использовать в тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.