Владимир Завертайлов

Scrum (скрам) и гибкие методологии разработки — зачем заказчику знать такие непонятные слова?

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

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

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

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

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

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

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

ОК, это плохо. Но как этого можно было избежать?

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

SCRUM помог бы вам в ситуации, когда…

  • Куча денег и времени ушла на проработку ТЗ, но по ходу работы над проектом поменялась концепция или бизнес-процессы. Доводить проект до конца в том виде, как описано в ТЗ — нет смысла. Деньги на ТЗ выброшены напрасно. Разработчик отказывается вносить изменения по ходу работы, ссылаясь на ТЗ.

  • Разработчик показывает проект в последний день перед запуском. Однако все сделано не так, как вы себе это представляли. Нужна значительная переделка. Разработчик по-своему трактует описанные в ТЗ требования и отказывается вносить изменения в проект на этом основании.

  • Нужно запустить костяк интернет-проекта с минимально-возможным бюджетом и сроками. Дополнительные функции разрабатывать уже после запуска, когда проект начнёт отбивать начальные инвестиции.

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

Механика процесса в web-разработке

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

Backlog вместо технического задания

Backlog — документ, который содержит список всех требований к проекту (виденье проекта, список того, что должно быть реализовано). Пункты списка упорядочены по степени важности. По ходу проекта список и приоритеты могут меняться, в зависимости от потребностей заказчика, новых идей или изменяющихся условий. Да, в классическом 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

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

Q. Какие преимущества Scrum дает клиенту?

A. Быстрый запуск проекта с самыми приоритетными функциями и минимально возможным бюджетом. Контроль над ходом работ и более гибкий контроль над бюджетом проекта.

Q. Как оформлять договорные отношения?

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

Q. Сколько занимает внедрение scrum? Что это дает?

A. У нас внедрение заняло около полугода. В первые месяцы мы получили довольно резкий негатив со стороны разработчиков (люди не любят, когда что-то меняется и добавляется больше контроля). Пришлось много рассказывать, убеждать, показывать. Мы получили довольно существенное проседание по качеству и скорости в этот период. Однако на сегодняшний день, когда период адаптации давно прошел, я расцениваю прирост производительности на уровне 20–30% (в разных командах — по разному).

Q. Когда SCRUM не сработает

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

Q. Какую оценку вы показываете заказчику?

A. Мы показываем экспертную оценку, выставляемую менеджером проекта или техническим руководителем. В ней как правило, заложены риски и учтена скорость работы конкретной команды (по опыту предыдущих проектов). Затем планирование этапа работ команды идет с помощью более точного механизма Planning Poker. Однако эта оценка редко интересует заказчика (как правило, она очень оптимистична и выставлять счета на основе этой оценки — самоубийство). Фактическую трудоемкость показываем некоторым клиентам, для которых это принципиально (например, если в договоре прописана почасовая оплата).

Q. Как поступать с этапами дизайна и контента? Тоже скрам?

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


 

Что еще почитать по этой теме

Scrumban разрулит: обновление для техподдержки
Сибирикс
26 Мая 2016
Scrumban разрулит: обновление для техподдержки
Если где-то в коммуникациях с клиентами есть слабые места — мы их устраняем. С этой целью появился Helpdesk и новое обновление для Доски задач.
Обновление: Scrumban теперь в 20 быстрее
Сибирикс
20 Апреля 2016
Обновление: Scrumban теперь в 20 быстрее
Хорошая новость для тех, кто любит задачи, да побольше. И желательно чтобы все на одной доске.
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Сибирикс
13 Апреля 2016
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Продвижение и оптимизация сайта — не так просто, как могут уверять SEO-компании. Мы решили морально подготовить вас ко всем форс-мажорам

У вас есть проект?

Давайте обсудим его. Продумаем. И сделаем!

Заказать клёвый проект
Заявка отправлена
Спасибо, ваша заявка отправлена. Эксперт студии Сибирикс свяжется с вами в ближайшее время для уточнения подробностей.