В інтерв'ю відмийте справжню спритність від спритного слова [закрито]

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

Моє запитання, які питання я можу задати в інтерв'ю, що розділило б ці магазини?

EDIT: Поки я шукаю стажування, я вважаю, що ці питання актуальні для всіх. Стажування - це контекст.

Я завжди починаю з цього питання:

Яка тривалість ваших ітерацій?

Оцініть їх відповідь:

1 тиждень - дивовижний, 2 тижні - чудовий, 3 - це нормально, 4 - посереднє. Більше, ніж це говорить про те, що вони борються, і більше 8 тижнів просто дивно. Якщо відповідь - це залежить , ви знаєте, що вони не мають жодного поняття.

Слідкуйте за:

Як часто ви звільняєтесь?

Це для перевірки першого питання. Правильна відповідь - щодня або в кінці кожного спринту . Агіліст знає, що між внутрішнім та зовнішнім випуском не повинно бути технічної різниці.

Попросіть їх захищати спритні методики. А потім попросіть їх спростувати, окресливши її слабкі сторони. Бонусні бали, якщо вони можуть орієнтуватися по цьому курсу, не засмічуючи його безглуздими модними словами.

Запитайте їх, чому вони цим користуються .

Ви відразу дізнаєтесь.

Я б попросив їх описати життєвий цикл розробки програмного забезпечення при використанні методології Agile. Якщо вони знайомі з цим, вони повинні бути в змозі точно описати кожну фазу в SDLC.

РЕДАКТ : Я щойно зрозумів, що ви запитуєте з точки зору респондента, а не інтерв'юера. У такому випадку я б, напевно, запитав їх про їх SDLC і бачив, чи відповідають ті дії, які вони кажуть, що відповідають дійсності Agile.

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

1. Запитайте про тестування одиниць. Надзвичайно велика відповідь, яку я отримую тут, була: "е, ми вирізали це, тому що нам не вистачало часу" (зауважте: перші 2 попереджувальні прапори - немає часу та немає тестування одиниці)
2. Запитайте, коли тестували програмне забезпечення та як часто. Тут можна отримати творчі відповіді. Особливо, якщо команда використовує "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 - це не лише ітерації, а й можливість команді легко адаптуватися до змін. Якщо ви повторно пишете неперевірений, заплутаний код, написаний під зовнішнім тиском, добре, що ви просто пишете лайний код в ітераціях. Зауважте, що ви можете отримати багато очок лише за кулі безперервної інтеграції. Але одного цього недостатньо, щоб принести вам більше 5 років, якщо ви не дотримуєтесь інших практик.

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

Тож ви просите поговорити з фактичними розробниками та запитати такі речі:

• Тож поговоріть зі мною через ваш поточний проект. Якою була початкова кінцева мета? Що містив перший спринт і що програмне забезпечення могло б зробити в кінці?
• Чи можете ви надати мені приклади функціональності чи дизайну для вашого останнього проекту, який, на вашу думку, склався інакше, ніж ви робили це як проект водоспаду?
• Наведіть мені приклад того, як великий фрагмент функціональності був розбитий на кілька спринтів? До якої неефективності / перероблення це призвело? І які поліпшення чи зміни від того, що спочатку передбачалося.
• Коли ви почали працювати з гнучким, що ви робили під час раннього спринту, чи змінили ви під час пізніших спринтів (або проектів), коли вам вдалося впоратися з методологією?

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

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

Вони повинні були бути приголомшливо брехуном, щоб мати змогу скласти речі, що коштують 10 - 15 хвилин, які могли б обійти вас, якщо ви знаєте свої речі.

Якщо ви не хочете робити їх оборонними, я виявив, що наступне питання розпочне розмову, яка розповість вам усе, що вам потрібно знати про те, чи реально вони використовують Agile підхід, чи просто платять за нього:

Хто відповідає за написання вимог / специфікацій для ваших програмних проектів?

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

Що мені виділяється, це те, що ви шукаєте стажування, що змушує мене замислитися над тим, яка ваша мета у питанні цих питань. Ви намагаєтесь задати питання про спритне, щоб інтерв'ю пройшло добре, чи ви насправді відмовились від пропозиції компанії, використовуючи спритну мову? Якщо ви дійсно шукаєте спритне середовище, виберіть питання (чому ви користуєтеся гнучким, у який час ваші очікування, скільки тривають ітерації тощо), і запитайте це по телефону або в електронній пошті, не витрачаючи часу на інтерв'ю. Якщо ви шукаєте дохід, зачекайте на співбесіду і задайте питання, які показують ваші знання / хвилювання щодо спритних методологій (Розкажіть про життєвий цикл розробки програмного забезпечення), не бентежуючи інтерв'юера, якщо він використовує якусь напівгітку гидоту.

Я прошу їх описати типовий запит, від початку і до остаточної доставки клієнту.

Я також запитую, чи зазвичай вони справляються з довгостроковою підтримкою продукту, який вони надають клієнтові (тому що команди, які, як правило, будують кращий продукт, знаючи, що це буде той, хто фіксує його о 1 годині ночі у неділю у вихідні дні праці).

Я також запитую, як керівництво бачить свою роль під час процесу. Це досить легко зрозуміти, чи мають вони відношення до вогню та забуття (ми запускаємо, ти летиш, ми просимо, якщо ти потрапив у ціль) чи відношення «ми допоможемо тобі накатати човен по річці».

Вони, як правило, показують, як вони дійсно роблять справи, а не як вони повинні робити їх, або як вони вимагають їх робити.

Найкращий спосіб я виявив, чи знає хтось, що вони роблять з точки зору SDLC, - це запитати їх, де вони закрутилися в минулому, і як би вони це зробили по-іншому. Люди, які вже кілька разів пройшли процес, і повністю визнають, де вони накрутили, і, як правило, про них досить детально. Вони відкрито обговорюють це, демонструють рівень впевненості, оскільки вони визнають, що вони не є ідеальними. Уникнення питання, кажучи: "Вони майже все роблять добре", - це справжній попереджувальний знак.

Як часто вони випускають на виробництво. Чим довший час, тим вони менш спритні. Як часто вони проводять майстер-класи з роздумів. Якщо вони знають, про що ви говорите, тоді добре. Як часто у них проводяться зустрічі команди «догоняння». Щодня чудово, щомісяця - погано. Чи є у них сервер безперервної інтеграції. Це не обов'язково, але дасть вам уявлення про їх використання інструментів. Як часто кінцеві користувачі сидять із розробниками. Ніколи не означає, що вони не спритні.

• Поставте їм ситуацію і попросіть її вирішити спритно;
• Розпитайте їх про їх улюблені спритні практики (планування покеру, програмування пар, bdd / tdd, kanban);
• Запитайте їх, чому вони не обрали чи не перейшли з інших методологій (водоспад, руп тощо)
• Назвіть найвідоміших людей у ​​гнучкому методологічному світі, які придумали цей термін і які найпопулярніші книги написані про нього.

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

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

Запитайте їх, як вони справляються з дизайном. Якщо вони скажуть вам, що дизайн не спритний, вони не отримують його.

Запитайте їх, як вони управляють мінливими вимогами. Якщо це здається, що зміна вимог має свій процес, вони, ймовірно, не отримують цього.

Якщо вони претендують на використання Scrum, подивіться, як вони це пишуть. Магазини, які роблять Scrum, як правило, знають досить добре, як його написати. Підказка: це не СКРУМ.

Це може здатися педантизмом, але я твердо переконаний, що для успішного застосування шаблону процесу на зразок Scrum, RUP, XP чи будь-чого іншого, вам потрібно зрозуміти філософію та "чому", щоб ви знали, як адаптуватися "що" вашій організації. У Scrum більшість людей, які виконують домашні завдання, натрапляють на цю інформацію. Люди, які шукають рецепти кулінарної книги для управління проектами, зазвичай пропускають цю деталь.

Що для мене має сенс - попросити їх описати, як вони поводяться з частиною процесу Agile. Саме зараз мій улюблений - це початок ітерації, але ви можете розробити власного улюбленого.

Запитайте: "Давши купу квитків на початку спринту, опишіть свій робочий процес звідси"

Ключові моменти слухати тут:

• Чи розцінюють біси білети?
• Ви стежите за швидкістю?
• Що відбувається, коли ваші оцінки досягають більшої швидкості?
• Що відбувається, коли ваші оцінки досягають більшої швидкості, коли у вас є термін? (Слідкуйте за сюди: чи зменшують вони складність, або переосмислюють, чи просто мертвують команди розвитку?

Жоден із них сам по собі не є вимикачами, але якщо їх відповіді на ці питання досить змусять задуматися, то, можливо, вони зацікавлені в спритних ритуалах , а не в дійсному спритному розвитку .