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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дайте им ситуацию и попросите их быстро ее решить;
• Спросите их об их любимых проворных практиках (планирование покера, парное программирование, bdd / tdd, kanban);
• Спросите их, почему они не выбрали или перешли из других методологий (водопад, руп и т. Д.)
• Какие самые известные люди в мире гибкой методологии, кто придумал этот термин и какие самые популярные книги написаны о нем.

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

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

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

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

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

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

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

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

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

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

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