«Стать крутой командой программистов можно за полгода-год»

Forbes.ru продолжает публиковать интервью с известными деятелями русского сегмента интернета. Сегодня о том, как выглядит создание новых интернет-сервисов глазами не предпринимателя, а разработчика, рассказывает управляющий партнер компании ScrumTrek Асхат Уразбаев. Полную аудиоверсию интервью можно прослушать на сайте программы «Рунетология». 

Асхат Уразбаев: Это зависит от того, чего вы хотите добиться от Agile и Scrum, потому что они решают разные проблемы. Для меня самое главное — сделать команду разработчиков более эффективной, чтобы они могли решать задачи, совершенствоваться.

— Слова Agile и Scrum последние год-полтора звучат часто, но, как мне кажется, у многих менеджеров нет понимания того, что эти слова значат.

— Да, есть узкая тусовка, которая эти слова применяет.

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

— Ребята, с которыми мы работали, пытались посмотреть, что получается. По их словам, производительность увеличивается в два-три раза. А сроки уменьшаются.

— То, что делалось месяцы, делается за десять дней?

— Да, но это субъективный параметр, потому что никто не меряет веб-разработку сроками. Когда нас спрашивают: «Как увеличивается производительность?», мы спрашиваем в ответ: «А в чем вы ее сейчас меряете?» Говорят, что ни в чем. Производительность ни в чем не меряется, и получается, что ее не с чем сравнивать. Зависит от степени бардака, который царил раньше. Если все было совсем плохо, то увеличение будет большим.

— По твоим наблюдениям, насколько высока степень бардака в тех проектах, куда ты приходишь? Что и как меняется после твоего прихода?

— У нас молодая индустрия. Компании не успевают наработать общие практики. Условно говоря, фирме 3 года. Ее нельзя сравнивать с компаниями, которые работают 40 лет. Чем она моложе, тем выше степень бардака. На первом этапе это позитивный бардак, который приносит пользу. Компания растет, доходит до 30 разработчиков, и становится важна эффективность взаимодействия внутри коллектива, иначе возникают проблемы. Чем старше компания, тем больше у нее проектов, тем выше степень бардака, мешающего жить. Тогда компания и начинает задумываться, что с этим можно сделать. Agile и Scrum — один из способов что-то изменить, и, как мне кажется, способ самый эффективный. В Agile самоорганизующаяся и самоуправляемая команда, нет сильной зависимости от ключевых разработчиков, то есть нет человека, который раздает задания. Все люди знают проект.

— Если останется один человек, то он будет владеть всей информацией?

— Всей нет, потому что проект большой, но важную информацию он будет знать. В хорошем Agile-проекте все примерно одинаково владеют информацией. Это называется «совместным владением кодом».

— Это не усложняет процесс?

— Нет, это его облегчает, потому что снимает риски, связанные с уходом ключевых разработчиков. И удешевляет процесс. Например, у тебя есть план итераций на неделю. У тебя есть один человек, который знает один конкретный кусок кода, например разбирается в какой-то функциональности. Кроме него, никто не может заниматься этой частью. Представь себе, что конкретно он не может сейчас работать в этой итерации, а ты предполагаешь, что он будет заниматься разработкой этой функциональности. Что ты предпримешь в такой ситуации? Или, например, три разработчика не взяли три фичи. Каждый может взять в разработку одну фичу и заниматься ею в течение недели. Затем неожиданно заканчивается итерация, и получается, что ни одна фича не сделана. В Agile и Scrum мы стараемся взять одну фичу всей командой из трех человек, доделать ее, протестировать, а потом приняться за следующую. Совместное владение кодом позволяет нам так работать. В итоге стабильность результата итерации выше. Вероятность того, что ты сделаешь основные фичи до конца, выше.

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

— Да, только это происходит в рамках итерации.

— Объясни мне, что такое итерация и зачем она нужна?

— Максим, какова основная проблема в разработке программного обеспечения, если посмотреть на твою команду сверху?

— Например, если говорить о Freshforex.ru с большой командой, проблема заключается в сроках и стабильности работы функций. Там пять разработчиков, но их не хватает. Поставленные сроки не выполняются, я не знаю, по какой причине.

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

— Видимо, сроки неверно оцениваются руководством отдела.

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

— Не беря других задач?

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

— Итерация — это неделя?

— Зависит от конкретной ситуации. Как правило, итерация — это срок от недели до месяца.

— Кто определяет размер итерации в каждом конкретном случае?

— Команда, заказчик, менеджер, руководство. Или совместно. Нужно подобрать длину итерации, которая будет удобна.

— Расскажи смысл понятия Scrum простыми словами.

— У тебя кросс-функциональная команда...

— У меня команда, в которой все знают код продукта. Под чьим руководством они выполняют работу?

— Под руководством владельца продукта. Давай возьмем конкретный пример. Например, у тебя стартап, и у тебя есть project-менеджер, который отвечает за то, чтобы этот стартап был успешным с точки зрения бизнеса. У него определенный набор задач, которые, как правило, сформулированы на уровне бизнеса, то есть это бизнес-требования, не технические. Конкретные формы и отчеты, на которые можно посмотреть и сделать выводы. Список такой функциональности называется бэклогом, списком фичей, списком требований. Product-owner занимается его координацией, он отвечает за приоритеты. В итерацию мы стараемся брать приоритетные фичи и заниматься разработкой этих фичей. В Scrum они называются спринтами.

— Agile и Scrum — разные вещи?

— Agile — это более широкое понятие, нежели Scrum. В Agile входят Scrum, экстремальное программирование и Lean. Scrum обладает меньшим набором практик. Вернемся к примеру. У тебя есть бэклог, product-owner, команда и специальный человек — Scrum-мастер, который следит за тем, чтобы люди соблюдали правила, ежедневно собирались на летучки, которые называются daily Scrum meeting (люди встречаются на 15 минут, чтобы обсудить план на день).

— Есть список задач, менеджер, модератор. Что происходит сначала?

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

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

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

— Это связано со спецификой российского программирования, в котором вообще не принято документировать?

— Да. У тебя есть небольшой план, по которому ты ежедневно работаешь и который помогает тебе управлять проектом. Команда в течение итерации по этому плану работает, и он нужен ей, а не менеджеру. На протяжении итерации команда ежедневно встречается на daily Scrum meeting. В конце итерации результат показывается заказчику и обговаривается, какие фичи сделаны, какие не сделаны и что нужно переделать. В твоем примере это выглядело бы следующим образом. Был бы бэклог, прибежал бы Вася или Петя и сказал, что надо еще что-то сделать, был бы product-owner, который добавил бы еще один пункт и вставил это в план следующей итерации. На общие сроки это повлияло бы, но была бы прозрачность, было бы понятно, что сделано, а что нет. Фичи бы делались, то есть фичи были бы доделаны до конца, а потом разработчики брались бы за следующие. Это не откладывало бы сроки текущих фич.

— По твоим наблюдениям, насколько проблема перегрузки исполнителей распространена в русских проектах?

— В 90% случаев это так.

— Реальная проблема у 90% компаний заключается в том, что выполнение задач не может завершиться, потому что появляются новые?

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

— Не ставит ли непреодолимых проблем менталитет?

— Это зависит от культуры внутри организации. Вопрос в том, чувствует ли команда ценность в формализации. Если люди чувствуют ценность, то они с удовольствием принимают новые методики. Например, Петя перегружен, и ему говорят, что работа будет организована по-другому: у тебя будет проект на определенное время, ты сделаешь эту работу, она будет сдана заказчику, и только потом ты приступишь к новой работе. То есть он не занимается одновременно десятью проектами, он занимается одним проектом, но ему придется приходить на daily Scrum meeting и демонстрировать результаты. Людям обычно это нравится. По моему опыту, команды веб-разработки хорошо принимают Scrum, они чувствуют, что это защищает их от некоторого произвола со стороны менеджмента.

— Давай поговорим о твоем опыте: сколько компаний ты перевел на рельсы подобной работы? Как это происходит?

— Несколько десятков компаний с разной степенью вовлечения. Чаще всего это коучинг: мы берем компанию, составляем бэклог, то есть список требований, потом планируем релиз — решаем, когда закончим запланированные действия, дальше планируем итерацию, затем ее закрываем. Закрытие — демонстрация результатов и ретроспектива по итогам, то есть мы решаем, как улучшить процесс. В течение какого-то количества итераций мы работаем совместно. Мы с Никитой приходим на daily Scrum meeting, наша задача помочь команде приобрести самосознание. Ребята сначала представляют собой группу людей, постепенно они начинают задумываться о целях проекта, становятся настоящей командой, людьми, которые хотят повысить собственную производительность.

— Сколько по времени это занимает? Насколько сложно переучивать программиста?

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

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

— Да. Если бы ребята были экстравертами, любили общаться, тусить и генерить вместе идеи, то некоторые практики Scrum, может, были бы и не нужны (например, daily Scrum meeting). Это дополнение для того, чтобы люди преодолели свою интровертность, нацеленность на написание кода и больше думали о том, как эффективно друг с другом взаимодействовать. Проекты проваливаются не потому, что люди плохо пишут код, а потому, что они не коммуницируют друг с другом.

— Ты сказал, что Scrum-мастер — это модератор, а не руководитель проекта. Каким образом у него строится взаимодействие с project-менеджером, который является начальником? Как ему не уйти в управление? Расскажи более подробно о взаимодействии и функциях.

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

— А объединить эти роли невозможно?

— Возможно, но есть определенные риски. Предположим, product-owner и Scrum-мастер — одно лицо. Обычно Scrum-мастер задает следующие вопросы: «Что ты делал вчера, что ты будешь делать сегодня, какие у тебя проблемы?» Зачем это нужно? Для того чтобы все понимали, что происходит. Если один из членов команды говорит, что закончил задачу №34 и переходит к задаче №35, это не очень хороший ответ, поскольку он не рассказал о том, что он конкретно сделал, что изменилось в коде, что произошло с продуктом. Если приходит менеджер проекта или product-owner и проводит Scrum, то, как правило, он приходит за статусом, точнее, люди ждут, что он приходит за статусом. Они автоматически будут говорить, что они сделали, что будут делать. Они скажут, что проблем нет. Это не daily Scrum. Получается, что product-owner — менеджер, а Scrum-мастер — равноправный член команды. Как только это начинает делать один человек, начинаются проблемы. Если идеи предлагает product-owner, это является давлением на команду. Product-owner — менеджер, предлагающий решения, которые плюс-минус обязательны для выполнения. Довольно трудно кому-то одному совмещать функции этих двух человек. Возникает проблема лидерства. Product-owner — лидер, человек, который ведет людей за собой, человек, как правило, с большим эго, человек, который вырвался в лидеры благодаря тому, что не боялся брать на себя ответственность, вел людей за собой. Scrum-мастер — человек с маленьким эго. Его задача не вылезти вперед, а сделать команду более эффективной.

— Agile применяется только в очной работе или в дистанционной работе его тоже возможно использовать?

— Мы делаем это в удаленных компаниях. Все больше и больше команд предпочитает заниматься этим удаленно. Современные средства позволяют это делать (Skype, видеоконференции).

— Можно ли привести конкретные примеры, как Agile и Scrum экономят деньги или время?

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

— И звучат слова: «Это совершенно не то, что я заказывал».

— Да. Вы поднимаете документы, показываете, что вам говорили, а заказчик говорит, что он не то имел в виду. В Agile и Scrum мы бы собрали требования, у нас был бы бэклог, мы бы начали работать, показали бы результат в конце первой итерации, и тут бы заказчик понял, что это не то, чего он ждет от сайта. Мы показываем сайт заказчику, он говорит, что это не то, что ему нужно, концепция меняется. Мы провалились, но провалились, потеряв неделю, а не три месяца. По опыту происходит так: из бэклога (около 100 фич) примерно 60 мы делаем, 40 выбрасываем и 40 добавляем. В итоге мы не только добавляем функционал, но и выбрасываем ненужные части.

— Иными словами, точно посчитать деньги невозможно. Возможно, это 100% бюджета: вы сделали то, а могли сделать на 100% не то.

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

— Насколько сейчас, как тебе кажется, распространены методы Agile? Сколько компаний стали этим заниматься с твоей подачи в Москве, в России? Скажи, какой процент эффективно использует эту методику?

— Процент я не могу назвать, но в вебе он большой — чуть меньше 50%, если брать типичные проекты. Мне нравится, что в Agile приходят лидеры, компании, которые на слуху.

— Можешь назвать какие-то конкретные удачные проекты из тех, что на слуху, которые делались и делаются с использованием Agile?

— Например, «Мегаплан», «Мой круг». Auto.ru сейчас использует Scrum.

— Какие услуги ScrumTrek оказывает российским компаниям чаще: реанимация бизнес-процессов или профилактика?

— Реанимация.

— Применяешь ли ты гибкие методологии в обычной жизни? И как, например?

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

— Вопрос от слушателя: «Каков максимальный срок внедрения Scrum в работу небольшой компании?» Назови и минимальный.

— Максимальный срок не ограничен. Есть такие компании, как Microsoft или «Лаборатория Касперского», у которых много команд. Процесс начинается с одной команды, а потом масштабируется. Минимальный срок — три месяца, наверное.

— В каких компаниях ваше внедрение Scrum и Agile можно признать полностью провальным и почему?

— Компании я не могу назвать, но я могу рассказать об обобщенных случаях. Основная причина — человеческий фактор. Учим мы примерно одним и тем же вещам с оглядкой на специфику компании. Наша задача в том, чтобы компания могла самостоятельно все это делать, то есть могла придумывать процессы. Часто имеет место политическое недовольство внутри организации, когда кто-то из менеджмента чувствует угрозу для себя в новой методологии, которая в какой-то степени отнимает у него контроль. Бывает так, что мое внедрение было неудачным, то есть я пришел в команду, прочитал короткий тренинг, но это не совсем то, что нужно людям. Я не считаю это провалом, потому что люди все равно внедряют Agile, просто полезность моего тренинга не такая высокая, какой могла бы быть. Провально, когда конечным пользователям заказчика результат не нужен. Например, вы работаете с госкомпаниями. Подавляющее большинство госкомпаний, что уж там говорить, не заинтересовано в результате, они заинтересованы в распиле. Внедрить там Agile и Scrum практически невозможно и бессмысленно.