Прогрессивный Скрам: рецепт прожарки проектов.
Бизнес, ПО, гаджеты и железо 05 Май 2020Если совместить идею метода «прогрессивного джипега» в проектах и классического Скрама, то получается довольно любопытный проектный подход:
В «прогрессивном джипеге» проект считается готовым на любой стадии, вопрос лишь в том на сколько он готов. Авторство идеи применять это при решении бизнес-задач приписывается Артемию Лебедеву. Если кто не в курсе, название берётся из метода сжатия изображений и его загрузки браузером: изображение появляется сначала размытое, потом, по мере загрузки, оно становится всё более чётким, пока не загрузится полностью. Таким образом, предлагается и смотреть на разработку и реализацию IT-проектов — постепенно наращивать функционал, пока не появится готовая картина, задуманная в самом начале работы (по крайней мере, на это нацелены все надежды исполнителя и заказчика…).
В итеративной разработке (например, в Скраме) понятие «готовности» проекта вообще, можно сказать, отсутствует! Проект всегда готов, но просто продукт в начале малофункционален… По этому, именно в Скраме принято сначала добиваться какого-то MVP с минимально необходимым набором функций, который можно реально запустить у заказчика. И вот потом уже, основываясь на практических отзывах, корректировать направление развития продукта — иными словами, пирожок ещё не готов, но начинку можете попробовать..
Соответственно, если взять слишком большой проект и начать «прогружать» его целиком по методу «прогрессивного джипега», постепенно наращивая сразу весь функционал, то можно неожиданно столкнуться со следующими удивительными последствиями:
-
слишком поздний срок рождения хоть сколько-нибудь значимого результата, потому что постоянно приходится обходить весь проект, равномерно и по чуть-чуть наращивая продукт;
-
имеем эффект потери фокусировки на результате из-за слишком большого объёма входных данных;
-
имеем отсутствие функционально пригодных участков для реальной эксплуатации на протяжении всего проекта, т.е. получим что-то дельное только в конце;
-
имеем кучу неопробованных в деле гипотез и много переделок по ходу проекта с ними связанных;
-
и т.д…
Я прихожу к выводу, что с достаточно большими проектами, которые плохо умещаются в сознании небольшой проектной команды из-за своих масштабов, можно совмещать два этих подхода:
-
«Прогружаем» первое приближение всего проекта, набросав его общую картину в слегка размытой форме. Это ещё не MVP, это могут быть прототипы или даже просто дизайнерские эскизы или укрупнённые карты для каждого из участков. Здесь мы определяем общую концепцию, долгосрочную задумку и философию проекта, его ориентировочные сроки и примерные бюджеты.
-
Находим в общей картине проекта наиболее актуальный кусок, самый интересный для заказчика или наиболее простой для разработки и достаточно автономный для запуска в эксплуатацию. Это нечто подобное приоритизации в Скраме — определяем наиболее актуальные и недорогие фичи и начинаем с них.
-
Приступаем к проработке этого участка проекта по методу этого самого «джипега». Следовательно, здесь мы стараемся «прожарить» до достаточной степени готовности наиболее важный на данный момент кусок проекта, детализуя его так, чтобы его можно было признать годным.
-
Передаём текущие результаты в эксплуатацию, как только это становится возможно. Ставим эту часть на поддержку и дальнейшие мелкие улучшения, может быть даже руками другой команды. Если передать внедрённый участок на сопровождение другой команде, то мы оставим фокус внимания основной команды разработки достаточно чётким для новых частей проекта. Важно чтобы эти команды между собой качественно коммуницировали, что очевидно, ведь они над одним продуктом работают…
-
Переходим к пункту 2 со следующим по важности участком проекта.
Таким образом, мы имеем общую картинку проекта (джипег), но самые важные кусочки этой картинки мы получаем как можно раньше в красивом и чётком виде, что даёт нам Скрам. При этом, второстепенные кусочки остаются набросками в фоне, пока не придёт их время. Результатами труда разработчиков можно будет пользоваться в десятки раз более сжатые сроки, чем ждать окончательной готовности всего функционала. Сами результаты же будут в наибольшей степени соответствовать требованиям заказчика, т.к. будут проходить обкатку на реальных данных по мере поступления.
Свежие комментарии