[PDF]Team Lead Body Of Knowledge (UKR)

Тім лідер (командний лідер) - - теоретичний мінімум


Рік: 2024;


Автор: Дмитро Попов (Айта таїесг ЧНУ), Чернівці. Пієр8://лумуми шакедій сопл/т/дйтаророу/
Працюю розробником більше 8 років, був технічним лідером на декількох проєктах (перший досвід тех лідера
отримав в 2016). Сертифікований Скрам розробник.


Засновано на досвіді автора та Ргоїе85іопа! Агіе І еадег5ПірТМ Сегіїйсацоп (РАІ. Г), також на 5УУЕСОМ (ШЕНЕ) 1
РМВОК Спшаєе (РМІ).


Залучені матеріали з книг:

. Фред Брукс, "Міфічний людино-місяць" (1975),

. Геральд Вайнберг, "Стати технічним лідером" (1986),

. Кент Бек, "Екстремальне програмування" (1999),

Генк Рейнвотер, "Як пасти котів" (2002),

Роберт Мартін, "Гнучка розробка" (2002),

Стівен Палмер, "Практичний посібник з функціонально-орієнтованої розробки" (2002),
Майк Коєн, "Гнучке оцінювання та планування" (2005),

. Кен Швабер та Джефф Сазерленд, "Посібник зі Скраму" (2010).


СК КР


Зміст


Хто такий технічний лідер в команді?........... шана З
Шаблон команди та основних конвенціїй.......... «анна нн 14
ПроОметоди півосі БВ оон Ло іа а бла ке 16
СсофеокІЛли -- БаЗОвІзнання дн нер оранці намалювали 18
Методології розробки програмного забезпечення........... ана 19


Яклтисати вимоги? лона ар ва а 94


Хто такий технічний лідер в команді?


"Лідерство - - це не про знання правильної відповіді, а про вміння знаходити правильну відповідь"
(Кріс Латтнер, розробник мови Зуміїї)


Перед розглядом посади "технічний лідер", розглянемо структуру команди.


В книзі "Міфічний людино-місяць" Фред Брукс пише, що команди розробників, які спільно працюють
над задачею, повинні бути невеликі, приблизно 10 людей.

Джефф Сазерленд 1 його 5сгит методологія також каже, що команда повинна складатися з 4-10
людей.

Якщо проєкт величезний, то організовуються декілька самодостатніх команд, кожна з яких працює
над своєю частиною проєкту. Це може навіть відбиватися на архітектурі проєкту, зокрема,
використовують мікросервісну архітектуру та мікрофронтенд. Між-командну взаємодію виконують
лідери команд та технічний директор (СТО).


І Фред Брукс і Зсгит-методологія вважають, що команда повинна бути крос-функціональна.


Команда з крос-функціональним складом включає в себе фахівців із різних областей, необхідних для
виконання проєкту чи завдання. У контексті 5сгит це зазвичай означає наявність учасників із різними
навичками у сферах дизайну, розробки, тестування та інших необхідних компетенцій. Це різноманіття
допомагає команді вирішувати різні аспекти проєкту без постійного залучення зовнішніх ресурсів,
сприяючи ефективності та співпраці. ОА спеціаліст (тестувальник) вважається частиною З5сгит
команди та слугує, щонайменше для двох цілей:

1. Програміст не повинен виключно сам тестувати свій код (як каже книга "Мистецтво тестування"
Гленфорда Майерса).

2. Звіт менеджеру проєкту про відсутність виявлених багів (помилок). Помилкою (багом) вважається
відхилення від специфікації.


Відповідно до 5сгит, команди є багатофункціональними (сго85-Гипсопаї), тобто учасники мають
усі навички, необхідні для створення цінності кожного спринту (ітерації розробки). Хоча
багатофункціональні команди повинні мати різноманітний набір навичок, це не означає, що кожен
член повинен бути експертом у всіх сферах. Основна увага приділяється володінню навичками,
необхідними для поступового постачання продукту. У той час як команди можуть вибрати людей, які
мають Т-подібний набір знань, деякі команди можуть вибрати експертів з бізнес-аналізу або експертів
з тестування. (5сгит 15 дейпей їп Фе 5сгит Сиіде бу Кеп 5сругабег апа /еїї 5иШегіапа).


Т-подібні навички (Т-5Ппареа 5КІШ5) - - це комбінація глибоких знань у конкретній області
(вертикальна частина "Т") і широкого спектра загальних навичок (горизонтальна частина "Т"). Це
означає, що людина має глибокі експертні знання в одній області, але також може працювати та
спілкуватися ефективно в інших галузях.


Технічний лідер та лідер команди повинні мати Т-подібні навички, а не фреймове мислення.


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


Фред Брукс пропонує розглядати технічного лідера в команді, як хірурга в операційній. В операційній
є головний хірург 1 його асистенти, які йому допомагають. Хірург робить головні рішення. В такому
випадку маємо чітку ієрархію в команді та обов'язки. Звісно, що така команда не може бути великою,
до 10 людей. Цей підхід особливо добре працює, якщо в команді є початківці, або спеціалісти
середнього рівня, які не мають достатньої експертизи. Цей підхід працює навіть, якщо в команді всі
спеціалісти високого рівня. Тех лід пояснює структуру проєкту й каже, що кому робити відповідно до
його навичок. Тех лід може консультуватися з учасниками команди, впроваджувати перехресне рев'ю
коду. На тех ліді відповідальність за технічну частину проєкту, тому він повинен контролювати дії та


знання інших розробників, вказувати на те, що потрібно вивчити й змінити.

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


Технічний лідер може виконувати роль тім лідера, але також це можуть бути окремі ролі.


Обов'язки лідера команди (сеата Ісад):

1. Спілкування з Ргодисі омпег (Власник Продукту (Ргодисі Ом/пег) - - представляє зацікавлені
сторони (з:акепоЇдег5) та є голосом клієнта).

. Спілкування з менеджером проєкту.

. Спілкування з іншими командами.

. Контроль комунікації в команді.

. Розгляд кар'єрного росту (Аєм ріап).

. Пріоритет задач.

. Складання гоадтар та беклогу (списку задач).
. Комунікація з технічним лідером.

. Деякі технічні задачі, код рев'ю.

0. Документація.


мл она ілроОом


Тім лідер може бути Скрам майстром, а проєктний менеджер мати роль Продукт овнера.


У чудовій книзі про технічне лідерство Джеррі Вайнберг пропонує модель лідерства МОЇ:
Мотивація: Здатність заохочувати технічних людей робити якнайкраще.

Організація: Здатність формувати існуючі процеси (або винаходити нові), які дозволять втілити
початкову концепцію в кінцевий продукт.

Ідеї чи інновації: Здатність заохочувати людей творити та відчувати себе творчими, навіть якщо вони
повинні працювати в межах, встановлених для певного програмного продукту чи програми.


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


Теат (сад (тім лід) тільки один в команої, технічних лідерів може бути декілька. Наприклад,
командний лідер може контролювати всю Зсгит крос-функціональну команду, в якій є група бекенд
розробників та група фронтенд розробників, кожна з яких має свого технічного лідера.


Обов'язки технічного лідера (гесб Ісаа):
1. Архітектура й стек технологій проєкту.
2. Перехресне код рев'ю.

3. Технічний менторінг спеціалістів.

4. Введення стандартів коду.

5. Налаштування СІ/СР (з РеуОр5).

6. Технічна документація.


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


Найм працівників виконує тех лідер разом з тім лідером. (Якщо тім лід 1 тех лід є однією особою, тоді
риб Гасіог збільшується, і можливість зірвати терміни релізу, деадіпе, також).


Лідер команди (тім лідер) повинен добре комунікувати з командою, залучати технічного лідера для
обговорення технічних аспектів, налагоджувати розвиток команди.


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


Програміст повинен аналізувати вимоги, давати естімацію (оцінку задач), робити декомпозицію
задачі.

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


Також є формула оцінки якості виконання задачі перед етапом ОА:
1 - (Час на виправлення багів / час початкової естімації).


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

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


Якості лідера, які описані в книзі Генка Рейнвотера "Як пасти котів":

. Системне мислення, тобто розуміння зв'язків.

. Широке мислення всім інтелектом, баланс між логікою й естетикою.
. Вміння аналізувати.

. Самокритика, вміння вчитися на помилках.

. Вміння делегувати завдання.

. Вміння слухати.

. Нормативна й чітка мова, вміння висловлюватися.

. Розуміння процесів та цілей бізнесу.


со -А с лом ма


Антипатерни лідера команди:

1. Диктатор 1 генерал.

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

"Генерали" виявляють значну схожість із диктаторами, виявляючи у своїй діяльності ще більшу
жорсткість. Якщо ви уявили себе генералом, а своїх підлеглих вважаєте солдатами, майте на увазі:
битви із противником вам доведеться вести одному. Солдати, швидше за все, будуть сидіти десь у
кутку, спокійно попиваючи каву. Протистоїть такому підходу стиль співпраці - - 1, ви знаєте, він має
широке вживання просто тому, що він правильний. Під час війни співпраця рідко має місце. У сфері
розробки програмного забезпечення, навпаки, важко уявити ситуацію, у якій встановленню відносин
з урахуванням співробітництва щось перешкодило б.


2. "Всезнайка". Такий діяч щиро вірить у те, що йому відомо все про його роботу, роботу компанії,
про конкретні завдання програмістів. Він буде нехтувати порадами інших. Буде часто робити
помилки. (Як казали багато філософів, чим більше знаєш, тим краще бачиш безодню невідомого).


3. Альфа "ботан".
Людина, яка постійно вказує на чужі помилки, як на невігластво. Думає, що всі мають знати те, що
він, і ще більше. Такий працівник просто не розуміє психологію людей і що люди різні.


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


Деякі причини для звільнення члена команди:

1. Саботаж роботи, свідоме затягування процесів.

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

4. Очевидна байдужість до продукту, відстороненість.


Відомий принцип тестування каже: Не плануйте тестування, виходячи з припущення, що помилок не
буде виявлено.

Але це не означає, що ви маєте робити припущення про те, що програміст не старанно працює.
Завжди вважайте, що розробник свідомо не винен у виникненні помилок, інакше будуть конфлікти,
тобто застосовуйте презумпцію невинуватості. Це так звана Айтібийоп Ніа5.


Командний й технічний лідер повинен контролювати, щоб розробники середнього рівня:
1. Розвивались, вивчали необхідні технології.

2. Не робили критичних помилок.

3. Не вводили експериментальні, не надійні технології.

4. Виконували свою роботу.


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


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


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


Комунікація дуже важлива в команді.

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

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


Закон Конвея - "Будь-яка організація що проєктує системи, з великою ймовірністю створить дизайн
зі структурою, яка буде копією структури комунікації в компанії".

Закон Конвея можна довести математично. Наприклад, у вас обмежений час і спілкуватися ви можете
тільки азбукою Морзе. В таких умовах людина буде шукати найкоротше рішення відповідно до
обмежень комунікації. Інший приклад, вам потрібно пояснити щось по телефону, але ціна розмови
дуже висока. Ви буде підбирати найкоротшу форму пояснення, щоб досягнути цілі. Ці приклади


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


РМВОК каже: "
Однією з цілей ефективного лідерства є створення високоефективної проєктної команди. Існує кілька
факторів, які сприяють створенню високоефективних проєктних команд:


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


Спільне розуміння. Мета проєкту та переваги, які він принесе, є загальними для всіх учасників.


Спільна відповідальність. Чим більше учасники проєктної команди відчувають відповідальність за
результати, тим краще вони, ймовірно, будуть працювати.


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


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


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


Стійкість. Коли виникають проблеми або невдачі, високоефективні проєктні команди швидко
відновлюються.


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


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


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


Портфоліо - - проєкти, програми, дочірні портфоліо та операції, якими керують як групою для
досягнення стратегічних цілей.


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


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


У своїй колекції нарисів про невдалі програмні проєкти Роберт Гласс (Кобегі СІаз5) склав список
найбільш поширених "програмних катастроф", зокрема:

1. Неадекватний опис завдань проєкту.

2. Незадовільне планування та оцінка.

3. Застосування нової для цієї компанії технології.

4. Непридатна/відсутня методологія керівництва проєктом.

5. Нестача провідних спеціалістів групи.

6. Зрив домовленостей виробниками апаратного/програмного забезпечення.


Ви5 Гасіог (фактор автобуса) проєкту - - це кількість ключових учасників команди, які у випадку
втрати своєї дієздатності, призведуть до неможливості рухати спільний проєкт далі. Вия Гасіог є
мірою зосередження інформації поміж окремими учасниками проєкту. Високий бБи5 Гасіог означає, що
проєкт зможе продовжувати розвиватись навіть за несприятливих умов.

Вищий Би5з Гасіог означає більшу стійкість проєкту до втрати ключових фахівців.

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


Для зменшення "риб Гасіог" у 5сгит, рекомендується:


1. Робити соде геуіему8: Забезпечте, щоб код переглядали інші члени команди, це допомагає із
взаєморозумінням коду.


2. Документація: Створюйте докладну технічну документацію, щоб інші розробники могли легко
розуміти та працювати з вашим кодом.


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


4. Ротація завдань: Дозволяйте різним членам команди працювати з різними частинами проєкту, щоб
було більше людей, які розуміють всю систему.


Ці підходи допоможуть розподілити знання 1 знизити ризик через "Би5 Гасіог".


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


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


МУСУУ метод - - це техніка пріоритизації, яка використовується у проєктному менеджменті для
визначення важливості вимог в проєкті. Цей метод названий за абревіатурою з англійських слів Ми5і,
Зпоціай, Соцій та М/оп'ї, які представляють різні рівні пріоритетів:


1. Мизі Паме (Має бути) - це обов'язкові елементи та умови, без яких проєкт не може вважатися
завершеним або успішним. Вони є критичними для успіху.


2. 5роцід Бауе (Повинно бути) - це важливі елементи, які мають велику цінність для проєкту, але їх
відсутність не є критичною.


3. Соцід Пауе (Могло бути) - це бажані елементи, які могли б бути включені, якщо дозволяє час та
ресурси. Вони не є критичними та можуть бути легко відкладені.


4. Моп'ї рауе (Не буде) - це елементи, які зараз не розглядаються або не включаються в поточний


обсяг проєкту.


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


Маніфест гнучкої розробки (Ал?іїе):


1. Люди та співпраця важливіші за процеси та інструменти.

2. Працюючий продукт важливіший за вичерпну документацію.

3. Співпраця із замовником важливіша за обговорення умов контракту.
4. Готовність до змін важливіша за дотримання плану.


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

Кожен мікросервіс може бути розроблений та підтримуватися окремою командою розробників.


Перехресне рев'ю коду - - практика перегляду коду, коли рев'ю коду можуть робити учасники команди
будь-якого рівня (а не тільки розробники однакового рівня).


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


Приклади:
1. "Я не вірю тобі щодо цієї проблеми, ти ж завжди робиш помилки",


2. "Цей вчений не вартий уваги, він не має навіть докторського ступеня",
3."Яне підтримую твою позицію, ти ж ще молодий і не маєш досвіду".


Атрибутивне упередження (Айгібибіоп Віа5) - це когнітивне упередження, яке виникає, коли люди
схильні приписувати причини подій або поведінки інших людей на основі власних упереджень або
обмеженого сприйняття, а не на основі об'єктивних фактів.

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


Вирішення конфліктів ефективно включає кілька кроків:

1. Визнання конфлікту: усвідомте, що є конфлікт і будьте готові його вирішити.

2. Зберігайте спокій та зосередженість: контролюйте емоції, щоб чітко і конструктивно спілкуватися.
3. Розумійте всі перспективи: слухайте всіх учасників, щоб зрозуміти їхні точки зору та занепокоєння.
4. Зосередьтеся на проблемі, а не на особі: адресуйте конкретну проблему, а не особистісні риси.

5. Знайдіть спільну мову: визначте спільні цілі чи інтереси, щоб побудувати основу для домовленості.


6. Генеруйте рішення: спільно працюйте над можливими рішеннями, заохочуючи креативність і
відкритість.


7. Оцінюйте рішення: аналізуйте доцільність та вплив кожного рішення, щоб знайти найкращий
варіант.


8. Дійдіть згоди щодо рішення: вирішіть, яке рішення можуть прийняти та на яке зможуть
зобов'язатися всі сторони.


9. Впроваджуйте рішення: реалізуйте обране рішення на практиці та моніторьте його ефективність.


10. Здійснюйте перевірку: перевіряйте через деякий час, чи було конфлікт вирішено 1 чи працює
рішення. За потреби вносьте корективи.


Книги для лідерів команди:

1. "Негдіпе Саїз: А Ргітег Їог Ргостатитегт8 У/Бо Іеад Ргодгатлтегя" бу НапК Ваїпу/аіег,
2. "Тре Мушіса! Мап-Мопі" Бу Еге ВгоокКе,

3. "Тре Мапарегз Раф: А Сиїде Гог Тесі І.садег8" бу Сатійе КЕоигпіег,

4. "Сівап Аєііе: ВасК іо Вазіс5" бу Кобегі Магіїп,

5. "Зсгит: ТВе Агі ої роїпе Тутсе Ше М/огКк іп Най Ше Тіте" Бу /еїї Зиїрегіапа,

6. "І. сагпіпе Аєїе: Упаегзіапйте Зсгит, ХР, І.сап, апа Капбап" Бу Апагеуу 5ісШтап,


7. "Ехітете Ргогтатитіпе Ехріаїпед" бу Кепі Веск.


Абзіїе МІ 58їасК:


"Адіїеє Зо0йате Дреуеіортепі: Ргіпсірієз, Райетпз8, апа Ргасіїсе8" Бу Кобегі С. Магіїп,
"Авіїе Езйтайтя апа Ріаппіпеє" бу Міке Собп,

"Абдіїе Те5іпе: А Ргасіїса! Сиіде Гог Тезіег5 апа Адіїе Театя" Бу Ілзєа Стізріп,

"Адіїе Ргоіесі Мапаєєтепі Еог Дипатіез" бу МагК С. Гаубоп,

"Абдіїе Ргоіесі Мапаєєтепі" Бу /еЙтеу Кіе5,


"Сівап Адіїе: ВасК іо Вазісз»" бу Кобегі Сесії Магіїп,


Ехітете ргобгаттіпя:

"Ехітете Ргогтататіпе Ехріаїпед" Бу Кепі ВескК,
"Тевійпє Ехітете Ргогтаттіпє" Бу Ілз5а Стівріп,
Усгим:

"Зсгит виїде" бу Кеп 5сруабег апа /еїї 5ЗиШегіапа,


"Еззепна! Зсгит: А Ргасіїса! Сиіде іо Ше Мові Рориїіаг Аєїіе Ргосе85" бу Кеппеї Кибіп.


рієря: //мумучу.5сгита.оге/


Шадлон команди та основних конвенцій


Хочете підвищити ймовірність успіху проєкту, найміть мінімум двох Сеньйорів в команду, також
бажано Сеньйора ОА, найміть Сеньйор Скрам майстра, і ще досвідченого ДеуОря5 спеціаліста. Чітко
пропишіть, що якість коду має бути одним з приймальних критеріїв. Покривайте код автоматичними
тестами, з боку розробників та ОД. В команді має бути тех-лідер, який постійно слідкує за якістю
коду. Чітко виконуйте всі Скрам церемонії. КРІ визначається на основі цінності інкременту в спринті.
Налаштуйте тестове середовище, та СІ/СР.


ОЕМ Ул ОР5


Як лідер команди/технічний лідер переконайтеся, що ці процеси налаштовані ретельно:


-5сгит, ХР (5іогу роїпіз ез(тайоп, кеапі согатипісайоп, геїгозреспує, соПесіує оуупет8Нір,
сопатійтепі).

Ветегпабег Сопууау'я Іам/, ВгооКз'8 Їам,, 5 5сгит уаїшез8.

-СтРіом. (Мопогеро ог роіугеро)

-Втапсб патіпє сопуепіоп.

-Сопатії тез5аєе сопуепіїоп.

-Соде геміему єміде (соде 5їуЇе витде).

-СУСР. Сопіпиоц5 Піевтайоп (СТ) - 15 а ргасіїсе, пої |ц5ї а ї00і.

Стеаїе а 5егуєг Гог Ше БасКепа, 50 їгопіепа деуеЇорег8 ууоцідп'ї рауе (о 5еї пр пе даїабазе ЇосаПу абег
сасі срапре ої БасКкепа.


(АМУ/5 СодеРірейпе, Сі. аб, СтЕНш).


-Лга Пому (аз Ббоага Пому).


-Рго|есі їєсп досиштепіайоп (Зу/аєєег, Старі ОЇ).
-Ртодесі (арр) іпзтаЙайоп доситепіайоп.
-Опроагдйте доситепіайноп.

-Арр уег8іопіпе (5еттуєег.оге).


-СресК "Виз Касіог".


Ргортататегя їп їсат песа:


Кедцітетепіз (Кієта, Р5, Сопйиепсе, Со0єЇе Досз, 5 тагіПДосз).
«ДЛОХ Дезієп арргоуед бу Ргортаттег.

С 5егуег, СІ/СЮ (Ст аб, Віїискеї, Дієта! Осеап, НегоКи, АУМУЗ).

- Ріасе Гог согатипісайоп (З1асК, 5Куре, Сооєїе Мегеі, 2о0т, Місгоб8ої).
« Евійтайоп (РосКег апа Т-5Бітгі е5ітайоп).

- Бузіет Гог ігаскіпе їа8К 5їашшя (Лга).

« МеШодоїіоєу (Уагетіаї!, Аріїе).

» Соде 8іапдагд8, Соде геуіему.

« Те5ітє, ипії їе5і ()е50), Е2Е 1езіз (Сурге588, РІіаумтіє бо).


У своїй колекції нарисів про невдалі програмні проєкти Роберт Гласс (Кобегі СІаз5) склав список
найбільш поширених "програмних катастроф", зокрема:

1. Неадекватне специфікування завдань проєкту (5 1970).

2. Незадовільне планування та оцінка (48 90).

3. Застосування нової для цієї компанії технології (4590).

4. Непридатна/відсутня методологія керівництва проєктом (4290).

5. Нестача провідних спеціалістів групи (4290).

6. Зрив домовленостей виробниками апаратного/програмного забезпечення (4290)


Джерела:


рирз://лумлу. сопУепіопаї сопатіїв.оге/еп/у 1.0.0/
рирз://пуіе.сотп/ро5і8/а-5пссе88ці-є1і-бтапсбіпе-подсі/

рерг// мулу. ехітетергостаттіпо.оге/гиіе8.Биті

рієр8: //8сгштеціде8.ого/

рирз://5етуег.ого/
рирз://4еуло/маг5ап/а-вітаріїбед-сопуепіїоп-Їот-патіпе-ргапспезв-апда-сопатїі-їп-91(-114
рір8://вбо0єЇе.сїриф. 10/5суЇевиіде/


ВооКк5 Шаг мій Пе!р а кеат Ісадег.


. "Негдйїпє Саїз: А Ргітег бог Ргобгататегя МПо сад Ргоргаттетя" Бу НапК Каїпу/атег,
. "Тре Мушфіса! Мап-Мопіф" Бу Еге ВгоокКе,

. "Тре Мапаєеєг'8 Ра: А Сшіде їог ТесП І садегя" бу Сапийе Коитпіег,

. "СІвап Аєііе: ВасК іо Вазіс8" бу Кобегі Магіїп,

. "Зегит: Тбе Агі ої Роїпеє Тмісе ре МотК їп Най їБе Тіте" Бу єї 5ЗиМегіапа.


сл фо м юн


Про методи співбесіди


ЗТАВ Іпіегміему Менпод


5їкшабіоп Таз5к Асіїоп Везиїі5


5ЕТ ТНЕ ОЕЗСВІВЕ ТНЕ ЕХРІАІМ М/НАТ ЗНАВЕ ТНЕ
СОМТЕХТ РОЮВРОЗЕ УОЮ РІО ООТСОМЕ


1. Питання про досвід. Про складні задачі.


Плюси: Дають в загальному зрозуміти рівень кандидата.
Мінуси: Не завжди релевантні, тобто не дають змогу точно оцінити.


2. Постановка закритих питань (бінарних питань), які потребують короткої та однозначної відповіді.


Плюси: Легко виявити помилку.
Мінуси: Не показують цілісність знань та взаємозв'язки між ними.


3. Відкриті питання (ореп-епаед диезіоп).


Плюси: Можуть виявити цілісність теоретичних знань.
Мінуси: Потребують більше часу та аналізу.


4. Ситуативне інтерв'ю: під час інтерв'ю кандидату пропонується вирішити змодельоване завдання,
певну ситуацію (наприклад, вихід за межі спринту, або збір вимог).


Плюси: Показує практичні вміння кандидата.
5. Лайф кодинг.


Плюси: виявляє практичні навички кандидата, та його вміння.
Мінуси: Потребує багато часу і не точно відповідає умовам реальної роботи.


6. Метод ЗТАБ - - це техніка для відповідей на співбесіді, що включає чотири елементи: Ситуація
(опис контексту), Завдання (виклик, який виник), Дія (конкретні кроки, які ви зробили), та Результат


(ваші досягнення або вплив дій).
9 - 58ішайоп - ситуація,

Т - та8Кк - завдання,

А- асйоп - дія,

В -- гезиїї - результат.


Метод 5ТАК найдоречніше застосовувати при відповідях на запитання, які починаються і слів:
"Опишіть ситуацію, коли ви..."


Тривалість співбесіди бажано, щоб була не більше двох годин, краще година, півтори (тобто дві
академічні години).


Софт скіли -- базові знання


Перший крок до спілкування - - бажання почути думку. Якщо людина хоче Есро сбатрег, це не
спілкування, максимум Сопіттайоп Біа5.


Також важливо не робити Айгібийоп Біа8, дивіться на реальні обставини.


Пасивна агресія та вислови з підтекстом (Іоадед дицезіоп5) дуже шкідливі.

Пасивно-агресивна поведінка характеризується пасивною ворожістю та уникненням прямого
спілкування. Замість прямих висловлювань, співрозмовник говорить (або пише) з негативним
підтекстом.


В принципі, 5 Зсгит уаїез мають налаштувати здорову атмосферу в команді.


Успішне використання Скрам залежить від того, наскільки вміло люди втілюють наступні п'ять
принципів:

Почуття обов'язку (Сопатійтепі),

Зосередженість (Роси5),

Відкритість (Ореппе55),

Повага (Вевресі) та сміливість (Соига?е).


Дивіться 5сгит біде в перекладі Тетяни Островерх.


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


Що таке 5сгит?


Скрам був розроблений насамперед як фреймворк для розробки програмного забезпечення. Він
враховував попередні напрацювання інженерів в таких методологіях як ЕД та ХР. Можна сказати,
що шлях до Скраму та Ехітете Ргостаттіпє (ХР) почався в 1960-х роках, коли виник "50Ймаге стізі8"
та стихійна (хаотична) розробка з мікроменеджментом.


Зсгит (Скрам) та Ехітете Ргорггатітіпе (ХР) грунтуються на Адіїе маніфесті.


Перша редакція Аєїе маніфесту була написана з 11 по 13 лютого 2001, на гірськолижному курорті в
горах Юти.

Серед авторів маніфесту були: Кент Бек, Роберт Мартін, Мартін Фаулер, Ендрю Хант, Дейв Томас,
Кен Швабер, Джефф Сазерленд.


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


1. Люди та співпраця важливіші за процеси та інструменти.

2. Працюючий продукт важливіший за вичерпну документацію.

3. Співпраця із замовником важливіша за обговорення умов контракту.
4. Готовність до змін важливіша за дотримання плану.


Гнучкі методики розробки (адіїе 5оЇбмаге демеїортепі, Адіїе розробки) - - узагальнюючий термін для
цілого ряду підходів і практик, що грунтуються на цінностях Маніфесту гнучкої розробки
програмного забезпечення та 12 принципах, що лежать у його основі.


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

Кен Швабер та Джефф Сазерленд вперше спільно представили 5сгит на конференції ООР5І А у 1995
році.


П'ять цінностей Скраму: Сміливість - - приймати виклики, Зосередженість - - концентруватися на
важливому, Відданість (согатійтегпі) - - відповідальність за досягнення цілей, Відкритість - -
прозорість у спілкуванні, Повага - - цінування внеску кожного члена команди.


Фреймворк - - це каркас, або система принципів, яка встановлює певні рамки для роботи.
Ролі в Зсгит:


- Власник продукту (Ргодисі Омупег): Представляє клієнта та визначає, що потрібно будувати.
- Скрам-майстер (5сгит тазіег): Налагоджує процес Зсгит 1 допомагає команді подолати перешкоди.
- Команда розробників: Крос-функціональна команда, відповідальна за доставку продукту.


Найефективнішим і дієвим методом передачі інформації команді розробників 1 всередині неї є бесіда
віч-на-віч.


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

Колаборативний характер крос-функціональної команди 5сгит сприяє відчуттю спільної
відповідальності.

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


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

Крос-функціональні команди призначені для концентрації на одному проєкті або продукті одночасно.
Ефективна координація та комунікація все ще є ключовими в крос-функціональних командах.
Команда Зсгит складається з одного 5сгит Мазіег, одного Ргодисі Ом/пег та розробників. У команді
Зсгит немає підкоманд чи ієрархій. Це згуртований підрозділ професіоналів, які зосереджені на одній
меті за раз, цілі продукту.

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

Технічний лідер, який часто називається "ТесП І. сад", може існувати в 5сгит команді для керування
технічним боком проєкту. Він відповідає за архітектуру та технічне бачення, допомагає команді у
розв'язані складних технічних проблем та забезпечує якість коду.


Зсгит вимагає від Скрам-майстра створення середовища, де:


1. Власник продукту розміщує роботу для складної проблеми у ВасКіоє продукту.

2. Команда Зсгит перетворює відібрану роботу на приріст вартості (Інкремент цінності) під час
спринту.

3. Команда Зсгит та її зацікавлені сторони (5іакероїдег5) оглядають результати та вносять корективи
на наступний спринт.

4. Процес повторюється.


СВОМ РЕОСЕЗ5


ЗРАІМТ
ВАСКІ06


ОЗЕВ СТОВІЕ5 Г ДОАЕМІРЗОМ


аб


-


ЗЕГЕСТЕО
РВОРОСТ
ВАСКІ0б


У5РАІМТРІ АММІМО


ІОВЕМІРЗИМ
ТОВЕМІР5ИМ


ЄРВІМТРІ АКМІН


р 5
и .


Під час Зсгит спринту ідеї перетворюються на цінність.
Спринти - - це фіксовані за часом події тривалістю один місяць або менше (2 тижні).
Новий спринт починається негайно після завершення попереднього.


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


Під час спринту:

- Не вносяться зміни, які б могли загрожувати меті спринту;

- Якість не знижується;

- Беклог (расКіоє) продукту уточнюється за потреби; і,

-Об'єм (5соре) може бути уточнений та переглянутий з Власником продукту, коли стане відомо
більше.


Спринт можна скасувати, якщо ціль спринту застаріє. Лише Власник продукту має право
скасувати спринт.


Зазвичай проєкт у методології 5сгит дотримується цих правил:

Кожен спринт починається з планування, проведеного Скрам-майстром, Власником продукту та
рештою команди, і складається з наради (теейпе), розділеної на дві частини, кожна з яких обмежена в
часі чотирма годинами. Домашнє завдання Власника продукту перед спринт-плануванням - -
розробити пріоритетний беклог продукту, що складається з набору елементів (пет), які користувачі
та зацікавлені сторони погодили. У першій частині наради (зустрічі) Власник продукту співпрацює з
командою, щоб вибрати елементи, які будуть доставлені до кінця спринту на основі їхньої цінності та
оцінки роботи, яку вони вимагають. Команда згодна продемонструвати робоче програмне
забезпечення, що включає ці елементи, до кінця спринту. Ця перша частина обмежена в часі (для
спринту тривалістю 30 днів вона обмежена в часі чотирма годинами; для коротших спринтів вона
пропорційно коротша), так що в кінці команда бере все, що вони вже зробили, і використовує це як
беклог спринту. У другій частині наради члени команди (з допомогою Власника продукту)
визначають індивідуальні завдання, які вони використовуватимуть для реальної реалізації цих
елементів. Знову ж таки, ця частина обмежена в часі в залежності від тривалості спринту. На кінець
планування спринту вибрані елементи стають беклогом спринту.


Команда проводить щоденну Зсгит нараду (Даїйу Зсгит тееїітя) щодня. Всі члени команди
(включаючи Зсгит-майстра та Власника Продукту) повинні брати участь, а зацікавлені сторони
(з'акепоідетз) також можуть брати участь (але повинні залишатися тихими спостерігачами). Нарада
обмежена в часі 15 хвилин, тому всі члени команди повинні приходити вчасно. Кожен член команди
відповідає на три питання: Що я зробив з моменту останньої щоденної наради? Що я збираюся
зробити між цією та наступною щоденною нарадою? Які перешкоди та завади стоять на моєму
шляху? Кожен член команди має бути лаконічним; якщо відповідь потребує обговорення, відповідні
члени команди планують наступну нараду відразу після наради.

Дейлі мітинг (стендап) повинен бути не більше 15 хвилин. В ньому беруть участь "Розробники" - всі,
хто робить щось для інкременту в спринті. Інші гості можуть бути хіба як спостерігачі, але на них час
не виділяється.

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


Кожний спринт обмежений в часі певною тривалістю, визначеною під час планування спринту: багато
команд використовують 30 календарних днів, але ця тривалість може відрізнятися - - деякі команди
обирають двотижневі спринти. Протягом спринту команда перетворює елементи беклогу спринту в
робоче програмне забезпечення. Вони можуть отримувати допомогу від людей, які не є членами
команди, але такі люди не можуть диктувати команді, як виконувати їхню роботу, і повинні довіряти
команді доставку. Якщо хтось з команди виявляє посередині спринту, що вони зобов'язалися занадто
багато або що вони можуть ще додати елементи, вони повинні переконатися, що Власник продукту
дізнається, як тільки вони розуміють, що спринт у небезпеці. Власник продукту (Ргодисі омпег) - -
член команди, який може співпрацювати з користувачами та зацікавленими сторонами, щоб
переглянути їх очікування, і використовувати цю інформацію для коригування беклогу спринту, щоб
відповідати фактичній потужності команди. І якщо вони виявляють, що у них закінчиться робота до
кінця спринту, вони можуть додати більше елементів до беклогу спринту. Команда повинна тримати
беклогу спринту актуальним та видимим для всіх. Ргодисі омтег - це роль.


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


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


Після спринту команда проводить зустріч ретроспективи спринту (єзргіпі геїгозресйує теейпе), щоб
знайти конкретні шляхи поліпшення своєї роботи. Участь беруть команда та 5сгит-майстер (І, за
бажанням, Власник продукту). Кожна людина відповідає на два питання: Що пішло добре під час
спринту? Що може покращитися у майбутньому? Зсгит-майстер фіксує будь-які покращення, 1
конкретні елементи (такі як налаштування нового сервера збирання, впровадження нової практики
програмування чи зміна офісного розташування) додаються до беклогу продукту.


У методології 5сгит є поширений інструмент, який називається "Зсгит Боага" або "Капрап
Боага". Це зазвичай цифрова дошка (або фізична дошка), розділена на колонки, що представляють
різні етапи роботи, такі як "То До", "Пп Ргоєге88" 1 "Допе". Дошка допомагає візуалізувати прогрес
завдань або користувацьких історій протягом спринту або проєкту, що полегшує команді відстеження
їхньої роботи та виявлення будь-яких заторів або проблем.


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


Навантаження (1.оад) - - це кількість роботи, обрана командою для поточного спринту. Це кількість
роботи, яку команда планує завершити протягом спринту. Воно повинно бути менше або рівним
ємності.


Швидкість (Уеїостуу) - - це кількість роботи, завершена в попередніх спринтах. Це міра минулої
продуктивності команди. Зазвичай дивляться на останні три-п'ять спринтів і беруть середнє значення
їхньої швидкості.


Ось формули:

швидкість ?2- ємність 2- навантаження,

буфер - ємність - навантаження

Різниця між ємністю та навантаженням - - це ваш планувальний буфер.


- Беклог продукту: Пріоритетний список функцій та покращень.

- Беклог спринту: Функції, обрані з Беклогу продукту для спринту.

- Інкремент: Сума всіх завершених завдань в кінці спринту.

- Спринт: Часовий блок (зазвичай 2-4 тижні) під час якого створюється потенційно готовий до
відвантаження інкремент продукту.

- Планування спринту: Зустріч для планування роботи на майбутній спринт.

- Щоденний 5сгит (Раїу З5сгит): Коротка щоденна зустріч для синхронізації та планування роботи на
день.

- Огляд спринту (зргіпі геміем/): Демонстрація завершеної роботи в кінці спринту.

- Ретроспектива спринту: Аналіз минулого спринту для покращення процесів.

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


Щоденний Зсгит - - це подія тривалістю 15 хвилин для розробників команди 5сгит.


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


Мета ретроспективи спринту -- спланувати способи підвищення якості та ефективності.


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


Скрам в основному зосереджений на організаційних процесах розробки програмного забезпечення,
але Екстремальне програмування (Ехітете Ргоргататіпя, ХР) навпаки, акцентується на процесах
кодування та тестування. ХР було розроблено Кентом Беком. Воно підкреслює керовану тестами
розробку (Те5і-Дгіуеп Реуеїортепі, ТОР), парне програмування, спільну власність, постійну
інтеграцію/постійне розгортання (Сопійпиоця Ппіеєтайоп/Сопійпиоця Деріоутепі, СІ/СР) та невеликі
ітерації.


5огу Роїпі (Сторі пойнт) та міфічна людино-година.


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


затягує його ще більше". Додавання більшої кількості людей до завдання, яке дуже поділене,
наприклад, прибирання номерів у готелі, зменшує загальну тривалість завдання (аж до моменту, коли
додаткові працівники заважають один одному). Однак інші завдання, включаючи багато
спеціальностей у проєктах програмного забезпечення, менш подільні. Щоб вирішити ці недоліки
поняття "людино-година", були створені 5іогу роїпія в 5сгит.


Уогу роїпі (Очки складності завдання) - це одиниця виміру, яка використовується в методології
розробки програмного забезпечення для оцінки складності задачі. Вона використовується для
приблизної оцінки часу і зусиль, не прив'язуючись до конкретної часової рамки.


Коли команда розробників оцінює задачу, вони приймають у розгляд три основні фактори: складність,
обсяг роботи та ризики. Вони потім призначають задачі певну кількість 80огу роїпіз, яка відображає
загальну складність. Чим більше 5іогу роїпіз8, тим складніше завдання. Це дозволяє команді
спрогнозувати, скільки робочих годин знадобиться на виконання задачі і планувати роботу
відповідно.


Між зіогу роїпі та часом не має прямопропорційної залежності.


Коли ми вводимо поняття "людино-година", ми робимо припущення: що всі люди (припустимо,
інженери ПЗ) мають однакові вміння, а отже можна чітко визначити час на виконання певної задачі.
Це припущення вже невірне, коли в команді є старші та молодші спеціалісти, які роблять одне й те
саме за різний час. Крім того, поняття "людино-година" говорить про те, що збільшення кількості
людей буде пропорційно відображатися на зменшенні терміну створення продукту, але це міф. Цю
помилку розбирав Фред Брукс у своїй книзі "Міфічний людино-місяць". Фредерік Брукс пише, що
потрібно врахувати витрати на комунікацію між інженерами, які в деяких випадках можуть бути
настільки великі, що виконується закон Брукса: "Додавання робочої сили до запізнілого програмного
проєкту затягує його ще більше". Додавання більшої кількості людей до завдання, яке дуже поділене,
наприклад, прибирання номерів у готелі, зменшує загальну тривалість завдання (аж до моменту, коли
додаткові працівники заважають один одному). Однак інші завдання, включаючи багато
спеціальностей у проєктах програмного забезпечення, менш подільні. Щоб вирішити ці недоліки
поняття "людино-година", були створені 5іогу роїпія в 5сгит.


5когу роїпі (Очки складності завдання) - це одиниця виміру, яка використовується в методології
розробки програмного забезпечення для оцінки складності задачі. Вона використовується для
приблизної оцінки зусиль, не прив'язуючись до конкретної часової рамки.


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


Між зіогу роїпі та часом не має прямопропорційної залежності.


З допомогою 51огу роїпіз визначається уеіосіїу ої 5сгит іеат.


Аксіоми 5огу роіпіз (Очки задачі):


1. Зкогу роїпіз відносні (поставте якесь опорне завдання).


2. 5огу роїпі5 представляють відносні зусилля, складність 1 ризики для завдання. (Складність
стосується структури, а не часу).


3. Зогу роїпіз є лінійними: 2 ЗР - І ЗР 7 2. (Одна 3-роїпіз 5їогу повинна вимагати приблизно
стільки ж роботи, скільки інша 3-роїпіз 5(0гу).


4. Не існує найбільшого числа сторіпойнтів (5іогу роїпіз). (На практиці кладуть ліміт, наприклад,
якщо одна задача більше ніж 13 сторіпойнтів, розділяємо її на дві).


Деталі про 51іогу роїпіз в книгах:
"Авіїе Езйтайтя апа Ріаппіпеє" бу МіКке Собп,
"І, сатіпе Адіїе" бу Апагем 5кеЙтап.


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


Методологія Мехиз є однією з підходів до масштабування розробки Аяїїе, спрямованою на спільну
роботу декількох 5сгит-команд над великими проєктами.


Основні правила методології Хехи5 включають:


-Роль Мехиз Піеєтайоп Теат (МІТ): Спеціалізована команда, яка відповідає за координацію роботи
декількох Зсгит-команд у межах Мехи58.


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


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


-Мехиз У5ргіпі Кеуісм: Під час цього заходу представники всіх команд демонструють свої робочі
інкременти та обговорюють, які кроки слід вжити для подальшого вдосконалення.


-Мехиз Зргіпі Веїгозресіїуе: Регулярні огляди роботи всієї Мехиц5-структури з метою виявлення та
виправлення проблем та покращення робочих процесів.

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


-Мехи8 Райу Зсгит ої 5сгитя (005): Це щоденна зустріч представників кожної 5сгит-команди з
метою обговорення інтеграційних питань та вирішення конфліктів.


-Мехиз Ургіпі ВасКіоє: Спільний перелік завдань для всіх 5сгита-команд, який допомагає уникнути
дублювання роботи та забезпечити спільне розуміння пріоритетів.


Ці правила допомагають забезпечити ефективну спільну роботу декількох команд у межах Мехи5,
спрощуючи співпрацю та забезпечуючи координацію.


Методологія Водоспад та У-модель


Методологія Водоспад (У/аїетіаї!) - - це традиційний підхід до управління проєктами, який
використовується в розробці програмного забезпечення та інших галузях. Вона характеризується
лінійним та послідовним процесом, де прогрес поступово рухається вниз (як водоспад) через
попередньо визначені фази. Ось розбір типових етапів Водоспаду: Збір вимог, Проєктування системи,
Реалізація, Тестування, Розгортання, Обслуговування. Одна з ключових характеристик методології
Водоспад - - кожна фаза повинна бути завершена перед переходом до наступної. Це означає, що мало
місця для гнучкості або змін після завершення фази, що може бути обмеженням в проєктах, де вимоги
ймовірно зміняться чи розвиватимуться з часом. Крім того, зворотний зв'язок від користувачів або
зацікавлених сторін зазвичай приходить пізно в процесі, що може призвести до дорогоцінного
перероблення, якщо виникають непорозуміння або зміни в вимогах. Незважаючи на ці недоліки,
методологія Водоспад може бути ефективною для проєктів з чітко визначеними та стабільними
вимогами, де важливі передбачуваність та контроль.

В моделі Магегіаі! тестування зазвичай відбувається після завершення всіх етапів розробки.

М-модель розширює модель УЧаїегіаї!, додаючи тестування на кожному етапі розробки. Кожен етап
розробки має відповідний етап тестування, утворюючи форму літери "У".


М-модель є концептуальною моделлю, що використовується в рамках методології У/атегіаї для
візуалізації зв'язку між різними етапами проєкту та відповідними тестами. На початку У-діаграми
розташовані етапи, такі як збір вимог, аналіз, проєктування системи та програмування, де
визначаються вимоги та планується архітектура системи. Після цього настає фаза реалізації, де
виконується написання коду. Після завершення фази реалізації, робота переходить до фази
тестування, де виконуються тести для перевірки відповідності програмного забезпечення вимогам та
специфікаціям. Всі ці етапи, починаючи з аналізу та завершуючи тестуванням, утворюють "прямий
шлях" У-діаграми. У У-моделі тестування починається відразу після виконання кожного етапу
розробки.


Оеуєеіорег'з ІїМе Сусіе Тезтег'зя Ійе Сусіе


Ассеркапсе
Тезі Оезідп
Ведцігетепі ж і '-'Р Ассеріапсе
Апаїузі5 Тезіїпд
Х 74
бузіет

Зузіет Тезі Оезідп бузіет
4. Фезідп Тед | г,
(у) Ф;

З. Й с;
я
г Це
5 Іпгедгайіоп ко
- Тезі Оезідп 4
С
Р 9
7 Фо
а Ко
о Упіє Тезі Ж
5 Моаціе резідп ) Хо
кл «в Тезїїпд


У-модель не відповідає Ардіїе розробці.


Екстремальне програмування


Екстремальне програмування (Ехітете Ргогтатитіпе, ХР) було розроблене в 1990-х роках Кентом
Беком разом з іншими програмістами. ХР є одним із методів гнучкої розробки програмного
забезпечення, який акцентує на швидких ітераціях розробки, невеликих командних розмірах,
тестуванні перед написанням коду та підтримці стандартів якості. (ВооК "Ехітете Ргоргатитіпо
Ехріаїпед" бу Кепі Веск, 1999)


Принципи Екстремального програмування (Ехітете Ргоргататіпе, ХР):


Планування:
е Користувацькі історії (иц5ег 5іогіе5) написані.
-. Планування випуску (Кгеіса5е ріаппіпеє) створює розклад випуску.
е Робіть часті та невеликі випуски.
- Проєкт розділений на ітерації.
е. Планування ітерацій (Пегайоп ріаппіпє) починається з кожної ітерації.


Управління:
е Зустріч "стендап" починається кожен день.
-. Вимірюється швидкість проєкту (Рго|есі Меіостсу).
-. Наднормові вважаються поганою практикою.


Проєктування:
е. Простота (принцип КІЗ85).
е. Виберіть системну метафору, для загального опису системи.
е. Створіть пробні рішення (з5ріке5) для зменшення ризику.
е-. Жодна функціональність не додається заздалегідь (принцип УАСМІ).
е. Робіть рефакторинг, коли це можливо, де завгодно (але перед цим пишіть тести).


Кодування:
е. Клієнт завжди доступний.
е-. Код повинен бути написаний відповідно до погоджених стандартів.
-. Спочатку напишіть модульний тест (ТОР).
- Усі виробничі коди програмуються в парі (раїг ргоггатитіп5).
е Тільки одна пара інтегрує код одночасно.
Інтегруйте часто.
-. Налаштуйте спеціальний інтеграційний комп'ютер (сервер). Автоматизація є основним
принципом досягнення успіху РеумОрз, а СІ/СОЬ є критично важливим компонентом.
-. Використовуйте колективну власність (соПесйує оуупег5Нір). За код відповідальна вся команда.


Тестування:
-. Весь код повинен мати модульні тести.
е-. Весь код повинен пройти всі модульні тести, перш ніж його можна буде випустити.
е. Якщо знайдено помилку, створюються тести.
е. Приймальні тести (Ассеріапсе 1е515) часто запускаються, і результати публікуються.


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


Комунікація: Кожен є частиною команди, і ми щоденно спілкуємося. Ми працюватимемо разом над
усім, починаючи від вимог до коду.


Зворотний зв'язок: Ми серйозно ставимось до кожної ітераційної зобов'язаності, поставляючи робоче


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


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


Мужність: Ми говоритимемо правду про прогрес та оцінки. Ми не документуємо виправдання для
невдачі, оскільки ми плануємо успіх.


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


Ріаппіпе/ГеедрасК Іоор5


Пегайоп ріап
М/еек5


Ассеріапсе іезі
ГДауз


З1апд-пр теекіпе
Опе дау


Раїг перобайоп


аг


Опіг їе5і


Міпшевз


Раїг ргоєгаттіпе
Зесопаз


Соде


Спайк (зріке) - це інновація в екстремальному програмуванні (ХР) в гнучкій (аєіе) розробці
програмного забезпечення. Це невелика історія (из8ег 810гу) або робота, яка призначена для збору
інформації, а не для створення інкременту в продукті.


Слово "спайк" походить від скелелазних занять. Під час сходження ми можемо зупинитися, щоб вбити
спайк (цвях) в скелі, що не є фактичним сходженням, але цим ми забезпечуємо, що майбутнє


сходження буде легким і простим.


Так само під час розробки команда проводить невеликий експеримент або дослідження та створює


доказ концепту (РОС, Ргоої ої Сопсері), який не є фактичною розробкою чи виробничими
завданнями, але спрощує майбутній розвиток.


Історію (и5ег 5їогу) не можна оцінити, поки розробницька команда не проведе дослідження обмежене
по часу (не більше часу однієї ітерації). Тому спайкам не призначаються бали історії (5їогу роїпів),
оскільки вони не пов'язані з інкрементом продукту 1, отже, не сприяють швидкості команди.


Спайки обмежені в часі.


Визначення завершеності (Дейпійоп ої Допе) та контроль якості (ОД) в Екстремальному
програмуванні (ХР).


Приймальні тести (Ассеріапсе 1е515) створюються під час аналізу вимог і перед кодуванням.
В Екстремальному програмуванні (ХР) приймальні тести зазвичай також розробляються відповідно
до методології розробки через тести (ТОР).


Історія користувача (5ег 5їогу) не вважається завершеною, поки вона не пройде свої приймальні
тести (Ассеріапсе 1е5і5). Це означає, що нові приймальні тести повинні бути створені кожної ітерації,
або команда розробників буде повідомляти про нульовий прогрес.

Контроль якості (ОА) є важливою частиною процесу ХР (Ехігете рговгатитіпе).

Екстремальне програмування вимагає взаємодії розробників із ОА спеціалістами.

Приймальні тести повинні бути автоматизовані, щоб їх можна було часто запускати (СІ/СР).
Результати приймальних тестів публікуються команді. Це відповідальність команди запланувати час
кожної ітерації для виправлення будь-яких неуспішних тестів.


Екстремальне програмування базується на ТО, автоматичних тестах.


о
ьЬ «- Ехігете Ргосгаттіпе, Рго|есі


Ехігете Ргодгаттипоу


Тезі 8сепагіо5


Мему Ме 8іоту


Ведиїгетепіє Рго)есі Меїосйу Видз
Сизідтег
Мегзіоп, ДА ссеріапеє дрргочаї, Згпаї!


Пегайоп
Мч Те5ія Реїсаєез


Мехі Негаїїоп


ЦП8ег 5іогіе8


| аївзі


: бузівт Неівазе
Агепесбига! у еіарпог Веїсаєе | різп


Зріке (| | | | | 7 Ріаппіпо є,


Упсепаїп Сопіїдепі
Езвій паїв 5 Евії паїв 5


бріке Сорупаім 2000 1. Повуал Меіїх


Цикл розробки програмного забезпечення


Цикл розробки програмного забезпечення (ПЗ) включає такі етапи:
1. Збір та аналіз вимог,

2. Проєктування системи (дизайн),

3. Розробка (програмування),

4. Тестування,

5. Розгортання (аеріоу),

6. Підтримка та покращення системи (програми).


Кожен етап важливий для успішного завершення проєкту.


Зокрема, він описаний у 5У/ЕВОК від ІННЕ.


Закон Літтла описується формулою:

І з МУ

де:

І, - середня кількість речей/клієнтів у системі/черзі.;

2. - середній темп прибування (інтенсивність надходження заяв);

МУ - середній час перебування у системі

Приклад: якщо відділення банку відвідує у середньому 10 клієнтів на годину (2) і клієнт перебуває у


ньому у середньому І годину (УМ), то середня кількість клієнтів, що знаходяться у відділені (1.)
досягає 10.


Програмний продукт - код - тести - документація (-- ліцензія - підтримка).


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


Якість реалізації фічі (продукту) до етапу тестування обчислюється за формулою:


Якість реалізації фічі - 1 - (Час на виправлення помилок після тестування / Початкова естімація на
імплементацію).


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


Якість реалізації фічі на рівні 0.3 (до етапу ОА - дцаїу аз5игапсе) вважається нормальним
показником, але вказує на потребу в додатковому часі для виправлення помилок (--2095 від початкової
оцінки на імплементацію).


Наприклад, якщо розробник витратив 5 днів на реалізацію фічі та І день на виправлення помилок, то
якість реалізації фічі дорівнює І - 1/5, тобто 0.8.


Ідеальним варіантом є досягнення якості реалізації фічі, рівної 1, але це може бути важко досяжним
на практиці через обмежені ресурси та інші фактори.


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


Якість реалізації менше за 0 вказує на дуже низьку якість роботи.


Ця формула досить універсальна, щоб використовувати її для оцінки роботи як програміста та й всієї
команди (якщо врахувати бета-тестування).


Історичним прикладом поганої естімації часу та вартості розробки може слугувати приклад
Аналітичної машини Беббіджа, яку він так і не завершив самостійно. Також декілька мейнфреймів
ІВМ вийшли за рамки бюджету та термінів. Однак слід зауважити, що Чарлз Беббідж був видатною
постаттю у світі розробки.


Доцільно вчитися на прикладах минулого, щоб уникнути подібних помилок у майбутньому.


Як писати вимоги?


Коли кмітливість - - це погано. Або як писати вимоги А?біїєе бізнес аналітику.


Оз5ег 5їогу


Ргіогіїу:


Убег 5іогу:


Аз а |Чезсгіріїоп ої изег),
І мапі |Еипсбіопаїїсу)
50 їБаї |бепебії).


Ассеріапсе Сгііегіа:


Сімеп |Ппом/ «Ніпд5 Бедіп)
М/беп (асбіоп іакеп)


Треп |оцісоте ої іаКіпд асііоп)


"ЕРгодисіРіап


Юзер сторі (пяег 5їогу) - це короткий опис, не технічною мовою, того, що користувач хоче отримати.
На основі юзер сторі розробляються приймальні тести (Ассеріапсе 1е515, рейпішоп ої Допе).

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


Юзер сторі та Ассеріапсе сгіїегіа можна писати в форматі СрегкКіп.
Приклад користувацької історії (и5ег 810гу).
Заголовок: Дозволити користувачам скидати свої паролі


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


Критерії прийняття:


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

2. Система надсилає електронний лист для скидання пароля з безпечним посиланням.

3. Користувачі можуть натиснути на посилання та ввести новий пароль.

4. Новий пароль перевіряється та зберігається.


Як писати вимоги бізнес аналітику:


0. Пояснити структуру вимог всім (принцип опису вимог).
1. Загальний опис зробити перед описом деталей.
2. Орієнтація на тест кейси, а не на розлогі формулювання.


3. Писати як для тупих, тобто повну інфу давати, щоб не прийшлося додумувати.
КІ85 - Кеер 16 5ітріє, 5кирій.


4. Підкріплювали вимоги скріншотами, якщо можливо.
5. Не писати технічні нюанси, за це відповідають розробники.
6. Вимогу перевіряє команда.


7. Не роздувати опис завдання, робити декомпозицію на декілька юзер сторі.