Чем дольше работаю с большими IT-командами, тем меньше верю в историю про “нанять еще сильных людей — и все заработает”. Про это еще Брукс писал давно в Мифическом человеко-месяце
В какой-то момент проблемы начинаются уже не из-за конкретных разработчиков. А из-за того, что: - у всех разные правила работы - процессы живут отдельно в каждой команде - бизнес не понимает, когда будет результат - команды перегружены - все постоянно что-то тушат
И чем больше компания, тем сильнее это начинает влиять на деньги, сроки и настроение людей внутри.
Наверное, поэтому мне интереснее не отдельные технологии, а то, как вообще устроена система разработки внутри компании. Как сделать так, чтобы: команды работали предсказуемо + изменения не ломали друг друга + у руководства была прозрачность + не было постоянного пожара.
· 01.06
Процессы свои в каждой команде - не вижу критичности, если не совсем адов зоопарк. Команды адаптируют под себя. Важно увязать команды между собой. То есть из ключевого только приоритеты в бэклогах и релизы спринтов.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён