role business analysts scrum
Запитання та відповіді на інтерв’ю для тестування програмного забезпечення за 2 роки досвіду
Визначна роль бізнес-аналітиків у SCRUM:
Бізнес-аналітик, якого скоро називають бакалавратом, відіграє дуже суттєву та важливу роль у СКРУМ .
Ця особа є сполучною ланкою між власником продукту / замовником та технічною ІТ-командою. Незважаючи на те, що ми натрапили на наш веб-сайт з підручників з питань бакалаврації, кілька підручників якимось чином буде унікальним та пояснить вам важливість бакалаврату в SCRUM.
Давайте досліджувати !!
=> Перегляньте ВСІ підручники з бізнес-аналітиків тут.
Що ви дізнаєтесь:
- Обов'язки бакалавра
- Бізнес-аналітик як власник продукту
- Бізнес-аналітик як член команди
- Важливість та роль бізнес-аналітиків у команді SCRUM
- Чому QA найкраще підходить для цієї роботи?
- Рекомендована література
Обов'язки бакалавра
У Scrum є кілька ролей бізнес-аналітиків, і є певні обов'язки, яких повинен дотримуватися BA.
Нижче наведено кілька вибіркових серед них.
- Догляд за відставанням товару на основі пріоритетів, наданих власником товару.
- Аналіз потреб замовника та пошук рішень для їх вирішення.
- Створення вимог у вигляді історій користувачів із відповідними критеріями прийнятності.
- Якщо у випадку, якщо історії користувачів уже створені власником продукту (з критеріями прийнятності), перегляньте їх, щоб переконатися, що всі бізнес-правила охоплені та критерії прийняття відповідають функціональності історії користувача.
- Співпраця з власником товару та зацікавленими сторонами, щоб зрозуміти сферу застосування, запропонувати вдосконалення вимог тощо.
- Підготовка таких документів, як каркасні каркаси, проектний процес, інтерфейс користувача тощо, за необхідності.
Окрім цього, a Бізнес-аналітик є важливим учасником мозкових штурмів, коли команда збирається для обговорення відставання у спринті, що має відбутися. ВА направляє команду, допомагає зрозуміти вимоги і навіть часом вимагає схвалення реалізації.
Він також тісно співпрацює із службами контролю якості, наприклад, аналізуючи висвітлення тестів, перетворюючи випадки реального використання в тестові кейси, надаючи розуміння для перевірки складних функціональних можливостей тощо. BA також бере участь у зборах з планування, щоб допомогти команді в оцінках, допомагаючи їм розуміти потік, складність та залежність.
BA завжди повинен продовжувати дізнаватися про нову тенденцію, що відбувається на ринку, продовжувати впроваджувати інновації та бути в курсі ділової сфери, для якої створений продукт.
Бізнес-аналітик як власник продукту
Залежно від замовника та компанії, трапляється, що в деяких компаніях бізнес-аналітик є власником продукту. У цих випадках BA відповідає за всі запити. Потім BA стає посередником між командою та зацікавленими сторонами.
BA повинен розуміти вимоги зацікавлених сторін, їхні думки щодо подальшого розвитку бізнесу та того, що (і як) має розвиватися. Потім, виходячи з вимог зацікавлених сторін, ВА повинен створити документи, історії користувачів, розставити пріоритети в матеріалах, допомогти команді зрозуміти їх, відповісти на їхні запитання про те саме тощо.
Найголовніше, на що слід звернути увагу, це те, що це доцільно, коли BA є фізично доступним і не геолокується в інший часовий пояс, щоб уникнути «розриву в спілкуванні».
Якщо BA, як у власника продукту, геолокується в інший часовий пояс, то не можна підходити до нього щоразу, і єдиний спосіб спілкування - це електронна пошта, чати чи дзвінки, отже це може призвести до браку, розриву і навіть неправильне спілкування часом.
Згідно з моїм досвідом, цього слід дотримуватися, коли керівник навчального закладу сидить у вашому кабінеті, поруч із вашою командою, щоб ваша робота не заважала і він (-і) був легко доступний. З точки зору бакалавра, вони володіють продуктом від імені зацікавлених сторін / замовників, приймають відповідні рішення і навіть повинні освоїти нові навички, які можуть включати вивчення деяких технічних аспектів розробки.
Наявність бізнес-аналітика як власника продукту є додатковою перевагою, оскільки бізнес-аналітик дуже добре розуміє продукт, і також можна узгодити пріоритетність та масштаб завдань.
Бізнес-аналітик як член команди
Інший варіант - мати бізнес-аналітика як члена команди, оскільки власник продукту буде недоступний щоразу. Коли бізнес-аналітик є членом команди, вони допомагають одноліткам у догляді за відставанням.
Мати бізнес-аналітика в якості члена команди вигідніше, оскільки технічній групі легко та комфортно спілкуватися з спеціалістом для роз'яснень або обговорень. BA також тісно співпрацює з командою з контролю якості для тестування, тобто аналізу покриття, охоплених випадків використання, будь-яких прихованих вимог чи надійності чи ефектів.
Іноді критерії прийнятності, написані власником Продукту, можуть бути розмитими та незрозумілими, тоді як член команди, відповідальність БА лягає на написання детально продуманих та чітко пояснених критеріїв прийняття. Якщо команді потрібна додаткова інформація, то BA також створює каркасні документи, потокові документи тощо, щоб допомогти команді зрозуміти вимоги.
У великомасштабних проектах, де модулі розподіляються між командами, наявність бакалавра для більш ніж однієї команди також є додатковою перевагою. Оскільки BA однаковий у команд, він може думати про взаємодію модулів, як нові функції або оновлення вплинуть на інші модулі тощо.
Таким чином, це могло б дуже допомогти технічним групам розглянути такі аспекти, як не завжди про них згадують історії користувачів або критерії прийняття.
Важливість та роль бізнес-аналітиків у команді SCRUM
Роль бізнес-аналітиків у SCRUM дуже важлива для успіху проекту. Їх участь починається з розуміння потреби замовника у демонстрації Sprint. Вони є першою контактною точкою технічної групи для роз’яснень. Вони навіть важливіші на початкових етапах нового проекту та великих за масштабом проектах.
Власник продукту не завжди буде хорошим письменником, іноді вони походять з технічного досвіду, а отже, бізнес-аналітик несе відповідальність за написання матеріалів, прийняття, каркасні схеми тощо.
У моєму проекті наша заявка на замовлення не була настільки хорошою з документацією, і навіть написані історії користувачів ніколи не складали більше 2-3 лайнерів, тоді як критерії прийняття були лише 1 лайнером. Саме бізнес-аналітик звик їх модифікувати, зробити їх більш пояснювальними та детальними.
Навіть часом траплялося, що наш постачальник послуг писав історії користувачів, які мали 21 або більше історій, і, отже, бізнес-аналітику доводилося витрачати зайвий час та зусилля на їх розбиття та встановлення пріоритетів у власника продукту.
Ви можете собі уявити, що сталося б, якби відсутній бізнес-аналітик, а власник продукту створив історію користувача на зразок „Як клієнт я хочу виконувати всі банківські операції для свого рахунку“ з такими критеріями прийняття, як:
- Клієнт повинен мати можливість авторизуватися.
- Клієнт повинен мати можливість здійснювати операції на моєму рахунку.
- Клієнт повинен мати можливість завантажувати мої історичні виписки тощо.
Зараз, на мій погляд, ця історія користувача містила б навіть більше 34 очок історії, отже, існує необхідність її подальшого розбиття. Ситуація погіршиться для технічної команди, якщо не буде надано належних діаграм потоків та екранів інтерфейсу (які потрібно створити).
Це призвело б до невдалого спринту і, в свою чергу, до невдалого проекту. Якщо власник продукту не є кваліфікованим / практикованим бізнес-аналітиком, у команді його потрібно мати.
Чому QA найкраще підходить для цієї роботи?
QA - це особа, яка перевіряє запропоноване рішення проблеми / вимоги, перевіряючи його. Отже, бізнес-аналітик / зацікавлені сторони / власники продуктів дуже хочуть дізнатись про зворотний зв’язок із забезпеченням якості. Участь BA в тестуванні - це трохи більше, ніж те, що воно знаходиться в розробці.
Бізнес-аналітик тісно співпрацює з QA при перегляді охоплення тестових випадків, що забезпечує розуміння прихованих потоків або вимог / ефектів. Таким чином, такий вид обміну знаннями (BA) дає їм змогу повністю зрозуміти функціональність продукту, ділові правила, очікування клієнтів, потоки, залежності та все.
QA завжди тестує з точки зору кінцевого споживача, який би використовував продукт, отже, шансів допомогти замовнику в удосконаленнях, вдосконаленнях продукту більше (у порівнянні з розробником). Розробники розробляють продукт для даної історії користувача та набору критеріїв прийняття, але не завжди вони замислюються про те, як клієнт використовує продукт .
При розробці впровадження продукту, потік та правила чітко визначені, але тестування повністю засноване на логічному мисленні та здатності мислити з точки зору кінцевих споживачів.
QA може почати входити в роль бізнес-аналітиків у SCRUM через безліч можливостей, які відкриваються в повсякденній роботі.
Рекомендуємо прочитати => Зміна кар’єри з тестера на бакалавра
Для контролю якості дуже легко потрапити в такі ролі, як:
- Дуже глибоко вивчіть вимоги та вкажіть на прогалини в оглядових зустрічах / мозкових штурмах тощо. Спробуйте подумати про кращі рішення та обговорити те ж саме з командою та спеціалістом.
- Будьте уважні до дзвінків із Власником продукту, задавайте питання та діліться своїми результатами. Це підвищить довіру Власника товару, що виявляє вашу зацікавленість у продукті.
- Помістіть себе між BA та командою розробників, ви повинні бути контактною точкою для розробників у разі пояснень або сумнівів.
- Налаштуйте процес тестування та продовжуйте впроваджувати його, змінюючи його, щоб допомогти у проведенні успішних спринтів.
- У випадку з продуктами з вигадливими інтерфейсами, слідкуйте за новими тенденціями та пропонуйте такі вдосконалення.
- Зрозумійте продукт повністю і всередину.
- Створіть глибокі знання своїх зацікавлених сторін, їхніх очікувань та поділіться з ними своїм досвідом.
Це також означає, що для того, щоб отримати роль бакалавра, вам потрібно підвищити свої навички. На ринку є кілька курсів, які включають як базовий, так і просунутий рівень.
Ви BA / QA? Ми справедливо вказали на все про вашу роль? Або ти вважаєш, що ми пропустили щось, що ви унікально виконуєте? Будемо раді почути Вас. Не соромтеся ділитися ними з нами у розділі коментарів нижче !!
=> Завітайте сюди, щоб побачити серію бізнес-аналітиків для всіх.
Рекомендована література
- Артефакти Scrum: відставання товару, відставання спринту та збільшення товару
- Чи існує межа початку та зупинки ролі контролю якості в Scrum?
- 39 найкращих інструментів аналізу бізнесу, що використовуються провідними бізнес-аналітиками (список від А до Я)
- Ролі та обов'язки команди Scrum: Майстер Scrum та власник продукту
- Перехід від тестера до бізнес-аналітика - покроковий посібник
- Почніть свою кар'єру як бізнес-аналітик: проспект кар'єри для вас
- ІТ-підтримка та розвиток бізнесу Координатор тренінгів із підготовки спеціалістів Пуна
- Випробування дефектів у Scrum: як це організовано в налаштуванні Scrum