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

2.
Про нас
Ірина Крючкова
Trainer @ E5
Business Analyst &
Proxy Product Owner @
Softserve
CSPO, CBAP
Роман Сахаров
Co-founder & trainer
@ E5
Business Analysis
Manager & Delivery
manager @ EPAM
Systems, CSM &
Trainer

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

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

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

6.
Класичний проект
1. Project Coordinator/Manager
2. Configuration Manager, DevOps
3. Development Team Lead/Developer
4. Test/QA engineer
5. Technical Writer
6. Business Analyst

7.
Agile => Scrum
• Власник Продукту (Product Owner)
• Scrum Master
• Команда розробки (Development
Team)

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

9.
Зацікавлені особи
Особа або група, що має відношення до зміни,
потреби або рішення
Визначаються з точки зору:
1. зацікавленості в,
2. впливу на
3. чи залежності від
зміни.

10.
Зацікавлені особи
1. Кінцевий користувач
2. Експерт предметної області
3. Спонсор
4. Замовник (Замовника)
5. Постачальник
6. Регулятор
7. Експерт по реалізації
8. Бізнес аналітик
9. Менеджер проекту
10. Тестувальник
11. Підтримка

11.
Техніки для аналізу зацікавлених осіб
1. Список зацікавлених осіб
2. Карта зацікавлених осіб
• Матриця (вплив/зацікавленість)
• Цибулева діаграма
3. RACI матриця
4. Персони

12.
Крок 3: Solution definition

13.
Визначити Рішення
Аналіз
поточного
стану
Визначення
майбутнього
стану
Оцінка
ризиків
Визначення
стратегії
змін

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

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

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

17.
Етапи виявлення (все просто )
Prepare
Conduct
Follow-
up

18.
Домашня робота
1. Бізнес клієнта
• Прочитайте про бізнес домен клієнта
• Відкрийте сайт його компанії
• Зрозумійте ключових конкурентів
2. Особистість клієнта
• Вивчіть профайли в соц. мережах та
лінкедині
• Розпитайте людей які можуть його знати
• Дізнайтесь хто приймає рішення

19.
Техніки для виявлення вимог
1. Інтерв'ю
2. Мозковий штурм
+
1. Benchmarking and Market
Analysis,
2. Business Rules Analysis,
3. Collaborative Games,
4. Concept Modelling,
5. Data Mining,
6. Data Modelling,
7. Document Analysis,
8. Focus Groups,
9. Interface Analysis,
10. Mind Mapping,
11. Observation,
12. Process Analysis,
13. Process Modelling,
14. Prototyping,
15. Survey or Questionnaire,
16. Workshops

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

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

22.
Рівні абстракції/Requirement levels
Бізнес
вимоги
Вимоги
зацікавлених
осіб
Вимоги до
рішення
Реалізація
Реалізація
Бізнес
вимоги
Користувацькі
вимоги
Функціональні
вимоги
Рівеньдеталізації

23.
Декомпозиція
Декомпозиція – розбивка на менші задачі (нічого
складного )
На чому засновуватись?
-Функціональні модулі
-Сценарії
-Конструктивно

24.
Крок 6: User Story mapping

25.
Story Mapping: що?
Цінна техніка для колективного створення функціональної
декомпозиції продукту

26.
Story mapping

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

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

29.
Для чого створюються документи?
1. Узгодження вимог
2. Управління скоупом
3. Передача знань
4. Зменшення
невизначеності
5. Гарантування якості
6. …
7. Бо вимагає регулятор
8. Потрібно щось
покласти в сейф
9. Виправдання вартості
10. Підстраховка
11. …

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

31.
Prioritization - MVP

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

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

34.
Підходи

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

36.
Product backlog
… — це документ, який має список вимог до
функціональності, які упорядковані згідно зі
ступенем важливості.
• Product backlog представляє список того,
що повинно бути реалізовано.
• Елементи цього списку називаються
елементами backlog-у (product backlog
items - PBI).

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

38.
Closest Iteration Final Iteration
TASKS STORY STORY/EPIC EPIC THEME
(Iteration in play)
Detailed Appropriately: Just In Time

39.
Detailed Appropriately: Product backlog

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

41.
Use Case - Визначення
Опис послідовності дій (включаючи альтернативні та
помилкові послідовності), які система може
реалізовувати у взаємодії із зовнішніми акторами
Поведінка, яку демонструє система з метою
отримання значимого результату для одного чи
більше акторів

42.
ADM_UC.01 Створити обліковий запис
Опис Створення облікового запису користувача Адміністратором
Актор Адміністратор
Передумови • Користувач залогінився в Систему
• У Користувача достатньо прав
Основний потік 1. Адміністратор викликає функцію
2. Система пропонує ввести інформацію про обліковий запис
3. Адміністратор зазначає необхідні дані
4. Система перевіряє коректність заповнення інформації
5. Система створює обліковий запис
6. Система повідомляє користувача (для якого створювався запис) про
створення його облікового запису
7. Система повідомляє Адміністратора про успішність виконання операції
Альтернативні
потоки
3а Адміністратор відмовляється від виконання операції
3а.1 Система відображає попередження
3а.2 IF Адміністратор погоджується – Система припиняє виконання сценарію,
ELSE – Система повертається до кроку 3
4а Введена інформація некоректна
4а.1 Система повідомляє Адміністратора про наявні помилки та повертається
до кроку 3
Постумови Обліковий запис створено, користувач (для якого створювався запис)
повідомлений

43.
Крок 11: User Story

44.
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 – цінність для кінцевого користувача, навіщо?
Картка

45.
Acceptance criteria - Критерії прийомки
• набір тверджень (pass/fail)
• визначають параметри користувацької
історії
• специфікують функціональні вимоги
• закривають не функціональні
• Вказують коли історія закінчена і
працює, як очікувалося
• додають визначеність, що команда
будує

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

47.
Прототипування
Етап розробки програмного
забезпечення на якому створюється
прототип програми – макет, для того
щоб
1. перевірити придатність
запропонованих концепцій,
2. виявити прогалини у вимогах і
3. отримати зворотній зв’язок від
користувачів.

48.
Основні підходи
1. Throw-away
• Паперові або на дошці
• У певному програмному забезпечення
• Інтерактивні або ні
2. Ті, що будуть розвиті у рішення
(або функціональні)
• Як етап розробки рішення

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

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

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

52.
Що можна моделювати
1. Concept Modelling
2. Data Modelling
3. Decision Modelling
4. Mind Mapping
5. Organizational Modelling
6. Process Modelling
7. Scope Modelling
8. …

53.
Типи діаграм
Діаграми
структури
Моделі даних
Діаграми компонент
Контекстні діаграми
Структурні …
Діаграми
поведінки
Процесні
Потоків даних
Блок-схеми
Діаграми станів …

54.
Крок 14: Software Requirements
Specification

55.
Software Requirements Specification
1. Повний опис поведінки системи
2. Включає:
• Функціональні вимоги
• Нефункціональні вимоги
• Інше

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

57.
Зміст SRS
1. Вступ
• Мета документу
• Умовні позначення
• Цільова аудиторія
• Скоуп продукту/проекту
• Посилання
2. Загальний опис
• Перспективи продукту
• Загальний опис
функціональності
• Опис користувачів
• Припущення, обмеження,
залежності
3. Функціональні вимоги
4. Інші вимоги
• Нефункціональні вимоги
5. Додатки

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

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

60.
Комунікаційний хаб
Communicates
Communicates
Facilitates
Team
Business
Analyst
Customer/Clients

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

62.
Активності для підтримки
1. Проводити тренінги по домену
2. Організовувати обмін знаннями на тему
функціоналу, або процесу
3. Відповідати на питання команди, або переправляти
їх до замовника
4. Пріоритезувати дефекти з замовником, або як
проксі
5. Прийняття (acceptance) задач

63.
Grooming – що?
1. Створення і деталізація PBI
2. Оцінка PBI
3. Пріорітизування PBI

64.
Оцінка задач
Estimation approach Category
Examples 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 model
Function 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 estimation
Average of an analogy-based and a Work
breakdown structure-based effort estimate
Judgmental combination Combination-based estimation
Expert judgment based on estimates from a
parametric model and group estimation

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

66.
Самостійне навчання
1. Вигерс Карл «Разработка требований к программному
обеспечению»
2. Business Analysis Body of Knowledge (BABOK), v.3
3. Dean Leffingwell, Don Widrig «Managing Software
Requirements: A Unified Approach»
4. Alistair Cockburn "Writing Effective Use Cases”
5. Dean Leffingwell “Agile Software Requirements"

67.
Business Analysis Big Bang 2.0
1. Теорія онлайн
2. Практика офлайн (Київ)
• Перевірені техніки бізнес аналізу,
• Необхідна теорія
• Практична робота на реальних прикладах
• Можливість пройти всі етапи роботи аналітика
• Домашні завдання та спільне обговорення результатів
• Тестування знань щотижня

68.
Принципи роботи
Робота в міні-командах над власним продуктом від ідеї до
детальних специфікацій
Заняття 1: Блок теорії – основні аспекти задачі, перелік технік
Домашнє завдання: детальне вивчення однієї з технік (відпрацювання на практиці, для тих,
хто онлайн)
Заняття 2: Відпрацювання техніки на практиці
Домашнє завдання: завершити почате
Контроль знань: Тестування з подальшим розбором результатів

69.
Розклад
Дата Місце Назва Деталі Вартість
24.03.2016
19:00 – 20:30
Онлайн Вебінар: Roadmap бізнес
аналітика
http://e-
5.com.ua/ru/calendar/event/351-
vebinar-roadmap-biznes-analitika
Безкоштовно
26.03.2016
10: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Київ
практика

70.
Питання?

71.
info@e-5.com.ua
E5Trainings
E5Trainings
E5
www.e-5.com.ua