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

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

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

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

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

(Мин + 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, основанное на взаимном доверии.

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

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

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

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

Построение карт историй на практике

Обязательно нужно вытащить представителей заказчика на процессы по выработке видения и построение карт историй (а на последнее собрание – еще и потенциальных пользователей).

Обратная сторона медали – это выбор платформы для разработки и создания архитектуры. Конечно, я имею в виду не Big Upfront Design, а более гибкий подход, ведь десятки или сотни диаграмм, пылящихся в дальнем ящике стола, – это не наша цель. Задача у нас – сделать продукт, минимизировав потери.

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

Можно взять ICONIX в качестве подмножества UML и процесса, но он будет скорее замещать построение карт историй, чем дополнять его.

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

Практики Scrum, или Как посадить заказчика на итеративную иглу

Не буду подробно останавливаться на традиционных практиках Scrum, хочу отметить лишь, что в них нужно по возможности вовлекать заказчика. Программа-минимум – это посещение заказчиком всех демонстраций. Вам жизненно необходимо «подсадить» заказчика на свой ритм работы, чтобы он хотел получать очередной инкремент функционала как наркотик. Это очень поможет выстроить атмосферу доверия между вами.

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

«Вредные» клиенты

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

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

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

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

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

Нелояльного клиента необходимо определить до появления проблем. Это можно сделать, наведя справки и в процессе непосредственного общения. Далее нужно рассчитать возможные риски – проблемы с оплатой, различные задержки. В самом простом случае следует пометить в CRM, что с данным заказчиком могут быть проблемы.

Следует хорошо подумать, нужен ли вам этот клиент, ведь с ним не получится работать на 100 % по Agile. Здесь подход должен быть комплексным: во внимание нужно принять как стоимость и сроки проекта, так и возможные риски.

Глава 6. Управление рисками

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

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

Работа с рисками ведется в несколько этапов, которые изображены на следующей схеме.

Первый мозговой штурм по рискам можно включить в нулевой спринт (кстати, его можно провести в виде инновационной игры Speed Boat) и затем каждый спринт выполнять дополнительный анализ и вырабатывать контрмеры. Отмечу, что ответные действия должны быть именно превентивными, так получается дешевле, но ни в коем случае не делайте больше, чем надо, свято соблюдая принципы KISS и YAGNI. В мозговом штурме могут участвовать и представители заказчика, озвучивая свое видение возможных проблем.

Цикл управления рисками

Для стимуляции мозгового штурма крайне рекомендую использовать один из следующих риск-воркшопов:

• SEI Taxonomy-Based Risk Identification – таксономия рисков и опросник от Software Engineering Institute;

• дисциплина управления рисками MSF вер 1.1 – более легковесная версия категоризации софтверных рисков от Microsoft.

Риски надо визуализировать, чтобы их знала вся команда (и заказчик) и полноценно участвовала в управлении ими. Худший вариант – создать Excel-файл с рисками (в самом укромном уголке) и при провале проекта сказать: «Этот риск у меня есть в реестре под номером 37». Самый гибкий вариант – сделать доску с рисками и отслеживать их жизненный цикл.

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

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

Возьмем только три градации для оценки вероятности и угроз (сколько ущерба он принесет) риска, и при этом не будем использовать денежные оценки (табл. 6.1).

Таблица 6.1.

Оценка вероятности и рисков

Безусловно, максимум внимания необходимо уделить «красным» рискам: мало того, что они наиболее вероятны, ущерб от них обещает быть максимальным.

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

Что касается Lessons Learned, для этого идеально подходит ретроспектива. Только замечу, что эти уроки и лучшие практики также необходимо распространять между командами, например на Scrum of Scrum.

Глава 7. Инженерные практики

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

Непрерывная интеграция

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

Непрерывная интеграция является своеобразным скелетом экстремального программирования, на который затем добавляются «мускулы» в виде других практик.

Разработка через тестирование и разработка с тестами

Сначала обсудим более традиционную практику – разработку с тестами. При таком подходе программист пишет код, а затем – автоматизированные тесты для него для проверки корректности.

Экстремальное программирование идет дальше и превращает проверку качества в инструмент для создания спецификации и архитектуры. Для этого этап написания тестов переносится в начало цикла разработки.

Цикл разработки в рамках TDD

Такой подход называется разработкой через тестирование или разработкой через тесты (Test Driven Development). Процесс работы разбивается на три этапа: