Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban

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

Разработчики прекрасно понимают это и вполне положительно относятся к закладыванию в проект пространства для маневра. Проблемы начинаются тогда, когда проект предсказуемо катится в тартарары, но ряд изначально заложенных результатов уже находится в стадии реализации, и перед разработчиками встает дилемма относительно того, что делать с вложенными в эти промежуточные результаты ресурсами и усилиями. Когда время и (или) деньги разработчиков начинают подходить к концу, нередко оказывается, что самые важные задачи до сих пор не выполнены: например, в случае с реновацией дома не имеет смысла вкладывать последние деньги в высокотехнологичную кухню, если в ванной еще даже не начиналась побелка. Конечно же, здравый смысл подсказывает нам, что всегда стоит начать с реализации самых минимальных требований к проекту, но не стоит думать, что после их выполнения работа автоматически заканчивается. Обе стороны – и заказчик, и разработчики – должны быть уверены в том, что проект не заканчивается после первого рабочего прототипа и процесс улучшения и доведения до ума финального продукта продолжится и в дальнейшем. Доверие – важный залог успеха, но понимание важности поэтапной реализации задачи является основой Agile. При наличии этого понимания вероятность того, что проект скатится под откос вместе со всеми ресурсами, затраченными на его реализацию, сравнительно невелика, если, конечно же, первоначальная идея проекта не была абсолютно нереалистичной – но в этом случае проблема отнюдь не в Agile.

MVP – это абсолютный минимум, необходимый для начала использования или работы. Использование каждой функциональности или нюанса должно быть результатом рационального выбора. Критерий отбора прост: если MVP работает без этой характеристики, то она не нужна. На практике вы безусловно можете допустить наличие пары не совсем необходимых характеристик – до тех пор, пока их реализация не начинает отнимать ресурс у основной цели. Ваша цель – выработать набор требований к проекту, который можно быстро и беспрепятственно реализовать.

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

Блистательная мысль

Отдел финансов редко выступает инициатором перехода к Agile, но его работники обычно очень положительно воспринимают данный переход, если объяснить им все его преимущества. Сокращение периода адаптации проекта для выхода на рынок, поэтапная реализация проекта и быстрый возврат инвестиций – все это звучит как райская музыка для людей, которые привыкли работать с деньгами. Достаточно сказать им, что гибкие подходы положат конец бесконечным спиралям бессмысленных бюджетных трат, – и эти люди ваши. Не забывайте о том, что они могут быть очень полезными союзниками!

Менеджмент рисков и ожиданий

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

• Не забрасывайте испробованные и надежные практики. Многие разработчики пытаются менять слишком многое слишком часто. Придерживайтесь плана и вносите изменения по одному. Если изменения не работают, откажитесь от них.

• Говорите. Говорите. ГОВОРИТЕ. Отсутствие взаимодействия между людьми – источник всех зол. Отсутствие информации является не менее губительным, чем плохая информация. Используйте регулярные отчеты о проделанной работе для гарантии того, что вы обсуждаете что нужно и когда нужно.