Методологія інженерії

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

Тема 2. Методологія розробки програмного

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

 Швидка розробка прикладних програм (RAD – Rapid Application Development)

 Гнучкі методології розробки (Agile methodology)
 XP
 DSDM
 FDD
 Scrum
 Kanban
 Crystal Family
 Полегшені методології (Lightweight methodologies)
 AUP

Слайд 2
Швидка розробка прикладних програм (RAD)

Швидка розробка додатків (Rapid Application

Development) полягає в ітеративній розробці та
швидкій побудові прототипів, замість великої фази
попереднього планування. "Планування" програмного
забезпечення, розробленого з використанням RAD
проходить разом зі створенням самого програмного
забезпечення. Відсутність великих фаз планування і
дизайну дозволяє швидше створювати ПЗ і змінювати
вимоги до нього.

Швидкий процес розробки додатків починається з розробки попередніх моделей даних

і моделей бізнес-процесів з використанням структурованих методів. На наступному
етапі, вимоги перевіряються з використанням прототипів, і, в кінцевому рахунку, для
уточнення моделей даних і процесів. Ці етапи повторюються ітеративно.

Слайд 3
Швидка розробка прикладних програм (RAD)

Під RAD-розробкою зазвичай розуміється процес розробки, що містить 3 елементи:

 невелику команду програмістів (до 10 осіб);
 короткий, але ретельно пропрацьований виробничий графік (від 2 до 6 місяців);
 повторюваний цикл, при якому розробники в міру того, як додаток починає
набувати форму, реалізують в продукті вимоги, отримані через взаємодію з
замовником.

Слайд 4
Методологія RAD передбачає використання у кожній ітерації:
• CASE-засобів для формування вимог, проєктування системи, автоматичної генерації
коду програм і структури БД, а також автоматичного тестування ПЗ;
• інструментальних засобів, що забезпечують візуальну розробку (програмування)
системи. Середовище розробки додатків дозволяє без написання коду програми
створювати складні графічні інтерфейси користувача, склад і структуру БД, запити
до БД, а також пов'язувати дані з елементами інтерфейсу (перемикачами, полями
введення, таблицями і т. Д.);
• інструментальних засобів, що підтримують об'єктно-орієнтований підхід. Ці засоби
дозволяють створити опис предметної області у вигляді сукупності об'єктів -
сутностей реального світу, характеризуються властивостями (атрибутами) і
поведінкою (методами);
• інструментальних засобів, що забезпечують подієве програмування. Кожен об'єкт,
що входить до складу програми, може генерувати події і реагувати на події, що
генеруються іншими об'єктами;
• шаблонів і бібліотек готових рішень як власної розробки, так і сторонніх виробників.

Слайд 5
Умови застосування RAD:
• може бути застосована для відносно невеликих проєктів, що розробляються для
конкретного замовника;
• непридатна для побудови складних розрахункових програм, операційних систем
або програм управління космічними кораблями, тобто програм, що вимагають
написання великого обсягу (сотні тисяч рядків) унікального коду;
• непридатна для розробки додатків, в яких відсутня яскраво виражена
інтерфейсна частина, що наочно визначає логіку роботи системи (наприклад,
додатки реального часу);
• непридатна для розробки додатків, від яких залежить безпека людей (наприклад,
керування літаком або атомною електростанцією), оскільки ітеративний підхід
припускає, що перші кілька версій, швидше за все не будуть повністю
працездатні.

Слайд 6
Методології гнучкої розробки Аgile
• Гнучка методологія розробки (Agile software development, agile-методи) —
серія підходів до розробки програмного забезпечення, орієнтованих на
використання ітеративної розробки, динамічне формування вимог і забезпечення їх
реалізації в результаті постійної взаємодії у межах самоорганізованих робочих
груп, що складаються з фахівців різного профілю (self-organized cross-functional
teams).
• Agile передбачає адаптивне планування, еволюційний розвиток, ранні поставки
продукту, а також постійне вдосконалення, швидку і гнучку реакцію на зміни.
• Основною метрикою agile-методів є робочий продукт. Віддаючи перевагу
безпосередньому спілкуванню, agile-методи зменшують обсяг письмової
документації в порівнянні з іншими методами. Це призвело до критики цих методів
як «недисциплінованих».

Слайд 7
Основні принципи Agile

 Люди та їх взаємодія важливіше, ніж процеси та інструменти;

 Готовий продукт важливіше, ніж його документація;
 Співпраця із замовником важливіше жорстких контрактних
обмежень;
 Реакція на зміни важливіша, ніж дотримання плану.

Слайд 8
Принципи Аgile

Слайд 9
Принципи Аgile
1. Найвищий пріоритет - це задоволення замовника за допомогою частих і безперервних
постачань цінного для нього продукту.
2. Зміни вимог приймаються навіть на пізніх етапах реалізації проєкту. Гнучкі процеси
вітають зміни, що є конкурентною перевагою для замовника.
3. Постачати повністю робоче програмне забезпечення кожні кілька тижнів, у крайньому
випадку, кожні кілька місяців. Чим частіше, тим краще.
4. Представники бізнесу і команда розробки повинні працювати разом над проєктом.
5. Успішні проєкти реалізуються мотивованими людьми. Дайте їм відповідне навколишнє
середовище, забезпечте всім необхідним і довірте зробити свою роботу.
6. Найефективніший метод взаємодії та обміну інформацією - це особиста бесіда.

Слайд 10
Принципи Аgile

7. Працездатне програмне забезпечення - головна міра прогресу проєкту.

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

* Повний текст на http://agilemanifesto.org.

Слайд 11
 Автори Agile Manifesto
У лютому 2001 року 17 фахівців в містечку Snowbird в штаті Юта зібралися, щоб обговорити
полегшені методики розробки. В результаті був створений документ «Маніфест гнучких методологій
розробки».
Кент Бек (TDD, XP, JUnit)
Майк Бідл (e-Architects Inc., «Scrum, Agile Software Development»)
Ейри ван Беннекум (RAD & DSDM)
Алістер Кокбьорн (Crystal methodologies).
Уорд Каннінгем (Cunningham & Cunningham, Inc, розвиток ООП, XP, концепція вікі)
Джеймс Греннінг (Agile methodologies process coach, «Test Driven Development for Embedded C»)
Стівен Меллор (співавтор методу ООАП Шлаєра-Меллора, працював над UML в Object Management Group)
Мартін Фаулер (Thoughtworks Inc., автор багатьох робіт з паттернів проєктування, рефакторингу та ін.
Джим Хайсміт (Adaptive Software Development)
Ендрю Хант (співавтор книги «Pragmatic Programmer: From Journeyman to Master» та ін.)
Рон Джеффріс (XProgramming.com, співавтор книги «Extreme Programming Installed»)
Джон Кьорн - євангеліст ООП з початку 90-х рр.
Брайан Мерік (дослідження процесів тестування ПЗ в гнучких методологіях розробки)
Роберт Мартін (Object Mentor Inc., співавтор книг з програмування та розробки ПЗ)
Кен Швабер ( Advanced Development Methods Inc., SCRUM, «Scrum, Agile Software Development»)
Джефф Сазерленд ( SCRUM).
Дейв Томас («The Pragmatic Programmer»)
Слайд 12
Методології Аgile
 Adaptive software development (ASD)
 Agile modeling
 Agile Unified Process (AUP)
 Crystal Clear methods
 Disciplined agile delivery
 Dynamic systems development method (DSDM)
 Extreme programming (XP)
 Feature-driven development (FDD)
 Lean software development
 Kanban
 Scrum
 Scrumban
Слайд 13
Dynamic systems development method (DSDM)
 Метод розробки динамічних систем - методологія розробки програмного забезпечення,
заснована на RAD (швидкій розробці прикладних програм).

 Мета методології - здати готовий проєкт вчасно і вкластися в бюджет. У той же час,
регулюючи зміни вимог до проєкту під час його розробки, DSDM є однією з гнучких
методологій розробки програмного забезпечення, а також розробок, які не входять до
сфери інформаційних технологій.

 Консорціум DSDM був створений в 1994 році конкуруючими компаніями (British

Airways, American Express, Oracle and Logica і ін.) Універсальний метод був
сформульований на основі досвіду організацій, різних за своєю діяльністю і
масштабами.

 Остання версія - DSDM Atern (2007). Найбільш популярна DSDM 4.2 (2003), яка
містить інструкцію, як використовувати DSDM разом з XP

Слайд 14
Передумови використання DSDM
 Повинна бути організована взаємодія між проєктною командою, майбутніми
користувачами та керівництвом.
 Повинна бути можливість розбиття проєкту на менші частини, що дозволить
використовувати ітеративний підхід.
 DSDM не може бути використана в проєктах, критичних з безпеки (розширене
тестування та затвердження в таких проєктах конфліктують з метою методу
DSDM укластися в терміни і в бюджет); а також до проєктів, метою яких є
зробити компоненти багаторазового використання (вимоги в таких проєктах
дуже високі).

Слайд 15
Основні принципи DSDM
 Фокус на потреби замовника / користувачів (Focus on the business need)
 Доставка продукту вчасно (Deliver on time)
 Співпраця з усіма учасниками проєкту (Collaborate)
 Тестування інтегровано в життєвий цикл проєкту (Never compromise quality)
 Інкрементна розробка (Build incrementally from firm foundations)
 Ітеративна розробка (Develop iteratively)
 Взаємодія з замовником / користувачами (Communicate continuously and clearly)
 Команда повинна бути уповноважена приймати важливі для проєкту рішення
без узгодження з вищим керівництвом (Demonstrate control)

Слайд 16
Фази проєкту DSDM

Слайд 17
Фази проєкту DSDM

 Передпроєктна
 Життєвий цикл проєкту
 Післяпроєктна

Слайд 18
Перепроєктна фаза DSDM

 Передпроєктна фаза - визначаються ймовірні проєкти, відбувається виділення

коштів і визначення проєктної команди. Рішення задач на цій стадії допоможе
уникнути проблем на більш пізніх стадіях проєкту.

Слайд 19
Життєвий цикл проєкту DSDM
 Дослідження
 Дослідження того, що проєкт може бути реалізований
 Дослідження економічної доцільності
 Створення функціональної моделі
 Визначення функціонального прототипу
 Узгодження планів
 Створення функціонального прототипу
 Аналіз функціонального прототипу
 Проєктування і розробка
 Визначення конструктивного прототипу
 Узгодження планів
 Створення конструктивного прототипу
 Аналіз конструктивного прототипу
 Реалізація
 Затвердження системи користувачем
 Навчання користувачів
 Передача користувачам (Operational handover)
 Аналіз ринку системи
Слайд 20
Постпроєктна фаза DSDM
 На цій стадії забезпечується ефективна робота системи. Це досягається за
рахунок підтримки проєкту, його поліпшення і виправлення помилок відповідно
до принципів DSDM. Підтримка проєкту здійснюється шляхом продовження
розробки, заснованої на ітеративній та інкрементній природі DSDM. Замість того,
щоб закінчити проєкт за один цикл, зазвичай повертаються до попередніх стадій
або етапів для того, щоб поліпшити продукт.

Слайд 21
Життєвий цикл проєкту DSDM

Слайд 22
Методики DSDM - 1
 Тайм-боксинг.
• Основна ідея - розділити весь проєкт на частини, кожна зі своїм бюджетом і
термінами виконання.
• Для кожної такої частини вибираються вимоги, які були розподілені за принципом
MoSCoW. Єдине, що можна змінити, - це вимоги (вимоги з найменшим пріоритетом
ігноруються).
• Принцип 80% / 20%.

 MoSCoW
• MUST – вимога ПОВИННА бути реалізована
• SHOULD – СЛІД виконати цю вимогу, якщо від цього залежить успіх проєкту
• COULD – МОЖЛИВО реалізувати цю вимогу, якщо вона не впливає на строки/ціну
проєкту
• WILL NOT – учасники проєкту домовились не реалізовувати цю вимогу, можливо
реалізувати в майбутньому.

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

Слайд 23
Методики DSDM - 2
 Тестування
• Проведення тестування на кожній ітерації
• Команда проєкту сама обирає процес тестування

 Робоча група
• Всі учасники проєкту збираються для обговорення вимог, функціональності
та ін.

 Моделювання
• Є обов’язковим
• Візуалізація у вигляді діаграм окремих частин системи або сфери
діяльності, над якими йде робота

 Управління конфігурацією (SCM)

• Строгий контроль версій продукту та процесу його розгортання

Слайд 24
Ролі DSDM
 Виконавчий спонсор / продюсер або Чемпіон проєкту (Executive Sponsor /
"Project Champion")
 Провидець (Visionary)
 Представник користувача (Ambassador User)
 Користувач-консультант (Advisor User)
 Менеджер проєкту (Project Manager)
 Технічний координатор (Technical Co-ordinator)
 Лідер команди (Team Lead)
 Розробник (Solution Developer)
 Тестувальник (Solution Tester)
 Секретар (Scribe)
 Посередник (Facilitator)
 Інші ролі: Бізнес-архітектор (Business Architect), менеджер з якості (Quality
Manager), фахівець з системної інтеграції (System Integrator) і т.д.
Слайд 25
Відмінності DSDM
 забезпечує незалежну від інструментів і техніки середу розробки (tool and
technique independent framework)
 змінні в проєкті - вимоги, а не час або ресурси
 акцент на комунікації

Слайд 26
SCRUM
 ітеративна та інкрементна методологія гнучкої розробки ПЗ;
 акцент на контролі якості процесу розробки;
 може використовуватися в роботі команд з підтримки ПЗ (Scrum of Scrums).

Слайд 27
Історія SCRUM
 Підхід вперше описали Гіротака Такеучі і Ікуджіро Нонака в статті The New
Product Development Game (Гарвардський Діловий Огляд, січень-лютий 1986).
Вони відзначили, що проєкти, над якими працюють невеликі, крос-функціональні
команди, зазвичай систематично проводять кращі результати, і пояснили це як
«підхід регбі».

Слайд 28
Історія SCRUM - 2

 На початку 1990-х Кен Швабер використовував Advanced Development Methods,

що згодом стане процесом Scrum в його компанії; в той час як Джефф
Сазерленд, Джон Скудіоталес і Джефф МакКенна розробили аналогічний підхід в
Easel Corporation, посилаючись на нього, використовуючи одне слово Scrum.
 У 1995 році Сазерленд і Швабер спільно представили документ, що описує
методологію Scrum на семінарі з проєктування та реалізації бізнес-об'єктів, який
був проведений в рамках конференції «Об'єктно-орієнтоване програмування,
системи, мови і додатки '95» (OOPSLA '95) в Остіні , штат Техас. У наступні роки
Швабер і Сазерленд співпрацювали, щоб об'єднати цей матеріал зі своїм
досвідом і практиками - розробити те, що стало відомо як Scrum.

Слайд 29
Основні визначення SCRUM
SCRUM - набір принципів, на яких будується процес розробки, що дозволяє в
жорстко фіксовані і невеликі за часом ітерації, звані спринти (sprints), надавати
кінцевому користувачеві працююче ПЗ з новими можливостями, для яких визначено
найбільший пріоритет.
Можливості ПЗ, які можуть бути реалізовані в черговому спринті, визначаються
на початку спринту на етапі планування і не можуть змінюватися до його кінця. При
цьому, строго фіксована невелика тривалість спринту надає процесу розробки
передбачуваність і гнучкість.

Слайд 30
Основні визначення SCRUM
 Scrum використовують не тільки для розробки ПЗ, він відмінно підходить для
багатьох процесів для створенню продукту: від венчурних до маркетингових
продуктів.

 Scrum вважається не методологією, а гнучким управлінським середовищем

розробки.

 Scrum зазвичай доповнюють інженерними практиками з інших гнучких

методологій (наприклад, практики розробки з екстремального програмування,
або практики аналізу і збору вимог з ICONIX).

Слайд 31
Основні елементи SCRUM

Ролі Артефакти Процеси

• Планування
• Володар • Беклог продукту спринта
продукту • Беклог спринта • Огляд спринта
• Скрам-майстер • Інкремент • Ретроспектива
• Команда продукту
• Скрам-зустріч

Слайд 32
Ролі в SCRUM
Product Owner - власник продукту являє собою зацікавлену сторону проєкту
(project stakeholders) та голос клієнта (voice of the customer); і несе
відповідальність за забезпечення того, щоб команда приносила користь бізнесу.

 визначає продукт в термінах, орієнтованих на клієнта (як правило, user stories),

додає їх в беклог продукту і розставляє їм пріоритети;
 команди Scrum повинні мати одного Власника продукту;
 ця роль не повинна поєднуватися з роллю Скрам-майстра;
 Власник продукту повинен зосередитися на бізнес-стороні розробки продукту і
витрачати більшу частину свого часу на зв'язок із зацікавленими сторонами і не
повинен диктувати технічні рішення команді;
 роль еквівалентна ролі представника клієнта в деяких інших процесах Agile,
таких як екстремальне програмування (XP).

Слайд 33
Ролі в SCRUM - 2
Оскільки Власник продукту є обличчям команди розробників, перед ним стоять такі
завдання комунікації:
 демонструє рішення ключовим зацікавленим сторонам, які не були присутні при
огляді спринту;
 визначає і оголошує про релізи;
 повідомляє статус команди;
 організовує огляд віх проєкту (project milestones);
 навчає зацікавлених сторін в процесі розробки;
 погоджує пріоритети, обсяг, фінансування та графік;
 гарантує, що беклог продукту буде наочним, прозорим і зрозумілим.
Емпатія - це ключова якість, яким повинен бути наділений Власник продукту (ability
to put one's self in another's shoes).
Здатність до ефективної взаємодії з Власником продукту також підвищується за
рахунок того, що він володіє певними навичками в методах визначення потреб
зацікавлених сторін, обговорює пріоритети між зацікавленими сторонами і
співпрацює з розробниками для забезпечення ефективного виконання вимог.

Слайд 34
Ролі в SCRUM - 3
Команда розробників несе відповідальність за доставку додаткової
функціональності продукту у кінці кожного спринта.
 Команда складається з 3-9 розробників, які виконують фактичну роботу (аналіз,
дизайн, розробка, тестування, технічна документація і т. Д.).
 Групи розробників є багатофункціональними, з усіма навичками, необхідними для
нарощування функціональності продукту.
 Команда розробників в Scrum є самоорганізованою (self-organizing), при цьому
може бути взаємодія з іншими ролями поза командою, наприклад, офісом
управління проєктами (PMO).

Слайд 35
Ролі в SCRUM - 4
Скрам-майстер несе відповідальність за усунення перешкод для здатності команди
доставляти цілі продукту і результати.
 не є традиційним керівником команди або менеджером проєкту, але діє як буфер
між командою і будь-якими зовнішніми процесами
 забезпечує дотримання рамок процесу Scrum
 допомагає забезпечити дотримання узгоджених процесів в рамках Scrum
 часто бере лідерство в проведенні ключових нарад
 заохочує спроби поліпшення роботи команди
 ця роль також згадується як координатор команди або servant-leader

Слайд 36
Ролі в SCRUM - 4

Слайд 37
Ролі в SCRUM - 4
Scrum Master обслуговує (serves) команду кількома способами, включаючи:
 навчання членів команди самостійному управлінню та крос-функціональності;
 допомагаючи команді зосередитися на створенні приростів функціональності,
які відповідають Definitions of Done;
 усуваючи перешкоди для прогресу команди;
 забезпечуючи те, щоб усі події Scrum відбувалися і були позитивними,
продуктивними та зберігалися в межах часового проміжку.

Слайд 38
Ролі в SCRUM - 4
Scrum Master обслуговує (serves) Власника продукту:
 допомогаючи в пошуках методів ефективного визначення цілей продукту та
управління беклогом;
 допомагаючи команді зрозуміти необхідність чітких і лаконічних елементів
беклогу;
 допомогаючи в створенні плану продукту;
 сприяючи співпраці зацікавлених сторін за потреби.

Слайд 39
Ролі в SCRUM - 4
Scrum Master обслуговує (serves) організацію таким чином:
 впроваджуючи керівництво, навчання та тренінг організації у її прийнятті
Scrum;
 консультуючи щодо впровадження Scrum в організації;
 допомогаючи працівникам та зацікавленим сторонам зрозуміти та впровадити
підхід до складної роботи на основі емпіричних даних;
 Усуваючи бар'єри між зацікавленими сторонами та командами Scrum.

Слайд 40
Ролі в SCRUM - 5
 «Свині» (Committed people)
 Власник продукту (Product Owner)
 Команда розробників (Development Team)
 Скрам-майстер (Scrum Master)
 «Кури» (Involved people)
 Користувачі (Users)
 Клієнти, продавці та ін. (Stakeholders)
 Експерти-консультанти (Consulting Experts)

Свиня йде по дорозі. Курка дивиться на неї і каже: «А давай відкриємо ресторан!»
Свиня дивиться на курку і відповідає: «Хороша ідея, і як ти хочеш його назвати?» Курка
думає і говорить: «Чому б не назвати " Яєчня з беконом "?» . «Так не піде, - відповідає
свиня, - адже тоді мені доведеться повністю присвятити себе проєкту (committed), а ти
будеш залучена тільки частково (involved)».

Слайд 41
Основні артефакти SCRUM
Спринт - ітерація в SCRUM, в ході якої реалізується функціональний приріст ПЗ.
Жорстко фіксований за часом (2 - 4 тижні). В окремих випадках, тривалість
спринту повинна бути не більше 6 тижнів.

 Вважається, що чим коротше спринт, тим більш гнучким є процес розробки,

релізи виходять частіше, швидше надходять відгуки споживача, менше часу
витрачається на роботу в неправильному напрямку. З іншого боку, при більш
тривалих спринтах, у команди є більше часу на вирішення виниклих в процесі
проблем, а власник проєкту зменшує витрати на наради, демонстрації продукту і
т.п.
 Різні команди підбирають довжину спринта відповідно до специфіки своєї роботи,
склад команд і вимог. Для оцінки обсягу робіт в спринті можна використовувати
попередню оцінку, яка базується на історичних даних. Попередня оцінка
фіксується в «беклозі проєкту / продукту» (project / product backlog).

Слайд 42
Основні артефакти SCRUM

Project backlog (журнал побажань проєкту) - це список вимог, які підлягають

реалізації, упорядкований за їх пріоритетами. Елементи цього списку називаються
користувацькими історіями (user stories) або елементами журналу (backlog items).
Журнал побажань проєкту відкритий для редагування для всіх учасників SCRUM-
процесу.

Слайд 43
Основні артефакти SCRUM
Історії користувача звичайно включають:
 Унікальний числовий ідентифікатор історії
 Назву історії користувача – короткий (приблизно до 10 слів) опис
функціоналу з точки зору користувача, сформульований у вигляді трійки «Роль»,
«Дія», «Мета». Наприклад: «Користувач вводить логін і пароль для того, щоб
авторизуватися на сайті».
 Пріорітет – унікальний числовий пріоритет історії користувача, чим він вища,
тим раніше дану історію необхідно зробити.
 Оцінка – числова відносна оцінка історії користувача за спеціальною шкалою.

Зазначені поля зручно розміщувати на стікері, який прикріплюється на дошку.

Слайд 44
Storymapping
Після того, як визначені користувацькі історії та ресурси, необхідно перейти до
виявлення функціоналу, який необхідно реалізувати для конкретної людини. Для
цього використовується сторімаппінг ( «story mapping») - спосіб візуалізації і
планування функціоналу.
Візуалізація відбувається на дошці і починається з високорівневих активностей
виявлених ресурсів. Активності розбиваються на завдання, які, в свою чергу,
розбиваються на підзадачі.
Верхній шар підзадач є простою можливою реалізацією функціоналу і зазвичай
включається в перший реліз. Підзадачі, які знаходяться нижче, представляють
собою реалізацію:
 додаткових можливостей;
 безпеки;
 зручності використання;
 продуктивності.
Чим нижче ми спускаємося по підзадачам, тим менший вони мають пріорітет.

Слайд 45
Storymapping

Слайд 46
Основні артефакти SCRUM

Sprint backlog - (журнал побажань спринту)

- містить функціональність (backlog items),
обрану Власником Продукту (Product Owner) з
журналу побажань проєкту. Всі функції
розбиті за задачами, кожна з яких оцінюється
скрам-командою. Кожен день команда оцінює
обсяг роботи, який потрібно виконати для
завершення спринту.
Протягом цього періоду ніхто не має права
змінювати перелік запитів на виконання робіт.

Слайд 47
Розмір беклогу в SCRUM
Для збереження керованості необхідно
підтримувати мінімальний розмір беклога,
але для стратегічного планування, скажімо,
на кілька кварталів вперед, необхідно мати
досить довгий беклог.
Рекомендується використовувати метод
«набігаючої хвилі» ( «rolling wave planning»).
В рамках Scrum такий підхід означає, що
історії користувачів розбиваються дуже
докладно лише на кілька найближчих
спринтів, а решта історії користувачів -
зберігаються у вигляді великих шматків
функціональності і докладно не описуються.
Такі великі історії користувачів, які в
подальшому будуть розбиті на маленькі,
називаються «епіками» ( «epic»).

Слайд 48
Перегляд беклогу (grooming)
До причин зміни беклогу та його елементів можна віднести:
 Великі елементи вже можна розбити на кілька менших
 Критерії прийняття можуть бути уточнені
 Можуть бути виявлені та досліджені заележності
 Елемент може потребувати подальшого виявлення та аналізу
 Зміна пріоритетів.
Перегляд беклогу означає, що елементи належним чином підготовлені та
впорядковані таким чином, щоб вони були зрозумілими та виконуваними для
розробників при планування спринту.
Рекомендується закладати до 10% ємності спринту на перегляд беклогу. Більш
зрілі команди не сприйматимуть це як заплановану визначену подію, а як
спеціальну діяльність, яка є частиною природного робочого процесу, уточнюючи та
коригуючи беклог , якщо є така потреба.

Слайд 49
Перегляд беклогу (grooming)

Слайд 50
Основні артефакти SCRUM
Burndown chart (діаграма згоряння задач) - діаграма, що демонструє кількість
зробленої роботи, і тієї, що залишилася, щодо часу на розробку проєкту. Може
будуватися як для спринту, так і для проєкту.

Слайд 51
Діаграма згоряння з відставанням
На практиці діаграму згоряння можна використовувати з 3-го дня для вироблення
коригувальних дій.

Слайд 52
Діаграма згоряння з відставанням
Команда повинна на черговій щоденній нараді обговорити, чому йде відставання
від плану і виробити ряд контрзаходів. Найпоширеніші причини:
 Сильна помилка в плануванні;
 Хвороба або інша причина відсутності одного або декількох членів команди;
 Недооцінка і реалізація ризиків (зазвичай технічних).
Про відставанні необхідно максимально оперативно повідомити Власнику продукту,
якщо він не веде щоденний моніторинг діаграми згоряння. Якщо команда сама не
зможе виробити контрзаходи, необхідно, щоб власник продукту прибрав з спринту
одну або кілька історій користувача з мінімальним пріоритетом.

Слайд 53
Діаграма згоряння з випередженням
В цьому випадку необхідно в беклог спринту взяти одну або кілька додаткових історій
користувачів з вищим пріоритетом з тих, які не ввійшли в спринт.

Слайд 54
 Зустрічі (наради) SCRUM (SCRUM Meetings):
 Планування спринту (Sprint Planning Meeting)
 Щоденна нарада (Daily Scrum Meeting)
 Демонстрація (Sprint Review Meeting)
 Ретроспектива (Sprint Retrospective)

Слайд 55
Планування спринту (Sprint Planning Meeting)
 Проходить на початку нової ітерації.
 З product backlog вибираються задачі, зобов'язання щодо виконання яких
протягом спринту приймає на себе команда;
 На основі обраних задач створюється sprint backlog. Кожне завдання оцінюється
в ідеальних людино-годинах;
 Рішення задачі не повинно займати більше 12 годин або одного дня. При
необхідності завдання розбивається на підзадачі;
 Обговорюється і визначається, яким чином буде реалізовано цей обсяг робіт;
 Тривалість наради обмежена зверху 4-8 годинами в залежності від тривалості
ітерації, досвіду команди тощо;
 (перша частина наради) беруть участь Product Owner + Команда: вибирають
завдання з product backlog;
 (друга частина наради) бере участь тільки команда: обговорюють технічні
деталі реалізації, наповнюють sprint backlog

Слайд 56
Щоденна нарада (Daily SCRUM Meeting)
 починається точно вчасно;
 всі можуть спостерігати, але тільки «свині» говорять;
 триває не більше 15 хвилин;
 проводиться в одному і тому ж місці протягом спринту.
 протягом наради кожен член команди відповідає на 3 питання:
 що я зробив з моменту минулої зустрічі для того, щоб допомогти команді
досягти мети спринту?
 що я зроблю сьогодні для того, щоб допомогти команді досягти мети
спринту?
 Чи бачу я перешкоди для себе або команди, які могли б ускладнити
досягнення мети спринту? (Над вирішенням цих проблем працює Скрам
майстер. Зазвичай це рішення проходить за рамками щоденного наради і в
складі осіб, безпосередньо порушених даними перешкодою.)

Слайд 57
Огляд підсумків спринту (Sprint review meeting)
 Проводиться в кінці спринту.
 Команда демонструє приріст функціональності продукту всім зацікавленим
особам.
 Залучається максимальна кількість глядачів.
 _Всі_ члени команди беруть участь в демонстрації (одна людина на
демонстрацію або кожен показує, що зробив за спринт).
 Не можна демонструвати незавершену функціональність.
 Обмежена чотирма годинами в залежності від тривалості ітерації і приросту
функціональності продукту.

Слайд 58
Ретроспективна нарада (Retrospective meeting)
У довгостроковому плані ретроспективи (або скорочено «ретро») є найважливішою
практикою Scrum: саме вони дозволяють адаптувати і кастомізувати Scrum, роблячи
з нього по-справжньому гнучкий фреймворк для управління проєктами.
 Проводиться після огляду спринту через невелику кількість часу, щоб оперативно
отримати зворотній зв'язок. Скрам-майстер збирає всю команду для обговорення
результатів спринту. Рекомендується запрошувати Власника Продукту для отримання
додаткового зворотного зв'язку.
 Члени команди висловлюють свою думку про минулий спринт.
 Учасники відповідають на два основних питання:
 Що було зроблено добре в минулому спринті?
 Що треба поліпшити в наступному?
 Виконують поліпшення процесу розробки (вирішують питання і фіксують вдалі
рішення).
 Обмежена однією-трьома годинами (залежить від розміру команди, довжини спринту,
кількості проблем).

Слайд 59
SCRUM Framework

Слайд 60
Зворотній зв’язок в SCRUM

Слайд 61
Інші поняття Scrum
Визначення готовності (Definition of Ready, DoR)
Критерії запуску, щоб визначити, чи специфікації та вхідні дані встановлені
достатньо для початку роботи.

Визначення зробленого (Definition of Done, DoD)

Критерії виходу, щоб визначити, чи завершена робота над елементом затримки
спринту, наприклад: DoD вимагає, щоб усі регресійні тести були успішними.
Визначення зробленого може змінюватись від однієї команди до іншої, але має бути
послідовним у межах однієї команди.

Слайд 62
Інші поняття Scrum - 2
Спайк (Spike) - період, визначений часом, який використовується для дослідження
концепції або створення простого прототипу.
Спайки можна планувати як проміжні між спринтами, або, для більших команд,
спайк можна прийняти як одну з багатьох цілей доставки спринту.
Спайки часто вводяться перед доставкою великих або складних елементів беклогу
для того, щоб забезпечити бюджет, розширити знання або надати підтвердження
концепції. Тривалість та цілі спайку узгоджуються командою до початку.
На відміну від зобов’язань спринту, спайки можуть не забезпечити відчутну та цінну
функціональність.Наприклад, метою спайку може бути успішне прийняття рішення
про те, як діяти.

Слайд 63
Інші поняття Scrum - 3
Трасуюча куля (Tracer bullet) - також називається безпілотним спайком (drone
spike). Це спайк із поточною архітектурою, поточним набором технологій, поточним
набором кращих практик, які призводять до якісного виробничого коду (production
code).
Це може бути просто дуже вузька реалізація функціоналу, але це не одноразовий
код.
Це якісний код, і решта ітерацій можуть спиратися на цей код. Часто такі реалізації-
це «швидкий постріл» через усі шари програми, наприклад, підключення поля
введення однієї форми до внутрішнього сервера, щоб довести, що шари з'єднуються
належним чином.

Слайд 64
Нульовий спринт
 Розробляється бачення проєкту (project vision). Цей короткий документ описує,
що представляє собою продукт, хто, коли, як і де буде його аудиторією, основні
фази проєкту, бізнес-модель для монетизації і так далі. Для створення бачення
проєкту можна використовувати інноваційні ігри, різного роду мозкові штурми і
фреймворки.
 Виявлення ресурсів та їх активностей (аж до окремих користувацьких історій). Уже
традиційно дану активність Scrum-команди реалізують в вигляді сторімаппінга,
результатом якого стають дошки і цілі стіни з візуалізацією активностей в проєкті.
 Обов'язково треба запросити представників замовника на процеси з вироблення
бачення і сторімаппінг (а на останні збори ще потенційних користувачів).
 Вибір платформи для розробки і створення архітектури.
 Йде підготовка до першого спринту. Для цього необхідно описати історії
користувачів, спроєктувати для них інтерфейс і оцінити. Роботу найкраще
побудувати в такому порядку, так як він сприяє більш якісному розуміння вимог і
їх оцінці.

Слайд 65
Обмеження SCRUM
Труднощі виникають коли:
 члени команди географічно розсіяні або мають неповну зайнятість:
У Scrum розробники повинні мати тісну та постійну взаємодію, в ідеалі більшу частину
часу працювати разом в одному просторі. Хоча останні вдосконалення технологій
зменшили вплив цих бар’єрів, маніфест Agile стверджує, що найкраще спілкування віч -на
–віч.

 члени яких мають дуже спеціалізовані навички:

У Scrum розробники повинні володіти Т-подібними
навичками, що дозволяє їм працювати над завданнями
поза їх спеціалізацією. Цьому може сприяти хороше
керівництво Scrum. Незважаючи на те, що члени команди з
дуже специфічними навичками можуть і роблять свій
внесок, вони повинні заохочуватися дізнаватися більше
про інші дисципліни та співпрацювати з ними.

Слайд 66
Обмеження SCRUM
 В продуктах з багатьма зовнішніми залежностями
Зовнішні залежності, такі як перевірка прийняття користувачами або узгодження з іншими
командами, можуть призвести до затримок та збоїв окремих спринтів.

 При розробці продуктів, які є застарілими (legacy) або мають жорсткий контроль
якості
У Scrum інкременти продукту повинні бути повністю розроблені та протестовані протягом
одного спринту; продукти, які потребують великої кількості регресійних тестів або тестів
на безпеку (наприклад, медичні пристрої або засоби керування транспортними засобами)
для кожного релізу, менш підходять для коротких спринтів, ніж для більш тривалих
водоспадних релізів.

Слайд 67
Як продати Scrum замовнику?
Важливо пояснити замовнику (нехай спринти двотижневі), що він зможе:
 кожні два тижні отримувати новий функціонал, який можна спробувати і
випустити на ринок для заробітку грошей;
 кожні два тижні змінювати вимоги, щоб зміни в бізнесі відбивалися і в ПЗ;
 регулювати терміни і вартість робіт за проєктами за рахунок можливості зупинити
проєкт після будь-якого спринту.

Слайд 68
Як відобразити процес у контракті?
Найкращим варіантом буде укладення контракту типу «Час і матеріали» (Time
and Material, T & M), при якому замовник буде оплачувати вам вартість команди та
обумовлений відсоток. Перевагою такого виду договору є управління за термінами і
вартістю з боку замовника, але треба зауважити, що при такому підході і ризики
перекладаються на нього. При такому підході різко скорочується етап аналізу
проєкту, оскільки немає необхідності давати точну оцінку термінів і гарантувати її.
Традиційним є підхід щодо укладення контрактів з фіксованою вартістю (Fixed
price), який, здавалося б, переносить багато ризиків на виконавця. Насправді
виконавець намагається всі ці ризики закласти у вартість контракту. Цей підхід
важко назвати гнучким, оскільки обидві сторони намагаються перемогти один
одного, замість того, щоб шукати «win-win» рішення, засноване на взаємній довірі.

Слайд 69
Екстремальне програмування (XP)
Засноване на спіральній моделі. Основні принципи:
 Короткий цикл зворотного зв'язку (Fine-scale feedback)
 Розробка через тестування (Test-driven development)
 Гра в планування (Planning game)
 Замовник завжди поряд (Whole team, Onsite customer)
 Парне програмування (Pair programming)
 Неперервний, а не пакетний процес
 Безперервна інтеграція (Continuous integration)
 Рефакторинг (Design improvement, Refactoring)
 Часті невеликі релізи (Small releases)
 Розуміння для всіх
 Простота (Simple design)
 Метафора системи
 Колективне володіння кодом (Collective code ownership) або обраними шаблонами
проєктування (Collective patterns ownership)
 Стандарт кодування (Coding standard or Coding conventions)
 Соціальна захищеність програміста (Programmer welfare):
 40-годинний робочий тиждень (Sustainable pace, Forty-hour week)
Слайд 70
Екстремальне програмування (XP)

Слайд 71
Екстремальне програмування (XP)

Слайд 72
Розробка керована функціональністю (FDD)
Feature driven development (FDD) — ітеративна та інкрементна методологія
розробки програмного забезпечення, одна з гнучких методологій розробки (agile).
FDD являє собою спробу об'єднати найбільш визнані в індустрії розробки
програмного забезпечення методики, які засновані на важливій для замовника
функціональності (features) ПЗ. Основною метою даної методології є розробка
реального працюючого ПЗ систематично, у встановлені терміни.

Слайд 73
Історія FDD

FDD була запропонована Джеффом Де Люка для проєкту розробки програмного

забезпечення для одного сінгапурського банку (розрахованого на 15 місяців і 50
осіб) в 1997 р. Де Люка виділив набір з п'яти процесів, які охоплюють як розробку
загальної моделі, так і створення списку, планування, проєктування і реалізацію
елементів функціональності (features).
Перший опис FDD з'явилося в 1996 році в главі 6 книги Java Modeling in Color with
UML. У книзі A Practical Guide to Feature-Driven Development (2002 рік) опис було
узагальнено, процес звільнився від прив'язки до мови програмування.

Слайд 74
Фази FDD
 Розробка загальної моделі;
 Складання списку необхідних функцій (features) системи;
 Планування роботи над кожною функцією;
 Проєктування функції;
 Реалізація функції.

Слайд 75
Розробка загальної моделі (Develop an overall model)

Проєкт FDD починається з високорівневого наскрізного аналізу системи та її

контексту. Далі, детальні моделі предметної області створюються для кожної
області моделювання і надаються експертам для оцінки. Одна із запропонованих
моделей, або їх комбінації, вибираються для того, щоб стати моделлю для кожної
предметної області. Моделі предметних областей поступово об'єднуються в
загальну модель.

Слайд 76
Складання списку функций (Build a Feature List)

 Зібрана інформація при побудові загальної моделі використовується для

складання списку функцій.
 Це здійснюється розбивкою областей (domains) на предметні області (subject
areas) з точки зору функціональності. Кожна окрема предметна область
відповідає якомусь бізнес-процесу, кроки якого стають списком функцій (feature
list).
 В даному випадку функції - це маленькі частини, представлені у вигляді «<дію>
<результат> <об'єкт>», наприклад, «перевірка пароля користувача». Розробка
кожної функції повинна займати не більше 2 тижнів, інакше завдання необхідно
розбити на кілька підзадач, кожна з яких зможе бути завершена в двотижневий
термін.

Слайд 77
План по функціям (властивостям) (Plan by Feature)

 Складається план розробки програмного забезпечення

 Визначаються Class Owners: володіння класами розподіляється серед провідних
програмістів шляхом складання і організації властивостей (або наборів
властивостей) в класи.

Слайд 78
Проєктування функцій (Design by Feature)
Для кожної функції створюється проєктний пакет. Провідний програміст виділяє
невелику групу функцій для розробки протягом двох тижнів. Разом з розробниками
відповідного класу провідний програміст складає докладні діаграми послідовності
для кожної функції, уточнюючи загальну модель. Далі пишуться оболонки класів і
методів, і відбувається критичний розгляд дизайну.

Слайд 79
Реалізація функцій (Build by Feature)

Після успішного розгляду дизайну, видима клієнту функціональність

реалізується в стан готовності. Для кожного класу пишеться код. Після модульного
тестування кожного блоку і перевірки коду, завершена функція включається в
основний проєкт (build).

Слайд 80
FDD best practices
 Об'єктне моделювання області (Domain Object Modeling)
 Розробка функцій (Developing by Feature)
 Індивідуальна власність класів / коду (Individual Class (Code) Ownership)
 Команди з розробки функціональності (Feature Teams)
 Інспекції / Перевірка коду (Inspections / Code review)
 Управління конфігурацією (Configuration Management)
 Регулярні релізи / збірки (Regular Builds)
 Видимість прогресу і результату (Visibility of progress and results)

Слайд 81
Методології Сrystal (Сrystal Family methodologies)

 Методи Crystal є сімейство методологій, які були розроблені Алістером Кокберном

в середині 1990-х років.
 Дослідження Кокберна показали, що команди, які не дотримуються формальних
процесів, можуть успішно виконувати проєкти. Тому Кокберн спробував
каталогізувати ті практики, які використовували такі команди.
 Вважаються «легкими методологіями» (lightweight methodologies)

Слайд 82
Методології Сrystal фокусуються на :
 Людях (People)
 Взаємодії Interaction)
 Співтоваристві (Community)
 Навичках (Skills)
 Талантах (Talents)
 Зв'язках (Communications)

Слайд 83
Основні принципи методологій Сrystal -1
 Часті поставки (Frequent Delivery): Власник проєкту / клієнти можуть очікувати
від команд (и) результати раз в кілька місяців. На великих або важливих
проєктах, результати можуть не йти відразу в виробництво (production), але
зацікавлені сторони повинні бачити проміжні версії і бути в змозі забезпечити
зворотний зв'язок.

 Постійний зворотний зв'язок (Continual Feedback): Вся проєктна команда

збирається на регулярній основі для обговорення проєктних активностей (project
activities). Команда також зустрічається із зацікавленими сторонами (stakeholders)
на регулярній основі, щоб переконатися, що проєкт рухається в очікуваному
напрямку і повідомити про несподіванки, які можуть вплинути на проєкт.

 Постійний зв'язок (Constant Communication): Для малих проєктів вся команда

збирається в тій же кімнаті, в той час, як для великих проєктів, команда буде
збиратися в тій же установі. Очікується, що команда проєкту легко може
зв'язатися з людьми, що визначають основні вимоги.

Слайд 84
Основні принципи методологій Сrystal -2
 Безпека (Safety):
• безпечна зона розробки, тобто, члени команди повинні бути ефективними і
повідомляти правду в ході проєкту, не побоюючись «репресій»; це відповідає
більшості гнучких методологій;
• деякі програмні проєкти впливають на безпеку своїх кінцевих користувачів.
Наприклад, система управління шатлом набагато більш критична з питань безпеки,
ніж калькулятор.
 Фокус (Focus): члени команди повинні знати топ 2 або 3 пріоритетні задачі, над якими
працюють інші розробники. Повинен бути наданий час, щоб закінчити ці задачі без
будь-яких переривань (without interruption)
 Доступ до користувачів (Access to Users): проєктна команда має доступ до одного
або декількох користувачів реалізованої системи
 Автоматизовані тести та інтеграція (Automated Tests and Integration): Crystal має
можливості для верифікації функціональності проєкту. Повинні бути створені органи /
команди для підтримки управління версіями, автоматизованого тестування, а також
частої інтеграції компонентів системи
Слайд 85
Крючові поняття Сrystal:
 Розмір проєкту (Project Size) - кількість людей, залучених в проєкт. Зі
збільшенням розміру команди, змінюється методологія Crystal (структура,
артефакти і управління проєктом стають більш формальними)

 Критичність (Criticality) - визначається потенційним нанесенням шкоди. Іншими

словами, збої системи життєзабезпечення можуть нанести набагато більше шкоди,
ніж гра, яка не дозволить вам зберегти ваш профіль. У міру збільшення
критичності проєкту, стійкість проєкту (rigidity of the project) необхідно збільшити
для забезпечення реалізації очікуваних потреб замовника.

Слайд 86
Методології Сrystal
Кожна конкретна методологія відповідає розміру і критичності проєкту. Відомі такі:
 Crystal Clear
 Crystal Yellow
 Crystal Orange
 Crystal Red
 Crystal Maroon
 Crystal Diamond
 Crystal Sapphire

У той час, як різні методології мають багато

спільних елементів, слід зазначити, що
вони не сумісні один з одним (not intended
to be upward or downward compatible).
Тобто, якщо проєкт починається як проєкт
Crystal Clear, не слід очікувати переходу до
проєкту Crystal Maroon.

Слайд 87
Сrystal Clear
 Ролі:
• Спонсор (Sponsor)
• Старший Архітектор (Senior Designer)
• Програміст (Programmer)
 Всі члени команди працюють в одній кімнаті.
 Найбільш важлива роль - Старший Архітектор, який буде здатний вирішувати всі
технічні питання. Ролі керівника проєкту, бізнес-аналітика, тестувальника і т.д. є
загальними для всіх членів команди.
 Очікується, що ПЗ буде поставлятися через кожні два-три місяці. Команда може
працювати з меншими ітераціями, але очікуваний реліз повинен бути кожні 60-90
днів.
 Crystal Clear вимагає мінімальної документації, оскільки етапом проєкту, як
правило, є фактична поставка програмного забезпечення, а не письмові
документи. Команда відповідає за визначення будь-яких додаткових артефактів,
які вони виробляють, а також для визначення своїх власних стандартів
кодування, практики тестування і т.д.
Слайд 88
Сrystal Orange
 Ролі можуть змінюватися в залежності від організації, але, як правило, вони
включають традиційні ролі архітектора, спонсора, бізнес-аналітика, керівника проєкту
і т.д.
 Акцент на тестуванні: очікується, що у кожної підгрупи в команді є тестувальник
 Типові проєкти середнього масштабу (typical medium-sized projects)
 Реліз ПЗ очікується раз в три-чотири місяці
 Набір результатів проєкту :
•   Вимоги (Requirements Document)
•      Розклад релізів (Release Sequence (Schedule))
•      Розклад проєкту (Project Schedule)
•      Звіти про стан проєкту (Status Reports)
•      Графічний дизайн (UI Design Document (if project has a UI))
•      Об'єктна модель (Object Model)
•      Керівництво користувача (User Manual)
•      Тестові сценарії (Test Cases)

Слайд 89
Lean manufacturing
Ощадливе виробництво (lean production, lean manufacturing, струнке
виробництво) - концепція управління виробничим підприємством, заснована на
постійному прагненні до усунення всіх видів втрат.

Ощадливе виробництво передбачає залучення до процесу оптимізації бізнесу

кожного співробітника і максимальну орієнтацію на споживача.

Виникла як інтерпретація ідей виробничої системи компанії Toyota

американськими дослідниками її феномена.

Слайд 90
Lean manufacturing
Основна концепція - оцінка цінності продукту для кінцевого споживача, на
кожному етапі його створення. В якості основного завдання передбачається
створення процесу безперервного усунення витрат, тобто усунення будь-яких
дій, які споживають ресурси, але не створюють цінності (не є важливими) для
кінцевого споживача.
Як синонім для поняття втрат іноді використовується термін з виробничої системи
Toyota - muda, що означає всілякі витрати, втрати, відходи, сміття. Наприклад,
споживачеві абсолютно не потрібно, щоб готовий продукт або його деталі лежали
на складі. Проте, при традиційній системі управління складські витрати, а також всі
витрати, пов'язані з переробкою, браком, та інші непрямі витрати перекладаються
на споживача.

Слайд 91
Lean manufacturing
Джеймс Вумек і Деніел Джонс в книзі «Ощадливе виробництво: Як позбутися втрат і
досягти процвітання вашої компанії» викладають суть ощадливого виробництва як
процес, який включає п'ять етапів:
Визначити цінність конкретного продукту.
Визначити потік створення цінності для цього продукту.
Забезпечити безперервний потік створення цінності продукту.
Дозволити споживачеві «витягувати» продукт (Канбан)
Прагнути досконалості.
Серед інших принципів виділяються: досягнення чудової якості (здача з першого
пред'явлення, система «нуль дефектів», виявлення і вирішення проблем у витоків їх
виникнення), гнучкість, встановлення довготривалих відносин зі споживачами (шляхом
ділення ризиків, витрат та інформації).

Слайд 92
Lean Software Development
Ощадлива розробка програмного забезпечення - методологія розробки
програмного забезпечення, що використовує методи концепції ощадливого
виробництва. Виникла з середовища прихильників концепції гнучкої методології
розробки.

Вперше висвітлено в книзі Lean Software Development Мері Поппендік і Toма

Поппендіка, де представлені традиційні принципи ощадливого виробництва
стосовно до розробки програмного забезпечення, також набір з 22 інструментів
(практик) та їх порівняння з гнучкою методологією розробки.

Слайд 93
Lean Software Development - принципи
 Виключення втрат. Втратами вважається все, що не додає цінності для
споживача. Зокрема:
 зайва функціональність / розробка неправильного продукту / нечіткі вимоги;
 зайві процеси / бюрократизація;
 очікування (паузи) в процесі розробки;
 психологічний стрес;
 повільне внутрішнє повідомлення / неефективна комунікація;
 незавершені задачі;
 дефекти.
Для визначення втрат використовується метод відображення потоку цінності
(value stream mapping technique). Далі визначаються і усуваються джерела
втрат. Усунення втрат повинно відбуватися ітеративно до тих пір, поки не
зникнуть навіть процеси і процедури, що здаються суттєвими.

Слайд 94
Lean Software Development - принципи
 Акцент на навчанні.  Короткі цикли розробки, раннє тестування, часта
зворотний зв'язок із замовником.
Розробка програмного забезпечення - це безперервний процес навчання, процес
вирішення проблем. Значення ПЗ вимірюється в придатності для використання, а не
у відповідності до вимог.
Замість того, щоб робити детальну архітектуру, різні ідеї можна було б спробувати,
написавши код. Процес збору користувацьких вимог може бути спрощений шляхом
подання скринів кінцевим користувачам та отримання від них зворотного зв'язку.
Накопичення дефектів повинно бути виключено за рахунок раннього тестування -
шляхом запуску тестів, як тільки буде написаний код.
Процес навчання прискорюється за рахунок використання коротких циклів
ітерації – кожен з них зв’язаний з рефакторингом та інтеграційним тестуванням.

Слайд 95
Lean Software Development - принципи
 Максимально відтерміноване прийняття рішень. Рішення слід приймати не
на основі припущень і прогнозів, а після відкриття істотних фактів.
Мається на увазі створення різного роду прототипів, які можна показати клієнтам,
тим самим відкладаючи деякі важливі рішення, поки клієнти не усвідомлюють свої
потреби. Це також дозволяє більш пізню адаптацію до змін і запобігання дорогих,
раніше обмежених технологією, рішень. Це означає, що планування повинно бути
зосереджено на різних варіантах і адаптації до поточної ситуації, а також повинні
бути створені шаблони для швидкого реагування.
Оцінка різних варіантів є ефективна, як тільки всі учасники процесу усвідомлюють,
що вони не є безкоштовними, але забезпечують необхідну гнучкість для прийняття
остаточних рішень.

 Максимально часта доставка замовнику. Короткі ітерації.

Слайд 96
Lean Software Development - принципи
 Мотивація команди. Не можна розглядати людей виключно як ресурс. Людям
потрібно щось більше, ніж просто список задач. Наприклад, розробнику
необхідно мати зв'язок з клієнтом, а керівник команди повинен надавати
підтримку в складних ситуаціях.
 Інтегрування. Передати цілісну інформацію про систему замовнику. Прагнути до
цілісної архітектури. Рефакторинг.
Повний і автоматизований процес розробки повинен супроводжуватися повним і
автоматичним набором тестів для розробників і клієнтів, що мають таке ж управління
версіями, синхронізацію і семантику, що і поточний стан системи. Цілісність повинна
перевірятися при ретельному тестуванні, тим самим гарантуючи, що система зробить те,
що чекає на неї клієнт. Автоматизовані тести також вважаються частиною виробничого
процесу, тому, якщо вони не додають цінності, їх слід вважати втратами. Автоматичне
тестування не повинно бути метою, а радше засобом досягнення мети, зокрема
скороченням дефектів.
 Цілісне бачення. Стандартизація, встановлення відносин між розробниками.
Поділ розробниками принципів ощадливості. «Мислити широко, робити мало,
помилятися швидко; вчитися стрімко».
Слайд 97
Lean Software Development - практики
Деякі практики ощадливої розробки аналогічні практикам швидкої розробки, а деякі
трохи відрізняються :
 Виявлення втрат (яп. Muda)
 Систематизування потоку цінності (Value stream mapping)
 Теорія обмежень
 «Витягуюча» система (Канбан)
 Теорія масового обслуговування
 Мотивація
 Вимірювання
 Розробка через тестування

Слайд 98
Витягуюче виробництво
Витягуюче виробництво (pull production) — схема організації виробництва,
при якій обсяги продукції та терміни її виготовлення на кожному виробничому етапі
визначаються виключно потребами наступних етапів (в кінцевому підсумку -
потребами замовника). Випуск матеріалів у виробництво зі складів виконується на
вимогу споживача, до моменту використання матеріалу у виробничих операціях.
Рішення щодо поповнення запасів матеріалів на складах приймаються на самих
складах, а не центральною службою або заводом.

Слайд 99
Kanban
Канбан — метод управління розробкою, який реалізує принцип «точно в строк» і
сприяє рівномірному розподілу навантаження між працівниками. При цьому підході
весь процес розробки прозорий для всіх членів команди.

Задачі по мірі надходження заносяться в окремий список, звідки кожен розробник

може отримати необхідну задачу (або користувацьку історію).

Слайд 100
Kanban
Робочі елементи візуалізуються, щоб дати учасникам уявлення про прогрес і
процесі, від початку і до кінця, зазвичай за допомогою Канбан-дошки (Kanban
board). Робота "витягується" в міру того, як дозволяє пропускна здатність, замість
того, щоб працювати в процесі на вимогу.
В області розробки знань і розробки програмного забезпечення це забезпечує
візуальну систему управління процесами, яка допомагає приймати рішення про те,
що, коли і скільки виробляти. Хоча основний метод Канбан виник з ощадливого
виробництва, він використовується, в основному, для розробки програмного
забезпечення та роботи, пов'язаної з технологіями. Однак Канбан можна
застосовувати до будь-якої області роботи, його можна навіть комбінувати з іншими
методами або середовищами розробки, такими як Scrum.

Слайд 101
Kanban - принципи
 Опора на існуючі методи розробки
Канбан починається з існуючих методів розробки і стимулює в них додаткові
зміни.
 Попередня домовленість про проведення важливих змін
Команда розробників повинна враховувати, що постійні зміни - це спосіб
поліпшити існуючий процес розробки, проте проведення глобальних змін має
великий ризик. Канбан заохочує невеликі й еволюційні зміни.
 Повага до існуючого порядку, ролей і обов'язків
 Заохочення ініціативи
Вітаються прояви ініціативи кожного розробника

Слайд 102
Канбан-дошка
Канбан-дошка (Kanban board)  - один з інструментів, який може
використовуватися при впровадженні методології управління розробкою «Канбан».
Разом з дошкою використовуються магніти, пластикові фішки, кольорові шайби
або стікери для подання робочих елементів і процесів.
Кожен з цих об'єктів є етап виробничого процесу і рухається по дошці, у міру
прогресу. Такий рух відповідає руху процесу виробництва. Дошка, як правило,
розділена на три логічні секції: «очікування», «робота в процесі» і «завершена
робота». Співробітники переміщують замітки в ту секцію дошки, яка відповідає
статусу завдання.
Зазвичай вказуються явні обмеження кількості елементів, які можуть
виконуватися в кожному стані робочого циклу.

Слайд 103
Час виконання та час циклу в Канбан
Для Kanban характерно вимірювання середнього часу для завершення одного
завдання, який іноді називають «часом циклу» (cycle time), і оптимізація
процесу, для того, щоб зробити час виконання (lead time) як можна меншим та
передбачуваним.

Слайд 104
Канбан-дошка
Найпростіші дошки складаються з трьох колонок: «зробити» (to-do), «в процесі»
(in progress), «зроблено» (done)

Слайд 105
Канбан-дошка
Найбільш популярна інтерпретація канбан-дошки для lean-розробки включає
наступні колонки відповідно до статусу завдань: обговорюється (backlog),
погоджено (ready), кодується (coding), тестується (testing), підтверджується
(approval) і зроблено (done). Також поширена практика іменування стовпців
інакше, наприклад: далі, розробка, готове, схвалення клієнта, перенесення змін на
робочий сервер.
Крім можливості перейменовувати стовпці / статуси на дошці Kanban, є
можливість і збільшувати кількість стовпців, однак відбувається це з умовою
подрібнення існуючих. 

Слайд 106
Канбан-дошка

Слайд 99
Канбан-дошка

Слайд 108
Scrum vs Kanban : Scrum workflow

У Scrum заздалегідь вибираються задачі для наступного спринта. Потім

наповнення спринта блокується, поступово виконуються задачі і в кінці спринта
черга задач порожня.

Слайд 109
Scrum vs Kanban : Kanban workflow

У Kanban все, що обмежено - це розмір черг задач, який називається

обмеженням WIP (work in progress). Це означає, що ви можете будь-коли змінити
елементи в черзі, і що “кінець спринта” не існує. Потік задач не припиняється.

Слайд 110
Scrumban

SCRUMBAN = SCRUM + KANBAN

 Використовуйте скрипти процесу Scrum, щоб задовольняти принципам Agile

 Використовуйте вдосконалення процесу Kanban, щоб дозволити команді
постійно вдосконалювати свій процес розробки

Слайд 111
Scrumban - відмінності
 Команда визначає власні слабкі сторони та можливості для подальшого
вдосконалення свого процесу розробки
 Акцент на середньому часі виконання (lead time) та часі циклу (cycle time)
Якщо час циклу знаходиться під контролем, а продуктивність команди збалансована з
урахуванням вимог до ресурсів, тоді час виконання також буде під контролем. Тоді
діаграма згоряння задач цілком передбачувана.

 Формується беклог фіксованого розміру, який регулярно буде нульовим до

закінчення запланованого інтервалу
 Планування спринтів проводиться на регулярній основі та синхронізоване з
оглядом спринта та ретроспективою. Мета планування - заповнити доступні слоти
 Якщо закінчені задачі не проходять контроль якості, вони повертаються на
доопрацювання та аналіз першопричини дефектів

Слайд 112
Scrumban - переваги
 Контроль якості
 Короткий час виконання
 Постійне вдосконалення
 Мінімізація відходів (все, що не додає вартості для замовника)
 Поліпшення процесу шляхом додавання деяких цінностей Scrum, якщо є така
необхідність

Слайд 113
Коли доцільно використовувати Scrumban
 Проєкти підтримки (maintenance)
 Проєкти з частими несподіваними користувацькими історіями або дефектами
реалізації
 Розробка нових продуктів
 Задачі, що передують ітеративній розробці (беклог, R&D)
 Задачі, що слідують за ітеративною розробкою (тестування системи, упаковка
та розгортання)

Слайд 114
Беклог в Scrumban
 Уникайте створення/аналізу занадто багато історій (вимог/дефектів) - зменшіть
витрати
 Перед початком розробки забезпечте необхідний рівень аналізу
 Розстановка пріоритетів на вимогу - ідеальний процес планування роботи завжди
повинен забезпечувати команді ту задачу, над якою слід працювати далі, не
більше і не менше

Слайд 115
Дошка Scrumban

Слайд 116
Kanban vs. Scrumban

Kanban Scrumban
Ролі Немає прописаних ролей Команда + інші, які потребує проєкт

Щодення Scrum нарада Немає Проводиться для впевненості в

коректній роботі згідно вимогам та
зменшення часу «простою» членів
команди. Може проводитись з
метою заповнити вільні слоти на
дошці

Оглад спринта та Не прописано процесом Може проводитись при

Ретроспектива необхідності для поліпшення
процесу та з метою навчання

Потік задач Постійний Постійний, але з лімітом задач

Слайд 117
Scrum vs. Scrumban
Scrum Scrumban
Дошки / Артефакти Дошки, беклоги, діаграми згоряння Тільки дошка
Формальності Daily scrum, планування спринта, огляд Daily scrum (планування, огляд та
спринта, ретроспектива спринта ретроспектива за необхідності)
Ітерації Так (спринти) Ні (постійний потік)
Потік задач Постійний Постійний, але з лімітом задач
Оцінка задач Так Ні (для задач приблизно однакового
об’єму)
Команди Мусять бути крос-функціональними Можуть бути спеціалізованими
Ролі Product Owner, Scrum Master, команда Команда + інші за необхідності
WIP Контролюється змістом спринта Контролюється станом потоку задач
Зміни Повинні чекати наступного спринта Додаються за необхідності на дошку (To do)
Беклог продукту Список пріоретизованих та оцінених Картки на даний момент часу
користувацьких історій
Затримки Вирішуються негайно Уникаються

Слайд 118