Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Доклад Алексея Рыбака на Whalerider 2013. Эволюция разработки в Badoo.

В докладе освещена ретроспектива организации разработки крупного интернет-проекта от стартапа до 190 миллионов пользователей.
Как устроена разработка сейчас, как в процессе развития проекта её перестраивали, какие проблемы решали,
преодолевая кризисы роста, на какие грабли наступали. В секции вопросов есть интересная информация о том, как в Badoo устроена
система мотивации и бонусов. Доклад будет интересен всем, кто занимается организацией процесса разработки в крупных интернет-проектах.

  • Login to see the comments

Доклад Алексея Рыбака на Whalerider 2013. Эволюция разработки в Badoo.

  1. 1. Эволюция разработки в Badoo Рыбак Алексей зам. главы разработки Badoo a.rybak@corp.badoo.com
  2. 2. привет Всего лишь ещё один рассказ о том, как развивалась разработка в большом проекте Кризисы роста: области ответственности, производственные цепочки Поделить/переделать, сохранив ценности и пульс
  3. 3. Badoo  Социальная сеть для встречи с новыми людьми  190М users, ~30M MAU, ~10M DAU  Крупнейшие страны: Испания, Италия, Франция, Бразилия, США  2 офиса разработки: Москва и Лондон  Миллионы строк кода, тысячи серверов, три датацентра  Стандартный стэк: Linux, nginx, PHP, MySQL, Memcached, C/C++  100+ инженеров
  4. 4. Продуктовая интернет-компания Программа в единственном экземпляре Менее остро стоят вопросы совместимости ПО и железа Можно всё подбирать под себя и подкручивать «на ходу»
  5. 5. Ценности продуктового стартапа Быстрый либо мёртвый Экспериментируем, скорость в ущерб качеству 24х7, «легкий» саппорт
  6. 6. От стартапа к продуктовой компании Бизнес-инварианты «Лёгкий» саппорт: разделение ответственности, инфраструктурные проекты Максимально быстрый цикл разработки при сохранении качества: производственные цепочки Проследим, как менялась разработка и сохранялись инварианты
  7. 7. Кризисы роста Кризис I: саппорт (10 – 20 чел, 2007) Кризис II: дробление и новые роли в организации (20 – 50 чел, 2009) Кризис III: качество (QA) и перестройка производственных цепочек (50 – 100+ чел, 2011)
  8. 8. Саппорт  Время программистов = время разработки продукта + время на саппорт  Саппорт в широком смысле • Поиск и мониторинг медленных/ненадежных мест • Переделка архитектуры • Инструменты для поддержки (мониторинг, деплой, управление кластерами...) • Инструменты для разработки (автоматизация, ядро...)
  9. 9. Саппорт: отдельную команду не строим  Пахнет «штрафбатом»  Вовлеченность и мотивация сотрудников  Твой софт – твой крест • Ты накосячил – ты и правь • Нагрузка вырастет в «стопицот» раз, вокруг всё миллион раз упадет, наш (твой!) софт должен это пережить • Пусть будут ошибки – давай быстро поправим, просто не тупи и делай
  10. 10. Кризис I: саппорт (2007) Отдельное направление: производительность, надежность, мониторинг Фейл: общие ресурсы Фикс: • A-team + C/C++ = Platform (инфраструктурные проекты) • Рост группы сисадминов/эксплуатации
  11. 11. Кризис II: дробление (2009?) Оставить быстрым цикл разработки Поделить команды функционально Производственная цепочка по-прежнему тривиальна: фигак-фигак, в продакшн! Строим продуктовую команду Не меняем сильно процессы, боимся сбить ритм
  12. 12. Кризис II: дробление  Фейл: как «не пошёл» Scrum  Функциональное дробление без перестройки производственных цепочек  С/С++, фичи, биллинг, A-team, мобильная разработка, бэк-офис, антиспам/почта  Проблемы: лиды, перераспределение зон  Фейл: позиции «магов»  Проблема: качество  Рекрутинг и HR, системный ревью зп
  13. 13. Кризис III: качество (2011) Перестройка производственных цепочек Отдел качества, release engineering Девелоперская инфраструктура: площадка, continuous integration, управление релизами, прочая автоматизация Перестройка без остановки разработки продукта: Ateam Параллельно: строим QA/RE
  14. 14. Сейчас: статусы задач (фичи)  PRD <-> нет вопросов у программистов  Задача разбита по компонентам (микрокоманды)  Если нужно железо – есть сроки  Сопутствующие задачи (BI, мониторинг)  Код и тесты написаны, тесты прошли на девеле, ревью  QA passed  Переводы готовы (40 языков, ~10 основных)  RE: тесты на стейджинге, деплой  Деплой м.б. поэтапным: группа пользователей -> метрики -> везде
  15. 15. Кризис III: перестройка процессов  Подготовка в 2011, плотно - лишь в 2012 году  Деплой по фичам: svn -> git, «шоты» (фича) и «билды» (релизы)  Девелоперская площадка: полная эмуляция 2х ДЦ и базовых компонент  Утилиты деплоя и автоматизации, интеграция с JIRA, доработка staging-инфраструктуры  Версионирование переводов
  16. 16. Кризис III: перестройка процессов  Строгий flow в JIRA + автоматизация  Unit-тесты: 22000 тестов за 3 минуты  Selenium-тесты: 500 тестов за 20 минут  2 релиза в день: утром и после обеда  Стогие стандарты кодирования, заголовки (модулькоманда-человек), покрытие кода  A-team -> передача сисадминам и релиз-инженерам
  17. 17. Выводы (1) Методологии не очень существенны Без фанатизма и сектанства. Waterfall? Пускай. Не Agile? И что? Выжили (не везде): backlogs, burn down charts, stand-up meetings
  18. 18. Выводы (2) Инфраструктурные проекты неизбежны Технический долг: время разработки продукта -> отдельная команда. A-team у нас – не DevOps Без QA можно обходиться, и долго. Качество на этапе релиза vs. качество в “продакшне” (ошибки, мониторинг)
  19. 19. Выводы (3) Неизбежность QA: рост по числу людей в команде фич Если строить QA – чем раньше, тем лучше Перестройка цепочек – наиболее болезненные процессы С отдельной командой – лучше: очень много сопутствующих задач
  20. 20. Спасибо! Ваши вопросы, пожалуйста! a.rybak@corp.badoo.com http://habrahabr.ru/company/badoo http://facebook.com/BadooMoscow http://twitter.com/BadooDev

×