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

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

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

Нелояльного клиента необходимо определить до появления проблем.Это можно сделать, наведя справки и в процессе непосредственного общения. Далее нужно рассчитать возможные риски – проблемы с оплатой, различные задержки. В самом простом случае следует пометить в 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.

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

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

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

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

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

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

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

• красный – пишем неработающий тест;

• зеленый – минимальными усилиями заставляем тест работать;