Допустим, вы заходите к себе домой, садитесь на старый диван, из которого торчат пружины, смотрите на старую, облупившуюся мебель и говорите себе: «так дальше продолжаться не может!». Вы решительно хотите сменить всю свою старую, потертую мебель на новую, экологичную и функциональную, подогнанную специально под ваши нужды. Причем вариант ширпотреба из IKEA — не рассматривается, т. к. у вас есть свои, четко осознанные специфичные требования к домашней обстановке.

Вы идете к ОЧЕНЬ крутому мастеру, искренне считая, что только профи способен воплотить в реальность ваши желания. Оказывается, что ждать нужно будет примерно месяц. Это несколько поубавило ваш пыл, но решение уже принято. Да и очень неуютно возвращаться на потертое лежбище. Вы вносите предоплату, рассказываете свои идеи дизайнеру, который детально все фиксирует, задает вам умные вопросы, подписываете договор и...

...Ждете. Вы ждете долгий месяц, за который вам обещали все сделать. И все это время — старая, неудобная мебель попадается вам на глаза и под ноги, раздражает вас. Ждете. Куда-то делась радость спонтанной покупки? Никто из мастерской вам не звонит, особо не беспокоит, не отчитывается, вопросов не задает… Ждете.

А потом ждете еще две недели. И вы уже в бешенстве. От былой решимости осталось не так много — а стоило ли вообще затевать переделку? А потом еще ждете, еще чуть-чуть и еще три часа, на которые вы пораньше ушли с работы. И вот вам привозят новый комплект. Собирают, расставляют, и вам в голову бьет вполне отчетливая мысль. НЕ ТО!

Это совсем не то, что вы себе представляли. Хотя это, возможно, и соответствует тому, что вы рассказали дизайнеру, но это не то, что вам нужно. Обивка слишком светлая и абсолютно не нравится вашей новой подружке. Вдобавок выяснилось, что у вашего пса — аллергия на пух в подушках. Стол слишком высокий, а кресла — слишком громоздкие. Но это уже все согласовано с фирмой-изготовителем и у них есть ваша подпись. Поменять ничего нельзя, вернее — можно, но это будет стоить столько же денег и займет еще столько же времени. О гарантии результата можно вообще не говорить.

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

Однако на деле большую часть времени ваша мебель лежала в полусобранном состоянии и дожидалась своей очереди. Лежала в виде спиленных деревьев где-то на пилораме.

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

Скажите, вы действительно думаете, что на сборку ваших шкафов у профессионалов ушел целый месяц? А теперь представьте, что вы решили заказать себе новый крутой сайт, вместо старого и неудобного… ну, вы поняли.

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

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

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

Итак, чтобы снизить риски в конце проекта, нужна поэтапная разработка с регулярным контролем текущего результата. Этого можно достичь, работая над проектом по методологии SCRUM (скрам).

SCRUM (от англ. «схватка», термин из регби) — это набор правил для организации гибкого процесса разработки. Он основан на командном подходе, работе итерациями (спринтами), фокусировке команды на цели каждой итерации. Цель каждого спринта — предоставить конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет.

Знакомо? Скорее всего при разработке была использована «водопадная» модель, или все вообще шло как-попало. Scrum — это альтернатива, лишенная перечисленных выше недостатков. И вот почему:

Ок, давайте перейдем к заказной web-разработке. Про то, как оформить договорные отношения я расскажу в конце статьи. А пока — посмотрим на то, как будет построен процесс работы. Я исхожу из того, что главный критерий счастья заказчика — это когда он получает не просто продукт, соответствующий характеристикам, изначально указанным в ТЗ, а то, что ему действительно было нужно. И получает этот продукт так быстро, как это вообще возможно. Пусть, не будет хватать части функций, и их будут реализовывать по ходу, но проект сразу начнет приносить деньги, не дожидаясь полной реализации всех мелких внутренних деталей.

Дальше мы будем рассматривать только фазу программирования (для простоты), хотя при желании подобный подход можно распространить и на некоторые другие фазы работ. Замечу, что наиболее хорошо Scrum проявляет себя на технически сложных проектах с большим объемом программирования (хотя, при определенной адаптации годится и для сборки типовых сайтов). Итак, работа по Scrum строится следующим образом.

Да, в классическом Scrum подразумевается, что заказчик проекта может вносить любые изменения прямо по ходу проекта (но не в текущий этап разработки). Однако в случае разработки сайтов, бюджет по большей части фиксирован (исключение — некоторые startup-проекты). А значит, и возможности заказчика влиять на ход выполнения — тоже ограничены.

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

В классическом Scrum предполагается, что продолжительность спринта фиксирована и, как правило, составляет от 2 до 4-х недель, в зависимости от опыта команды. Поскольку далеко не все сайты требуют столь продолжительной фазы разработки (особенно учитывая, что разработка ведется 2−3 программистами параллельно), мы решили ограничить только максимальную продолжительность спринта. Нам подошли двухнедельные спринты. Однако, если команда может собрать проект за 3 дня — значит мы формируем 3-х дневный спринт.

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

При разработке по scrum на проекте есть парочка ключевых ролей. Product Owner — владелец продукта. Отвечает за представление интересов заказчика и конечных пользователей на проекте. Не является членом команды разработчиков. В идеале это должен быть представитель заказчика. Однако, поскольку эта роль накладывает очень высокие требования к опыту и компетенции индивида в сфере разработки и развития интернет-проектов, а так же требует постоянного личного участия в проекте (что не всегда возможно для заказчика) — в нашем случае эту роль выполняет менеджер проекта.

Ну и конечно, на проекте есть команда разработчиков :-) А в ней: Scrum Master — член команды, следящий за соблюдением принципов Scrum и проводящий ежедневные планерки. Роль не предполагает каких-то дополнительных полномочий по проекту, кроме самого Scrum-а.

Основная задача Product Owner-а — поддерживать в актуальном состоянии список задач по проекту (backlog) и правильно (с точки зрения бизнес-целей проекта) расставлять приоритеты. При этом в backlog попадают, как правило, не мелкие задачи (ака «нарисовать кнопочку»), а более крупные бизнес-задачи (например «реализовать авторизацию через социальные сети»).

Не обязательно иметь весь список задач (достаточно чтобы он был известен на пару следующих этапов) В начале каждого этапа работ команда набирает себе из этого списка столько задач, сколько способна реально успеть за этап (скажем, за 2 недели). Разбивает на подзадачи и делает точные оценки сроков.

Daily meetings (или Stand-up Meeting) — очень важный ежедневный ритуал, который позволяет ощутить пульс проекта. На протяжении всего спринта команда собирается в одно и тоже время в специально отведенном месте. Каждый член команды поочередно должен ответить на три вопроса:

• Что было сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы?

Важно не превращать Daily-Meeting в обсуждение технических деталей проекта (это можно сделать позднее), либо в формальное выяснение статуса проекта. У нас Daily Meeting обычно занимает по 5−10 минут на команду.

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

После демонстрации команда, воодушевленная напутствиями заказчика, проводит ретроспективу (анализирует ход прошедшего этапа работы с целью улучшения процессов разработки) и приступает к следующему этапу работ. На практике нам за несколько лет работы по scrum только пару раз удалось привлечь разработчиков и клиентов на совместную демонстрацию проекта (очень сложно состыковать всех по времени, да и отечественные заказчики это не очень любят).

Хотя вообще, получение отзывов на свою работу от бескомпромиссного заказчика («О, ребят, вы клёвую штуку сделали» или «Блин, ну чё за дрянь наворотили!») может стать весомым стимулом к саморазвитию команды. (Опять же, наш русский менталитет заказчика склонен выискивать и преувеличивать недостатки проекта. Получать отзывы на свою работу от Европейцев или Американцев намного приятнее. Нужно понимать, не будет ли команда демотивирована после полученного отзыва).

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

Q. Как оформлять договорные отношения?
A. В России на данный момент практически нет заказчиков, готовых идти на гибкий бюджет проекта. Разумным компромиссом я считаю заключение договора на разработку проекта с поэтапной разбивкой + дополнительные соглашения на возникающие по ходу развития проекта хотелки. Поскольку на западе уже довольно много клиентов готовы работать без фиксированного бюджета, вполне возможно через несколько лет это появится и у нас. В конце концов, нет никаких проблем работать внутри себя по Scrum, не показывая это наружу, заказчику :-).

Q. Когда SCRUM не сработает
A. Гос-заказы. А также все случаи, когда не сработают и другие методы: низкая квалификация команды, заниженные сроки/бюджет, некомпетентный менеджер проекта.

Q. Как поступать с этапами дизайна и контента? Тоже скрам?
A. Вообще можно попробовать. Методика — адаптивная, может и получится. Но у нас — не прижилось. Мы используем эти этапы как бы за рамками Scrum.