Как программист, вас волнует, какой метод использует процесс разработки?

Я нахожусь на рынке труда, и у меня есть ряд приоритетов для моей следующей работы, включая зарплату, направление деятельности и т. Д. Однако в моем списке требований нет ни одной вещи - это методология процесса разработки. Я чувствую, что моя работа заключается в создании программного обеспечения, и я рассматриваю структуру процесса как нечто, что я могу приспособить, будь то разборки, водопад или что-то еще.

Является ли методология процесса разработки приоритетом для вас?

Для меня это важно только потому, что не мешает здравому смыслу, который, как мы надеемся, есть у большинства профессионалов.

Когда мы говорим о контроле версий, есть аргумент, что any version control beats not having anything at allэто не так с методами разработки. Методы означают правила, а правила иногда нарушаются. Я работал в компаниях, которые занимались действительно глупыми делами до тех пор, пока кто-нибудь помнит, что любая проблема, с которой столкнулась эта глупая процедура, ушла давным-давно.

Я хочу следующее от компании:

• Четко документированные процедуры, которые помещаются на нескольких страницах. Если мне придется читать диссертацию или (что еще хуже) роман, чтобы набрать скорость, я потеряюсь надолго.

• Свидетельство того, что компания открыта для изменения процедур в лучшую сторону. Мне нужно быть в состоянии пойти к кому-то и сказать: «Я понимаю, почему ты делаешь [xyz], но есть инструмент, который делает большую часть этого для тебя сейчас. Можем ли мы его использовать?»

• Небольшая конкуренция может быть хорошей и часто неизбежной. Но я избегу любого магазина, где конкуренция используется в качестве основного средства мотивации людей. Если вы записали что-то, что отправляет число строк, совершенных разработчиком в день, на лазерный принтер в 17:00, я не хочу работать на вас.

• Если вы не помешали сборкам в благословенных репозиториях получать изменения, нарушающие указанную сборку, я бегу, как черт. Последнее, что я хочу сделать в 5:00, - это внести изменения из основного репозитория, чтобы проверить мою локальную сборку, только для того, чтобы исправить чью-то еще точку с запятой.

• Я предпочитаю прыгать в методы, которые похожи на установленный метод, который упал с гибкого дерева. Это не обязательно, но чувство фамильярности помогает преодолеть первоначальный горсток попытки быть продуктивным, не совершая процедурную ошибку.

Если я увижу, что буду тратить больше времени на обиды на процедуры, чем на благодарность за их существование, я, вероятно, перейду на работу.

Другой громкий "о, нет, никогда!" это «Мы надеемся , вы будете также установить лучшие практики для нас. У нас есть шесть миллионов строк кода и 21 надомные, мы должны использовать в SVN или что - то?» ,

Кто-то может повеселиться, разбираясь с этим. Я не тот парень :)

Как разработчик, я забочусь о том, что процесс разработки нормален. Ряд различных методологий разработки может обеспечить нормальный процесс разработки. Наоборот, сломанная компания может обеспечить безумный процесс, независимо от того, как они это называют.

Поэтому мне безразлично, какова их официальная «методология развития». Однако я все равно буду спрашивать об этом просто потому, что это дает мне возможность задавать дополнительные вопросы, чтобы выяснить, что они на самом деле делают.

Да, я видел некоторые плохие методологии, которые, я думаю, я бы не хотел повторять снова. В качестве пары примеров рассмотрим следующие: Будете ли вы в стиле ковбоя для команды из дюжины разработчиков, где каждый может использовать свой собственный контроль версий, соглашения о кодировании и т. Д.? Я знаю, что не буду. Как насчет того, чтобы изменить строку кода, нужно заполнить дюжину форм и около 20 подписей, чтобы одобрить изменение в производстве, которое может занять несколько недель, поскольку высшее руководство может получить некоторое время для получения? «Все» оставляет вещи слишком открытыми для моего разума, но тогда, может быть, я немного циничен здесь.

Как разработчик, я не возражаю против того, какая методология используется, если это правильная методология, правильно используемая.

Так, например, я бы не хотел работать в компании, которая занимается «ковбойским кодированием» , особенно если они достаточно невежественны, чтобы думать, что они на самом деле делают Agile .

Я предпочитаю места, где есть метод развития, которому каждый может следовать.

Я работал на работах, которые были очень разочаровывающими из-за выбора процессов, используемых для развития и бизнеса в целом. В эти дни у меня есть некоторые минимальные требования к процессу. Любой бизнес, который не занимается этим, я считаю плохо управляемым и не будет работать. У меня нет терпения к идиотизму, которое у меня было раньше, поэтому я спасаю себя и их многих от обострения, пропуская эти работы.

Пока у нас есть некоторое подобие разумных требований, какой-то деловой представитель, который заинтересован и отзывчив, и понимает, что команда разработчиков имеет большое влияние во временных рамках, тогда я счастлив и могу вписаться во что угодно.