Roadmap Бізнес АналітикаІрина Крючкова та Роман Сахаров @E5

Про нас

Ірина КрючковаTrainer @ E5

Business Analyst & Proxy Product Owner

@ Softserve CSPO, CBAP

Роман СахаровCo-founder & trainer @ E5

Business Analysis Manager &

Delivery manager @ EPAM Systems,

CSM & Trainer

З чого ви починаєте проект?

Крок 1: Ваша (BA) роль

Типи методологій

Класичний проект

1. Project Coordinator/Manager 2. Configuration Manager, DevOps3. Development Team Lead/Developer4. Test/QA engineer 5. Technical Writer 6. Business Analyst

Agile => Scrum

• Власник Продукту (Product Owner)

• Scrum Master• Команда розробки (Development Team)

Крок 2: Аналіз зацікавлених осіб

Зацікавлені особи

Особа або група, що має відношення до зміни, потреби або рішенняВизначаються з точки зору:

1. зацікавленості в, 2. впливу на 3. чи залежності від

зміни.

Зацікавлені особи

1. Кінцевий користувач2. Експерт предметної

області3. Спонсор4. Замовник (Замовника)5. Постачальник6. Регулятор7. Експерт по реалізації8. Бізнес аналітик

9. Менеджер проекту10. Тестувальник11. Підтримка

Техніки для аналізу зацікавлених осіб

1. Список зацікавлених осіб2. Карта зацікавлених осіб

• Матриця (вплив/зацікавленість)• Цибулева діаграма

3. RACI матриця4. Персони

Крок 3: Solution definition

Визначити Рішення

Аналіз

поточног

о стану

Визначення майбутньо

го стану

Оцінка ризиків

Визначення

стратегії змін

Цінність як основна мета

Головне питання аналітика

Крок 4: Виявлення вимог

Етапи виявлення (все просто )

Prepare

Conduct

Follow-up

Домашня робота

1. Бізнес клієнта• Прочитайте про бізнес домен клієнта• Відкрийте сайт його компанії• Зрозумійте ключових конкурентів

2. Особистість клієнта• Вивчіть профайли в соц. мережах та

лінкедині• Розпитайте людей які можуть його знати• Дізнайтесь хто приймає рішення

Техніки для виявлення вимог

1. Інтерв'ю2. Мозковий штурм+3. Benchmarking and

Market Analysis, 4. Business Rules Analysis, 5. Collaborative Games, 6. Concept Modelling, 7. Data Mining, 8. Data Modelling,

9. Document Analysis, 10. Focus Groups, 11. Interface Analysis, 12. Mind Mapping, 13. Observation, 14. Process Analysis, 15. Process Modelling, 16. Prototyping, 17. Survey or Questionnaire, 18. Workshops

Після зустрічі, підтримка контакту

• Напишіть meeting minutes• Домовтеся про подальші зустрічі і способи комунікації

• Сформуйте план комунікацій

Крок 5: Організація вимог

Рівні абстракції/Requirement levels

Бізнес вимоги

Вимоги зацікавлених

осіб

Вимоги до рішення

Реалізація

Реалізація

Бізнес вимоги

Користувацькі вимоги

Функціональні вимоги

Ріве

нь

дета

ліза

ції

Декомпозиція

Декомпозиція – розбивка на менші задачі (нічого складного )

На чому засновуватись?- Функціональні модулі- Сценарії- Конструктивно

Крок 6: User Story mapping

Story Mapping: що?

Цінна техніка для колективного створення функціональної декомпозиції продукту

Story mapping

Крок 7: Високорівневі вимоги

Які документи створює аналітик

1. Концепція2. Бачення та скоуп3. Документ бізнес вимог4. Технічне завдання5. Тендерна документація6. Специфікації вимог до

програмного забезпечення …

Для чого створюються документи?

1. Узгодження вимог2. Управління скоупом3. Передача знань4. Зменшення

невизначеності5. Гарантування

якості6. …

7. Бо вимагає регулятор

8. Потрібно щось покласти в сейф

9. Виправдання вартості

10.Підстраховка11.…

Крок 8: Пріоритезація

Prioritization - MVP

Чому важливо пріоритизувати?

Фактори, що впливають на пріоритет

1. Вигода2. Зобов'язання3. Вартість4. Ризик5. Залежності6. Чутливість до часу7. Стабільність8. Відповідність політикам

Підходи

Крок 9: Створення Backlog

Product backlog

… — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. • Product backlog представляє список

того, що повинно бути реалізовано. • Елементи цього списку називаються

елементами backlog-у (product backlog items - PBI).

З чого складається Backlog?

Closest Iteration Final Iteration

TASKS STORY STORY/EPIC EPIC THEME(Iteration in play)

Detailed Appropriately: Just In Time

Detailed Appropriately: Product backlog

Крок 10: Створення Use Cases

Use Case - Визначення

Опис послідовності дій (включаючи альтернативні та помилкові послідовності), які система може реалізовувати у взаємодії із зовнішніми акторами

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

ADM_UC.01 Створити обліковий записОпис Створення облікового запису користувача АдміністраторомАктор АдміністраторПередумови • Користувач залогінився в Систему

• У Користувача достатньо правОсновний потік

1. Адміністратор викликає функцію2. Система пропонує ввести інформацію про обліковий запис3. Адміністратор зазначає необхідні дані4. Система перевіряє коректність заповнення інформації5. Система створює обліковий запис6. Система повідомляє користувача (для якого створювався запис)

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

операціїАльтернативні потоки

3а Адміністратор відмовляється від виконання операції3а.1 Система відображає попередження3а.2 IF Адміністратор погоджується – Система припиняє виконання сценарію, ELSE – Система повертається до кроку 34а Введена інформація некоректна4а.1 Система повідомляє Адміністратора про наявні помилки та повертається до кроку 3

Постумови Обліковий запис створено, користувач (для якого створювався запис) повідомлений

Крок 11: User Story

As a [user role] I want [activity] so I can [benefit]As a [user role] I can [activity] so that [benefit]

User role – хто (новий користувач, гість, безробітний)?Activity – функціональність, дія системи, що?Benefit – цінність для кінцевого користувача, навіщо?

Картка

Acceptance criteria - Критерії прийомки

• набір тверджень (pass/fail)• визначають параметри

користувацької історії • специфікують функціональні

вимоги• закривають не функціональні• Вказують коли історія закінчена і

працює, як очікувалося• додають визначеність, що

команда будує

Крок 12: Прототипування

Прототипування

Етап розробки програмного забезпечення на якому створюється прототип програми – макет, для того щоб

1. перевірити придатність запропонованих концепцій,

2. виявити прогалини у вимогах і 3. отримати зворотній зв’язок від

користувачів.

Основні підходи

1. Throw-away• Паперові або на дошці• У певному програмному

забезпечення• Інтерактивні або ні

2. Ті, що будуть розвиті у рішення (або функціональні)• Як етап розробки рішення

Крок 13: Моделювання

Мета моделювання

Візуалізація структури або поведінки бізнес домену або інформаційної системи для подальшого аналізу, узгодження або удосконалення

Модель – спрощене відображення реальності, часто розглянутої з обмеженої кількості різних кутів зору

Принципи моделювання

•Вибір моделі справляє вирішальний вплив на рішення1•Кожна модель може мати різні ступені абстракції2•Найкращі моделі ті, що ближче до реальності3•Не потрібно обмежуватися однією моделлю4

Що можна моделювати

1. Concept Modelling2. Data Modelling3. Decision Modelling4. Mind Mapping5. Organizational Modelling6. Process Modelling7. Scope Modelling8. …

Типи діаграм

Діаграми структури

Моделі даних

Діаграми компонент

Контекстні діаграми

Структурні …

Діаграми поведінки

Процесні

Потоків даних

Блок-схеми

Діаграми станів …

Крок 14: Software Requirements Specification

Software Requirements Specification

1. Повний опис поведінки системи2. Включає:

• Функціональні вимоги• Нефункціональні вимоги• Інше

Характеристики SRS

1. Коректність2. Повнота3. Однозначність4. Відслідковуваність5. Тестованість6. Відповідність7. Визначені пріоритети8. Можливість ідентифікації

Зміст SRS

1. Вступ• Мета документу• Умовні позначення• Цільова аудиторія• Скоуп продукту/проекту

• Посилання2. Загальний опис

• Перспективи продукту• Загальний опис функціональності

• Опис користувачів• Припущення, обмеження, залежності

3. Функціональні вимоги

4. Інші вимоги• Нефункціональні вимоги

5. Додатки

Функціональні вимоги

1. Варіанти використання2. Прототипи користувацького інтерфейсу3. Опис класів та об'єктів4. Стани та переходи5. Діаграми діяльності6. Формули, правила та інші функціональні

вимоги

Крок 15: Підтримка розробки

Комунікаційний хаб

Communicates

Communicates

Facilitates

Team

Business Analyst

Customer/Clients

Рівні планування

Активності для підтримки

1. Проводити тренінги по домену2. Організовувати обмін знаннями на тему

функціоналу, або процесу3. Відповідати на питання команди, або

переправляти їх до замовника4. Пріоритезувати дефекти з замовником, або

як проксі5. Прийняття (acceptance) задач

Grooming – що?

1. Створення і деталізація PBI2. Оцінка PBI3. Пріорітизування PBI

Оцінка задач

Estimation approach CategoryExamples of support of implementation of estimation approach

Analogy-based estimation Formal estimation model ANGEL, Weighted Micro Function Points

WBS-based (bottom up) estimation Expert estimation Project management software, company specific activity templates

Parametric models Formal estimation model COCOMO, SLIM, SEER-SEM, TruePlanning for Software

Size-based estimation models Formal estimation modelFunction Point Analysis,[14] Use Case Analysis, SSU (Software Size Unit), Story points-based estimation in Agile software development

Group estimation Expert estimation Planning poker, Wideband Delphi

Mechanical combination Combination-based estimationAverage of an analogy-based and a Work breakdown structure-based effort estimate

Judgmental combination Combination-based estimationExpert judgment based on estimates from a parametric model and group estimation

Робота в спринтах

Самостійне навчання

1. Вигерс Карл «Разработка требований к программному обеспечению»

2. Business Analysis Body of Knowledge (BABOK), v.33. Dean Leffingwell, Don Widrig «Managing Software

Requirements: A Unified Approach»4. Alistair Cockburn "Writing Effective Use Cases”5. Dean Leffingwell “Agile Software Requirements"

Business Analysis Big Bang 2.0

1. Теорія онлайн2. Практика офлайн (Київ)

• Перевірені техніки бізнес аналізу,• Необхідна теорія• Практична робота на реальних прикладах• Можливість пройти всі етапи роботи аналітика• Домашні завдання та спільне обговорення результатів• Тестування знань щотижня

Принципи роботи

Робота в міні-командах над власним продуктом від ідеї до детальних специфікацій

Заняття 1: Блок теорії – основні аспекти задачі, перелік технік

Домашнє завдання: детальне вивчення однієї з технік (відпрацювання на практиці, для тих, хто онлайн)

Заняття 2: Відпрацювання техніки на практиціДомашнє завдання: завершити почате

Контроль знань: Тестування з подальшим розбором результатів

Розклад

Дата Місце Назва Деталі Вартість24.03.201619:00 – 20:30

Онлайн Вебінар: Roadmap бізнес аналітика

http://e-5.com.ua/ru/calendar/event/351-vebinar-roadmap-biznes-analitika

Безкоштовно

26.03.201610:00 – 18:00

Київ Workshop «Управління вимогами в Agile проектах: від ідеї до працюючого продукту»

http://e-5.com.ua/ru/calendar/event/346-workshop-upravlinnya-vimogami-v-agile-proektakh-vid-ideji-do-pratsyuyuchogo-produktu

10% знижки по кодуITKaiZenClub

З 5.04.2016протягом 2 місяців

Онлайн теорія

Курс Business Analysis Big Bang 2.0

http://e-5.com.ua/ru/calendar/event/345-kurs-business-analysis-big-bang-2-0

10% знижки по кодуITKaiZenClubКиїв

практика

Питання?

info@e-5.com.uaE5TrainingsE5TrainingsE5www.e-5.com.ua