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

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

Тема 3. Загальні практики методологій Agile

 Загальні практики Agile - 1
 Ітеративна та інкрементна розробка (Iterative and incremental development)
 Журнал побажань проєкту і спринту (Product & Sprint Backlogs)
 Користувацька історія (User story)
 Відображення користувацьких історій (User Story Mapping)
 Сюжетне моделювання (Story-driven modeling)
 Парне програмування (Pair programming)
 Неперервна інтеграція (Continuous integration (CI))
 Information radiators (scrum board, task board, visual management board, burndown
chart)
 Події Scrum (Scrum events (sprint planning, daily scrum, sprint review and
retrospective))
 Timeboxing
 Крос-функціональна команда (Cross-functional team)

Слайд 2
Загальні практики Agile - 2
 Покер планування (Planning poker)
 Вимірювання продуктивості (Velocity tracking, Story points)
 Предметно-орієнтоване проєктування (Domain-driven design, DDD)
 Рефакторинг (Refactoring)
 Розробка через тестування (Test-driven development, TDD)
 Розробка, заснована на приймальних тестах (Acceptance test-driven
development, ATDD)
 Розробка, заснована на функціонуванні (Behavior-driven development,
BDD)
 Agile testing
 Agile modeling

Слайд 3
Ітеративна та інкрементна розробка ПЗ
виконання робіт паралельно з безперервним аналізом отриманих результатів і
коригуванням попередніх етапів роботи. Проєкт при цьому підході в кожній фазі
розробки проходить цикл PDCA: Планування — Реалізація — Перевірка — Дія (plan-
do-check-act cycle)

Слайд 4
Журнал побажань продукту та спринту (Product & Sprint
Backlogs)

Журнал побажань продукту - список вимог до функціональності, упорядкований

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

Слайд 5
Користувацька історія (User Story)
 спосіб опису вимог до розроблюваної системі, сформульованих як одне або більше
пропозицій повсякденною або діловою мовою користувача
 користувацька історія обмежена в розмірі та складності. Часто історія пишеться на
маленькій паперовій картці, що гарантує, що вона не стане занадто великою
 в Екстремальному програмуванні користувацькі історії пишуться користувачами
(замовниками) системи. У SCRUM - пишуться або схвалюються роллю Власника
продукту. Для замовників користувацькі історії є основним інструментом впливу на
розробку програмного забезпечення
 є швидким способом документувати вимоги клієнта, без необхідності розробляти великі
формалізовані документи і згодом витрачати ресурси на їх підтримку. Мета
користувальницьких історій полягає в тому, щоб бути у змозі оперативно і без
накладних витрат реагувати на швидкі зміни вимог реального світу
 неофіційне визначення вимог, поки відсутня процедура приймального тестування.
Перш, ніж реалізовувати користувацьку історію, клієнт повинен визначити відповідну
приймальну процедуру для гарантії, що цілі користувацької історії були досягнуті

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

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

1453
Неавторизований
користувач вводить логін і
пароль для авторизації на
сайті
200 10

Слайд 7
Користувацька історія (User Story)
Іноді ще використовують додаткові поля:
 Детальний опис – текстовий та графічний опис користувацької історії. Застосовується,
перш за все, у розрізнених командах для зберігання знань про функціональні продукти.
 Демонстрація – досить детальний сценарій, що пропонує демонстрацію користувацької
історії. Наприклад, для користувацької історії з авторизацією, можна використовувати
наступні короткі сценарії для демонстрації:
1. Користувач вводить логін «root» і пароль «pass», і переходить на сторінку особистого
профілю на сайті.
2. Користувач вводить логін «root» і пароль «wrongpass», і отримує повідомлення
«Введений неправильний логін або пароль».
 Категорія – використовується для підвищення керованісті за допомогою категоризації
задач. В якості категорій можуть бути представлені як продуктові категорії («теми» та
«епіки» в термінології Scrum), так і категорії типу «Оптимізація виробничої якості»,
«Технічна історія» і тому подібні.

Слайд 8
Переваги користувацької історії
 історії короткі. Вони представляють собою маленькі шматочки ділових ціностей,
які можна реалізувати в періоді від кількох днів до кількох тижнів
 дозволяють розробникам та клієнтам обговорювати вимоги протягом усього
життя проєкту
 розглядаються лише в момент використання
 підтримують близький контакт з клієнтами
 дозволяють розбити проєкт на невеликі етапи
 підходять для проєктів, де вимоги мінливі або погано зрозумілі
 полегшують оцінку задач

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

Слайд 10
Користувацькі історії та сценарії використання
 Хоча користувацькі історії та сценарії використання служать єдиній меті
документування користувацьких вимог між ними є відмінності з точки зору
взаємодії між користувачем і системою.
 Користувальницькі історії - це невелике та зручне в роботі представлення
інформації. Вони сформульовані на щоденній мові користувача та містять у собі
невеликі деталі, і таким чином залишаються відкритими для інтерпретації. Вони
допомагають читачу розуміти, що повинна робити система.
 Сценарії використання (use cases), на відміну від користувальницьких історій,
описують процеси і його кроки детально, і можуть бути сформульовані з точки
зору формальної моделі. Сценарій самодостатній. Він забезпечує повну необхідну
інформацію та деталі для розуміння. Сценарій описується як «узагальнений опис
ряду взаємодій між системою та одним або більше агентами, де агент -
користувач або інша система».

Слайд 11
Сюжетне моделювання (Story Modelling)
 представляє собою метод об'єктно-орієнтованого моделювання
 Інші форми об'єктно-орієнтованого моделювання зусереджені на діаграмних
класах. Замість абстрактних статичних структур, сюжетне моделювання
фокусується на конкретних прикладах сценаріїв, і на тому, як кроки зразкових
сценаріїв можуть бути представлені у вигляді діаграм і об'єктів, як ці діаграми
об'єктів розвиваються в процесі виконання сценарію

Слайд 12
Сюжетне моделювання (Story-driven Modelling)
Пропонується використовувати наступні підходи:
 Текстові сценарії (textual scenarios)
 Макети графічного інтерфейсу (GUI mock-ups)

Scenario Go-Dutch barbecue

•Start: This Sunday Peter, Putri, and Peng meet at the park for a go-Dutch barbecue. They use the Group Account app
to do the accounting.
•Step 1: Peter brings the meat for $12. Peter adds this item to the Group Account app.
•Step 2: Putri brings salad for $9. Peter adds this item, too. The app shows that by now the average share is $7 and
that Peng still have to bring these $7 while Peter gets $5 out and Putri gets $2 out.
•Step 3: ...

Слайд 13
Сюжетне моделювання (Story-driven Modelling) - 2
 Розкадровка (Story boarding) –
сценарій з діаграмами об’єктів

 Виведення діаграми класів

(Class diagram derivation)
– засновані на розкадровках

Слайд 11
Сюжетне моделювання (Story-driven Modelling) - 3
 Проєктування алгоритма (Algorithm design) – виклад поведінки в нотації
псевдокоду (pseudocode notation)

Update the saldo of all persons:

•visit each item
•for each item add the value to the total value and add 1 to the number of items
•compute the average share of each person by dividing the total value by the number of persons
•visit each person
•for each person reset the saldo
•for each person visit each item bought by this person
•for each item add the value to the saldo of the current person
•for each person subtract the share from the saldo

 Реалізація поведінки (Behavior implementation)

Слайд 15
Сюжетне моделювання (Story-driven Modelling) - 4
 Тестування (Testing) – тести написані на псевдокоді

Test update the saldo of all persons:

• create a group account object
• add a person object with name Peter and a person object with name Putri and a person object with name Peng to
the group account object
• add an item object with buyer Peter, description Meat, and value $12 to the group account object
• add an item object with buyer Putri, description Salad, and value $9 to the group account object
• call method update the saldo of all persons on the group account object
• ensure that the saldo of the Peter object is $5
• ensure that the saldo of the Putri object is $2
• ensure that the saldo of the Peter object is -$7
• ensure that the sum of all saldos is $0

Слайд 16
Сюжетне моделювання (Story-driven Modelling) - 5
 Доведено, що сюжетне моделювання добре працює для співпраці з експертами
поза межами ІТ.
 Люди, які працюють в інших областях, як правило, відчувають труднощі при
описанні своїх потреб в загальних рисах (тобто описанні класів) і за загальними
правилами (псевдокод). Проте, ці люди за допомогою конкретних прикладів і
сценаріїв легко визначають проблемні випадки і те, чи були їхні потреби були
враховані належним чином.
 Підтримується в таких інструментах, як UMLLab, MDELab, Fujaba і ін.

Слайд 17
Парне програмування (Pair Programming)
 техніка програмування, при якій початковий код створюється парами людей, що
програмують одну задачу сидячи за одним робочим місцем. Один програміст
(«провідний», driver) управляє комп'ютером і, в основному, думає над
кодуванням в деталях. Інший програміст («штурман», navigator) зосереджений на
картині в цілому і безперервно переглядає код, розроблений першим
програмістом. Час від часу вони міняються ролями.

Слайд 18
Різновиди парного програмування - 1
 Експерт-експерт (Expert-expert) - очевидний вибір для забезпечення найвищої
продуктивності, але часто не дає нових ідей для вирішення проблем, оскільки
обидві сторони навряд чи будуть ставити під сумнів усталені практики.
 Експерт-новачок (Expert-novice) - створює можливості для "менторингу"
новачка. Така пара може дати нові ідеї, оскільки новачок задає багато питань.
Експерт, для того, щоб пояснити існуючі практики, може знаходити їх недоліки.
Проте, заляканий новачок може пасивно «спостерігати за майстром» ("watch the
master") і навряд чи буде реально брати участь в розробці. Крім того, деякі
експерти можуть не мати терпіння, необхідного для забезпечення конструктивної
участі новачка.
 Новачок-новачок (Novice-novice) - може дати значно кращі результати, ніж в
разі, якщо два новачка працюють незалежно один від одного, але ця практика,
як правило, не рекомендується.

Слайд 19
Різновиди парного програмування - 2
 Віддалене парне програмування (Remote pair programming) - два програміста
фізично знаходяться у різних місцях, працюють за допомогою спільного real-time
редактора, спільного робочого столу (shared desktop) або IDE плагін для
віддаленого парного програмування. Віддалене парне програмування вносить
додаткові труднощі, такі як додаткові координаційні затримки (трекінг завдань і
т.п.), іноді втрата вербальної комунікації, і конфлікти через таких речей, як «у
кого клавіатура".

Слайд 20
Різновиди парного програмування - 3
 Пінг-понг програмування (Ping-pong programming) — парне програмування,
адаптоване для методу розробки через тестування. У кожен момент часу
клавіатурою користується тільки один учасник, а код знаходиться в одному з двох
станів: успішно проходить всі тести або є хоча б один тест, який не виконується. У
першому стані розробники повинні зробити вибір, що вони будуть робити (писати
новий тест, коригувати існуючий тест або проводити рефакторинг коду) і хто це
буде робити. Після завершення рефакторингу, код завжди повинен бути в
початковому стані - проходити всі тести. При цьому підході скорочується число
ситуацій, в яких потрібно прийняти рішення про передачу клавіатури та
знижується ймовірність виникнення розбіжностей.

Слайд 21
Переваги і недоліки парного програмування
Переваги:
 Підвищення дисципліни
 Високий командний дух (Team building)
 Якісні архітектура і код
 Економічна обґрунтованість (знижується продуктивність, але знижується і кількість
внесених дефектів (за даними IBM на ~ 15%), а отже, знижуються витрати на підтримку
продукту)
 Колективне володіння кодом
 Навчання
Недоліки – часте використання анти-патернів поведінки в парному програмуванні, як
наприклад:
 «Watch the master» і «Диктатор»
 «Зганяй за кавою»
 Мовчання вказує на відсутність співпраці
 Розподіл задач за одним столом
 Незручно сидіти
 Партнер зайнятий своїми справами
 Свої налаштування середи розробки
 Стиль кодування
Слайд 22
Одиниці роботи (Units of work)
Одиниці роботи (units of work) є елементами Agile проєкту, такими, як функції
(features), запити на зміни (change requests), помилки (bugs), варіанти
використання (use cases), користувацькі історії та ін. Задачі включають в себе один
або кілька одиниць робіт, виконаних в ході ітерацій циклу проєкту.

Можна визначити одиницю роботи, використовуючи години, дні, бали

користувацької історії (story points) або будь-які інші довільні одиниці, які ви можете
послідовно вимірювати по декількох проєктах. Кожна задача в проєкті оцінюється в
контексті одиниці роботи.

Слайд 23
Проблема оцінки одиниць роботи в розробці програмного
забезпечення
В класичному розумінні, кожна задача вимірюється в ідеальних людино-годинах.
Але реальний світ вносить свої корективи. Наразі використовуються підходи:

 PERT

 Story points

Слайд 24
 Program Evaluation and Review Technique
PERT або Program Evaluation and Review Technique була розроблена в 50-і роки
XX століття в ВМС США.

Для оцінки задачі представляються три числа:

O: гранично оптимістична оцінка.
N: номінальна і найбільш ймовірна оцінка.
P: вкрай песимістична оцінка, в яку закладені всі неприємності, які можуть
статися під час виконання завдання.
Очікувана тривалість завдання описується наступною формулою:

А відхилення, що фактично є мірою невизначенності задачі, рахується за

формулою:

Слайд 25
 Program Evaluation and Review Technique - приклад
Оптимістична оцінка задачі О = 4. Найбільш ймовірна оцінка – N = 6.
Песимістична оцінка P = 11.
Тоді задачі можна оцінити як

Або

Слайд 26
Бали користувацької історії (Story points)
Бали користувацької історії (user story points) - довільні значення,
використовувані для вимірювання зусиль, необхідних для завершення
користувальницької історії. У більшості випадків, керівники проєктів визначають
бали користувальницької історії з ряду Фібоначчі (наприклад, 1, 2, 3, 5, 8). Точне
значення бала користувальницької історії може змінюватися з плином часу.
При оцінці за допомогою story points призначаються бали для кожного елемента
списку задач. При цьому важливі відносні значення. Наприклад, користувацька
історія, якій присвоюється 2 бали, повинна бути в два рази більше, ніж історія, якої
присвоюється 1. Вона також повинна становити дві третини історії, яка оцінюється в
3 бали.
Можна використовувати 100, 200 і 300, або 1 мільйон, 2 мільйони і 3 мільйони.
Важливе відношення балів, а не фактичні числа.

Слайд 27
Бали користувацької історії (Story points)
Для відносних оцінок необхідно вибрати еталонну користувацьку історію. Вона
повинна бути:
 проста і зрозуміла для команди;
 типова для даного проєкту;
 невеликого розміру.
Цю користувацьку історію команда приймає за 1 бал. Тоді користувацька історія,
яка буде в два рази менше за еталонну, матиме розмір ½ бала, а користувацька
історія, яка в п'ять разів більше еталонної, матиме розмір 5 балів. Таким чином,
story point - це відносна одиниця виміру.

Слайд 28
Що враховують story points
Оскільки story points представляють собою зусилля на розробку історії, оцінка
команди повинна включати всі, що може вплинути на зусилля. Це може включати:
 Обсяг роботи
 Складність роботи
 Будь-який ризик або невизначеність при виконанні роботи

Слайд 29
Що враховують story points – об’єм робіт
Розглянемо приклад розробки двох веб-сторінок.
На першій сторінці є тільки одне поле і ярлик з проханням ввести ім'я.
На другій сторінці є 100 полів, які також просто заповнюються невеликою
кількістю тексту. Друга сторінка не складніше, ніж перша. Між полями немає
взаємодії, а значить і немає додаткового ризику.
Друга сторінка повинна бути оцінена більшою кількістю story points, ніж перша,
але не в 100 разів. Можливо, друга сторінка потребує всього лише в 2 або 3 або 10
разів більше зусиль, ніж перша.

Слайд 30
Що враховують story points - складність
Тепер подумаємо про іншу веб-сторінку із 100 полями. Деякі з них представляють
собою поля дати із віджетами календаря. Деякі з них форматують текстові поля
(номера телефонів або документів). Інші поля перевіряють контрольну суму, як і
номери кредитних карт.
Ця сторінка також вимагає взаємодії між полями. Якщо користувач вводить карту
Visa, відображається тризначне поле CVV. Але якщо користувач вводить карту
American Express, відображається чотиризначне поле CVV.
Незважаючи на те, що на цьому екрані ті ж 100 полів, ці поля складніше
реалізувати. Є більше шансів, що розробник внесе дефекти при реалізації.
Ця додаткова складність повинна бути відображена в наведеній оцінці.

Слайд 31
Що враховують story points – ризик і невизначенність
 Якщо команді пропонується оцінити елемент списку задач, а зацікавлена сторона
ще толком не знає, що потрібно реалізувати, ця невизначеність повинна бути
відображена в оцінці.
 Якщо реалізація функціональності включає в себе рефакторинг старого
«крихкого» коду, який не має автоматичних тестів, цей ризик повинен бути також
відображений в оцінці.

Слайд 32
Чому story points ?
 Дні / години не враховують роботу, не пов'язану з проєктом, яка неминуче
проникає займає наш час: електронні листи, зустрічі та інтерв'ю, в яких може
брати участь член команди.
 Планування в днях або годинах тягне емоційну прихильність до оцінки. Відносна
оцінка усуває емоційну прихильність.
 Кожна команда оцінить роботу в дещо іншій шкалі, що означає, що їх
продуктивність (виміряна в story points) буде, природно, відрізнятися. Це, в свою
чергу, унеможливлює спекуляції продуктивністю в оцінці роботи команд.

Слайд 33
Estimate smarter not harder
 Індивідуальна задача не повинна займати більше, ніж 16 годин. (Якщо ви
використовуєте story points, ви можете вирішити, що, скажімо, 20 балів - це
верхня межа.) Коли щось оцінюється вище 16-годинного (або 20-бального)
порогу вашої команди, це сигнал для того, щоб розбивати його на більш
деталізовані задачі і переоцінювати
 Для елементів, які йдуть далі в беклозі задач, дають приблизну оцінку. На той
час, коли команда фактично почне працювати над цими елементами, вимоги
можуть змінитися, і ваша оцінка, безумовно, зміниться. Тому попередні оцінки не
будуть настільки точними. Не витрачайте час на оцінку роботи, яка, ймовірно,
зміниться. Просто дайте власнику продукту приблизну цифру, яку він може
використовувати, щоб оцінити продукт взагалі.

Слайд 34
Вчитись на минулих помилках
 Ретроспектива - зустріч, під час якої команда повинна враховувати ідеї минулих
ітерацій, в тому числі точність їх оцінок. Багато інструментів Agile (наприклад,
JIRA Software) відстежують story points, що значно полегшує повторну оцінку.
Спробуйте, наприклад, підняти останні 5 користувацьких історій, які команда
оцінила в 8 балів. Обговоріть, чи мала кожна із задач однаковий рівень зусиль.
Якщо ні, обговоріть, чому.
 Як і все інше в Agile, оцінка - це практика. Згодом ви станете оцінювати завдання
все краще і краще.

Слайд 35
Приклад оцінки користувацьких історій по категоріям

Слайд 36
Альтернативи – оцінка методом T-shirt sizes

Слайд 37
Інші одиниці вимірювання задач

Слайд 38
Покер планування (Planning Poker, Scrum Poker)

 техніка оцінки, заснована на досягнення домовленості, головним чином

використовується для оцінки складності майбутньої роботи або відносного
обсягу вирішуваних завдань при розробці програмного забезпечення.
 різновид методу Wideband Delphi (метод планування, заснований на
«голосуванні на базі консенсусу» і анонімних оцінках екпертів кожного
завдання).
 використовується в екстремальному програмуванні
 метод вперше був описаний Джеймсом Греннінгом (James Grenning) в 2002 році і
пізніше популяризував Майком Коном (Mike Cohn) в книзі «Agile Estimating and
Planning»

Слайд 39
Покер планування - підготовка
 необхідно підготувати список обговорюваних функцій і кілька колод
пронумерованих карт. Список функцій або користувацькі історії описують ПЗ, що
розробляється
 карти в колодах повинні бути пронумеровані. Зазвичай колода містить карти, що
містять числа Фібоначчі, включаючи нуль: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; інші
різновиди колод можуть використовувати аналогічні послідовності
 аргумент на користь використання послідовності Фібоначчі - відображення типової
невизначеності при обговоренні найважливіших і великих пунктів
 одна зі спеціальних колод містить наступну послідовність: 0, ½, 1, 2, 3, 5, 8, 13,
20, 40, 100 і іноді «?», що означає невпевненість, і чашку кави, яка б означала
вимогу перерви. Деякими організаціями використовуються звичайні ігрові карти,
що включають туз, 2, 3, 5, 8 і короля. Король буквально означає: «Даний пункт
занадто великий або його занадто складно оцінити». Викидання короля завершує
обговорення пункту в поточному колі
 може використовуватися таймер, щоб встановлювати ліміт часу одного кола

Слайд 40
Покер планування - підготовка

Слайд 41
Покер планування – процедура проведення - 1
 Кожному учаснику обговорення видається по одній колоді карт, ідентичних одна
одній.
 Ведучий (Moderator), який не бере участі в обговоренні, веде збори.
 Менеджер продукту (Product Manager) представляє короткі огляди кожного з
пунктів. Команда може задавати питання і вести обговорення пропозицій і ризиків.
 Коли вибір зроблений, учасники вибирають по одній карті і кладуть їх «сорочкою»
вгору. Числові позначення карт можуть використовуватися по-різному: вони
можуть означати кількість днів, які найбільше підходять дні або відносні одиниці
складності (story points).
 Кожен учасник називає свою карту і перевертає її.

Слайд 42
 Покер планування – процедура проведення - 2
 Учасники з граничними оцінками мають можливість їх обґрунтувати. Корисно буде
обговорити наступні питання: «Які труднощі ти бачиш у цій задачі?» та «Чому ти
думаєш, що під час реалізації не виникне ніяких проблем?»
 Процес обговорення триває до тих пір, поки не буде досягнуто консенсусу. Голос
учасника, який, швидше за все, буде реалізовувати задачу, має більшу вагу.
• Слід відмітити, що консенсус не повинен бути абсолютним. Ви можете домовитись, що
набір сусідніх оцінок теж є консенсусом.
 Таймер використовується для забезпечення структурованості обговорення; ведучий
або менеджер продукту може в будь-який час перезапустити таймер, після
завершення часу всі обговорення повинні бути припинені, потім починається нове
коло покеру.

Слайд 43
 Переваги Покеру планування
 техніка мінімізує «ефект прив'язки» шляхом опитування кожного з учасників
команди таким чином, що ніхто не знає чужого рішення до одночасного оголошення
вибору кожного з учасників

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

 дослідження K. Молёккен-Ествольда (K. Moløkken-Østvold) і Н. Хаугена (NC Haugen)

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

Слайд 44
 Альтернативи : афінна оцінка
 Всі задачі записуються на картах без будь-яких оцінок. Експертна група стоїть біля
вікна або стіни, на якій карти розподілені випадковим чином. Учасники не говорять
між собою - вони просто сортують карти. Карти задач, що вимагають більше зусиль,
переміщуються вниз, а ті, що вимагають менше зусиль, переміщуються вгору.
 Будь-який учасник групи може в будь-який момент перемістити будь-яку карту,
навіть якщо вона вже була переміщена іншим учасником. Карти переміщені кілька
разів, відкладаються в сторону для обговорення. Згодом безмовне сортування
завершується і починається обговорення.
 На наступному етапі між картами малюються лінії, що представляють зусилля, що
вимагаються для реалізації задач.

 Підхід з використанням таких категорій або "кошиків" можна використовувати і в

класичному покері планування.

Слайд 45
Альтернативи : афінна оцінка

Слайд 46
 Продуктивність (Velocity)
 метрика, яка передбачає, який обсяг робіт Agile команда може успішно завершити
протягом спринту (або аналогічного часового періоду)

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

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

 визначається шляхом відстеження одиниць роботи (units of work), необхідних для

виконання всіх поставлених задач протягом ітерації

Слайд 47
Вимірювання продуктивності (Velocity tracking)

Слайд 48
 Продуктивність (Velocity)
З чого почати?
 Це ваш перший покер планування і команда не розуміє відносно чого оцінювати нові
задачі. Зберіть кілька вже реалізованих задач (в ідеалі вже знацомих або типових) і
оцініть їх складність відносно один одного. Використовуйте ці задачі для оцінки нових.
 Якщо у вас новий проєкт і реалізованих задач немає, спробуйте використати афінну
оцінку.
Не усереднюйте оцінки, якщо два члени команди оцінили задачу по-різному
Не змінюйте оцінки
 Навіть якщо в ході реалізації ви зрозуміли, що помилилися при плануванні, залиште
оцінку незмінною. Ви будете помилятися і в майбутньому, причому в обидві сторони.
Дайте цим помилкам компенсувати один одного, не втручайтеся в процес.

Слайд 49
 Продуктивність (Velocity)
Оцінка багів
 Деякі команди оцінюють всі баги, крім тих, що виникли в ході реалізації нових завдань в
ітерації.
 Деякі не оцінюють баги, обґрунтовуючи це тим, що швидкість команди повинна
показувати нову цінність, яка додається в продукт, і виправлення багів не повинно
впливати на зростання цього показника.
 Який би підхід ви вибрали залишайтеся послідовними. Інформація про історичну
швидкість команди не повинна постраждати від застосування різних підходів до оцінки.

Нульові оцінки
 Хтось вважає, що не буває задач, які не потребують зусиль. Інші відповідають їм, що
призначення балів найпростішим завданням веде до необгрунтованого зростання
графіка швидкості команди.
 Ви можете ввести оцінку в 1/2 бали для таких задач і ретроспективно відстежувати чи не
перевищує частка таких завдань розумні межі. Принцип той же – послідовність.

Слайд 50
 Продуктивність (Velocity)
Переоцінка незавершених задач між ітераціями
 Не завжди вдається завершити задачу в одну ітерацію. Проте не варто змінювати її
оцінку при плануванні наступної ітерації виходячи з кількості роботи, що залишилась.
Враховуйте це при плануванні, але залиште оцінку незмінною для історії.

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

Записуйте все
 Історичні дані - важливий інструмент вдосконалення ваших оцінок.

Слайд 51
Безперервна інтеграція (Continuous Integration)
 практика розробки програмного забезпечення, яка полягає в злитті робочих копій в
загальну основну гілку розробки (development branch) кілька разів на день і виконанні
частих автоматизованих збірок проєкту для якнайшвидшого виявлення та вирішення
інтеграційних проблем. У звичайному проєкті, де над різними частинами системи
розробники працюють незалежно, стадія інтеграції є заключною. Вона може
непередбачувано затримати завершення робіт. Перехід до безперервної інтеграції
дозволяє знизити трудомісткість інтеграції і зробити її більш передбачуваною за
рахунок найбільш раннього виявлення та усунення помилок і протиріч.
 вперше визначено та запропоновано Граді Бучем в 1991 р

Слайд 52
Безперервна інтеграція (Continuous Integration)
• Вимоги до проєкту
• Початковий код і все, що необхідно для побудови та тестування проєкту,
зберігається в репозиторії системи управління версіями;
• Операції копіювання зі сховищ, збірки і тестування всього проєкту автоматизовані і
легко викликаються з зовнішньої програми.
• Організація
• На виділеному сервері організовується служба, в завдання якої входять :
• отримання початкового коду з репозиторію;
• збірка проєкту;
• виконання тестів;
• розгортання готового проєкту;
• відправка звітів.
• Локальна збірка може проводитись:
• за зовнішнім запитом,
• за розкладом (як правило, щодня),
• за фактом поновлення репозиторію та за іншими критеріями.
Слайд 53
Безперервна інтеграція - процес
 Запустити тести локально
Безперервна інтеграція призначена для використання в поєднанні з
автоматизованими модульними тестами, написаними на основі TDD. Це робиться
шляхом запуску та проходження всіх модульних тестів у локальному середовищі
розробника і допомагає уникнути того, що незавершена робота одного розробника
порушує копію іншого розробника. Якщо необхідно, частково завершені функції
можна вимкнути перед комітом.

 Скомпілювати код на сервері

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

Слайд 54
Безперервна інтеграція - процес
 Запустити тести на сервері
На додаток до автоматизованих модульних тестів організації, які використовують CI,
зазвичай використовують сервер збірки, щоб реалізувати безперервні процеси
застосування контролю якості загалом – невеликі зусилля, які застосовуються часто.
Окрім запуску модульних та інтеграційних тестів, такі процеси виконують
додатковий статичний аналіз, вимірюють і профілюють продуктивність, витягують і
форматують документацію з вихідного коду та полегшують ручні процеси QA.
Це безперервне застосування контролю якості має на меті покращити якість
програмного забезпечення та скоротити час його доставки, замінивши традиційну
практику застосування контролю якості після завершення всієї розробки. Це дуже
схоже на початкову ідею частішої інтеграції для полегшення інтеграції, яка
застосовується лише до процесів забезпечення якості.

Слайд 55
Безперервна інтеграція - процес
 Розгорніть артефакт із сервером
Наразі безперервна інтеграція часто переплітається з безперервною
доставкою або безперервним розгортанням у так званому конвеєрі CI/CD.
«Безперервна доставка» гарантує, що програмне забезпечення, що знаходиться в
основній гілці репозиторію, завжди знаходиться в стані, який можна розгорнути для
користувачів, а «безперервне розгортання» робить процес розгортання повністю
автоматизованим.

Слайд 56
Безперервна інтеграція (Continuous Integration)

Слайд 57
Безперервна інтеграція - практики
 Підтримка репозиторію коду
 Ця практика підтримує використання системи контролю перевірок (revision control
system) для вихідного коду проекту. Усі артефакти, необхідні для побудови проекту,
слід помістити в репозиторій.
 У цій практиці та в спільноті контролю ревізій прийнято вважати, що систему можна
побудувати з свіжої копії коду (fresh checkout) та не вимагати додаткових
залежностей. Прихильник екстремального програмування Мартін Фаулер також
згадує, що там, де розгалуження підтримуються інструментами, його використання
слід звести до мінімуму. Замість цього краще інтегрувати зміни, а не підтримувати
кілька версій програмного забезпечення одночасно. Основний репозиторій (trunk or
mainline) має бути місцем для робочої версії програмного забезпечення.

Слайд 58
 Безперервна інтеграція - практики
 Автоматизована збірка
 Збірка системи повинна запускатись однією командою.
 Автоматизація збірки має включати автоматизацію інтеграції, яка часто
включає розгортання у виробничому середовищі. У багатьох випадках скрипт збірки
не лише компілює бінарні файли, але й створює документацію, сторінки веб-сайтів,
статистичні дані та медіа файли.

 Зробити збірку, що тестується (self-testing)

 Після компіляції коду всі тести повинні бути запущені, щоб підтвердити, що збірка
веде себе так, як очікують розробники.

Слайд 59
 Безперервна інтеграція - практики
 Кожен щодня робить коміт до основної гілки
 Здійснюючи регулярні коміти, кожен розробник може зменшити кількість
суперечливих змін. Перевірка тижневої роботи може призвести до конфлікту з
іншими функціями, і їх може бути дуже важко вирішити. Ранні невеликі конфлікти в
певній області системи змушують членів команди повідомляти про зміни, які вони
вносять.
 Внесення всіх змін принаймні один раз на день (один раз на створену функцію)
зазвичай вважається частиною визначення безперервної інтеграції.
 Крім того, як правило, рекомендується виконувати принаймні нічну збірку.
Очікується, що типова частота буде набагато вищою.

 Кожний коміт до основної гілки повинен бути в збірці

 Система повинна створити коміти до поточної робочої версії, щоб переконатися, що
вони правильно інтегровані. Поширеною практикою є використання автоматизованої
безперервної інтеграції, хоча це можна зробити вручну. Автоматизована безперервна
інтеграція використовує сервер для відстеження змін в системі контролю перевірок, а
потім автоматично запускає процес збірки. Слайд 60
 Безперервна інтеграція - практики
 Збірка повинна завершуватись швидко
 Збірку потрібно завершити швидко, щоб у разі виникнення проблеми з інтеграцією її
швидко було виявлено.

 Усі можуть побачити результати останньої збірки

 Повинно бути легко з’ясувати, чи порушується збірка, і, якщо так, то хто вніс
відповідні зміни та в чому полягала ця зміна.

 Автоматизація розгортання
 Більшість систем CI дозволяють запускати тестові сценарії після завершення збірки. У
більшості ситуацій можна написати сценарій для розгортання програми на тестовому
сервері в реальному часі, який кожен може переглянути. Подальшим успіхом у цьому
є безперервне розгортання, яке вимагає розгортання програмного забезпечення
безпосередньо у виробничому середовищі, часто з додатковою автоматизацією для
запобігання дефектів або регресії.
Слайд 61
 Безперервна інтеграція - практики
 Тестування в клоні виробничого середовища
 Наявність тестового середовища може призвести до збоїв у системах під час їх
розгортання у виробничому середовищі, оскільки воно може суттєво відрізнятися від
тестового. Однак створення копії виробничого середовища коштує непомірно.
Натомість тестове середовище або окреме перед-виробниче середовище (“staging")
має бути створено як масштабована версія виробничого середовища для зменшення
витрат. У цих тестових середовищах віртуалізація сервісів звичайно
використовується для отримання доступу на вимогу до залежностей (API, сторонніх
додатків, служб, мейнфреймів тощо), які не контролюються командою або надто
складні для налаштування у віртуальній тестовій лабораторії.

 Кожен коміт для виправлення багів повинен мати тест

 Під час виправлення дефекту доцільно створити тест, який відтворює дефект. Це
дозволяє уникнути повернення дефекту та повторної його появи (регресії).

Слайд 62
 Безперервна інтеграція - практики
 Зробіть легким отримання останніх результатів
 Розміщення збірок для легкого доступу для зацікавлених сторін і тестувальників
може зменшити кількість переробок, необхідних під час відновлення функції, яка не
відповідає вимогам. Крім того, раннє тестування зменшує шанси, що дефекти
доживуть до розгортання. Виявлення помилок раніше може зменшити обсяг роботи,
необхідної для їх усунення.
 Усі програмісти повинні почати день з оновлення проекту з репозиторію. Таким
чином, усі вони залишаться в курсі змін.

Слайд 63
Переваги безперервної інтеграції
 проблеми інтеграції виявляються і виправляються швидко, а значить дешевше
для проєкту;
 негайний запуск модульних тестів з новим кодом;
 постійна наявність поточної стабільної версії разом з продуктами зборок - для
тестування, демонстрації, і т. п.
 негайний ефект від неповного або непрацюючого коду привчає розробників до
роботи в ітеративному режимі з більш коротким циклом.

Слайд 64
Недоліки безперервної інтеграції
 витрати на підтримку роботи безперервної інтеграції;
 потенційна необхідність у спеціальному навчальному сервері під потреби
безперервної інтеграції;
 негайний ефект від неповного або непрацюючого коду відучує розробників від
виконання періодичних резервних включень коду в репозиторій.
• у разі використання системи управління версіями вихідного коду з підтримкою
розгалуження, ця проблема може вирішуватися створенням окремої «гілки»
(branch) проєкту для внесення великих змін (код, розробка якого до
працездатного варіанту займе кілька днів, але бажано частіше резервне
копіювання в репозиторій) . Після завершення розробки та індивідуального
тестування такої гілки, вона може бути об'єднана (merge) з основним кодом або
«стволом» (trunk) проєкту.

Слайд 65
Timeboxing
 виділяється фіксований період часу (timebox) до кожної запланованої активності.
Графік розділений на кілька окремих періодів часу (timeboxes), причому кожна
частина з яких має свої кінцеві результати, терміни і бюджет
 терміни і якість проєкту залишаються незмінними, змінюватися можуть тільки :
 зміст проєкту (об’єм робіт)
 вартість (додаються ресурси)
 використовується в DSDM, RAD, XP та ін.
 може використовуватися для вирішення особистих завдань протягом меншого
часового відрізку

Слайд 66
Крос-функціональна команда (Cross functional team)
 група людей з різними функціональними знаннями, які працюють для
досягнення спільної мети
 може включати в себе людей з областей фінансів, маркетингу, операційної
діяльності, відділу кадрів і т.п. Як правило, включає в себе співробітників всіх
рівнів організації, але може включати також і людей ззовні (зокрема,
постачальники, ключові клієнти або консультанти )

Слайд 67
Крос-функціональна команда (Cross functional team)
 Часто функціонують як команди самоврядування, призначених для реалізації
конкретного завдання, яке вимагає вхідні дані та експертизу від багатьох
департаментів. Призначення задач для команди, що складається з
багатопрофільних осіб, підвищує рівень творчості та нестандартного мислення.
Кожен учасник пропонує альтернативний погляд на проблему і потенційне
вирішення задачі.
 Деякі дослідники розглядають крос-функціональну взаємодію як кооперативне
або конкурентне, в той час як інші стверджують, що функціональні області
організації часто змушені конкурувати і одночасно співпрацювати один з одним (
"coopetition"), і тому дуже важливо зрозуміти, яким чином ці складні взаємини
впливають на продуктивність фірми
 Прийняття рішень в команді може залежати від консенсусу, часто на чолі з
менеджером / тренером / лідером команди. Лідерство може бути серйозною
проблемою для крос-функціональних команд, оскільки на лідерів покладено
завдання спрямовувати членів команди з різних областей.

Слайд 68
Переваги крос-функціональної команди
 Процеси стають «менш односпрямованим» (less unidirectional)
 Обробляється більший обсяг інформації
 Забезпечується велика глибина інформації
 Велике коло співпраці

Слайд 69
Предметно-орієнтоване проєктування (Domain-driven design)

 набір принципів і схем, спрямованих на створення оптимальних систем об'єктів.

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

 не є якою-небудь конкретною технологією або методологією, а набором правил,

які дозволяють приймати правильні проєктні рішення.

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

незнайомій предметній області.

 термін був вперше введений Е. Евансом в його книзі з такою ж назвою «Domain-
Driven Design»

Слайд 70
Визначення DDD:

 Область (domain) — предметна область, до якої застосовується ПЗ, що

розробляється
 Модель (model) — описує окремі аспекти області і може бути використана для
вирішення проблеми
 Мова описання (ubiquitous language) — використовується для єдиного стилю
опису домену та моделі

Слайд 71
Концепція DDD:

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

Слайд 72
Елементи DDD:
 Сутність (Entity) - категорія індивідуальних об'єктів, які мають концептуальну
ідентичність, є незмінними на різних етапах програми, для яких атрибути не грають
великого значення
 Об’єкт-значення (Value object) -   об'єкт, який містить атрибути, але не має
концептуальної ідентичності
 Агрегат (Aggregate) - колекція об'єктів, які пов'язані між собою кореневим об'єктом.
Коренева сутність колекції об'єктів гарантує узгодженість змін, що вносяться до сукупності,
забороняючи зовнішнім об'єктам посилатися на членів колекції
 Подія предметної області (Domain Event) - об'єкт предметної області, який визначає
подію
 Служба (Service) - коли будь-яка операція концептуально не відноситься до будь-якого
об'єкту, вона може бути реалізована в сервісі
 Репозиторій (Repository) – методи отримання об'єктів домену повинні звертатися до
спеціалізованих сховищ таким чином, що альтернативні реалізації зберігання можна легко
поміняти місцями.
 Фабрика (Factory) – методи створення об'єктів домену повинні звертатися до
спеціалізованої фабрики таким чином, що альтернативні реалізації можна легко поміняти
місцями.
Слайд 73
Переваги і недоліки DDD:

Система, заснована на Domain-Driven Design може обійтися дорого, оскільки

розробники повинні поєднати ізоляцію та інкапсуляцію об'єктів предметної області.
У той час як Domain-Driven Design надає безліч технічних переваг, таких як
можливість підтримки (maintainability), Microsoft рекомендує застосовувати його
тільки для складних предметних областей, де модель і лінгвістичні процеси
забезпечують очевидні переваги в подальшому проєктуванні і розробці.

Слайд 74