Читать онлайн «Гибкое управление проектами и продуктами». Страница 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Традиционный 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.

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