Объединение методологии разработки Scrum и подхода "Прогрессивный Jpeg"

Если совместить идею метода «Прогрессивного Jpeg» в проектах и классического Скрама, то получается довольно любопытный проектный подход.

В «Прогрессивном Jpeg» проект считается готовым на любой стадии, вопрос лишь в том, насколько он готов. Авторство идеи применять это при решении бизнес-задач приписывается Артемию Лебедеву. Если кто не в курсе, название берётся из метода сжатия изображений и его загрузки браузером: изображение появляется сначала размытое, потом, по мере загрузки, оно становится всё более чётким, пока не загрузится полностью. Таким образом, предлагается смотреть и на разработку, и на реализацию проектов: постепенно наращивать функционал, пока не появится готовая картина, задуманная в самом начале работы.

В итеративной разработке (например, в Скраме) понятие «готовности» проекта, можно сказать, отсутствует! Проект всегда готов, но просто продукт в начале малофункционален. Поэтому, именно в Скраме принято сначала добиваться какого-то MVP с минимально необходимым набором функций. И уже потом, основываясь на практических отзывах, корректировать направление развития продукта. Иными словами — пирожок ещё не готов, но начинку уже можете попробовать.

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

— слишком поздний срок рождения хоть сколько-нибудь значимого результата, потому что постоянно приходится обходить весь проект, равномерно и по чуть-чуть наращивая продукт;

— имеем эффект потери фокусировки на результате из-за слишком большого объёма входных данных;

— имеем отсутствие функционально пригодных участков для реальной эксплуатации на протяжении всего проекта, т.е. получим что-то дельное только в конце;

— имеем кучу неопробованных в деле гипотез и много переделок по ходу проекта с ними связанных;

— и т.д.

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

1. «Прогружаем» первое приближение всего проекта, набросав его общую картину в слегка размытой форме. Это ещё не MVP, это могут быть прототипы или даже просто дизайнерские эскизы или укрупнённые карты для каждого из участков. Здесь мы определяем общую концепцию, долгосрочную задумку и философию проекта, его ориентировочные сроки и примерные бюджеты.

2. Находим в общей картине проекта наиболее актуальный кусок, самый интересный для заказчика или наиболее простой для разработки и достаточно автономный для запуска в эксплуатацию. Это нечто подобное приоритизации в Скраме — определяем наиболее актуальные и недорогие фичи и начинаем с них.

3. Приступаем к проработке этого участка проекта по методу этого самого «Jpeg». Следовательно, здесь мы стараемся «прожарить» до достаточной степени готовности наиболее важный на данный момент кусок проекта, детализуя его так, чтобы его можно было признать годным.

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

5. Переходим к пункту 2 со следующим по важности участком проекта.

Таким образом, мы имеем общую картинку проекта (Jpeg), но самые важные кусочки этой картинки мы получаем как можно раньше в красивом и чётком виде. Сами результаты будут в наибольшей степени соответствовать требованиям заказчика, так как будут проходить обкатку на реальных данных по мере поступления, а не явятся сюрпризом в конце проекта.

Автор: Ильин Илья