1. Переход от проектной
разработки к продуктовой
Константин А. Беклемишев
kbeklemishev@naumen.ru

2. ● Это 14 лет разработки на C++, Python и Java
● Гибкая масштабируемая архитектура
● Более 20-и серверных компонент
● Три интерфейса пользователя
● Две команды разработки
● Группа тестирования
Что такое Naumen Phone?

3. Глобальные цели
Выход на зарубежные рынки в регионе APAC
Следствие: Смещение фокуса с проектной
деятельности на продуктовую (релизный
цикл)

4. ● Клиент в ед.времени один
● Решение внедряется своими силами
● Новый функционал делается во время
работы на проектом
● Период опытной эксплуатации
(тестирование)
● Всегда уникальное решение
Проект:

5. ● Клиентов в ед. времени много
● Решение внедряется силами партнеров
● Функционал не расширяется при внедрении
● Решение массовое
Продукт:

6. Чего хотят партнеры
● Стабильная версия и поддержка
● О новом функционале должно быть
известно заранее (за год, а луче за два)

7. Как это отражается на
Разработке?
Релизный цикл
Гарантия сроков

8. Смена VCS
SVN => GIT
Удобное ветвление и слияние
Версионирование через git-tags

9. Организация мульти-репозитория
Дробим супер-репозиторий на множество мелких

10. Android Repo
● Выстраивание структуры репозитория
● Синхронизация репозиториев
● Массовые операции над репозиториями
● Управление/работа с общими Релизами
● Отправка кода на CodeReview

11. Глазами разработчика
$ repo init -b 6.0
$ repo sync
$ repo start super_feature
$ git add
$ git commit
$ git push repo upload

12. CodeReview (Gerrit)
+1 от коллеги, +1 от второго и АвтоБот
заpushит изменение в репозиторий

13. Заключительные этапы
Сборка RPM-пакетов: на каждый коммит или по требованию
Деплой на стенды автотестирования:
Phoenix и Sandbox
По результатам автотестов RPM-пакеты попадают в
RPM-репозиторий, либо отбраковываются
Теперь с ними можно работать Тестировщикам!
Задача может быть закрыта только ими.

14. Производство версии в
миниатюре
Roadmap (40%) Техн.долг Проекты
Пул задач 6.0
Набор задач в Итерации
6.0.1
Распределение итерации задач между
тестировщиками

15. Ключевой параметр
для гарантии сроков
Предварительная оценка
разработчика!

16. Премирование
Чего хотят люди от премий:
● Получать чаще, чем раз в год
● Знать за что, и чтобы "что" было
объективным
● Понимать, чего ждать, уметь это рассчитать

17. Премирование
Это механизм поощрения и стимуляции.
Чего хочет компания:
● Прогнозируемых сроков разработки
● Эффективной командной работы

18. Единственный объективный показатель:
обещанная задача в срок!
Коэффициент эффективности
K=ΣTvi/80
Варианты расчета коэффициентов:
Персональный
Командный
Наставический
Премирование

19. Премирование
Наши разработчики
сделали плагин к
Redmine для
автоматического
рассчета премий

20. Премирование

21. Вопросы?