Регистрация
Зарегистрируйся на сайте и получи доступ к полному контенту сайта и подпискам бесплатно!

Гибкая разработка: курочка по зернышку клюет

5
0
943 0
Аудио Текст
17 сентября 2013

Разработка сайтов и программного обеспечения — весьма высококонкурентный бизнес. И выигрывают в борьбе за заказы те компании, которые готовы обеспечить высокое качество продукта в самые сжатые сроки. О том, как этого добиться, рассказывает основатель и генеральный директор компании «Сибирикс» Владимир Завертайлов.

Из передачи вы узнаете:
— в чем суть гибкой методологии разработки ПО по модели Scrum;
— каковы преимущества Scrum по сравнению с классической «водопадной» моделью;
— для каких типов задач Scrum лучше, чем иные методологии, а для каких его не стоит использовать;
— как можно распланировать крупный проект разработки на короткие производственные циклы длительностью несколько недель;
— как отслеживаются и исправляются ошибки в проекте, создаваемом по методологии Scrum;
— как формируется бюджет Scrum-проекта и по какой схеме разработчик выставляет счета заказчику в ходе работы;
— как часто и в каком формате заказчик может контролировать процесс разработки;
— и многое другое.

Станислав Жураковский: Здравствуйте, друзья! Вы смотрите программу «Бизнес online», с вами я, Станислав Жураковский. Разработка ПО — это сложный и высококонкурентный бизнес, выигрывают в нем те компании, которые готовы делать максимально хорошее и качественное ПО в минимальные сроки. О том, как этого добиться, мы сегодня поговорим с генеральным директором и основателем компании Sibirix Владимиром Завертайловым.

Владимир Завертайлов, генеральный директор Sibirix.
Родился в 1981 году в городе Абакан.
В 2004 году окончил факультет информационных технологий Алтайского государственного технического университета.
В 2003 году основал компанию «Сибирикс» и возглавил ее.

С. Ж.: Владимир, приветствую вас в нашей студии!
Владимир Завертайлов: Всем привет!
С. Ж.: Мы знаем, что есть такая методология разработки ПО, как Scrum. Расскажите нам о ней, пожалуйста, в общих чертах.
В. З.: В общих чертах это методология, которая появилась из-за проблемы с тем, что очень много проектов, по статистике, вылетало за свои сроки и бюджеты.

По «водопадной» модели, когда пишется большое, «толстое» ТЗ и потом это ТЗ реализуется, успешно заканчивается порядка 14% проектов.

И встала задача увеличения количества успешных проектов. Умные люди думали, анализировали и придумали Scrum . Основная штука Scrum в том, что мы запускаем проект по частям, отгружая заказчику сначала самые важные, с точки зрения бизнеса, для него фичи, функции.
С. Ж.: А вот вы сказали, 14% заканчивается, а что происходит с остальными аж 86%?
В. З.: Эта статистика была собрана в США по самым хардкорным проектам. Остальные проекты по «водопадной» модели либо заканчивались не в срок и превышали свой бюджет, либо вообще были аннулированы. По Scrum статистика значительно лучше, там порядка 45% проектов заканчивается в срок и укладываются в бюджет. То есть примерно в три раза лучше статистика, чем по классической «водопадной» модели.
С. Ж.: В три раза. Получается, половина?
В. З.: Ну да.
С. Ж.: Половина проектов, а половина все равно заканчивается не в срок или с превышением финансирования?
В. З.: Или с превышением финансирования, да.
С. Ж.: Вы вообще были первыми, кто это сделал…
В. З.: Среди веб-студий? Да.
С. Ж.: А как вы пришли к этой модели, как заразились этим?
В. З.: Это была очень интересная история. У нас был заказчик, который делал стартапы в Кремниевой долине. В США эта тема была очень «прокачана», а у нас в России нет. И он нам просто насильно это внедрил, и вот оттуда это пошло.
С. Ж.: То есть такое внедрение сверху?
В. З.: Да, внедрение сверху.
С. Ж.: Это был 2001 год. А сколько студий пошло по вашим стопам?
В. З.: Я даже не знаю. Это в последнее время становится очень популярным. На самом деле, мне кажется, у крупных, больших проектов, у которых не до конца сформулированы требования, просто даже другого способа нет реализовать это нормально, кроме как действовать по Scrum, по этапам.
С. Ж.: А вот смотрите, есть ведь интернет-магазины, есть корпоративные порталы, есть совершенно разные проекты, неужели для них для всех подходит Scrum?

В. З.: Для маленьких проектов Scrum не нужен. Если проект на одну-две недели, то это слишком масштабный framework. А если проект большой, например на три, четыре, пять, шесть месяцев разработки, там очень хорошо ложится Scrum, очень хорошо ложится командная разработка, и, в принципе, здесь уже ощущается выхлоп от этого.

С. Ж.: А есть еще какие-то области вообще деятельности в программировании, где Scrum не подходит категорически?
В. З.: Смотрите, Scrum построен на том, чтобы сделать продукт, эффективный для заказчика, чтобы заказчик как можно быстрее получил результат, который можно пощупать. Если заказчик не заинтересован в результате, то там Scrum не подходит абсолютно. Кажется, парадокс, да?
С. Ж.: Да.
В. З.: Как может быть заказчик не заинтересован в результате? Но тем не менее такое сплошь и рядом бывает в каких-нибудь госорганизациях, где цель заключается не в том, чтобы получить готовый рабочий проект, а в том, чтобы попилить что-нибудь.
С. Ж.: Освоить бюджет?
В. З.: Ну да. Там эффективность просто не нужна.
С. Ж.: А в процентном соотношении — лично из твоей деятельности — это сколько? Сколько процентов заказчиков заинтересованы в результате?
В. З.: Мы по своей специфике просто не пересекаемся в основном с теми людьми, которые не заинтересованы в результате. Мы не подходим друг другу.
С. Ж.: Давай тогда представим, что я твой клиент. Давай сформируем ТЗ, будем разрабатывать с помощью Scrum, сделаем, например, интернет-магазин для крупной компании. Я крупный спортивный дистрибьютор, я хочу сделать себе интернет-магазин, наладить дистрибуцию, я произвожу сноуборды, допустим. Вот как мы поступим в данном случае, что мы сделаем?
В. З.: Первое, что мы с тобой сделаем, — это сядем и запишем те функции, которые ты хочешь видеть в интернет-магазине и отсортируем их по приоритету с точки зрения твоего бизнеса. Ну, например, у тебя самое главное в интернет-магазине, чтобы была витрина, чтобы был онлайн-заказ, чтобы была оплата, доставка. Еще ты хочешь дополнительно, чтобы товар можно было трехмерно покрутить, чтобы там была социальная сеть и какие-то дополнительные вещи, которые напрямую у тебя на продажи не влияют. У нас будет список твоих «хотелок», мы его отсортируем по приоритету и будем выполнять твой проект согласно этим приоритетам. И как только у нас будет готов самый важный для тебя функционал, мы сразу же запускаем проект в Сеть. Им же можно пользоваться, и ты сразу можешь получать продажи, получать заявки с сайта, но еще не реализована, например, в интернет-магазине социальная сеть, это потом будет. Вот так постепенно, шаг за шагом, мы наращиваем твой интернет-магазин до максимума.
С. Ж.: То есть ты хочешь сказать, что мы интернет-магазин запустим сразу, потому что интернет-магазин именно как функцию нельзя запустить по частям?
В. З.: Да, скорее всего так, потому что базовый функционал интернет-магазина — это не слишком большая задача.
С. Ж.: Базовый функционал можно запустить в рамках одной итерации?
В. З.: Да, в рамках одной итерации.
С. Ж.: И получится, что я уже смогу продавать?
В. З.: Да.
С. Ж.: А сколько итерация длится в среднем?
В. З.: У нас, по опыту, она длится от одной до двух недель. Нам максимально комфортна двухнедельная итерация.
С. Ж.: У многих, по-моему, до шести?
В. З.: Ну, это много.
С. Ж.: А по поводу «много» давай поговорим. Интернет-магазин, понятно, базово мы как-то запустим?
В. З.: Да.
С. Ж: Но вот какая есть штука, очень важная: мобильные платформы уже данность, это не будущее, это сегодняшняя данность. А как быть, например, с ревьюерами в классическом App Store, где месяц, то есть четыре недели, у тебя может приложение апрувиться, то есть выставляться на модерацию и проверяться. Как соблюсти тут двухнедельный срок?
В. З.: А как это влияет на разработку?
С. Ж.: Получается, что именно релиз ты можешь выпускать только раз в месяц в лучшем случае.
В. З.: Значит, нужно так синхронизировать эти релизы, чтобы они совпадали с требованиями App Store, например.
С. Ж.: А можно написать, например, две версии? То есть, написали версию, а пока она апрувиться, пишем следующую.
В. З.: Можно делать две итерации за этот период, да.
С. Ж.: Тогда, если мы говорим о таких проектах, которые идут, что называется, сразу в народ, как отслеживать баги? Где в этой системе именно отслеживание багов и как оно происходит? И запросы пользователей — как это делается?
В. З.: Мы сначала использовали продукт JIRA австралийской компании Atlassian, очень популярный среди разработчиков и программистов. А сейчас постепенно перетянули все такие задачи в корпоративный портал «1С-Битрикс», сделали специальную штуку для работы по Scrum специально для портала «1С-Битрикс», называется Scrumban. Запросы пользователей, баги и все такие вещи храним внутри корпоративного портала цельно, едино, в общем, со всеми задачами вместе.
С. Ж.: JIRA не позволяла это сделать?
В. З.: Да. JIRA не все умела, что мы хотели.
С. Ж.: Получается, «1С: Битрикс» все умеет, вы сами дописали все, что было нужно?
В. З.: Да.
С. Ж.: А есть ведь еще такое понятие, как бюджет. Если он у меня фиксированный, а он у меня все-таки будет фиксированный, то как быть в случае со Scrum? Ведь непонятно, когда этот процесс закончится, потому что он продолжается. И как быть тогда?
В. З.: Откуда вообще пошло, что в Scrum нефиксированный бюджет? При работе с западными заказчиками это, как правило, проблемы какой-то не составляет. Они понимают уже, что такое Scrum, они как-то к этому привыкли и, в принципе, готовы делать проект и развивать его шаг за шагом, добавляя какие-то новые функции и понимая, что с добавлением функции у нас бюджет увеличивается, с убиранием какой-то функции у нас бюджет может сократиться. Это для них удобно.
С. Ж.: Так тоже бывает, когда бюджет сокращается?

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

При фиксированном бюджете как бывает? Приходит заказчик и говорит: «Вот сколько будет стоить, скажите, пожалуйста, сразу, а потом мы уже будем определяться с вами». Здесь важно выработать какую-то стратегию, по которой мы будем развивать продукт, и первоначально оценить те функции, о которых он говорит, и потом придерживаться этого бюджета. Если заказчик говорит: «Давайте сейчас мы вот это, вот это, вот это добавим, а это, вот это, вот это уберем», мы можем без проблем менять одни вещи на другие равноценные. Это как если бы ты заказывал что-то в магазине, насобирал себе целую корзинку, и пока тебе это везут, ты мог бы еще сказать: «А давайте мне не красные штаны, а зеленые, поменяем», — прямо в процессе доставки. Примерно так это работает, можно менять на равноценное.
С. Ж.: А как я, заказчик, пойму, что проект готов и дальше мне нужна только поддержка? Где нужно остановиться?
В. З.: Заказчик сам определяет, где ему нужно остановиться. Здесь смысл в том, что мы можем выпустить первую версию проекта, скажем, за две недели, три недели, в одну-две итерации, и после этого заказчик может выкатить продукт на рынок, если позволяет набор функций. Рынок уже как-то отреагирует и скажет: «Чувак, надо что-то переделать, твоя идея фуфло, давай что-нибудь еще по-другому сделаем». И в зависимости от реакции рынка можно корректировать набор функций. В Scrum это нормально, в Scrum приветствуются изменения на любых фазах производства проекта.
С. Ж.: В первой итерации, допустим, запускам мы интернет-магазин. А где-то у нас, например, взяли и вылезли критичные баги, которые нужно долго исправлять. Бывает такое?
В. З.: Значит, баги — это отдельная история, баги должны обязательно исправляться в рамках гарантий по проекту, в рамках каких-то еще вещей. Здесь, в Scrum, речь идет не про баги, а про новые функции, «хотелки» и т. д. «Хотелки» свои заказчик добавляет, и рынок может говорить, что то, что хотел раньше заказчик, в самом начале, — это не совсем то, что ему нужно, ну не будет это работать, не будет это продаваться в таком виде. Соответственно, нужно на это реагировать, и вот как раз Scrum это позволяет.
С. Ж.: Сели, начали писать и поняли, что все совсем не так?
В. З.: Да, копали не туда.
С. Ж.: Получается, что через несколько итераций продукт модернизируется до неузнаваемости?
В. З.: Бывает.
С. Ж.: А для пользователя, получается, есть огромный плюс в том, что интерфейсно это меняется не слишком сильно, поэтапно. Пользователю, получается, проще адаптироваться, если это какой-то потребительский продукт, да?
В. З.: Я участвовал в нескольких проектах, когда мы делали три, четыре, пять итераций, запускали альфа-версию продукта, показывали какому-то кругу экспертов. А эксперты говорили, что, например, технарям это удобно, а обычным пользователям — нет, и доходило до смены концепции. Но поскольку у нас был Scrum, у нас были итерации, мы могли относительно безболезненно поменять структуру продукта. Это лучше, чем сделать «толстое» ТЗ, допилить его до конца, а потом выяснить, что пилили не туда.
С. Ж.: А скажи, пожалуйста, если мы говорим про финансирование, вот такой важный вопрос: а как оно проходит, в рамках каждой отдельно итерации либо в общем, за проект?
В. З.: В рамках каждой итерации мы выставляем отдельный счет, отдельное допсоглашение, но при этом абсолютно нормальная ситуация, если мы заранее скажем, что проект стоить будет вот такую-то сумму денег, если вы ничего не будете менять. Но у заказчика всегда есть возможность что-то поменять.
С. Ж.: А почему в рамках итерации каждая оплачивается отдельно, так удобнее?
В. З.: Так удобнее всем.
С. Ж.: Несмотря на то что документооборота, грубо говоря, больше получается?
В. З.: Не сильно больше. Раз в две недели подписывается допсоглашение, подкалывается к основному договору, оплачивается счет, все.
С. Ж.: А тогда скажи, пожалуйста, если говорить про Scrum как методологию, она лучше подходит для проектов, которые с нуля делаются, или уже существующих?
В. З.: Не важно.
С. Ж.: Мне хочется «закопаться», понять, как в процессе Scrum мне как заказчику с вами общаться? Брифы вот эти все, где это все выставляется. Как происходит утверждение всех этих вещей? Я знаю, что у вас продукт есть, Planning Poker?
В. З.: Да, есть такое, для планирования итераций.
С. Ж.: Давай тогда погрузимся в планирование в Scrum. Как я буду видеть, что у вас и как происходит?

В. З.: В Scrum есть такая роль — product owner. Это человек, который отвечает за то, чтобы продукт был клевым для пользователя, чтобы им было офигенно удобно пользоваться и т. д. Российские заказчики пока не совсем могут выполнять эту роль до конца, не совсем могут корректно ее выполнять, поэтому нужен project manager на нашей стороне, который будет проксировать требования заказчика и аккуратно их передавать команде.

Значит, как происходит процесс планирования? Мы садимся с заказчиком, набираем список его «хотелок», набрали, приоритезировали с точки зрения важности запуска. Берем самую верхнюю часть этого списка, что мы хотим делать в первую очередь, и детально прописываем требования: как это будет приниматься, как это будет сдаваться, но не на весь список «хотелок», а только на самую верхнюю часть. И по самой верхней части мы отлично понимаем, как у нас пойдет работа, по нижней она нам пока не нужна, мы на ней не фокусируемся.
С. Ж.: А чего не хватает нашим заказчикам, чтобы быть product owner в этой системе?
В. З.: Мне кажется, здесь дело в том, что еще не хватает доверия к такому подходу. На Западе уже немножко привыкли, готовы по шагам работать с нефиксированным бюджетом. У нас на такое тоже идут, но только когда с командой поработают три-четыре итерации, когда уже поймут, что люди проверенные, что с ними все нормально, косяков не будет. Вот тогда уже это начинает хорошо работать.
С. Ж.: А со временем происходит рост сознательности в плане Scrum у заказчиков? Можно сравнить пять лет назад и сейчас?
В. З.: Пять лет назад никто вообще не слышал про это, сейчас спрашивать начали.
С. Ж.: А в брифингах насколько часто приходится участвовать?
В. З.: Ну, раз в две недели ориентировочно мы садимся, довыясняем дополнительные требования.
С. Ж.: А поясни, пожалуйста, что такое «скрам скрама» (Scrum of Scrums)?
В. З.: Scrum of Scrums предназначен для очень крупных проектов, когда одной команды не хватает, и там добавляется несколько команд, которые внутри себя работают по Scrum, но еще и снаружи у них Scrum с итерациями. Это для очень больших проектов, в Вебе я не знаю, где это в России применяется. Какие-нибудь госуслуги, может быть.
С. Ж.: А как, кстати, госуслуги делать с помощью Scrum? То есть вот если ты бы сейчас делал госуслуги...
В. З.: Я боюсь, я не знаю механику, что там происходит. Скорее всего, там тысяча подрядчиков, которые как-то между собой интегрируются, но не знаю, как там построена механика.
С. Ж.: А как бы ты сделал? Вот если взять ситуацию, когда у тебя нет ограничений, как бы ты сделал госуслуги с точки зрения Scrum?
В. З.: Я никогда про это не задумывался, и это, опять же, госорганизация, там много-много нюансов, пока со всеми все согласуешь…
С. Ж.: То есть там согласований будет больше, чем пользы?
В. З.: Больше, чем работы, да.
С. Ж.: Тогда последний вопрос вот о чем: каковы перспективы Scrum здесь в России и будет ли светлое будущее, когда абсолютно все будут знать о том, что Scrum есть?
В. З.: Сейчас уже практически все знают, но среди разработчиков не все готовы и привыкли использовать. Среди заказчиков знают еще мало, но надо вести просветительскую деятельность, и постепенно крупные проекты, я думаю, все перейдут на такой подход.
С. Ж.: Получается, это только вопрос времени?
В. З.: Ну да.
С. Ж.: Спасибо тебе большое за интересную беседу!
В. З.: Вам спасибо.
С. Ж.: Я желаю тебе побольше понимающих клиентов и, конечно же, побольше интересных заказов.
В. З.: Всем спасибо, удачного вам бизнеса!
С. Ж.: Это была программа «Бизнес online» на SeoPult.TV, и я , Стас Жураковский. Смотрите нас, предлагайте темы, задавайте вопросы. Счастливо!

Развернуть текстовую версию
Комментарии