Питання #1 Поясніть суть Agile за 30 секунд?

Agile — це методологія гнучкої розробки першочергово сьогодні популярна в ІТ, яка дозволяє клієнтам швидше отримувати якісне програмне забезпечення.

Іншими словами Agile — це сукупність підходів і моделей поведінки, орієнтованих на використання ітеративної розробки, time boxes (часових рамок), динамічне формулювання вимог і забезпечення реалізації ПЗ в результаті взаємодії всередині високо самоорганізованої робочої групи із фахівців різних профілів.

Питання #2 Що таке маніфест Agile?

Agile Manifesto — це документ, який описує основні цінності і принципи гнучкої розробки.

Маніфест Agile базується і визначає 4 ключові цінності:

  • Люди та співпраця важливіші за процеси та інструменти
  • Працюючий продукт важливіший за вичерпну документацію
  • Позитивна співпраця із замовником важливіша за обговорення умов контракту
  • Готовність до змін важливіша за дотримання плану

Хоча права частина важлива не менше за ліву, слід цінувати більше те що зліва.

Питання #3 Які головні принципи Agile?

  1. Найвищим пріоритетом для нас є задоволення потреб замовника, шляхом завчасного та регулярного постачання програмного забезпечення. Замовники і виконавці зацікавлені в успіху однаково, з тієї точки зору, вони пливуть одному човні 🙂
  2. Схвальне ставлення до змін, навіть на заключних стадіях розробки. Agile-процеси надають можливість використовувати зміни задля забезпечення конкурентоспроможності замовника.
  3. Працюючий продукт слід випускати якомога частіше, з періодичністю від пари тижнів до пари місяців.
  4. Впродовж усього проекту розробники і представники бізнесу повинні працювати разом і прозоро щодня.
  5. Над проектом повинні працювати вмотивовані професіонали. Щоб робота була виконана, створіть їм умови, надайте підтримку і повністю на них покладіться.
  6. Особиста комунікація – найефективніший та найпрактичніший метод як донести інформацію до команди, так і поширити її всередині.
  7. Працюючий продукт – головний показник прогресу.
  8. Agile допомагає налагодити сталий темп процесу розробки.
  9. Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.
  10. Простота – це мистецтво не робити зайвої роботи.
  11. Найкращі вимоги, архітектурні та технічні рішення виникають у командах, що здатні самоорганізовуватись.
  12. Команда на регулярних зустрічах намагається знайти способи підвищення власної ефективності та відповідно корегує свою роботу.

Головною проблемою розробки програмного забезпечення було визнано — ніхто з учасників, на жодному з етапів не володіє повною інформацією, що слід робити.

Питання #4 Які головні відмінності між Agile і традиційним методологіями управлінням проектами (Waterfall)?

За Agile усе відбувається значно швидше: представлення прототипу, тестування, доставка самого програмного продукту на ринок з адаптацією до його мінливих потреб. У той час як традиційний підхід до проектів досить повільний і дорогий. Також у Waterfall проектах не заохочуються зміни, а зворотний зв’язок ігнорується до повного закінчення проекту.

Питання #5 Коли потрібно використовувати методологію Agile?

  • Коли клієнт не має чітких вимог
  • Коли клієнт очікує швидких релізів
  • Якщо клієнт не надає всі вимоги одночасно не зна чого хоче і готовий до експериментів перевірки права своєї ідеї на життя як то кажуть.

Питання #6 Коли не слід використовувати Agile?

Перш ніж використовувати Agile методологію, потрібно задати наступні питання

  • Чи функціональність продукту реально розбити на частини?
  • Чи є зв’язок з клієнтом
  • Чи вимоги є гнучкі
  • Час справді обмежений
  • У розпорядженні є достатньо кваліфікована команда

Питання #7 Коли потрібно використовувати Waterfall замість Scrum -у?

Scrum мастер може звертатися до інструментів Waterfall -у, якщо вимоги прості, передбачувані, повністю окреслені, зрозумілі і заздалегідь відомо що вони не зміняться.

Питання #8 Назвіть гнучкі методології розробки, що знаєте?

Kanban, Test Driven Development і Feature Driven Development, Lean, Extreme Programming… згадуйте методології, які знаєте.

Питання #9 Чи є різниця між Agile і Scrum?

Так! Agile більш ширше поняття. Agile це методологія, скоріше навіть філософія зі своїм набором цінностей, котра впливає на поведінку людини і до якої відноситься Scrum. Аджайл придумали для того щоб встигати за змінами на ринку.

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

Agile: У Agile кожна ітерація прив’язана до SDLC (циклом розробки програмного забезпечення) включаючи планування, проектування, кодування, аналіз вимог, модульне тестування та приймальне тестування, коли продукт демонструється зацікавленим особам.

Scrum: а у Scrum -і спринт є основною одиницею розробки. За кожним спринтом йде планова зустріч, де визначаються і оцінюються завдання для спринта (identified and estimated). Під час кожного спринту команда створює готову частину продукту, а по завершенні спринту відбувається доставка.

Kanban доволі популярний спосіб організувати роботу в дусі Аджайлу і про нього в представленому ракурсі можуть запитувати теж.

Питання #10 Розкажіть більше що Ви знаєте про Scrum?

Scrum — це одна з методик гнучкої розробки. У Scrum -і робиться акцент на планомірному контролі процесу розробки. Головна особливість скраму — це розбивка процесу розробки на ітерації з чіткими відрізками часу (зазвичай 2-6 тижнів; їх називають “спринтами”).

На початку спринта проводится “планування спринту” — нарада на 3-4 години, де обговорюються головні завдання, які будуть виконуватися протягом спринта. В кінці спринта проводиться “демо” — демонстрація результатів роботи команд за цей спринт.

Перед самим першим спринтом замовник, або його представник формує список вимог до майбутнього продукту котрий розроблятиметься. Такі вимоги називають User Story, а самого замовника Product Owner. У User Story Product Owner вказує пріоритет по кожній задачі. Спочатку будуть реалізовуватися задачі з більш високим пріоритетом. Увесь список називається Product backlog або “резерв продукту”.

Окрім Product Owner, серед учасників ще особливо виділяють scrum-мастера. Скрам мастер — слідкує щоб слідували усім принципам скраму. У якості скрам-мастера виступає хтось із команди.

На першій зустрічі, на початку спринта, окрім того, що задачі встановлюється пріоритет, надається ще приблизна оцінка в “абстрактних людських днях”, яку ще називають “story point”.Потім команда вирішує, скільки вона успішно виконає завдань за час спринта. Наприклад, замовник відображає 7 задач, а команда зможе зробити тільки 5. Значить 2 зайві задачі підуть у наступний спринт. Якщо замовнику така обставина не подобається, він може підвищити їх пріоритет, тоді інші завдання будуть вилучені зі спринту, а ці 2 завдання посядуть їх місце. Крім того, скрам-мастер може розбити деякі завдання на більш дрібніші, надати їм пріоритети на свій розсуд, щоб замовник залишився задоволеним.

Список відібраних задач на спринт називається “sprint backlog”, або “резерв спринта”. Для кращої наглядності звичайно складається таблиця, в якій перелічуються завдання, які необхідно реалізувати, які перебувають у процесі реалізації, і ті, що вже виконані (схоже на Канбан дошку, але не зовсім). Також будується діаграма “згоряння задач”. Вона графічно показує, скільки ще задач залишилося виконати. В ідеалі графік “згоряння задач” до кінця спринта повинен опуститися до нуля.

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

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

Зазвичай за 2-3 спринта можна виявити головні проблеми, які заважають працювати ефективніше, звісно ці проблеми слід усунути. Такі умови сприяють більшій продуктивності команди, не збільшує навантаження на команду. До ери гнучких методологій, це було неможливе.

Також в середині спринта, іноді ще проводять проміжні зустрічі, присвячені плануванню наступного спринта. На ній звичайно уточняють пріоритети задач, а також можуть бути якісь задачі поділені, нові задачі додані в product backlog.

Питання #11 Розкажіть про ролі в Scrum?

У Скрамі учасників поділяють на “свиней” і “кур”. “Свині” повністю задіяні у процесах, “кури” – тільки-но частково. До категорії “свиней” відносить наступні ролі:

Product Owner (власник продукту) Scrum майстер і Scrum Team (команда розробників). В ідеалі ці ролі повинні бути крос-функціональними і не використовуватися спільно з іншими проектами.

Product Owner (власник продукту) — володіє всією розробкою продукту, призначає завдання команді ( the list of Product Backlogs) і виступає у ролі звязуючої ланки між scrum командою (команда розробників) та зацікавленими сторонами.

Scrum Майстер виступає в якості фасилітатора Scrum команди. Роз’яснює питання. Стежить за тим, щоб в команді діяли правила scrum і проводили зустрічі за scrum -ом, Відповідальний за управління спринтом. А також концентрується на рентабельності інвестицій (ROI).

Scrum команда бере участь у зустрічах за scrum -ом та виконує поставлені перед нею завдання. До Scrum команди належать Developers, QA, Group of Product Owner, Business Analyst,

Рекомендований розмір команди в Scrum – 7 плюс або мінус 2 (тобто від 5 до 9 членів команди).

До “курей” відносяться ролі:

Користувачі (Users)

Клієнти, продавці (особи, які ініціюють проект і для кого проект повинен приносити вигоду. Вони задіяні у Скрам тільки під час оглядових зустрічей по спринту (Sprint Review));

Управлінці (Managers) (люди, які управляют персоналом);

Експерти-консультанти (Consulting Experts).

Багато Scrum мастерів не мають можливості працювати з крос-функціональною або спеціалізованою командою по ряду причин. Це питання може спонукати інтерв’юера запитати, як ви плануєте працювати з командою, у якій не було дизайнера або тестувальника, або як будете навчати команду, яка ще не посвячена в нюанси роботи.

Питання #12 Повторіть що входить в обов’язки Скрам мастера?

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

Питання #13 Це нормально, якщо хтось хоче змінити вимоги?

Так, Scrum майстер передбачає це. Методологія Agile заохочує зворотний зв’язок, щоб продукт можна було поліпшити. 

Члени команди повинні вміти приймати зміни і розуміти ризики, пов’язані зі зміною вимог, особливо в кінці спринту.

Грунтуючись на зміні вимог, команда тестування може оновити тест-план і перевірку test cases для досягнення кінцевих термінів.

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

Питання#14 Якщо план часові інтервали (timebox plan) потрібно змінити, хто повинен повторно розставити пріоритети?

Потрібно робити при обговоренні усією командою та власником продукту.

Питання #15 Які типи показників або звітів ви будете використовувати?

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

Питання #16 What is a Task Board?

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

Загалом, стовпці, які використовуються на дошці завдань, є такими

  1. User Story: Actual Business Requirement (Description)
  2. To Do: All the tasks of current sprint
  3. In Progress: Any task being worked on
  4. Verify: Tasks pending for verification
  5. Done: Tasks which are completed

Питання #17 Яка різниця між epic, user stories and task?

Epic: Функція програмного забезпечення, описана в описі продукту (product backlog).

User Stories: з точки зору клієнта це business functions, вони поставляються у певному спринті, як і очікувалося.

Task: завдання до виконання

Питання #18 Що таке story points/efforts/ scales?

По-суті це є абстрактні одиниці, які використовуються для обговорення складності задач

Найбільш поширеною шкалою є послідовність Фібоначчі (1,2,3,5,8,13,… .100), хоча деякі команди використовують лінійну шкалу (1,2,3,4….), Повноваження 2 (1, 2,4,8 ……) і розмір тканини (XS, S, M, L, XL)

Питання #19 Отже, перерахуйте артефакти які використовуються у Скрамі?

    • Product Backlog
    • Sprint Backlog
    • Sprint Goal / Task Board
  • Sprint Burndown Chart.

Питання #20 Що таке Burnup Chart?

Діаграма вигоряння: Він показує прогрес історій, зроблених з плином часу. Тоді як Sprint Burndown Chart скільки залишилося зробити.

Питання #21 What is the difference between Burn-up and Burn-down chart?

Burn Down Charts Записані діаграми забезпечують доказ того, що проект на ходу чи ні. Графіки згоряння та випалювання є графіки, які використовуються для відстеження ходу проекту.

Burn-up charts represent Записані діаграми показують, скільки робіт було завершено в проекті, тоді як діаграма Burn-down представляє залишилися в проекті роботи.

Питання #22 What are the types of burn-down charts?

Є 4 найпопулярніші burn down charts in Agile.

  1. Product burn down chart
  2. Sprint burn down chart
  3. Release burn down chart
  4. Defect burn down chart

Питання#23 What is Product Burn down Chart?

Графік, який показує, скільки Product Backlog Items (User Stories) implemented/not implemented.

Питання#24 What is Sprint Burn down Chart?

Графік, який показує, скільки Sprints implemented/not implemented by Scrum Team.

Питання#25 What is Release Burn down Chart?

Графік, який показує, скільки List of releases still pending, which Scrum Team have planned.

Питання#26 What is Defect Burn down Chart?

A graph which shows how many defects identified and fixed.

Питання #27 Яка ключова різниця між sprint backlog and product backlog?

Product backlog: містить список всіх бажаних функцій і належить власнику продукту

Sprint backlog: Це підмножина від Product backlog, що належить команді, і функціонал, який вона зобов’язується доставити в спринт. Sprint backlog створюється на Sprint Planning Meeting.

Питання #28 Що таке спринт?

У Scrum -і проект розділений на Sprints (Спринти). Спринт — це одна ітерація циклу розробки програмного забезпечення в скрамі. Зазвичай спринт жорстко фіксований за часом. Кожен Sprint має певну часову шкалу (від 2 тижнів до 6 тижнів). Цей графік буде узгоджений Scrum Team під час зустрічі по плануванню Sprint. Тривалість спринту вибирається на підставі розміру команди, специфіки роботи, вимог, розміру проекту. Найчастіше методом проб і помилок.  Для оцінки обсягу робіт в спринті може бути використана попередня оцінка, яка вимірюється в очках у історії. Попередня оцінка фіксується в беклозі проекту. Тут User Story розділені на різні модулі. Кінцевий результат кожного Sprint -а повинна бути версія продукту представлена замовнику.

Питання #29 Яку ідеальну довжину спринта можна вважати?

Ідеальна довжина одного спринту складає від 1 до 4 тижнів, при цьому найчастіше використовується 2-тижневий спринт.

Питання #30 What is a Sprint Planning Meeting? Опишіть, що відбувається на нараді з планування Спринту?  

У плануванні Спринту власник продукту позиціонує ціль і обговорює пункти з високим пріоритетом. Команда оцінює обсяги роботи, щоб завершити заплановане протягом наступного спринту.

Питання #31 Поясніть, що таке Spike and Zero sprint in Agile? Яка їх мета?

Sprint Zero: Вводиться для виконання деяких попередніх досліджень перед ініціюванням першого спринту. Зазвичай цей спринт використовується перед початком проекту для створення середовища розробки, підготовки перед product backlog і т.п.

Spike: Spike– це теж типи історій, які використовуються для досліджень, розвідки, дизайну і навіть прототипування. Тобто Spike це проміжні спринти для роботи, пов’язаної з будь-яким технічним чи дизайнерським питанням.Spike спринти бувають двох типів Technical Spikes and Functional Spikes.

Питання #32 Поговоримо про ритуали (процеси в Scrum)?

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

Ритуали в скрамі це:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Питання #34 Що таке «щоденний Stand-Up»?

Це Scrum Meeting зустріч, яка зазвичай проводиться Scrum мастером. І на цьому так би мовити засіданні команда робить update роботи попереднього дня та формулює завдання та контекст на наступний день.

Загалом якщо підсумувати, то Stand-Up Meeting зводиться до 3 питань, які звучать наступним чином:

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

Зустріч відбувається кожен день, бажано вранці, приблизно по 15 хвилин.

Такі зустрічі потрібні для того, щоб активізувати команду і змусити її сфокусуватися на робочому плані.

Питання #36 What is a Sprint Review Meeting?

Sprint Review Meeting це зустріч на якій Scrum команда демонструє доступну версію продукту, а власник продукту оголошує, які елементи завершені, а які не завершені. Власник продукту додає додаткові елементи до product backlog на основі відгуку стекхолдерів.

Питання #37 What is a Sprint Retrospective Meeting?

Scrum команда знову зустрічається після Sprint Review Meeting й опрацьовує інформацію отриману в попередньому спринті, наприклад, “Що було добре”, “Що можна покращити”. Це допомагає Scrum Team уникнути помилок у наступних спринтах.

Питання #38 Що таке re-factoring?

Re-factoring — це процес модифікації, покращення існуючого коду. Причому під час рефакторингу функціональність програми зазвичай залишається та ж сама.

Питання #39 Що таке «швидкість команди» (velocity)?

Velocity це середня кількість очок за останні 3-4 спринту. Швидкість команди використовується, щоб допомогти передбачити, коли будуть доставлені елементи беклогу і коли буде завершений проект.

Питання #40 Поясніть, як можна виміряти швидкість спринту у розрізненій чи неспрацьованій ще команді?

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

1 – очки історії X команди: якщо виміряти її потужність у відсотках від 40 годин тижня

2- показник очків історії / у людино-годинах

Для нашого сценарію застосовується другий метод.

Питання #41 Місце тестування QualityAssurance під час Agile?

У Agile методології тестування не є етапом, як у традиційних моделях розробки ПЗ. Це діяльність, паралельна розвитку в Agile. Часовий відрізок для тестування менший у Agile порівняно з традиційними моделями. Команда тестування під час Agile починає працювати з малих функціональностей в Agile, тоді як в традиційних моделях команда тестування працює на повну програму вже після розробки програми.

Основною діяльністю тестування під час Agile є автоматизоване Unit testing and Exploratory testing (дослідницьке тестування).

Хоча, залежно від вимог проекту, тестувальник може виконати функціональні та нефункціональні тести.

Питання #42 Що таке Agile quality strategies?

  • Re-factoring
  • Non-solo development
  • Static and dynamic code analysis
  • Reviews and Inspection
  • Iteration/sprint demos
  • All hands demo
  • Light weight milestone reviews
  • Short feedback cycles
  • Standards and guidelines

Питання #43 Якими якостями повинен володіти хороший Agile тест-інженер?

Хороший Agile тестувальник повинен мати наступні якості:

    1. Agile tester повинен добре знати і розуміти Agile принципи і концепції
    1. бути здатним швидко розуміти вимоги і працювати зі значними масивами подекуди розрізненої інформації
    1. Оскільки вимоги постійно змінюються, тестер повинен розуміти і усвідомлювати ризики, пов’язані з цим
    1. На підставі вимог Agile tester повинен бути здатним правильно розставляти пріоритети роботи
  1. Ефективно комунікувати з діловими партнерами, розробниками й іншими тестерами

Питання #44 Ви б рекомендували автоматизоване тестування на Вашому проекті?

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

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

Питання #45 Що таке Scrum ban?

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

Питання #46 Опишіть моменти, коли учасники Вашої групи не ладили. Як справлялися з цим?

Конфлікти мають місце бути, але інтерв’юер хоче побачити вашу здатність до ефективного лідерства. Згадайте час, коли у вас було кілька членів команди, які не могли працювати разом. Як ви заохочували цих учасників з метою домогтися їх успішної співпраці? Ви переконалися, що у них спільна мета? Вкажіть проблему, з якою ви зіткнулися, поясніть, як ви її вирішували і що за результат отримали в результаті.

Які види тестування проводяться під час Agile?

Головними видами тестування під час Agile висткпають автоматизоване тестування (automated unit testing) та дослідницьке тестування (exploratory testing). Хоча, залежно від вимог проекту, тестувальник може виконати будь-які види тестування, функціональні та нефункціональні тести (Functional and Non-functional tests).

Які переваги ітерації на проекті?

Переваги є

Вона допомагає об’єктивно вимірювати прогрес
Він забезпечує послідовні засоби вимірювання швидкості команди
Це допомагає встановити послідовну схему доставки

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.