Как перевести команды разработчиков на единый шаблон проекта
Когда все команды True Engineering перешли на единый трекер на базе Azure DevOps (TFS), это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как проектный офис разработал логику, по которой сейчас работают наши разработчики.
Вопрос:
А зачем?
Ну, как бы, вы уверены, что вы действительно выигрываете от единого шаблона и, как вы сами выразились, конвеера разработки?
По каким метрикам выросли? Как измеряли удобство для команды? А что будете делать, если одна из команд захочет отдельный статус для код ревью, одна для merged but not released, а третья отдельную логику для reopen?
И, как вы понимаете, вопрос не только в статусах, но и в самих процессах.
эта история как раз про процессы - создать единую систему координат для всех продуктовых команд. чтобы у них не было желания и необходимости изобретать собственные велосипеды.
прежде чем переводить всех на единый шаблон, мы пообщались с разработчиками и составили общую картину, которую и воплотили в этом подходе. то есть этот шаблон родился из жизни и десятков, если не сотен проектов у нас за спиной. на данный момент мы исходим из того, что критической необходимости что-то менять ни у кого не возникнет
что касается метрик, то в данном случае мы ставили во главу угла Time-to-Market. единый шаблон - это единые процессы, а единые процессы - это предсказуемый результат. плюс, все разработчики мыслят в одном ключе, который в себе объединяет лучшие наши практики. опять-таки, всё родилось из опыта
цифрами пока поделиться не можем, возможно, вернёмся к этой теме, когда накопим данные