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

1. Эволюция разработки в Badoo
Рыбак Алексей
зам. главы разработки Badoo
a.rybak@corp.badoo.com

2. привет
Всего лишь ещё один рассказ о том, как
развивалась разработка в большом
проекте
Кризисы роста: области
ответственности, производственные
цепочки
Поделить/переделать, сохранив
ценности и пульс

3. Badoo
 Социальная сеть для встречи с новыми людьми
 190М users, ~30M MAU, ~10M DAU
 Крупнейшие страны: Испания, Италия, Франция, Бразилия,
США
 2 офиса разработки: Москва и Лондон
 Миллионы строк кода, тысячи серверов, три датацентра
 Стандартный стэк: Linux, nginx, PHP, MySQL, Memcached,
C/C++
 100+ инженеров

4. Продуктовая интернет-компания
Программа в единственном экземпляре
Менее остро стоят вопросы совместимости ПО
и железа
Можно всё подбирать под себя и
подкручивать «на ходу»

5. Ценности продуктового стартапа
Быстрый либо мёртвый
Экспериментируем, скорость в ущерб
качеству
24х7, «легкий» саппорт

6. От стартапа к продуктовой компании
Бизнес-инварианты
«Лёгкий» саппорт: разделение ответственности,
инфраструктурные проекты
Максимально быстрый цикл разработки при
сохранении качества: производственные цепочки
Проследим, как менялась разработка и сохранялись
инварианты

7. Кризисы роста
Кризис I: саппорт (10 – 20 чел, 2007)
Кризис II: дробление и новые роли в
организации (20 – 50 чел, 2009)
Кризис III: качество (QA) и перестройка
производственных цепочек (50 – 100+ чел,
2011)

8. Саппорт
 Время программистов = время разработки продукта +
время на саппорт
 Саппорт в широком смысле
• Поиск и мониторинг медленных/ненадежных мест
• Переделка архитектуры
• Инструменты для поддержки (мониторинг, деплой,
управление кластерами...)
• Инструменты для разработки (автоматизация,
ядро...)

9. Саппорт: отдельную команду не строим
 Пахнет «штрафбатом»
 Вовлеченность и мотивация сотрудников
 Твой софт – твой крест
• Ты накосячил – ты и правь
• Нагрузка вырастет в «стопицот» раз, вокруг всё
миллион раз упадет, наш (твой!) софт должен это
пережить
• Пусть будут ошибки – давай быстро поправим,
просто не тупи и делай

10. Кризис I: саппорт (2007)
Отдельное направление: производительность,
надежность, мониторинг
Фейл: общие ресурсы
Фикс:
• A-team + C/C++ = Platform
(инфраструктурные проекты)
• Рост группы сисадминов/эксплуатации

11. Кризис II: дробление (2009?)
Оставить быстрым цикл разработки
Поделить команды функционально
Производственная цепочка по-прежнему
тривиальна: фигак-фигак, в продакшн!
Строим продуктовую команду
Не меняем сильно процессы, боимся сбить ритм

12. Кризис II: дробление
 Фейл: как «не пошёл» Scrum
 Функциональное дробление без перестройки
производственных цепочек
 С/С++, фичи, биллинг, A-team, мобильная разработка,
бэк-офис, антиспам/почта
 Проблемы: лиды, перераспределение зон
 Фейл: позиции «магов»
 Проблема: качество
 Рекрутинг и HR, системный ревью зп

13. Кризис III: качество (2011)
Перестройка производственных цепочек
Отдел качества, release engineering
Девелоперская инфраструктура: площадка,
continuous integration, управление релизами, прочая
автоматизация
Перестройка без остановки разработки продукта: Ateam
Параллельно: строим QA/RE

14. Сейчас: статусы задач (фичи)
 PRD <-> нет вопросов у программистов
 Задача разбита по компонентам (микрокоманды)
 Если нужно железо – есть сроки
 Сопутствующие задачи (BI, мониторинг)
 Код и тесты написаны, тесты прошли на девеле, ревью
 QA passed
 Переводы готовы (40 языков, ~10 основных)
 RE: тесты на стейджинге, деплой
 Деплой м.б. поэтапным: группа пользователей -> метрики -> везде

15. Кризис III: перестройка процессов
 Подготовка в 2011, плотно - лишь в 2012 году
 Деплой по фичам: svn -> git, «шоты» (фича) и «билды»
(релизы)
 Девелоперская площадка: полная эмуляция 2х ДЦ и
базовых компонент
 Утилиты деплоя и автоматизации, интеграция с JIRA,
доработка staging-инфраструктуры
 Версионирование переводов

16. Кризис III: перестройка процессов
 Строгий flow в JIRA + автоматизация
 Unit-тесты: 22000 тестов за 3 минуты
 Selenium-тесты: 500 тестов за 20 минут
 2 релиза в день: утром и после обеда
 Стогие стандарты кодирования, заголовки (модулькоманда-человек), покрытие кода
 A-team -> передача сисадминам и релиз-инженерам

17. Выводы (1)
Методологии не очень существенны
Без фанатизма и сектанства. Waterfall? Пускай. Не
Agile? И что?
Выжили (не везде): backlogs, burn down charts,
stand-up meetings

18. Выводы (2)
Инфраструктурные проекты неизбежны
Технический долг: время разработки продукта ->
отдельная команда. A-team у нас – не DevOps
Без QA можно обходиться, и долго. Качество на
этапе релиза vs. качество в “продакшне” (ошибки,
мониторинг)

19. Выводы (3)
Неизбежность QA: рост по числу людей в
команде фич
Если строить QA – чем раньше, тем лучше
Перестройка цепочек – наиболее болезненные
процессы
С отдельной командой – лучше: очень много
сопутствующих задач

20. Спасибо!
Ваши вопросы, пожалуйста!
a.rybak@corp.badoo.com
http://habrahabr.ru/company/badoo
http://facebook.com/BadooMoscow
http://twitter.com/BadooDev