Основанный в Швеции, а ныне базирующися в Берлине музыкальный сервис Soundcloud готовится к продаже за $1 млрд, сообщило на исходе июля агентство Bloomberg. На недавней минской конференции MobileOpimized выступил Android-разработчик Soundcloud Фернандо Сехас (Fernando Cejas). В интервью dev.by он рассказал о том, как работают Agile-команды внутри стартапа-единорога и как парное программирование влияет на качество кода.

Читать далее

Аргентинец в Берлине

— Я разрабатываю под Android едва ли не с самого его появления. Помню, когда только начинал играться с ранними версиями, система выглядела сырой, словно прототип. Сейчас я не мобильный разработчик в привычном понимании слова: в Soundcloud работаю в команде, которая занимается ядром инфраструктуры приложения. Так что с фреймворком Android почти не имею дела — занят созданием более совершенных инструментов под Android, которые облегчат работу другим разработчикам.

Я родился в Аргентине, но немного помотался по миру: сначала переехал в Испанию, потом год поработал в США, затем снова вернулся в Испанию, и вот теперь уже почти два года живу в Берлине.

Мне нравится работать в Soundcloud: люблю и разработку, и музыку. У нас в компании всё о музыке: здесь работает много меломанов, музыкантов, в офисе даже есть звукозаписывающая студия и DJ-станция. Можно просто прийти, взять инструмент и поиграть в своё удовольствие.

О разнице между Agile-методами и реальной гибкостью

Всего в Soundcloud около 180 программистов. Раньше у нас были раздельные команды для Android и iOS, но сейчас от деления отказались: мы разбиваемся на небольшие группки, которые занимаются конкретными функциями приложения. Например, в одной команде собираются по два Android-, iOS-, web- и бэкенд-разработчика — и все вместе работают над конкретной частью продукта или фичей. В моей команде — core team — сейчас шесть человек.

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

Хороший программист должен быть гибким. По-моему, использовать гибкие методологии и быть гибким — совсем не одно и то же.

Конечно, можно просто взять один из Agile-фреймворков и пытаться подстроиться под него — неважно, будет это Scrum, Kanban или популярный нынче Scrumban, который пытается взять лучшее из обоих миров. Но мы стараемся не адаптироваться под фреймворки, а, наоборот, менять их под себя. Это ключевой момент. Если Scrumban помогает вам быть производительным и без ежедневных планёрок, смело отменяйте планёрки. Собирайтесь раз в две недели или даже раз в месяц. И наоборот, если вам нужно что-то срочно обсудить, соберите команду прямо сейчас, не тяните до следующей запланированной даты. Берите из идей лучшее, а не следуйте за ними слепо.

Каждый человек должен чётко понимать, как ему работается лучше всего, искать подходящие техники. Я, например, использую для организации своих задач личную канбан-доску. Когда мне нужно на чём-то сосредоточиться, я использую технику pomodoro. Иногда она работает лучше, иногда хуже, но, как правило, она даёт хороший результат.

О пользе парного программирования

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

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

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

Кстати, даже когда мы программируем в парах, код всё равно отправляется на pull request, и его обязательно должен одобрить кто-то третий. Разница в том, что когда ты пишешь код один, то должен получить два одобрения, а когда вы работаете в паре, достаточно одного.

Раньше я работал в консалтинге. Разумеется, там подход совершенно иной: ты постоянно перемещаешься между разными проектами и продуктами, и рабочие техники приходится адаптировать к каждому клиенту и заказчику. Но парное программирование помогает даже в этом случае: ты можешь пойти в офис к заказчику и поработать в паре с кем-то из компании клиента. Я и сам так делал, и это всегда отлично работало: так ты можешь быстро получить нужные знания о продукте.

«Делитесь идеями!»

Я убеждён, что хороший программист должен рассказывать о своих идеях, о своих решениях сложных проблем. Разумеется, мы не можем выложить весь код Soundcloud в открытый доступ: наша бизнес-модель этого не позволяет. Но часто мы запрашиваем у руководства разрешение на выкладывание наших библиотек в сеть.

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

О Soundcloud Go и о целях

Я считаю, что Soundcloud — всё ещё стартап. Стартап — это ведь не про размер компании, не про количество работников и офисов; это про бизнес-модель.

В марте мы запустили Soundcloud Go, самый крупный внутренний проект за всё время существования компании, и он стал для нас всех поворотным моментом. Разумеется, любая компания хочет быть прибыльной, не зависеть от инвестиций. И Go — это «плюс один» для прибыльности Soundcloud.

Go стал большим техническим вызовом для нас: мы должны были затронуть каждую строку базового кода Soundcloud. Около 200 микросервисов на бэкенде, плюс все платформы — Android, iOS и Web — всё пришлось разобрать и, если требовалось, переписать. Убедиться, что ничего не упущено, что всё скоординировано — это очень сложная задача.

Скажем, если пользователь купил подписку на Android, он должен в реальном времени увидеть результат покупки и на iOS — а это значит, разработчики под разные платформы должны постоянно работать вместе. Нам ещё много всего предстоит улучшить и исправить. Хороший программист должен принимать сложные вызовы, чтобы становиться лучше.

Но наша главная цель остаётся прежней: мы хотим быть не столько платформой для прослушивания популярных артистов, сколько платформой для создателей музыки. И Soundcloud Go — это возможность монетизации не только для нашей компании, но и для музыкантов.

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

«Отмечайте свои достижения»

Вот вам совет: отмечайте свои достижения. Я убеждён, что это лучший путь к тому, чтобы поддерживать мотивацию на должном уровне.

В Soundcloud каждый может предложить маленький праздник, в любой день. Если завершена большая задача, мы можем выбраться на озеро и провести там пару дней всей командой. А можем и просто пойти на пиво. И даже немножко напиться!

Не стесняйтесь показать людям, как вы рады своим достижениям. Даже если вы работали над чем-то самостоятельно, и никто в команде с этой работой не связан, отметьте результат сами. Просто сделайте то, что поднимет вам настроение в этот момент.

Фото: Андрей Давыдчик, dev.by

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.