1. Опыт реформирования большой
команды разработчиков
Сергей Никулин

2. Команда HeadHunter в конце 2010г
• Разработка и поддержка самого крупного job
сайта восточной европы
• Около 10 внутренних заказчиков
• ~30 программистов и верстальщиков и ~5
тестировщиков
• “функциональное” деление команд

3. Технологии на конец 2010г
• Issue tracker – JIRA
• Wiki – Confluence
• SCM – Subversion
• Нестабильный trunk, релиз собирается в
ветке

4. Система мотивации на конец 2010г
• Заказчики оценивают всю разработку в
целом
• Руководитель распределяет бонусы
индивидуально по каждому человеку

5. Существующие проблемы на конец
2010г
• Низкая скорость выпуска задач – заказчики
не довольны
• Тестирование является узким местом
• Очень дорогая разработка крупных задач (>
2 недель)

6. Возможные пути решения
• Уменьшение размеров команд – дробление
функциональных или создание автономных
• Стабильный trunk, разработка в ветках
• Внедрение методологии – SCRUM или
Kanban

7. Выбранная конфигурация
• SCRUM для всех
• Автономные команды под заказчика
• GIT со стабильным master’ом
• Тимлид в команде + Тимлид
функционального направления

8. Организация команд

9. Опыт работы “по-новому”
• Резкое повышение скорости выпуска
задач и удовлетворенности заказчиков
• Шаринг ресурсов работает очень плохо
• Снижение качества

10. Как нам повысить качество?
• Централизованная приемка кода +
функциональные автотесты
• Усиление роли функциональных тимлидов
• Технологический долг
• Технологический налог

11. Новая система мотивации
• Architecture Board оценивает каждую команду
• Заказчик определяет общий бонусный фонд
для своей команды
• Каждый получает бонус пропорционально з.п.

12. Остающиеся проблемы
• Иногда возникает дисбаланс ресурсов
• Качество надо повышать дальше

13. Вопросы?
• nikulin@hh.ru
• http://twitter.com/nikulin