Вообще тут нет одного стандарта или супер-приемов, которые де-факто являются эффективными. На процесс разработки могут влиять множество факторов, как то особенности организационной структуры компании, особенности модели продаж, харизма или опыт руководителей, опыт и слаженность команды разработчиков, методика разработки, языки программирования и особенности продуктов, которые разрабатываются. Перечислять можно долго.
Лично я бы выделил два основные правила во всем этом:
1. Не принимайте ничто в своих моделях за аксиому. Это значит, что если что-то эффективно работает сегодня, то не значит, что через год это будет работать столь же эффективно. Постоянно улучшайте позитивные решения и избегайте негативных. Например, если сейчас вы коммитите со скоростью пять раз в день, то это не значит, что через год такой темп будет востребован.
2. Экономическая эффективность разработки — вот о чем стоит думать каждый день. Все принятые решения должны быть именно экономически эффективными. Например, вы можете отказаться от отной технологии или программы в пользу другой, только бы росла скорость разработки, падало количество ошибок в коде, качество кода росло, количество времени на исправление ошибок было минимальным, и так далее. Фактически, нет разницы, в какой именно программе вы работаете, особо не важно, на каком языке, как часто вы делаете коммиты и что пишете в комментарии, важно, чтобы вы не загрузли со всем этим, отвлекаясь на красивые пассажи и реверансы, хотя нужно просто написать код. Решать проблемы нужно по мере их возникновения. Например, мы провели множество смен ПО багтрекинга и постановки задач, сейчас ими пользуемся настолько редко, что можно сказать, что оно вообще у нас отмерло. И это не мешает нам контроллировать процесс и вести успешную разработку. Инструменты должны быть эффективными, а это возникает только тогда, когда есть опыт их использования. Инструмент сам по себе не поможет, иногда даже навредит.