![Page 1: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/1.jpg)
Опыт реформирования большой команды разработчиков
Сергей Никулин
![Page 2: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/2.jpg)
Команда HeadHunter в конце 2010г• Разработка и поддержка самого крупного job
сайта восточной европы
• Около 10 внутренних заказчиков
• ~30 программистов и верстальщиков и ~5тестировщиков
• “функциональное” деление команд
![Page 3: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/3.jpg)
Технологии на конец 2010г• Issue tracker – JIRA
• Wiki – Confluence
• SCM – Subversion
• Нестабильный trunk, релиз собирается в ветке
![Page 4: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/4.jpg)
Система мотивации на конец 2010г
• Заказчики оценивают всю разработку в целом
• Руководитель распределяет бонусы индивидуально по каждому человеку
![Page 5: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/5.jpg)
Существующие проблемы на конец 2010г
• Низкая скорость выпуска задач – заказчики не довольны
• Тестирование является узким местом
• Очень дорогая разработка крупных задач (> 2 недель)
![Page 6: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/6.jpg)
Возможные пути решения• Уменьшение размеров команд – дробление
функциональных или создание автономных
• Стабильный trunk, разработка в ветках
• Внедрение методологии – SCRUM или Kanban
![Page 7: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/7.jpg)
Выбранная конфигурация• SCRUM для всех
• Автономные команды под заказчика
• GIT со стабильным master’ом
• Тимлид в команде + Тимлидфункционального направления
![Page 8: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/8.jpg)
Организация команд
![Page 9: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/9.jpg)
Опыт работы “по-новому”• Резкое повышение скорости выпуска
задач и удовлетворенности заказчиков
• Шаринг ресурсов работает очень плохо
• Снижение качества
![Page 10: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/10.jpg)
Как нам повысить качество?• Централизованная приемка кода +
функциональные автотесты
• Усиление роли функциональных тимлидов
• Технологический долг
• Технологический налог
![Page 11: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/11.jpg)
Новая система мотивации• Architecture Board оценивает каждую команду
• Заказчик определяет общий бонусный фонд для своей команды
• Каждый получает бонус пропорционально з.п.
![Page 12: Опыт реформирования большой команды разработчиков (Сергей Никулин)](https://reader033.vdocument.in/reader033/viewer/2022060200/5598cab81a28ab3b568b4824/html5/thumbnails/12.jpg)
Остающиеся проблемы• Иногда возникает дисбаланс ресурсов
• Качество надо повышать дальше