Отказ от настоящего гибкого модного словечки в интервью [закрыто]

14

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

Мой вопрос: какие вопросы я могу задать в интервью, которое бы выделило эти магазины?

РЕДАКТИРОВАТЬ: Хотя я ищу стажировку, я чувствую, что эти вопросы актуальны для всех. Часть стажировки - это контекст.

indyK1ng
источник
14
Хм, спросите их, свинья это или курица?
Роберт Харви
1
@ Роберт Лолвут?
Мэтью Прочитал
3
@Matthew: en.wikipedia.org/wiki/The_Chicken_and_the_Pig
Роберт Харви
@ indyK1ng 1. Знаете ли вы компанию, которая действительно гибкая? 2. Большую часть времени методология должна быть адаптирована к реальности, и наоборот. PS Согласен в отношении модного слова!
Амир Резаи
2
@ Роберт Они должны ответить: «Бла-бла-Agile. Бла-бла-водопад. Бла-бла-парадигма».
Марк С

Ответы:

8

Я всегда начинаю с того, что задаю этот вопрос:

Какова продолжительность ваших итераций?

Оцените их ответ:

1 неделя замечательная, 2 недели отличные, 3 в порядке и 4 посредственные. Дольше, чем это означает, что они борются, и более 8 недель просто странно. Если ответ таков , вы знаете, что они не имеют ни малейшего понятия.

Продолжайте с:

Как часто вы отпускаете?

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

Мартин Уикман
источник
5
Стандарт по умолчанию - 2 - 4 недели. 1 неделя спринтов ...? Хм ... я бы с подозрением.
Аарон Макивер
5
Там нет "стандарт"; это варьируется между компаниями / командами / ситуациями. Я считаю, что накладные расходы Scrum, как часть длины спринта, слишком расточительны для однонедельных спринтов, поэтому мы используем два.
Кристофер
1
Я проверил много разной продолжительности, и мне нравится 1 для очень маленьких проектов в небольших командах, но для крупных корпоративных проектов 3 или 4 дали мне лучшие результаты.
3
Я думаю, что эти термины «настоящие» против «разбавленных» гибких, которые раздражают мои перья. Я всегда применял концепции и принципы Agile Manifesto, но никогда не использовал одну из фирменных версий Agile. Настаивание только на одной из многих гибких методологий нарушает первый принцип манифеста. Но я понимаю, что вы говорите.
Берин Лорич
2
Для меня «настоящий» agile - это agile, который применяет манифест и его 12 принципов - независимо от того, как он называется. Есть много модных слов, которые добавляют к основному значению Agile, а затем утверждают, что вы не Agile, если вы не делаете это.
Берин Лорич
6

Попросите их защищать гибкие методологии. И затем попросите их опровергнуть это, обрисовав его слабые стороны. Бонусные баллы, если они могут пройти этот курс, не засоряя его бессмысленными модными словами.

Марк Канлас
источник
4
+1 Всегда хорошо найти способ взять интервью у компании.
Джереми Хейлер
@ Джереми, к сожалению, они не очень хорошо это воспримут. Я бы не рекомендовал это!
Амир Резаи
@ Амир: Пожалуйста, объясните! Я никогда не оставлял интервью без их вопросов. Что не так с соискателем, желающим узнать больше о компании? Если они не воспринимают это хорошо, то это верный признак того, что я не хочу работать на них!
Джереми Хейлер
1
Я знаю, что некоторым компаниям на самом деле не нравится, когда их собеседник не задает вопросов ... для них это говорит об отсутствии интереса к работе.
Рейчел
2
Я думаю, что просить их «защищать гибкие методологии», вероятно, не самый лучший способ спросить;)
Мэтью Рид
6

Спросите их, почему они используют это .

Вы сразу узнаете.

user2567
источник
8
На это можно ответить довольно легко, хотя с помощью готовых ответов. «Чтобы сократить время выхода на рынок и оставаться конкурентоспособным». Это должен быть подход туда и обратно. Если ОП знаком с Agile / Scrum и хочет быть уверенным, что бизнес тоже; Я бы понял, что у ОП должно быть множество вопросов по этому вопросу ... в частности, что беспокоит их на прежнем месте работы и как новый бизнес может решить эту проблему.
Аарон Макивер
2
Ответ, который вы упоминаете, не может быть сказан кем-то, кто понимает ловкость. Это довольно хороший признак того, что они не знают, почему они должны использовать схватку. Каждая компания старается сократить время выхода на рынок и оставаться конкурентоспособной. Если вы ответите мне на вопрос, я отвечу «это единственная методология, адаптированная к разработке программного обеспечения» или «она дает много информации о том, что мы должны улучшить».
@Pierre 303 Любая причина, чтобы предположить, почему с точки зрения бизнеса, что гибкое внедрение было процессом, который мог бы увеличить наше время выхода на рынок и оставаться конкурентоспособным со своевременными выпусками нашего программного обеспечения, недопустимо и определило бы это лицо как не знающее, почему использовать Scrum? Вы должны понимать, что менеджеры по найму не всегда технически склонны, но это не означает, что использование Scrum в организации напрасно.
Аарон Макивер
1
@Pierre 303 Можете ли вы немного уточнить свой ответ? Причина использования любого метода разработки программного обеспечения состоит в том, чтобы «обеспечить максимально возможную эффективность для наших клиентов», что относится как к гибким, так и к RUP и другим.
Мартин Уикман
1
Полностью согласен. Спросите их, почему они даже выбрали Agile. Твердое вещество. +1
проворный скаут
5

Я бы попросил их описать жизненный цикл разработки программного обеспечения при использовании методологии Agile. Если они знакомы с ним, они должны быть в состоянии точно описать каждый этап в SDLC.

РЕДАКТИРОВАТЬ : Я только что понял, что вы спрашивали с точки зрения интервьюируемого, а не интервьюера. В этом случае я, вероятно, спросил бы их об их SDLC и посмотрел бы, соответствуют ли шаги, которые, по их словам, они предпринимают, тому, что на самом деле Agile.

Рейчел
источник
Хороший вопрос относительно вопроса о SDLC. Однако я был в организации, где они следовали всем этапам SDLC, но команда плохо применила методологию.
Амир Резаи
@ Амир: Если бы это было так, я бы предположил, что они, по крайней мере, пытались следовать гибкой методологии. Скорее всего, у них есть веская причина отклониться от этого, или они не знают, что делают, и будут готовы учиться, если вы потратите время, чтобы научить их.
Рейчел
У них есть веская причина. Они адаптируют методологию к своей реальности.
Амир Резаи
3

Подход, который я использую, на самом деле имеет мало общего с гибкими модными словами, но он имеет отношение к гибким практикам. Одна из общих черт во всех гибких командах - короткая итерация, большинство людей получают эту часть (это один из 12 принципов гибкой разработки на сайте http://agilemanifesto.org ). Цель короткой итерации состоит в том, чтобы заблаговременно получить отзыв о качестве разработанного программного обеспечения. Это где я начинаю.

  1. Спросите о модульном тестировании. В подавляющем большинстве случаев ответ, который я здесь получаю, звучит так: «Мы вырезали это, потому что у нас не было достаточно времени» (примечание: первые 2 флага предупреждения - нет времени и нет модульного тестирования)
  2. Спросите о том, когда программное обеспечение тестировалось и как часто. Ответы могут быть креативными здесь. Особенно, если команда использует «Agile» в качестве предлога, чтобы отбросить весь процесс в сторону. Если ответ ближе к концу проекта или к чему-то другому, кроме каждой итерации, они не знают, что такое Agile.

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

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

Берин Лорич
источник
2

Есть несколько вещей, которые отделяют тех, кто "делает" проворную от тех, кто проворен:

  • Спросите о непрерывной интеграции, если они не используют CI, вычитают точку. Добавьте точку, если они есть. Дополнительные очки:
    1. Добавьте 1, если они используют двухфазные коммиты (код должен успешно скомпилироваться, прежде чем разработчик сможет зарегистрироваться).
    2. Добавьте 1, если сценарий сборки включает запуск набора тестов
    3. Добавьте 1, если сборка не удалась, если покрытие кода падает ниже определенного порога
    4. Добавьте 2, если возможно развернуть приложение так, чтобы оно было готово к запуску в один клик
  • Спросите о том, что TDD (разработка через тестирование) вычитает 2 балла, если они не используют TDD, добавляют 1, если они это делают.
  • Спросите об итерациях, как долго они (вычтите 2 балла, если они не выполняют итеративную разработку, вычтите 1, если итерация длиннее месяца или меньше двух недель, добавьте 1, если 2 недели)
  • Спросите, как проводится оценка, добавьте 1, если они используют баллы истории, добавьте 2, если они планируют покер или что-то подобное, вычтите одно, если они используют оценки абсолютного времени, вычтите 2, если разработчики не участвуют в процессе оценки.
  • Спросите, как создаются функции, добавьте 1, если разработчик отвечает за элемент сверху вниз (вертикальный срез), вычтите 1, если разработчики отвечают за определенный слой (горизонтальный срез).

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

Майкл Браун
источник
1
«Спрашивать о TDD (разработка через тестирование) вычитать 2 балла, если они не используют TDD, добавить 1, если они делают», не имеет смысла. Просто добавьте 3, если они делают.
cbrandolino
Я понимаю, что вы говорите ... Я не упростил мою формулу ... но я думаю, что моя точка зрения ясна.
Майкл Браун
1
WTF имеет CI и TDD, чтобы сделать с Agile? Конечно, облегчает выпуск, но вам не нужно, чтобы он работал гибко. И поверьте мне, я знаю компании с TDD и CI, которые НЕ являются гибкими.
gbjbaanb
Только TDD и CI не делают среду гибкой. Тем не менее, отсутствие этих элементов является предупреждающим признаком того, что не существует настоящего обязательства быть гибким.
Майкл Браун
2

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

Итак, вы просите поговорить с реальными разработчиками и спросить что-то вроде

  • Так что поговорите со мной через ваш текущий проект. Какова была начальная конечная цель? Что содержал первый спринт и что могло сделать программное обеспечение в конце?
  • Можете ли вы привести примеры функциональности или дизайна вашего последнего проекта, который, по вашему мнению, работал не так, как если бы вы работали как проект с водопадом?
  • Приведите пример того, как большая часть функциональности была разбита на несколько спринтов? К какой неэффективности / переделке это привело? И какие улучшения или изменения от того, что изначально предполагалось.
  • Когда вы начали работать с Agile, какие вещи вы делали на ранних спринтах, которые вы изменяли на более поздних спринтах (или проектах), когда вы осваивали методологию?

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

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

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

Джон Хопкинс
источник
2

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

Кто отвечает за написание требований / спецификаций для ваших программных проектов?

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

JohnFx
источник
2

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

отметка
источник
Это вопрос, который я хотел бы задать во время части интервью «У вас есть ко мне вопросы». Я задаю вопрос, чтобы определить, говорят ли они правду, когда говорят, что они проворны. Я уже был в ковбойской среде и хотел бы предотвратить это. Я знаю, что есть организации, которые используют agile в качестве модного слова, поэтому я пытаюсь отфильтровать их. Кроме того, интервью идут в обе стороны, я беру интервью у компании, а они у меня.
indyK1ng
1

Я прошу их описать типичный запрос, от начала до окончательной доставки клиенту.

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

Я также спрашиваю, как руководство видит свою роль в процессе. Довольно легко увидеть, имеют ли они отношение «забыл и забыл» (мы запускаем, вы летите, мы спрашиваем, попали ли вы в цель) или «мы помогаем вам спустить лодку вверх по реке».

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

Кристофер Махан
источник
1

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

kemiller2002
источник
1

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

Генри
источник
+1 ИМО, первое, что умирает в проворной организации - ретроспектива. На самом деле это скорее концепция Scrum, но успешная гибкая система приходит с пониманием того, насколько хорошо ваш процесс обеспечивает поддержку, а не отключает вашу организацию. Без какого-либо механизма самоанализа я не понимаю, как это возможно.
МВД
0
  • Дайте им ситуацию и попросите их быстро ее решить;
  • Спросите их об их любимых проворных практиках (планирование покера, парное программирование, bdd / tdd, kanban);
  • Спросите их, почему они не выбрали или перешли из других методологий (водопад, руп и т. Д.)
  • Какие самые известные люди в мире гибкой методологии, кто придумал этот термин и какие самые популярные книги написаны о нем.
Eimantas
источник
1
Честно говоря, я бы провалил четвертый пункт. Я знаю, что такое agile, и я прочитал несколько онлайн-ресурсов о том, как разные люди выкладывают вещи. Однако мой путь к гибкому подходу всегда был индивидуален для команды / среды, в которой я работаю.
Берин Лорич
0

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

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

JB King
источник
0

Спросите их, как они справляются с дизайном. Если они скажут вам, что в Agile нет дизайна, они не получат его.

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

Если они утверждают, что используют Scrum, посмотрите, как они это пишут. Магазины, которые хорошо разбираются в Scrum, как правило, достаточно хорошо знают, как их написать. Подсказка: это не SCRUM.

Это может показаться педантичным, но я твердо убежден в том, что для успешного применения шаблона процесса, такого как Scrum, RUP, XP или чего-либо другого, вам необходимо понять философию и «почему», чтобы вы знали, как адаптироваться «что» в вашей организации. В Scrum большинство людей, которые делают домашнее задание, сталкиваются с этой небольшой информацией. Люди, которые ищут рецепты поваренной книги для управления проектами, обычно упускают эту деталь.

MIA
источник
0

Для меня имеет смысл попросить их описать, как они справляются с частью гибкого процесса. Прямо сейчас мой фаворит - начало итерации, но вы можете разработать свой собственный фаворит.

Спросите: «учитывая кучу билетов в начале спринта, опишите ваш рабочий процесс отсюда»

Ключевые моменты для прослушивания здесь:

  • Разработчики оценивают билеты?
  • Вы отслеживаете скорость?
  • Что происходит, когда ваши оценки превышают вашу скорость?
  • Что происходит, когда ваши оценки превышают вашу скорость, когда у вас есть крайний срок? (Следите за вращением здесь: они уменьшают сложность, или перераспределяют, или просто убивают команду разработчиков?)

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

RyanWilcox
источник