Карго-культ в разработке ПО
В последнее время вижу много примеров, как технические руководители проектов(aka CTO) следуют канонам Карго-культа при разработке и управлению проектами, вместо того, чтобы вводить сущности по мере их надобности, а сам процесс выстраивать исходя из текущих потребностей, доступных ресурсов и квалификации исполнителей. Мы поговорим о том, как их выяв…
То что одни называют карго культом, другие называют лучшими практиками. И часто суть таких практик не в том, что с ними так хорошо, как в том что без них куда хуже. Ежедневные митинги часто и правда кажутся бесполезными и раздражают. Особенно, когда люди (как и автор этой заметки) не понимают их реальных целей (и, соответственно, проводит их наверняка не правильно). Но даже в таком виде от них куда больше пользы, чем кажется.
Это становится очевидным, когда видишь проекты, в которых подобных митингов не было. Мне лично кажется куда более дикой ситуация, когда люди сидя за соседними столами за несколько месяцев не удосужились пообщаться - пока не упёрлись в проблему, суть которой сводилась к тому, что ВСЮ работу одного из них почти за полгода нужно было переделывать... И ведь это были умные и талантливые ребята. И у них было множество объективных обстоятельств и рациональных причин делать именно так...
Аналогично и с облачной инфраструктурой. Да это перебор. Но только до тех пор, пока ты не остался с набором модулей на покрытом пылью старом ПК разработчика, которые там работают - но перенести их куда либо ещё требуются месяцы труда DevOps инженеров. Что особенно весело, когда тебе нужно быстро масштабировать проект. И да, как раз тут добрым (или не очень) словом и поминаются unit тесты (или их отсутствие)...
Но в чём я полностью согласен с автором - так это в том, что в любом проекте (и не только) нужна осознанность - чёткое и ясно представление о том, что именно ты делаешь и зачем, какой результат ты намерен получить и как им далее воспользоваться, каковы отдалённые последствия и эффекты. Собственно все методики - будь то дедушкин Waterfall или папин SCRUM - и родились как результат подобной осознанности применительно к своим проектам.
И именно благодаря осознанности их создателей, которая и позволяла им выбирать оптимальные (для тех ситуаций) решения и снискали заслуженную популярность. При их слепом применении они, естественно, не так эффективны и часто избыточны. Есть соблазн многое упростить. Вот только при недостатке осознанности и опыта это упрощение часто заканчивается плачевно...
"Мне лично кажется куда более дикой ситуация, когда люди сидя за соседними столами за несколько месяцев не удосужились пообщаться - пока не упёрлись в проблему, суть которой сводилась к тому, что ВСЮ работу одного из них почти за полгода нужно было переделывать."
Это вполне обычная ситуация для любого Enterprise, причем причин, по которым не было взаимного обсуждения - может быть масса, в том числе и личные какие-то обиды и желания подсидеть кого-то.