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

Опыт реформирования большой команды разработчиков

Сергей Никулин

Команда HeadHunter в конце 2010г• Разработка и поддержка самого крупного job

сайта восточной европы

• Около 10 внутренних заказчиков

• ~30 программистов и верстальщиков и ~5тестировщиков

• “функциональное” деление команд

Технологии на конец 2010г• Issue tracker – JIRA

• Wiki – Confluence

• SCM – Subversion

• Нестабильный trunk, релиз собирается в ветке

Система мотивации на конец 2010г

• Заказчики оценивают всю разработку в целом

• Руководитель распределяет бонусы индивидуально по каждому человеку

Существующие проблемы на конец 2010г

• Низкая скорость выпуска задач – заказчики не довольны

• Тестирование является узким местом

• Очень дорогая разработка крупных задач (> 2 недель)

Возможные пути решения• Уменьшение размеров команд – дробление

функциональных или создание автономных

• Стабильный trunk, разработка в ветках

• Внедрение методологии – SCRUM или Kanban

Выбранная конфигурация• SCRUM для всех

• Автономные команды под заказчика

• GIT со стабильным master’ом

• Тимлид в команде + Тимлидфункционального направления

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

Опыт работы “по-новому”• Резкое повышение скорости выпуска

задач и удовлетворенности заказчиков

• Шаринг ресурсов работает очень плохо

• Снижение качества

Как нам повысить качество?• Централизованная приемка кода +

функциональные автотесты

• Усиление роли функциональных тимлидов

• Технологический долг

• Технологический налог

Новая система мотивации• Architecture Board оценивает каждую команду

• Заказчик определяет общий бонусный фонд для своей команды

• Каждый получает бонус пропорционально з.п.

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

• Качество надо повышать дальше

Вопросы?• nikulin@hh.ru

• http://twitter.com/nikulin