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.
Опыт реформирования большой   команды разработчиков        Сергей Никулин
Команда HeadHunter в конце 2010г• Разработка и поддержка самого крупного job  сайта восточной европы• Около 10 внутренних ...
Технологии на конец 2010г•   Issue tracker – JIRA•   Wiki – Confluence•   SCM – Subversion•   Нестабильный trunk, релиз со...
Система мотивации на конец 2010г• Заказчики оценивают всю разработку в  целом• Руководитель распределяет бонусы  индивидуа...
Существующие проблемы на конец              2010г• Низкая скорость выпуска задач – заказчики  не довольны• Тестирование яв...
Возможные пути решения• Уменьшение размеров команд – дробление  функциональных или создание автономных• Стабильный trunk, ...
Выбранная конфигурация•   SCRUM для всех•   Автономные команды под заказчика•   GIT со стабильным master’ом•   Тимлид в ко...
Организация команд
Опыт работы “по-новому”• Резкое повышение скорости выпуска  задач и удовлетворенности заказчиков• Шаринг ресурсов работает...
Как нам повысить качество?• Централизованная приемка кода +  функциональные автотесты• Усиление роли функциональных тимлид...
Новая система мотивации• Architecture Board оценивает каждую команду• Заказчик определяет общий бонусный фонд  для своей к...
Остающиеся проблемы• Иногда возникает дисбаланс ресурсов• Качество надо повышать дальше
Вопросы?• nikulin@hh.ru• http://twitter.com/nikulin
Upcoming SlideShare
Loading in …5
×

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

1,596 views

Published on

  • Be the first to comment

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

  1. 1. Опыт реформирования большой команды разработчиков Сергей Никулин
  2. 2. Команда HeadHunter в конце 2010г• Разработка и поддержка самого крупного job сайта восточной европы• Около 10 внутренних заказчиков• ~30 программистов и верстальщиков и ~5 тестировщиков• “функциональное” деление команд
  3. 3. Технологии на конец 2010г• Issue tracker – JIRA• Wiki – Confluence• SCM – Subversion• Нестабильный trunk, релиз собирается в ветке
  4. 4. Система мотивации на конец 2010г• Заказчики оценивают всю разработку в целом• Руководитель распределяет бонусы индивидуально по каждому человеку
  5. 5. Существующие проблемы на конец 2010г• Низкая скорость выпуска задач – заказчики не довольны• Тестирование является узким местом• Очень дорогая разработка крупных задач (> 2 недель)
  6. 6. Возможные пути решения• Уменьшение размеров команд – дробление функциональных или создание автономных• Стабильный trunk, разработка в ветках• Внедрение методологии – SCRUM или Kanban
  7. 7. Выбранная конфигурация• SCRUM для всех• Автономные команды под заказчика• GIT со стабильным master’ом• Тимлид в команде + Тимлид функционального направления
  8. 8. Организация команд
  9. 9. Опыт работы “по-новому”• Резкое повышение скорости выпуска задач и удовлетворенности заказчиков• Шаринг ресурсов работает очень плохо• Снижение качества
  10. 10. Как нам повысить качество?• Централизованная приемка кода + функциональные автотесты• Усиление роли функциональных тимлидов• Технологический долг• Технологический налог
  11. 11. Новая система мотивации• Architecture Board оценивает каждую команду• Заказчик определяет общий бонусный фонд для своей команды• Каждый получает бонус пропорционально з.п.
  12. 12. Остающиеся проблемы• Иногда возникает дисбаланс ресурсов• Качество надо повышать дальше
  13. 13. Вопросы?• nikulin@hh.ru• http://twitter.com/nikulin

×