itkaizenclub: business analysis roadmap
TRANSCRIPT
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Київ
практика
Питання?