Книга Гибкое управление проектами и продуктами - Борис Вольфсон
Шрифт:
Интервал:
Закладка:
Ограничение по срокам возникает как институт, который призван снизить риски заказчика. Однако на практике получается наоборот, жесткие давящие сроки приводят к деструктивной позиции обеих сторон: исполнитель запрещает заказчику менять требования, даже если для этого имеется реальная бизнес-необходимость, а клиент жестко требует исполнения сроков, порой в ущерб качеству, ведь масштаб проекта также фиксируется.
Необходимо отметить, что недоверие преодолеть очень непросто.
Рассмотрим стандартный подход к оценке сроков завершения проекта – метод PERT (Program (Project) Evaluation and Review Technique), или метод оценки по трем точкам. Его преимуществом является простота и определенный учет рисков. К недостаткам относят маленькую точность и необходимость иметь полную информацию о масштабе работ, что не очень подходит для Scrum.
Метод заключается в получении трех оценок:
• оптимистичной (Мин);
• вероятной (Сред);
• пессимистичной (Макс).
Вычислить наиболее вероятную дату завершения можно по формуле:
(Мин + 4 × Сред + Макс) / 6.
Отклонение высчитывается по формуле:
(Макс – Мин) / 6.
Для оценки сроков релиза в 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 клиенту, ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:
• каждые две недели получать новый функционал, который можно попробовать и выпустить на рынок для зарабатывания денег;
• каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО;
• регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта.
Второй вопрос, который появляется сразу после первого, – как отразить процесс в контракте. Наилучшим вариантом здесь будет заключение контракта типа «время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но следует отметить, что при таком подходе и риски перекладываются на него. Еще скажу, что при таком варианте резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.
Традиционным для нашей страны является подход по заключению контрактов с фиксированной стоимостью, который, казалось бы, переносит многие риски на исполнителя. В действительности исполнитель старается все эти риски заложить в стоимость контракта. Этот подход трудно назвать гибким, так как обе стороны пытаются победить друг друга вместо того, чтобы искать решение Win-Win, основанное на взаимном доверии.
О нулевом спринте обычно многие молчат или пишут совсем немного. Буквально год или два назад наконец-то начали активно обсуждать эту фазу проекта, причем на данный момент в основном разбирается продуктовая часть.
Главным документом в проекте, с которого обязательно стоит начать его разработку, является видение проекта. Этот краткий документ описывает, что представляет собой продукт, какой будет его аудиторией, основные фазы проекта, бизнес-модель для монетизации и т. д. Словом, он заменяет целый пакет документов, который принято использовать в тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.
