Extreme-programming - Історія редагувань

WikiSysop в 07:46, 2 вересня 2022

2022-09-02T07:46:32Z

WikiSysop в 10:12, 20 серпня 2022

2022-08-20T10:12:03Z

WikiSysop в 10:09, 20 серпня 2022

2022-08-20T10:09:38Z

WikiSysop в 09:57, 20 серпня 2022

2022-08-20T09:57:48Z

WikiSysop: Створена сторінка: == eXtreme Programming — гнучка методологія розробки програмного забезпечення. == Автор (америка...

2022-08-20T09:57:13Z

Створена сторінка: == eXtreme Programming — гнучка методологія розробки програмного забезпечення. == Автор (америка...

Нова сторінка

== eXtreme Programming — гнучка методологія розробки програмного забезпечення. ==

Автор (американський розробник Кент Бек) XP не придумав нічого нового, а взяв кращі практики гнучкої розробки і посилив до максимуму. Тому програмування і називається екстремальним.

=== XP відрізняється від інших гнучких методологій тим, що застосовується тільки в області розробки програмного забезпечення. Воно не може бути використане в іншому бізнесі або повсякденному житті, як scrum, kanban або lean. ===

Мета методики XP — впоратися з постійно мінливими вимогами до програмного продукту і підвищити якість розробки. Тому XP добре підходить для складних і невизначених проектів.

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

=== Принципи XP ===
# '''Простота''' - XP розробка починається з самого простого рішення, яке задовольнить поточну потребу в функціональності. Члени команди враховують тільки те, що повинно бути зроблено зараз, і не закладають в код функціональність, яка знадобиться завтра, через місяць або ніколи.
# '''Комунікація''' - XP комунікація між розробниками ведеться не за допомогою документації, а наживо. Команда активно спілкується між собою і з замовником.
# '''Зворотній зв’язок''' - Зворотний зв’язок у XP реалізується відразу в трьох напрямках:
* фідбек від системи при постійному тестування модулів
* фідбек від замовника, так як він входить в команду і бере участь у написанні приймальних тестів
* фідбек від команди під час планування щодо часу на розробку.
# '''Сміливість''' - Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.
# '''Повага''' - В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну.

← Попередня версія		Версія за 07:46, 2 вересня 2022
Рядок 1:		Рядок 1:
		+	[[Aspirantura\| До змісту]]
	== eXtreme Programming — гнучка методологія розробки програмного забезпечення. ==		== eXtreme Programming — гнучка методологія розробки програмного забезпечення. ==

@@ Рядок 32: / Рядок 32: @@
 В XP, якщо команда не встигає виконати всі задачі до дати релізу, то реліз не відсувається, а ріжеться частина функціоналу, найменш важлива для замовника.
 '''Планування ітерацій проводиться кожні два тижні, іноді частіше або рідше. Замовник обов’язково присутній: він визначає функціональність на наступну ітерацію і вносить зміни у вимоги до продукту.'''
-# Часті релізи версій
+# '''Часті релізи версій''' - XP версії випускаються часто, але з невеликим функціоналом. По-перше, маленький обсяг функціональності легко тестувати і зберігати працездатність всієї системи. По-друге, кожну ітерацію замовник отримує частину функціоналу, яка має бізнес-цінність.
-XP версії випускаються часто, але з невеликим функціоналом. По-перше, маленький обсяг функціональності легко тестувати і зберігати працездатність всієї системи. По-друге, кожну ітерацію замовник отримує частину функціоналу, яка має бізнес-цінність.
+# '''Користувальницькі тести''' - Замовник сам визначає автоматизовані приймальні тести, щоб перевірити працездатність черговий функції продукту. Команда пише ці тести і використовує їх для тестування готового коду.
+# '''Колективне володіння кодом''' - В XP будь-який розробник може правити будь-який шматок коду, так як код не закріплений за своїм автором. Кодом володіє вся команда.
-# Користувальницькі тести
+# '''Безперервна інтеграція коду''' - Це означає, що нові частини коду відразу ж вбудовуються в систему — команди XP заливають новий білд кожні кілька годин і частіше. По-перше, відразу видно, як останні зміни впливають на систему. Якщо новий шматок коду щось зламав, то знайти помилку і виправити в рази простіше, ніж через тиждень. По-друге, команда завжди працює з останньою версією системи.
-Замовник сам визначає автоматизовані приймальні тести, щоб перевірити працездатність черговий функції продукту. Команда пише ці тести і використовує їх для тестування готового коду.
+# '''Стандарти кодування''' - Коли кодом володіють всі, важливо прийняти єдині стандарти оформлення, код виглядав так, як ніби він написаний одним професіоналом. Можна виробити свої стандарти або прийняти готові.
+# '''Метафора системи''' - Метафора системи — це її порівняння з чимось знайомим, щоб сформувати у команди спільне бачення. Зазвичай метафору системи продумує той, хто розробляє архітектуру і представляє систему цілком.
-# Колективне володіння кодом
+# '''Стійкий темп''' - XP команди працюють на максимумі продуктивності, зберігаючи стійкий темп. При цьому екстремальне програмування негативно ставиться до переробок і пропагує 40-годинний робочий тиждень.
-В XP будь-який розробник може правити будь-який шматок коду, так як код не закріплений за своїм автором. Кодом володіє вся команда.
+# '''Розробка, заснована на тестуванні''' - Одна з найважчих практик методології. В XP тести пишуться самими програмістами, причому ДО написання коду, який потрібно протестувати. При такому підході кожен шматок функціоналу буде покритий тестами на 100%. Коли пара програмістів заливають код в репозиторій, відразу запускаються модульні тести. І всі вони повинні спрацювати. Тоді розробники будуть впевнені, що рухаються в правильному напрямку.
+# '''Парне програмування''' - Уявіть двох розробників за одним комп’ютером, що працюють над одним шматком функціональності продукту. Це і є парне програмування, сама спірна практика XP. Стара приказка «одна голова добре, а дві краще» відмінно ілюструє суть підходу. З двох варіантів вирішення проблеми вибирається найкращий, код оптимізується відразу ж, помилки відловлюються ще до їх здійснення. У підсумку маємо чистий код, в якому добре розбираються відразу двоє розробників.
-# Безперервна інтеграція коду
+# '''Простий дизайн''' - Простий дизайн в XP означає робити тільки те, що потрібно зараз, не намагаючись вгадати майбутню функціональність. Простий дизайн і безперервний рефакторинг дають синергетичний ефект — коли код простий, його легко оптимізувати.
-Це означає, що нові частини коду відразу ж вбудовуються в систему — команди XP заливають новий білд кожні кілька годин і частіше. По-перше, відразу видно, як останні зміни впливають на систему. Якщо новий шматок коду щось зламав, то знайти помилку і виправити в рази простіше, ніж через тиждень. По-друге, команда завжди працює з останньою версією системи.
+# '''Рефакторинг''' - Рефакторинг — це процес постійного поліпшення дизайну системи, щоб привести його у відповідність новим вимогам. Рефакторинг включає видалення дублів коду, підвищення зв’язності і зниження сполучення. XP передбачає постійні рефакторинги, тому дизайн коду завжди залишається простим

← Попередня версія		Версія за 10:09, 20 серпня 2022
Рядок 18:		Рядок 18:
	# '''Сміливість''' - Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.		# '''Сміливість''' - Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.
	# '''Повага''' - В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну.		# '''Повага''' - В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну.
		+
		+	=== 13 практик екстремального програмування ===
		+
		+	# Вся команда
		+	Усі учасники проекту з застосуванням XP працюють як одна команда. У неї обов’язково входить представник замовника, краще, якщо це буде реальний кінцевий користувач продукту, що розбирається в бізнесі. Замовник висуває вимоги до продукту і розставляє пріоритети в реалізації функціональності. Йому можуть допомагати бізнес-аналітики. З боку виконавців у команду входять розробники і тестувальники, інколи коуч, що направляє команду, і менеджер, який забезпечує команду ресурсами.
		+
		+	# Гра в планування
		+	'''Планування в XP проводять у два етапи — планування релізу і планування ітерацій.'''
		+
		+	На плануванні релізу команда програмістів зустрічається з замовником, щоб з’ясувати, яку функціональність він хоче отримати до наступного релізу, тобто через 2-6 місяців. Так як вимоги замовника часто розмиті, розробники конкретизують їх і дроблять на частини, реалізація яких займає не більше одного дня. Важливо, щоб замовник розбирався в операційному середовищі, в якому буде працювати продукт.
		+
		+	Задачі записуються на картки, а замовник визначає їх пріоритет. Далі розробники оцінюють, скільки часу піде на кожну задачу. Коли задачі описані і оцінені, замовник переглядає документацію і дає добро на початок роботи. Для успіху проекту критично, щоб замовник і команда програмістів грали на одному полі: замовник вибирає дійсно необхідну функціональність в рамках бюджету, а програмісти адекватно зіставляють вимоги замовника зі своїми можливостями.
		+
		+	В XP, якщо команда не встигає виконати всі задачі до дати релізу, то реліз не відсувається, а ріжеться частина функціоналу, найменш важлива для замовника.
		+	'''Планування ітерацій проводиться кожні два тижні, іноді частіше або рідше. Замовник обов’язково присутній: він визначає функціональність на наступну ітерацію і вносить зміни у вимоги до продукту.'''
		+
		+	# Часті релізи версій
		+	XP версії випускаються часто, але з невеликим функціоналом. По-перше, маленький обсяг функціональності легко тестувати і зберігати працездатність всієї системи. По-друге, кожну ітерацію замовник отримує частину функціоналу, яка має бізнес-цінність.
		+
		+	# Користувальницькі тести
		+	Замовник сам визначає автоматизовані приймальні тести, щоб перевірити працездатність черговий функції продукту. Команда пише ці тести і використовує їх для тестування готового коду.
		+
		+	# Колективне володіння кодом
		+	В XP будь-який розробник може правити будь-який шматок коду, так як код не закріплений за своїм автором. Кодом володіє вся команда.
		+
		+	# Безперервна інтеграція коду
		+	Це означає, що нові частини коду відразу ж вбудовуються в систему — команди XP заливають новий білд кожні кілька годин і частіше. По-перше, відразу видно, як останні зміни впливають на систему. Якщо новий шматок коду щось зламав, то знайти помилку і виправити в рази простіше, ніж через тиждень. По-друге, команда завжди працює з останньою версією системи.
		+
		+	# Стандарти кодування
		+	Коли кодом володіють всі, важливо прийняти єдині стандарти оформлення, код виглядав так, як ніби він написаний одним професіоналом. Можна виробити свої стандарти або прийняти готові.
		+
		+	# Метафора системи
		+	Метафора системи — це її порівняння з чимось знайомим, щоб сформувати у команди спільне бачення. Зазвичай метафору системи продумує той, хто розробляє архітектуру і представляє систему цілком.
		+
		+	# Стійкий темп
		+	XP команди працюють на максимумі продуктивності, зберігаючи стійкий темп. При цьому екстремальне програмування негативно ставиться до переробок і пропагує 40-годинний робочий тиждень.
		+
		+	# Розробка, заснована на тестуванні
		+	Одна з найважчих практик методології. В XP тести пишуться самими програмістами, причому ДО написання коду, який потрібно протестувати. При такому підході кожен шматок функціоналу буде покритий тестами на 100%. Коли пара програмістів заливають код в репозиторій, відразу запускаються модульні тести. І всі вони повинні спрацювати. Тоді розробники будуть впевнені, що рухаються в правильному напрямку.
		+
		+	# Парне програмування
		+	Уявіть двох розробників за одним комп’ютером, що працюють над одним шматком функціональності продукту. Це і є парне програмування, сама спірна практика XP. Стара приказка «одна голова добре, а дві краще» відмінно ілюструє суть підходу. З двох варіантів вирішення проблеми вибирається найкращий, код оптимізується відразу ж, помилки відловлюються ще до їх здійснення. У підсумку маємо чистий код, в якому добре розбираються відразу двоє розробників.
		+
		+	# Простий дизайн
		+	Простий дизайн в XP означає робити тільки те, що потрібно зараз, не намагаючись вгадати майбутню функціональність. Простий дизайн і безперервний рефакторинг дають синергетичний ефект — коли код простий, його легко оптимізувати.
		+
		+	# Рефакторинг
		+	Рефакторинг — це процес постійного поліпшення дизайну системи, щоб привести його у відповідність новим вимогам. Рефакторинг включає видалення дублів коду, підвищення зв’язності і зниження сполучення. XP передбачає постійні рефакторинги, тому дизайн коду завжди залишається простим
		+
		+
		+	Методологія XP викликає багато суперечок і критики з боку тих, хто так і не зміг її впровадити у своїй команді.
		+
		+	'''Переваги'''
		+	* замовник отримує саме той продукт, який йому потрібен, навіть якщо на початку розробки сам точно не представляє його кінцевий вигляд
		+	* команда швидко вносить зміни в код і додає нову функціональність за рахунок простого дизайну коду, частого планування і релізів
		+	* код завжди працює за рахунок постійного тестування і безперервної інтеграції
		+	* команда легко підтримує код т. к. він написаний за єдиним стандартом і постійно рефакториться
		+	* швидкий темп розробки за рахунок парного програмування, відсутність наднормової роботи, присутності замовника у команді
		+	* висока якість коду
		+	* знижуються ризики, пов’язані з розробкою, так як відповідальність за проект розподіляється рівномірно та вихід/прихід члена команди не зруйнує процес
		+	* витрати на розробку нижче, так як команда орієнтована на код, а не на документацію і збори
		+
		+	=== Недоліки ===
		+	* успіх проекту залежить від включеності замовника, якої не так просто добитися
		+	* важко передбачити витрати часу на проект, так як на початку ніхто не знає повного списку вимог
		+	* успіх XP сильно залежить від рівня програмістів, методологія працює тільки з senior фахівцями
		+	* менеджмент негативно ставиться до парного програмування, не розуміючи, чому він повинен оплачувати двох програмістів замість одного
		+	* регулярні зустрічі з програмістами дорого обходяться замовникам
		+	* вимагає дуже сильних культурних змін
		+	* із-за нестачі структури та документації не підходить для великих проектів
		+	* так як гнучкі методології функціонально-орієнтовані, нефункціональні вимоги до якості продукту складно описати у вигляді користувальницьких історій.
		+
		+
		+	=== Щоб впровадити XP в існуючий проект, треба поступово освоювати його методики в областях: ===
		+	* '''тестування''' - Команда створює тести ПЕРЕД написанням нового коду і поступово переробляє старий код. Для старого коду тести пишуться по мірі необхідності: коли потрібно додати нову функціональність, виправити помилку або переробити частину старого коду.
		+	* '''проектування''' - Команда поступово рефакторить старий код, зазвичай перед додаванням нової функціональності. Як і у випадку з тестуванням, рефакторинг старого коду проводять тільки за необхідності. При цьому команді варто сформулювати довгострокові цілі переробки коду і поступово досягати їх.
		+	* '''планування''' - Команда повинна перейти на тісну взаємодію з замовником. На цьому етапі важливо донести до нього переваги роботи в одній команді з розробниками і інтегрувати його в команду.
		+	* '''менеджмента''' - Роль менеджерів при переході на XP — контролювати, щоб всі члени команди працювали за новими правилами. Менеджер проекту приймає рішення, коли розлучитися з членом команди, який не справляється з роботою в нових умовах, або знайти нового і правильно інтегрувати його в роботу.
		+	* '''розробки''' - Перетворення в розробці починаються з організації робочих місць для програмування парами. Наступне завдання — програмувати парами більшу частину робочого часу, як би важко це не давалося розробникам.

@@ Рядок 13: / Рядок 13: @@
 # '''Комунікація''' - XP комунікація між розробниками ведеться не за допомогою документації, а наживо. Команда активно спілкується між собою і з замовником.
 # '''Зворотній зв’язок''' - Зворотний зв’язок у XP реалізується відразу в трьох напрямках:
-* фідбек від системи при постійному тестування модулів
+#* фідбек від системи при постійному тестування модулів
-* фідбек від замовника, так як він входить в команду і бере участь у написанні приймальних тестів
+#* фідбек від замовника, так як він входить в команду і бере участь у написанні приймальних тестів
-* фідбек від команди під час планування щодо часу на розробку.
+#* фідбек від команди під час планування щодо часу на розробку.
 # '''Сміливість''' - Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.
 # '''Повага''' - В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну.