Модуль 2: Старт проекта и аналитической фазы

1. Частина 2: Старт проекту та аналітичної фази Роман Сахаров @E5
2. Де ми зараз? Business Analysis Essentials Вступ: Хто такий бізнес аналітик? Частина 1: Робота з замовником, бізнес вимоги. Частина 2: Старт проекту та аналітичної фази. Частина 3: Опис та деталі продукту. Частина 4: Аналітик у фазі побудови продукту. Частина 5: Комунікації аналітика. Частина 6: Кар'єрний розвиток аналітика.
3. Отже, у вас вже є  Stakeholder matrix  Business requirements/Vision
4. Питання 1 Що є наступним кроком аналітика?  Починаємо створювати продукт  Деталізуємо вимоги  Плануємо і налаштовуємо процес бізнес аналізу  Пріоретизуємо деталізований функціонал та плануємо розробку
5. Business Analysis planning Розділ 1
6. Що планувати будемо? 1. Коли та які аналітичні активності матимуть місце 2. Формальність та рівень деталей артефактів 3. Процес пріоретизації вимог 4. Управління змінами 5. Інструменти
7. Плануємо підхід  Плановий – Plan driven  Гнучкий (керований змінами) - Agile
8. 1. Які ключові аналітичні етапи? 1. Виявлення та моделювання 2. Написання та структурування вимог 3. Створення дизайну (архітектури)
9. Agile
10. RUP
11. Waterfall
12. 2. Формальність та рівень деталей артефактів
13. Plan-driven details  Ідеально деталізовані
14. Agile details Just In Time Closest Iteration Final Iteration TASKS STORY STORY/EPIC EPIC THEME (Iteration in play)
15. Артефакти Agile  Vision  Backlog  Task (user story)  Manuals Plan driven  BRD  Functional Req. Doc.  Use Case Req. Doc.  Specification Req. Doc.  Approval archive  Change request log  Manuals
16. Деталізація також залежить  Знайомства з продуктом  Досвідченість команди  Повторюваності проекту  Складності домену
17. Темплейти і стандарти  Rational Unified Process (RUP) template  IEEE 830 - SRS template  ГОСТ 19.202-78  Specification By Example  User Story
18. 3. Процес пріоретизації вимог Agile  Оснований на цінності та принципах Minimum Viable Product  Постійно змінюється Plan-driven  Заснований на WBS  Не змінюється до випуску
19. Approval process
20. 4. Управління змінами
21. 5. Інструменти Документація  Confluence  Sharepoint  Wiki Моделювання  Visio  Enterprise architect Макетування/прототипування  Balsamiq  Axure
22. Ієрархія та traceability Розділ 2
23. Питання 2 Чому важливо зберігати ієрархію вимог?  Документація зберігається в структурованому виді  Можливо відслідкувати звідки походить вимога  Зрозуміло які високорівневі вимоги не покриті  Це насправді не обов'язково
24. Згадаємо рівні вимог
25. Classic Agile Business requirements User requirements Functional requirements Vision and Scope, BRD Vision …and Scope? BRD Use Case Functional specification, SRS Userstory +Acceptancecriteria +Details(SBE, wireframes…) + So that…
26. Tracing requirements… Back to business level  Дерева в Wiki tools, KBs (parents - children)  Нумерування(not the best practice)  Search-based traceability To test cases  Traceability matrix (e.g. Trace Analyst in JIRA)  Tests attached to requirements To code  Basic Integration between Version-Control & Change-Tracking  Task-Based Development (TBD)
27. Requirements workshops Розділ 3
28. Звідки можна отримати вимоги?  Brainstorming session  Interview users  Send questionnaires  Work in the target environment  Study analogous systems  Examine suggestions and problem reports  Talk to support teams  Conduct workshops  Demonstrate prototypes to stakeholders
29. Requirements workshop це структурована, фасилітована подія на якій старанно обрана група зацікавлених працює разом щоб виявити, створрити, підтвердити і задоукментувати заздалегідь визачені типи вимог.
30. Питання 3 Результатом requirements workhsop є…:  Специфікація програмного забезпечення (SRS)  Backlog  Business requirements document  Матриця зацікавлених  Неструктуровані вимоги по продукту  Структурований draft артефакту з вимогами
31. Як провести workshop?
32. Підготовка 1. Дізнайтесь, що можна «викопати» заздалегідь 2. Зрозумійте кінцевий результат 3. Створіть план воркшопу 4. Оберіть правильних людей 5. Підготуйте учасників 6. Оберіть правильне місце та час
33. Проведення 1. Прийдіть заздалегідь  2. Створіть умови 3. Дотримуйтесь плану 4. Дайте слово кожному 5. Візуалізуйте 6. Використовуйте техніки (напр. root cause analysis) 7. Призначте секретаря (або запис) 8. Використовуйте «parking lot»
34. Питання 4: Чи використовували ви Root Cause Analysis?  Так  Ні
35. Root Cause Analysis  5 чому Problem: Our company lost sales to the tune of $10M in 2011. Why? Our demand forecasts were constantly wrong. Why? We did not get any input from the field Why? The field agents did not have access to systems Why? The IT department did not allocate any systems to them Why? Management did not think it was a priority (root cause)  І діаграма Ішікава (fishbone diagram )
36. Оформлення результатів  Задокументуйте, скомунікуйте, підтвердьте  Розішліть action points  Подякуйте 
37. Software Requirements Specification 1. Introduction  1.1 Purpose of requirements document  1.2 Scope of the product  1.3 Definitions, acronyms and abbreviations  1.4 References  1.5 Overview of the remainder of the document 2. General description  2.1 Product perspective  2.2 Product functions  2.3 User characteristics  2.4 General constraints  2.5 Assumptions and dependencies 3. Specific requirements  Covering functional, non-functional and interface requirements. 4. Appendices
38. Product Backlog – що це? product backlog це пріоретизований список функцій, з коротким описом всього функціоналу, що бажанийу продукті
39. Організація backlog
40. Характеристики backlog - DEEP 1. Detailed Appropriately 2. Estimated 3. Emergent 4. Prioritized Це і є управління беклогом
41. User Story Mapping workshop Техніка для колективної розробки функціональної розбивки продукту
42. Етапи Story Mapping Крок1: Бренйсторм функцій продукту
43. Результат Story mapping
44. Етапи Story Mapping Крок1: Бренйсторм функцій продукту Крок 2: Погрупуйте близькі за змістом
45. Етапи Story Mapping Крок1: Бренйсторм функцій продукту Крок 2: Погрупуйте близькі за змістом Крок 3: Назвіть групи
46. Етапи Story Mapping Крок1: Бренйсторм функцій продукту Крок 2: Погрупуйте близькі за змістом Крок 3: Назвіть групи Крок 4: Упорядкуйте по User Journey
47. Етапи Story Mapping Крок1: Бренйсторм функцій продукту Крок 2: Погрупуйте близькі за змістом Крок 3: Назвіть групи Крок 4: Упорядкуйте по User Journey Крок 5: Пріоретизуйте
48. Етапи Story Mapping Крок1: Бренйсторм функцій продукту Крок 2: Погрупуйте близькі за змістом Крок 3: Назвіть групи Крок 4: Упорядкуйте по User Journey Крок 5: Пріоретизуйте Крок 6: Окресліть релізи
49. Результат Story mapping
50. Ми розглянули 1. Планування процесу аналізу 2. Вибір ієрархії вимог 3. Початковий етап виявлення вимог на воркшопі
51. А далі? Частина 3: Опис та деталі продукту
52. Питання?
53. Have we met your expectations?
54. Найближчі події  Продовження серії вебінарів: Business Analysis Essentials  Воркшоп «Управління вимогами в Agile проектах: від ідеї до працюючого продукту»  ITKaizenClub: «Як вижити у період скорочень?»  Тренінг: «Планування професійного розвитку на 2015 рік»
55. Дякуємо! info@e-5.com.ua E5Trainings E5Trainings E5 www.e-5.com.ua

Notas del editor

I'm a firm believer in traceability if you have actual regulatory compliance needs, for example the Food and Drug Administration's CFR 21 Part 11 regulations requires it, then clearly you need to conform to those regulations. I question traceability which is solely motivated by "it's a really good idea“

Traceability to business goal is actually implemented using different levels of requirements Vision => Themes => Epics => User Stories
The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of easily. This is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.
A typical product backlog comprises the following different types of items:
Features
Bugs
Technical work
Knowledge acquisition
By far the predominant way for a Scrum team to express features on the product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected."
You can read a great deal more about user stories in the resource library of this site, on Mike Cohn's blog, and, of course, in the User Stories Applied for Agile Software Development book.
Because there's really no difference between a bug and a new feature-- each describes something different that a user wants-- bugs are also on the put on the product backlog. This has been discussed quite extensively on Mike's blog, particularly in the post titled, Bugs on the Product Backlog.
Technical work and knowledge acquisition activities also belong on the product backlog. An example of technical work would be, "Upgrade all developers' workstations to Windows 7." An example of knowledge acquisition could be a product backlog item about researching various JavaScript libraries and making a selection.
The product owner shows up at the sprint planning meeting with the prioritized product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized p0roduct backlog and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five.
http://agilebench.com/blog/the-product-backlog-for-agile-teams
http://www.mountaingoatsoftware.com/blog/make-the-product-backlog-deep

Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.
Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.
Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.
Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed.
The second mechanism, "Pull," also limits WIP by making the production velocity of the upstream process dependent on the downstream consumption velocity. The first mechanism only refers to the amount of WIP, but this second refers to the flow, its direction and speed.
"Direction" - The motivation of production is given only by the downstream process."Speed" - Kanban communicates the timing and the amount of next production."Pull" limits WIP by making the upstream process's production dependent on the downstream process consumption in the 1st derivation order. This dependency is achieved by the Kanban exchange occurring in the store, pushing the production control information from the downstream process to the upstream.Back to Figure 3: the left-hand side of the graph explains how it makes work self-directing and promotes Kaizen. Everyone can understand what is happening and how well the process is flowing by seeing the Kanban cards posted to boards. Watching the workflow in the Gemba is the start of Kaizen. And physical Kanban cards put on the boards visually makes work self-directing without central control of management. This autonomous process provides data on its performance to support Kaizen, and shifts management attention from assigning or dispatching detailed work to Kaizen activities.
As shown by the graph's arrows, terminating in the three effects, the ultimate goals of Kanban can be represented by "Limits WIP", "Continuous Flow" and "Kaizen". A Kanban system "Limits WIP" while sustaining "Continuous Flow". It buffers variability due to common cause variation, and exposes special cause variability, providing candidates for Kaizen.

Модуль 2: Старт проекта и аналитической фазы

Estás leyendo una previsualización.

Eche un vistazo a continuación

Модуль 2: Старт проекта и аналитической фазы

Más Contenido Relacionado

Similares a Модуль 2: Старт проекта и аналитической фазы (20)

Más de E-5 (20)

Модуль 2: Старт проекта и аналитической фазы

Notas del editor

Модуль 2: Старт проекта и аналитической фазы

Estás leyendo una previsualización.

Модуль 2: Старт проекта и аналитической фазы

Recomendado

Más Contenido Relacionado

Similares a Модуль 2: Старт проекта и аналитической фазы (20)

Más de E-5 (20)

Модуль 2: Старт проекта и аналитической фазы

Notas del editor