DUMP-2013 Управление разработкой - Переход от проектной разработки к продуктовой - Беклемишев Константин

780 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
780
On SlideShare
0
From Embeds
0
Number of Embeds
213
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DUMP-2013 Управление разработкой - Переход от проектной разработки к продуктовой - Беклемишев Константин

  1. 1. Переход от проектнойразработки к продуктовойКонстантин А. Беклемишевkbeklemishev@naumen.ru
  2. 2. ● Это 14 лет разработки на C++, Python и Java● Гибкая масштабируемая архитектура● Более 20-и серверных компонент● Три интерфейса пользователя● Две команды разработки● Группа тестированияЧто такое Naumen Phone?
  3. 3. Глобальные целиВыход на зарубежные рынки в регионе APACСледствие: Смещение фокуса с проектнойдеятельности на продуктовую (релизныйцикл)
  4. 4. ● Клиент в ед.времени один● Решение внедряется своими силами● Новый функционал делается во времяработы на проектом● Период опытной эксплуатации(тестирование)● Всегда уникальное решениеПроект:
  5. 5. ● Клиентов в ед. времени много● Решение внедряется силами партнеров● Функционал не расширяется при внедрении● Решение массовоеПродукт:
  6. 6. Чего хотят партнеры● Стабильная версия и поддержка● О новом функционале должно бытьизвестно заранее (за год, а луче за два)
  7. 7. Как это отражается наРазработке?Релизный циклГарантия сроков
  8. 8. Смена VCSSVN => GITУдобное ветвление и слияниеВерсионирование через git-tags
  9. 9. Организация мульти-репозиторияДробим супер-репозиторий на множество мелких
  10. 10. Android Repo● Выстраивание структуры репозитория● Синхронизация репозиториев● Массовые операции над репозиториями● Управление/работа с общими Релизами● Отправка кода на CodeReview
  11. 11. Глазами разработчика$ repo init -b 6.0$ repo sync$ repo start super_feature$ git add$ git commit$ git push repo upload
  12. 12. CodeReview (Gerrit)+1 от коллеги, +1 от второго и АвтоБотзаpushит изменение в репозиторий
  13. 13. Заключительные этапыСборка RPM-пакетов: на каждый коммит или по требованиюДеплой на стенды автотестирования:Phoenix и SandboxПо результатам автотестов RPM-пакеты попадают вRPM-репозиторий, либо отбраковываютсяТеперь с ними можно работать Тестировщикам!Задача может быть закрыта только ими.
  14. 14. Производство версии вминиатюреRoadmap (40%) Техн.долг ПроектыПул задач 6.0Набор задач в Итерации6.0.1Распределение итерации задач междутестировщиками
  15. 15. Ключевой параметрдля гарантии сроковПредварительная оценкаразработчика!
  16. 16. ПремированиеЧего хотят люди от премий:● Получать чаще, чем раз в год● Знать за что, и чтобы "что" былообъективным● Понимать, чего ждать, уметь это рассчитать
  17. 17. ПремированиеЭто механизм поощрения и стимуляции.Чего хочет компания:● Прогнозируемых сроков разработки● Эффективной командной работы
  18. 18. Единственный объективный показатель:обещанная задача в срок!Коэффициент эффективностиK=ΣTvi/80Варианты расчета коэффициентов:ПерсональныйКомандныйНаставическийПремирование
  19. 19. ПремированиеНаши разработчикисделали плагин кRedmine дляавтоматическогорассчета премий
  20. 20. Премирование
  21. 21. Вопросы?

×