2.79M

Category:

software

Методології розробки програмного забезпечення

1.

Методології розробки
програмного забезпечення.
© 2022 Комп'ютерна школа Hillel

2.

Sequential Life Cycle
Models
© 2022 Комп'ютерна школа Hillel

3.

Waterfall
Requirement analysis
Design
Development
Testing
YOUR TITLE
03
Maintenance
© 2022 Комп'ютерна школа Hillel

Характеристики моделей
Суворий перехід від одного
етапу до іншого
Продукт готовий лише
Процес керується
наприкінці останньої
планом: кожен крок та
фази.
його компоненти
мають бути заплановані
та заплановані до
початку роботи.
© 2022 Комп'ютерна школа Hillel

6.

Коли використовувати моделі?
Вимоги чітко
Немає динамічних та
визначені, добре
швидко
описані та всі
впроваджуваних
недоліки виправлені
нових технологій
Розвиток продукту
стабільний
© 2022 Комп'ютерна школа Hillel

7.

Плюси послідовних моделей
Стабільність вимог
Немає двозначних чи
невизначених вимог
На кожному етапі формується
закінчений набір проектної
документації
Просто та легко використовувати
Усі етапи робіт виконуються у
логічній послідовності
Прозорість процесів для
замовника
© 2022 Комп'ютерна школа Hillel

8.

Мінуси послідовних моделей
Необхідність затвердження
повного обсягу вимог до системи
на першому етапі
Багато часу та сил на
документацію
Повернення до попередніх стадій
не можливе
Збільшення витрат коштів та часу
у разі потреби зміни вимог
Не підходить для ситуації, коли
клієнти змінюють вимоги проект
© 2022 Комп'ютерна школа Hillel

9.

Проблеми при тестуванні у послідовних моделях
Оскільки тестування проводиться наприкінці проекту, зазвичай воно піддається
тиску часу. Така ситуація веде до неприємного компромісу між якістю та датою
випуску
Поширений випадок, коли команда тестування в стислий термін стверджує
реліз, який погано тестується
Також у таких випадках команда тестувальників видається вузьким місцем
© 2022 Комп'ютерна школа Hillel

10.

Spiral Life Cycle
Models
© 2022 Комп'ютерна школа Hillel

11.

12.

Характеристика моделі
● Поєднує в собі ідею ітеративної розробки з упором на аналіз та
управління ризиками
● Робота з розвитку проходить через послідовність прототипів, які
тестуються, потім реконструюються, репрототипуються та повторно
тестуються доти, доки всі ризиковані проектні рішення не будуть
підтверджені (або відхилені) під час тестування
● На кожній ітерації ми проводимо раунд аналізу ризиків і, відповідно,
визначаємо найвищий ризик чи ризики, який ми повинні орієнтуватися
у кожній ітерації
© 2022 Комп'ютерна школа Hillel

13.

Determine
objectives
Все починається з цієї стадії,
це стадія планування
Відбувається збирання вимог
Комунікація між менеджером
та командою
© 2022 Комп'ютерна школа Hillel

14.

Risk phase
Визначення ризиком
Пріоритезація ризиків
Визначення правильної
стратегії, щоб пом'якшити
або обійти ризики
© 2022 Комп'ютерна школа Hillel

15.

Engineering phase
Створення, розробка та
тестування
© 2022 Комп'ютерна школа Hillel

16.

Plane next phase
Планування наступної фази
© 2022 Комп'ютерна школа Hillel

17.

Коли використовувати модель?
У проектах із
Складні вимоги
високими
ризиками
Власник не
впевнений у
вимогах
© 2022 Комп'ютерна школа Hillel

18.

Плюси моделі
Змінні вимоги можуть бути
враховані
Кращий risk management
Вимоги формуються чітко
Користувач бачить раніше ПЗ
© 2022 Комп'ютерна школа Hillel

19.

Минусы модели
Процеси складні
Зайва документація
Керувати процесами складно
Може бути дорогим, особливо для
маленьких проектів
© 2022 Комп'ютерна школа Hillel

20.

Проблеми при тестуванні у послідовних моделях
Важко оцінити час на тестування
Важко планувати тестування
На початковій стадії важко проводити тестування над прототипами, не
розуміючи і не маючи кінцевого продукту
© 2022 Комп'ютерна школа Hillel

21.

Iterative or
Incremental models
© 2022 Комп'ютерна школа Hillel

22.

23.

Різновиди моделі
Kanban
Scrum
Feature
driven
development
Agile
Iterative
models
Rational
Unified
Process
Microsoft
Solutions
Framework
І ще дуже багато інших
© 2022 Комп'ютерна школа Hillel

24.

Характеристики моделі
Багаторазове
Система розвивається
повторення тих самих
ітеративно та
невеликими порціями
Клієнтоорієнтована
стадій
© 2022 Комп'ютерна школа Hillel

25.

Коли використовувати моделі?
Є велика ймовірність
зміни важливого
Час виходу ринку
функціоналу у
обмежено
Основні вимоги мають
майбутньому
бути визначені. Решту
функціональності
можна додати через час
© 2022 Комп'ютерна школа Hillel

26.

Плюси моделей
Гнучкість
Легше керувати ризиками
Можливість адаптації процесу на
основі кроків, що були зроблені з
попередньої ітерації
Швидке виробництво готового
продукту
Швидкий час доставки
Тестування та налагодження
набагато простіше
© 2022 Комп'ютерна школа Hillel

27.

Мінуси моделей
Незрозуміла вартість продукту
Можуть виникнути проблеми з
архітектурою системи
Може знадобитися більше
ресурсів
Нестабільні вимоги
Необхідно більше контролю та
залучення з боку менеджменту
© 2022 Комп'ютерна школа Hillel

28.

Проблеми під час тестування
Необхідність проведення регресійного тестування після кожної ітерації
Часта зміна вимог призводить до труднощів у підтримці тестової документації
© 2022 Комп'ютерна школа Hillel

29.

30.

31.

Agile
Agile — це ітеративний підхід до управління
проектами та розробки програмного
забезпечення, який допомагає командам швидше
та з меншими труднощами приносити користь
своїм клієнтам. Замість того, щоб робити ставку
на великий вибух, agile-команда виконує роботу
невеликими, але видатковими частинами.
У 2001 році з'являється 17 фахівців, внаслідок
чого народився Agile маніфест.
A
B
D
C
© 2022 Комп'ютерна школа Hillel

32.

Agile manifesto
Люди та їх взаємодії – гнучкий розвиток, який
спрямовано на людей. Команда в першу чергу
взаємодіє із замовником і не залежить від
інструментів чи процесів.
© 2022 Комп'ютерна школа Hillel

33.

Agile manifesto
Готовий продукт – з точки зору клієнта
працююче програмне забезпечення набагато
корисніше і цінніше, ніж документація щодо
цього продукту.
© 2022 Комп'ютерна школа Hillel

34.

Agile manifesto
Співпраця із замовником – клієнт часто
стикається з проблемою у визначенні необхідної
системи. Спільна робота підвищує ймовірність
розуміння того, що саме вимагає клієнт.
© 2022 Комп'ютерна школа Hillel

35.

Agile manifesto
Реакція зміни – зміни у проектах неминучі.
Середовище розробки, законодавство,
конкуренти, нові технології дуже впливають на
проект. Усі ці фактори мають враховуватися.
© 2022 Комп'ютерна школа Hillel

36.

Принципи Agile
1
Наш вищий пріоритет
це задоволення замовника за допомогою частих та
безперервних поставок продукту, цінного для нього.
2
3
4
Ми приймаємо зміни
У вимоги навіть на пізніх етапах реалізації проекту.
Гнучкі процеси
вітають зміни, що є конкурентною перевагою для
замовника.
Постачання робочого програмне забезпечення
кожні кілька тижнів, у крайньому випадку кожні кілька
місяців. Що частіше, то краще.
© 2022 Комп'ютерна школа Hillel

37.

Принципи Agile
5
6
7
8
Представники бізнесу
та команда розробки повинні працювати разом над
проектом
Успішні проекти будуються мотивованими людьми
Дайте їм відповідне довкілля, забезпечте всім необхідним і
довірте зробити свою роботу
Найефективніший метод
взаємодії та обміну інформацією – це особиста розмова
Робоче програмне забезпечення
головний захід прогресу проекту
© 2022 Комп'ютерна школа Hillel

38.

Принципи Agile
9
10
11
12
Постійна увага
до технічної досконалості та якісної архітектури сприяють
гнучкості.
Простота необхідна
як мистецтво максимізації роботи, яку слід робити.
Найкраща архітектура
Вимоги та дизайн створюється в командах, що
самоорганізуються.
Команда постійно шукає способи стати ефективнішою.
шляхом налаштування та адаптації своїх процесів.
© 2022 Комп'ютерна школа Hillel

39.

40.

Scrum
Scrum — легкий фреймворк, який допомагає людям,
командам та організаціям створювати цінність за
допомогою адаптивних розв'язків комплексних проблем.
Scrum заснований на емпіризмі та ощадливому мисленні.
Емпіризм стверджує, що джерелом знань є досвід, а
прийняття рішень ґрунтується на спостереженнях.
Ощадливе мислення скорочує втрати та фокусується на
головному.
Scrum використовує ітеративний, інкрементальний підхід
для оптимізації передбачуваності та управління
ризиками. Scrum залучає групи людей, які в сукупності
мають всі навички та досвід для виконання роботи, і в
міру необхідності діляться знаннями і набувають
потрібних навичок.
© 2022 Комп'ютерна школа Hillel

41.

Daily scrum
Product Backlog
Scrum Master
Product Owner
24 H
Sprint Planning
Meeting
Team
1-4
WEEKS
Sprint Review
Sprint
Retrospective
Sprint Backlog
Finished Work
© 2022 Комп'ютерна школа Hillel

42.

43.

Обов’язки
Product owner
Власник продукту відповідає за максимізацію
цінності продукту, одержуваного в результаті
роботи Scrum Team. Способи досягнення
максимальної цінності можуть бути різними і
залежать від організацій, Scrum Teams і
конкретних людей.
Розробляє та точно комунікує Product Goal
Створює та чітко пояснює елементи
Product Backlog
Впорядковує елементи Product Backlog
Забезпечує прозорість, доступність та
розуміння Product Backlog
© 2022 Комп'ютерна школа Hillel

44.

Обов’язки
Scrum master
Scrum master несе відповідальність за
застосування Scrum відповідно до посібника.
Допомагає всім зрозуміти теорію та практики
Scrum як усередині Scrum Team, так і в
організації. Scrum Master відповідає за
ефективність команди.
навчає учасників команди щодо
самоврядування
допомагає Scrum Team фокусуватися на
створенні Інкременту
сприяє усуненню перешкод, що заважають
прогресу команди
переконується в тому, що всі події Scrum
відбуваються, що вони позитивні,
продуктивні і не виходять за межі обмежень
часу.
направляє, навчає організацію у застосуванні
Scrum
усуває бар'єри між зацікавленими особами та
командою
© 2022 Комп'ютерна школа Hillel

45.

Характеристика
Scrum team
Scrum команда - невелика команда людей, яка
складається з одного Scrum Master, одного
Product Owner та Developers. Усередині Scrum
Team немає підкоманд та ієрархій. Це згуртоване
поєднання професіоналів, у будь-який момент
часу сфокусованих на одній меті – Product Goal.
Scrum Team крос-функціональна, тобто
учасники мають всі навички, необхідні для
створення цінності в кожному Sprint. Також
вони самоврядні, тобто самі вирішують хто,
що, коли і як робить.
Scrum Team досить маленька, щоб
залишатися моторною, і досить велика, щоб
виконувати значну роботу протягом Sprint —
зазвичай складається не більше ніж з 10 осіб.
Вся команда несе відповідальність за
створення цінного, корисного Increment у
кожному Sprint.
© 2022 Комп'ютерна школа Hillel

46.

47.

Product backlog
Product Backlog — це впорядкований та
постійно оновлюваний список того, що
необхідно для покращення продукту. Це єдине
джерело роботи, яку виконує Scrum Team
© 2022 Комп'ютерна школа Hillel

48.

Як правильно формується User story
Acceptance criteria
Студент повинен
володіти теорією
тестування
Студент повинен вміти
працювати з API
Студент має вміти
писати тестову
документацію
© 2022 Комп'ютерна школа Hillel

49.

INVEST
I
Independent - незалежна, щоб не блокувати один одного
N
Negotiable - хороша історія, яка відображає суть, а не деталі
V
Valuable - цінна, значуща
E
Estimable - можна оцінити
S
Small - невелика, Декомпозувати
T
Testable - Зрозуміла для написання тестів з неї
© 2022 Комп'ютерна школа Hillel

50.

Як правильно формується User story
Definition of ready
Definition of done
Надання всіх необхідних вимог
Розуміння командою, що вони
5 і як
повинні робити
Розповсюдження всіх змін для
всіх stakeholders
Тести написані та пройдені
Усі документації оновлено
Юніт тести написані
Усі acceptance criteria
досягнуті
© 2022 Комп'ютерна школа Hillel

51.

Sprint backlog
Sprint backlog — частина беклогу продукту з
найвищою важливістю та сумарною оцінкою, що не
перевищує швидкість команди, відібраної для спринту
© 2022 Комп'ютерна школа Hillel

52.

Increment
Increment — це конкретна сходинка для
досягнення Product Goal. Кожен Increment є
доповненням до всіх попередніх. Вони ретельно
перевіряються для забезпечення спільної роботи
всіх Increments. Щоб надати цінність, Increment
має бути придатним для використання.
© 2022 Комп'ютерна школа Hillel

53.

54.

Обговорюємо
Sprint planning
Планування спринту – планування роботи, яку
необхідно виконати у цьому Sprint. Результатом
події стає sprint backlog, створений спільними
зусиллями всією командою.
Яка основна мета спринту?
Що може бути готове в цьому спринті?
Як виконуватиметься обрана робота?
© 2022 Комп'ютерна школа Hillel

55.

Planning poker
Покер планування (Planning Poker) - техніка
оцінки, заснована на досягненні домовленості,
що головним чином використовується для
оцінки складності майбутньої роботи або
відносного обсягу розв'язуваних завдань при
розробці ПЗ.
© 2022 Комп'ютерна школа Hillel

56.

Story point
Story Point — це метрика, що використовується
в Scrum для оцінки складності реалізації user
story, яка є абстрактною і є зусиллями,
необхідними для реалізації оцінюваної user story.
© 2022 Комп'ютерна школа Hillel

57.

В ході sprint
Sprint
Sprint - у Scrum ітерація називається Sprint.
Результатом Sprint є готовий продукт (build),
який можна передавати (deliver) замовнику
(принаймні система має бути готова до показу
замовнику).
не вносяться зміни, які можуть
загрожувати Sprint Goal. В ідеальному
світі!)
Ця подія фіксованої тривалості трохи більше
місяця для забезпечення узгодженості. Новий
Sprint починається одразу після завершення
попереднього.
© 2022 Комп'ютерна школа Hillel

58.

Що робимо?
Daily Scrum
Daily scrum — збори членів команди для
синхронізації діяльності команди та позначення
проблем.
Що було зроблено з попереднього скраммітингу?
Які проблеми?
Що буде зроблено до наступного
скромного мітингу?
© 2022 Комп'ютерна школа Hillel

59.

Sprint review
Sprint review — показ власнику товару
працюючого функціоналу товару, зробленого за
спринт. Основне завдання проведення огляду
спринту полягає у отриманні зворотного зв'язку.
© 2022 Комп'ютерна школа Hillel

60.

Що обговорюємо?
Retrospective
Retrospective — заплановане підвищення якості
та ефективності
Що було зроблено добре?
Що можна покращити?
Які покращення робитимемо?
© 2022 Комп'ютерна школа Hillel

61.

62.

63.

64.

Практики в Kanban
1
Візуалізація процесу
Візуалізація майбутньої роботи за допомогою каталожних
карток або стікерів на стіні або на електронній дошці
2
Обмежити work in progress (WIP)
Встановлення лімітів (WIP) на кожному етапі процесу гарантує, що проблеми з робочим
процесом буде видно на дошці — вузькі місця та невикористані ресурси стануть
3
4
очевидними.
Управління процесом
Мета – зробити потік роботи рівномірним та передбачуваним, сфокусувати
вас на результаті, а не на утилізації ресурсів.
Зробіть правила явними
Четверта базова практика свідчить про важливість використання явних правил у роботі.
Ціль – зробити прозорими домовленості, знизити залежність від людського фактора.
© 2022 Комп'ютерна школа Hillel

65.

Практики в Kanban
4
Зворотній зв'язок
Більш відомо, як зустрічі в Канбані. Мета – отримати інформацію про показники системи
та результати скоєних раніше дій, спланувати наступні експерименти та замкнути петлю
5
4
зворотного зв'язку
Поліпшення
Основні практики Канбана заохочують безперервні, поступові зміни у
пошуках поліпшень, які збільшуються у масштабі та впливу у міру того, як
команда та організація набувають впевненості.
© 2022 Комп'ютерна школа Hillel

66.

Метрики в Kanban
• Cycle Time — час, який завдання перебувало в розробці від моменту, коли їй почали
займатися, до моменту, коли вона пройшла фазу кінцевого постачання.
• Lead Time — час від появи завдання до кінцевої поставки. Включає Cycle Time та час
очікування у черзі на реалізацію
• Wasted Time — час, який завдання проводить у різних чергах, а не безпосередньо у роботі.
• Effectiveness — відсоток часу, який витрачається безпосередньо на роботу із завданням, а не
на очікування у різних чергах.
• Work In Progress (WiP) — кількість завдань, що одночасно перебувають у роботі.
Поділяється на різні стадії роботи над завданням.
© 2022 Комп'ютерна школа Hillel

67.

68.

1
У Канбан немає таймбоксів ні на що
У Канбан завдання більше та їх менше
2
3
У Scrum основна орієнтація команди – це
успішне виконання спринтів, у Kanban на
першому місці завдання
© 2022 Комп'ютерна школа Hillel

69.

70.

Мінуси Kanban
Нестабільний перелік завдань
Примітивне планування
Підвищене навантаження на
менеджмент
© 2022 Комп'ютерна школа Hillel

71.

Висновки
Всі підходи зі своїми плюсами та мінусами,
кожен з яких чудово підходить для
застосування в проектах з абсолютно
різними вхідними даними та вимогами.
Як для QA engineer, нам необхідно
інтегрувати тестування в ЖЦПЗ як на ранніх
стадіях, починаючи з статичного
тестування, так і на стадії підтримки ПЗ
після його випуску.

72.

English Русский Rules