Команды работают в Гибком, обычно стойком к найму людей, которые не работали в Гибком? [закрытый]

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

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

Понимание основных принципов Agile важно для понимания Agile. TDD - лишь небольшая часть Agile, а точнее XP (Extreme Programming).

Сначала я хотел бы взглянуть на Agile Manifesto:

Индивидуумы и взаимодействия важнее процессов и инструментов

Рабочее программное обеспечение вместо исчерпывающей документации

Сотрудничество с клиентами вместо переговоров по контракту

Реагирование на изменение вместо следования плану

То есть, пока есть ценность в элементах на справа мы больше ценим предметы слева.

Затем я бы взглянул на процесс SCRUM (который также является небольшой частью Agile), чтобы увидеть, что в нем задействовано.

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

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

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

Я понимаю ваше разочарование, но правда в том, что если вы никогда не работали в Agile-среде, вы, скорее всего, будете вести себя противодействующим гибкости (так сказать), и, скорее всего, вы даже не станете поймите, что вы делаете не так.

Поскольку Agile - это во многом философия работы, это не то, чему вы можете научиться, просто прочитав книгу, вам нужно иметь глубокое понимание того, как работают не-Agile фирмы, какие проблемы это вызывает, как Agile меняет это и как вы бороться с энтропией (попытками внешнего мира вернуть не-гибкость).

Я советую вам сначала прочитать больше об Agile и начать анализировать свое собственное поведение и поведение той фирмы, в которой вы в настоящее время работаете. перспектива Agility / non-Agility. Как только вы научитесь различать закономерности, вы можете начать попытки изменить свою фирму изнутри. Если вам это не удастся, обратитесь в Agile-компанию, и я обещаю, что вас наймут.

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

Когда компания использует общий термин «Agile» при наборе персонала без уточнения (например, , запрашивая опыт XP или Scrum), они часто заменяют что-то еще, что они ищут. Им могут понадобиться «разработчики, которые будут объединять программы», или «разработчики, которые не будут упираться в отсутствие требований и проектных документов до того, как они начнут работать», или «разработчики, которые не уходят в темный угол неделями подряд. ". Уловка состоит в том, чтобы понять, что они означают.

С узкой точки зрения найма Кремниевой долины,

Я бы, наверное, задал такой вопрос: какие методологии разработки вы использовали до этого момента в своей карьере? В чем-то из них воплощен дух идеалов Agile?

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

Может быть, они берут образ бармена в кантине Мос-Эйсли (перефразировано):

Мы не хотим, чтобы здесь были люди вашего вида.

The brand of agile that we use is composed of Project Management Practices as defined by SCRUM and Engineering Practices as defined by XP. If we are starting a new team, we will look for key roles to serve as embedded coaches for the team (an Iteration Manager/ Scrum Master Coach, Analyst Coach, Technical Coach and Testing Coach). For an existing team, given that we use pairing, we are more interested in developers that work well with others than a super programmer.

Because we using pairing, a new developer will become productive within a month with the agile engineering practices as well as the business and application domains. It provides the team with little value if a strong programmer joins the team but is unable to pair effectively.

When we interview, we ask the candidates to pair with several team members. Through pairing, we learn if the developer works well with others in a pair. In addition, we gain insight into the developer's technical skills. Because the candidate works in several pairs, we get the perspective of a number of team members.

All of our agile teams have been very effective and their projects successful. We have trained more team members to become effective with agile than we have hired experienced agile personnel.

Я несколько раз нанимал разработчиков в agile-команды. Я вовсе не против найма разработчика без опыта Agile - они будут немного дешевле; -)

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

Например, ценить свой код и дизайн - верный признак того, что они будут «кобылой» в схватках и проверках кода.

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

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

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

не методология процесса. Поскольку каждая компания в любом случае адаптирует свою гибкую модель (если они этого не делают, они делают это неправильно), действительно не имеет значения, с какого варианта они начали. Вы должны знать некоторую терминологию, но это займет не больше дня перед собеседованием.

не методология процесса. Поскольку каждая компания в любом случае адаптирует свою гибкую модель (если они этого не делают, они делают это неправильно), действительно не имеет значения, с какого варианта они начали. Вы должны знать некоторую терминологию, но это займет не больше дня перед собеседованием.

Работодатели, скорее всего, будут нанимать людей, которые разбираются в гибкой методологии, потому что гибкие методологии требуют, чтобы почти каждый член команды знал о процессах, требуемых каждой гибкой методологией (SCRUM, Crystal, XP). Например, SCRUM требует, чтобы все члены команды, включая руководство, понимали концепцию самоорганизации и следовали ей. Им нужно будет понять, что их текущая производительность не будет диктоваться им: вместо этого им нужно открыто решать свои проблемы (или то, что обычно происходит на ежедневном SCRUM). Если вы поместите в команду кого-то, кто не знает Agile, он может сразу предположить, что, поскольку у этой методологии мало документации, они могут работать и кодировать и исправлять для создания проекта. Однако гибкие методологии требуют много процессов, а не документации.

Абсолютно Да

Есть много командной работы и доверие к своим сверстникам в Agile и специально в экстремальном программировании. Вам нужно знать, другие люди пишут приличные тесты и не нарушают ваш код. Хорошие разработчики XP не хотят людей в команде, которые собираются сделать свою работу намного сложнее.

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

В эти дни все говорят, что они Agile, и если вы предложите достаточно денег, практически все с малейшим технологическим навыком поступит на работу ... Итак ожидают, что люди поставили вас через интервью по программированию в паре Отказ

Обычно нам нужно знать:

• Можете ли вы действительно пара программы?
• Вы действительно знаете, как сделать TDD?
• Вы просто говорите эти вещи или вы можете продемонстрировать, что вы делаете их?
• Собираетесь ли вы взять на себя инициативу или вы ждете старой школы «менеджер проекта» «-тип, чтобы сказать вам, что делать?

Вещи, которые помогут вам нанять в Agile Shop:

• у вас есть Пытался ввести разработку тестирования где-то, даже если вы не получили бай-в. (Работал для меня ...)
• У вас есть образец код, который вы написали - или проект с открытым исходным кодом, на котором вы можете продемонстрировать разработку, ориентированное на тестирование , автоматизированные сборки ...
• Вы найдете Это Вы работали в командах с циклами короткого выпуска ...