Просто про Scrum: гибкая разработка интернет-проектов

Вам доводилось когда-либо взаимодействовать с разработчиками? А не возникало ли у вас после этого желание подкрутить отверткой чего-нибудь в их мозгах? Чтобы лучше работали. Потому что одно маленькое недопонимание — и ждите на проекте эдакой миниатюрной катастрофы.

От слов — к статистике: перед вами процент успешно завершенных интернет-проектов в США за далекий 1994 год:

А теперь 2012-ый. Думаете, многое изменилось?

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

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Дискоммуникация

Множество бизнесов теряло деньги из проекта в проект. С этим нужно было что-то делать. В результате была выработана концепция «гибкой» разработки в противовес стандартной.

Сегодня в разработке есть так называемая «водопадная» модель (стандартная) и «гибкая» модель (Scrum, читается как «Скрам»). Если коротко: первая не предполагает частого контакта с исполнителем, вторая — напротив, всячески его поощряет.

Сравните:

Стандартная модель: Waterfall / WTF

Суть «водопадной» модели заключается в следующем:

1. Вы анализируете потребности бизнеса, оформляете их в техническую спецификацию, отдаете в разработку. Техническое задание на проект средней сложности — это документ в 50 страниц, на разработку которого лично вы потратите достаточно много времени.

2. Начинается разработка, которая идет по определенным этапам: дизайн → верстка → программирование → тестирование → сдача проекта. Ждать, пока вы сможете «потрогать» проект, тоже придется долго.

3. Вы получаете готовый проект и работаете над его продвижением.

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

Во-первых, «водопаду» нужно, чтобы вы спланировали весь проект сразу. А это значит — спланировали бюджет, выдвинули пожелания к срокам выполнения и, самое главное, сделали техническое задание, где были бы учтены все требования. А зачастую, особенно, когда речь идет о каких-то инновационных проектах, продумать всё и сразу просто невозможно. Но «водопад» суров.

Во-вторых, «водопадная» модель не предусматривает вашего активного участия в работе над проектом. Вы передаете требования, получаете дизайн, снова отдаете требования — и прощаетесь с проектом до самого его релиза. Если мы говорим о небольших проектах-то «водопад» подходит идеально, но что, если есть объективная потребность контролировать весь процесс и корректировать его? К сожалению, снова мимо кассы.

В-третьих, в «водопаде» очень дорого обходятся изменения. Например, ситуация: ваш проект находится в разработке. Он сложный, поэтому разрабатывается уже давно. За это время рынок меняется, и какие-то функции на проекте становятся неактуальными. Вы звоните руководителю проектов и говорите, что такую-то функцию нужно переделать. Но полный функционал уже был описан в ТЗ, поэтому вам придется его переписывать и перезаключать договор, разработчикам — полностью приостанавливать рабочий процесс, а всё вместе это — потери времени.

В «водопадной» модели участие заказчика в разработке проекта минимальное (есть только на начальном этапе). По сути, вам не дают вносить изменения в проект и контролировать процесс, а потом демонстрируют готовый продукт. Логично, что такой «черный ящик» вас может не устроить:

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

Scrum — гибкий, но твердый

Противовес стандартной модели разработки — «гибкая» модель (Scrum).

В Scrum весь процесс разработки строится иначе:

1. Вы также анализируете потребности бизнеса, но вместо технического задания просто готовите список всех функций (в этом вам помогает руководитель проекта).

2. Функциям присваивается приоритет (например, для интернет-магазина каталог товаров важнее, чем личный кабинет пользователя — следовательно, приоритет первого будет ощутимо выше).

Пример типичного списка компонентов интернет-магазина, с приоритетами:

1. Разработка идет отдельными этапами по принципу: выбрали на этап самые приоритетные функции (на рисунке отмечены красным) → подготовили дизайн → сверстали → запрограммировали → запустили проект с минимальным функционалом → снова выбрали приоритетные функции… И так до последнего этапа.

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

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

4. Каждый последующий этап будет наращивать функционал проекта, пока все функции не будут реализованы.

Итак, если говорить об особенностях работы по Scrum’у, то нужно отметить:

• Прозрачность. В Scrum’е после каждого этапа разработки вам будут демонстрировать то, что получилось, а еще регулярно снабжать наглядными отчетами о том, как идут дела на проекте. Кстати, «хроника» работы над проектом, которая содержится в таких отчетах — очень полезная вещь при общении с боссом.
• Быстрые, дешевые изменения. Разработка ведется «кусочками», и это позволяет вам быстро внедрять новое в проект. Например, после окончания первого этапа и запуска проекта вы решили, что социальная сеть вам не нужна. Так как она имела меньший приоритет, к ней еще не приступали, а значит, вы просто связываетесь с руководителем проекта и вычеркиваете ее из общего списка функций.
• Быстрый запуск. Проект с базовыми функциями запускается уже после первых этапов разработки, после чего он с каждым этапом «обрастает» новыми функциями. А вы этим временем можете заняться, например, продвижением интернет-проекта в поисковой выдаче.
• Гибкий бюджет. В зависимости от того, как вы будете влиять на проект в ходе разработки — будет меняться и бюджет (причем, он может как уменьшиться, так и вырасти). В ряде случаев гибкость бюджета нежелательна, так как это мешает спланировать затраты (мы в таких случаях используем собственный метод — Scrum по фиксированной цене). А для стратапов и других продолжительных проектов, где сложно спланировать сразу весь бюджет, Scrum подходит безупречно.

Если у вас намечается длительный, сложный проект, которым вы живете и собираетесь жить ближайшие несколько месяцев — тогда только гибкая разработка и Scrum в помощь.

Еще одно очко в пользу Scrum — практика показывает, что успешно завершенных проектов, разработанных по Scrum, в 3 раза больше, чем таковых, разработанных по «водопадной» модели:

Источник картинки на тизере: IconArchive