Рубрика «процессы» - 5

Стоит ли высокое качество ПО затрат на его разработку? - 1

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.

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

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

Когда-то я был младшим разработчиком и ужасно не любил слово «процессы». Все эти регулярные встречи и прочее общение казались глупостями, отвлекающими от содержательной работы (написания кода, конечно). Думаю, такой этап случался в жизни у каждого, кто занимался разработкой; но такому этапу полезно повторяться регулярно: любую деятельность можно оптимизировать (например, вообще отменив), и иногда ощущение бессмысленности происходящего оказывает поистине целебное действие.

Как устроены процессы разработки в различных компаниях - 1

Мы решили посвятить процессам разработки наш следующий Team Leader Meetup, который пройдёт вечером 17 июня в московском офисе Яндекса. Регистрация открыта!

Нашими экспертами согласились быть:

  • Анатолий anatolix Орлов, CTO, Ozon
  • Алексей Катаев deusdeorum, Head of Software Development, SkyEng
  • Александр Гутман, CTO, JoomPay
  • Евгений Парамонов, руководитель разработки поисковых подмешиваний, Яндекс
  • Андрей Плахов yafinder, руководитель отдела функциональности поиска, Яндекс

Сегодня они отвечают на некоторые вопросы, чтобы подготовить будущую дискуссию:

1. На какой основе построены процессы у вас в компании?
2. По вашему опыту, какой процент успеха команды определяется правильными процессами, а какой индивидуальным мастерством?
3. Бывают ли ситуации, в которых тимлид имеет полное право игнорировать любые процессы?
4. Расскажите какую-нибудь страшную историю из вашего опыта со словом «процесс»

Под катом — много огня, сарказм в адрес авторов вопросов, максимально различные мнения и, конечно, страшные истории.

Читать полностью »

Введение от переводчика

В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.

Ещё от переводчика

Статья от 2016 года, но речь в ней идёт о базовых концепциях, которые не устаревают.

Ссылки на понятия и комментарии от меня (переводчика) расположены в квадратных скобках [] и снабжены указателем "прим. переводчика".

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

Отдельное спасибо Яну Гравшину за помощь в вычитке и редактуре текста.

Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.

001

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

Читать полностью »

image

Здравствуй! В далёком 2005 году в ABBYY появился первый мобильный SDK. А в 2007 в компании образовался отдельный департамент ABBYY Mobile, и начали рождаться технологии, которые стали основой наших приложений — ABBYY Business Card Reader, ABBYY FineScanner и ABBYY TextGrabber. В 2009 наш первопроходец Business Card Reader вышел на мобильные (кнопочные!) телефоны Nokia под управлением Symbian. И совсем скоро, 19 марта 2019 года, мы будем праздновать первое десятилетие.

В этом посте мы расскажем и покажем, как устроена изнутри жизнь и работа ABBYY Mobile, какие технологии мы разрабатываем, куда ездим в командировки и многое другое.
Читать полностью »

Как Unsplash масштабируется силами небольшой команды - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

Масштабирование Unsplash маленькой командой: 8 человек и 10 миллионов запросов в сутки - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

Как восемь человек масштабируют highload-проект. Опыт Unsplash - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

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

Выстраиваем эффективное взаимодействие инженерной и продуктовой команд - 1
@innubis

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

Мы в Badoo относительно небольшими силами (в моей команде 30 человек) ежемесячно деплоим порядка сотни новых востребованных фич, при этом не теряя в качестве кода, планирования и поддержки. Каким образом нам удаётся оставаться «на коне» и как у нас построено взаимодействие инженерной команды с продуктовой, я расскажу в этой статье.

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

Читать полностью »

Привет!

Сегодня я расскажу о создании отдела тестирования на примере небольшой компании, которая уже 3 года выпускает мобильные игры. Особенность в том, что компания не зависит от спонсоров и живёт за счёт денег, которые зарабатывает. И нам, как сотрудникам, важно делать то, что, на наш взгляд, будет нравиться пользователям. Есть возможность экспериментировать и работать на аудиторию, но, при этом, куда меньше времени на разработку продукта.

Необходимость в QA отделе появилась год назад и процесс тестирования мне необходимо было выстроить, не ломая при этом график релизов.

Тестирование в мобильном геймдеве: что такое и в чём проблема

QA в мобильной разработке выступает чем-то вроде секретной службы. Пока работает хорошо, никто не замечает, что тестирование проводится. Но стоит Акелле хотя бы раз промахнуться и комментарии к игре пестрят сообщениями разной степени разгневанности. В сущности, задача мобильного тестировщика — проследить за тем, чтобы в приложении был минимум заметных багов, а команды разработки чётко представляли себе смысл каждого релиза и работали на достижение результата.

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

Процесс тестирования сталкивается со следующими проблемами:

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

Читать полностью »

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

Особенности разработки мобильной MMO RTS. Часть 6 - 1
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js