Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Підтримка
www.wikidata.uk-ua.nina.az

Гнучка розро бка програ много забезпе чення англ Agile software development agile методи клас методологій розробки прогр

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

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

Гнучка́ розро́бка програ́много забезпе́чення (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між багатофункціональними командами здатними до самоорганізації. Гнучка розробка — засіб для підвищення продуктивності розробників програмного забезпечення.

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

Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.

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

Історія

  • 1992 — сімейство методологій стало початковою точкою розвитку методів розробки програмного забезпечення, що і призвело до появи Agile. Розробка Crystal належить [en]. Методологія була названа Crystal у 1997 році. Застосовується командами з 6-8 чоловік, які знаходяться в одному місці й працюють над створенням програмних систем, котрі не є критичними для життя користувачів.
  • 1993 — рефакторинг. Термін вперше ввів [en] в статті під назвою «Creating Abstract Superclasses by Refactoring».
  • 1994 — Dynamic Systems Development Method. DSDM був розроблений консорціумом, що є об'єднанням постачальників і виробників програмного забезпечення. Метою їх роботи було — спільними зусиллями розробити і поширити незалежний фреймворк для швидкої розробки додатків з використанням накопиченого досвіду. Jennifer Stapleton, будучи одним із засновників і членом DSDM, внесла істотний внесок у компіляцію вихідних ідей і думок. Arie van Bennekum є одним з авторів Agile-маніфесту і брав активну участь у роботі консорціуму DSDM починаючи з 1997 року.
  • 1995 — Scrum та Парне програмування. SCRUM був розроблений спільно Джефом Сазерлендом і Кеном Швабером. Парне програмування як концепція була описана одночасно і незалежно кількома авторами. [en] опублікував статтю «A Development Process Generative Pattern Language», в якій міститься опис патерну «Розробка в парах». [en] писав про «Dynamic Duos» у своїй книзі «Constantine on Peopleware», опублікованій у тому ж році. Дана концепція стала складовою частиною методології Extreme Programming. Незалежно від того, що було виконано кілька досліджень, що демонструють ефективність програмування в парах, дана концепція не знайшла реального відображення в Agile-маніфесті.
  • 1997 — Feature Driven Development. Методологію Feature Driven Development (FDD) розробив [en]. Процес розробки ПЗ за методологією FDD був представлений світу за допомогою публікації книги «Java Modeling in Color with UML: Enterprise Components and Process», де Джеф виступив у співавторстві з [en]. Пітер заснував компанію TogetherSoft, яку потім продав компанії Borland.
  • 1999 — Адаптивна розробка. [en] сформулював концепцію Adaptive System Development і опублікував книгу з такою ж назвою. Ідея виросла з його роботи за методологіями швидкого створення додатків (RAD). Він запропонував три фази життєвого циклу: 1) Speculation; 2) Collaboration; 3) Learning. Під час роботи в Chrysler Кент Бек розробив концепцію екстремального програмування (Extreme Programming). Він опублікував цей метод в 1999 в книзі — Extreme Programming Explained. Частиною Extreme Programming є концепція історій користувача і планування релізу (Release Planning). Дана методологія описує найкращі практики у сфері планування, управління, проєктування, кодування і тестування. Ворд Каннінгем і [en] також привнесли свої ідеї, так що всі троє вважаються засновниками методу EP.
  • 2000 — Події, що призвели до маніфесту. Боб Мартін проявив ініціативу і взявся за організацію, що стала історичною, зустрічі, яка відбулася у лютому 2001 року на гірськолижному курорті. Він є власником компанії Uncle Bob Consulting.

Маніфест гнучкої розробки

Докладніше: Маніфест гнучкої розробки

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

Маніфест гнучкої розробки розроблений і прийнятий 17 розробниками 11-13 лютого 2001 року на лижному курорті The Lodge at Snowbird в горах Юти. Маніфест підписали представники наступних методологій Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature driven development, Pragmatic Programming. Agile Manifesto містить 4 основні ідеї та 12 принципів. Примітно, що Agile Manifesto не містить практичних порад.

Основні ідеї:

  • Особистості та їхні взаємодії важливіші, ніж процеси та інструменти;
  • Робоче програмне забезпечення важливіше, ніж повна документація;
  • Співпраця із замовником важливіша, ніж контрактні зобов'язання;
  • Реакція на зміни важливіша, ніж дотримання плану.

Принципи, які роз'яснює Agile Manifesto:

  • Задоволення клієнта за рахунок ранньої та безперебійної поставки коштовного програмного забезпечення;
  • Вітання змін вимог навіть наприкінці розробки (це може підвищити конкурентоспроможність отриманого продукту);
  • Часта поставка робочого програмного забезпечення (кожен місяць або тиждень або ще частіше);
  • Тісне, щоденне спілкування замовника з розробниками впродовж всього проєкту;
  • Проєктом займаються мотивовані особистості, які забезпечені потрібними умовами роботи, підтримкою і довірою;
  • Рекомендований метод передачі інформації — особиста розмова (віч-на-віч);
  • Робоче програмне забезпечення — найкращий вимірювач прогресу;
  • Спонсори, розробники та користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
  • Постійна увага поліпшенню технічної досконалості та зручному дизайну;
  • Простота — мистецтво не робити зайвої роботи;
  • Найкращі технічні вимоги, дизайн та архітектура виходять у самоорганізованої команди;
  • Постійна адаптація до мінливих обставин.

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

Критика

Багато керівників проєктів, що працюють у традиційних методологіях на кшталт «водоспаду», критикують agile-методи.

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

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

Методології

Існують методології, які дотримуються цінностей і принципів заявлених в Agile Manifesto, деякі з них:

  • Agile Modeling — набір понять, принципів і прийомів (практик), що дозволяють швидко і просто виконувати моделювання і документування в проєктах розробки програмного забезпечення. Не включає в себе детальну інструкцію з проєктування, не містить описів, як будувати діаграми на UML. Основна мета — ефективне моделювання і документування; але не охоплює програмування та тестування, не включає питання управління проєктом, розгортання і супроводу системи. Однак включає в себе перевірку моделі кодом.
  • Agile Unified Process (AUP) спрощена версія IBM Rational Unified Process (RUP), розроблена Скоттом Амблером, яка описує просте і зрозуміле наближення (модель) для створення програмного забезпечення для бізнес-додатків.
  • Agile Data Method — група ітеративних методів розробки програмного забезпечення, в яких вимоги та рішення досягаються в рамках співпраці різних крос-функціональних команд.
  • DSDM заснований на концепції швидкої розробки додатків (Rapid Application Development, RAD). Являє собою ітеративний і інкрементний підхід, який надає особливого значення тривалій участі в процесі користувача/споживача.
  • Essential Unified Process (EssUP).
  • Екстремальне програмування (англ. Extreme programming, XP).
  • Feature Driven Development (FDD) — функціонально-орієнтована розробка. Використовуване в FDD поняття функції або властивості (англ. feature) Системи досить близько до поняття прецеденту використання, використовуваному в RUP, істотна відмінність — це додаткове обмеження: «кожна функція повинна допускати реалізацію не більше, ніж за два тижні». Тобто якщо сценарій використання досить малий, його можна вважати функцією. Якщо ж великий, то його треба розбити на декілька відносно незалежних функцій.
  • Getting Real — ітераційний підхід без функціональних специфікацій, що використовується для веб-додатків. У даному методі спершу розробляється інтерфейс програми, а потім її функціональна частина.
  •  — це ітераційно-інкрементний метод розробки програмного забезпечення. Позиціюється, як легкий і гнучкий варіант RUP. OpenUP ділить життєвий цикл проєкту на чотири фази: початкова фаза, фази уточнення, конструювання та передачі. Життєвий цикл проєкту забезпечує надання зацікавленим особам та членам колективу точок ознайомлення і прийняття рішень впродовж усього проєкту. Це дозволяє ефективно контролювати ситуацію і вчасно приймати рішення про задовільність результатів. План проєкту визначає життєвий цикл, а кінцевим результатом є остаточний додаток.
  • Scrum встановлює правила керування процесом розробки та дозволяє використовувати вже існуючі практики кодування, коректуючи вимоги або вносячи тактичні зміни. Використання цієї методології дає можливість виявляти і усувати відхилення від бажаного результату на більш ранніх етапах розробки програмного продукту.
  • Бережлива розробка програмного забезпечення (англ. lean software development). Використовує підходи з концепції бережливого виробництва.

Примітки

  1. Agile-маніфест розробки програмного забезпечення [ 18 січень 2015 у Wayback Machine.]. Перевірено 14.01.2015.

Джерела

  • Smith G. Improving the process of drafting families of software systems elements of agile methodologies / GI Smith, AL Kolesnik, K. Lavrischeva, O. Slabospitsky // programming problems. — 2010. — № 2-3. — S. 261—270. (англ.)
  • История Agile (рос.)
  • Статья Введение в гибкую разработку программного обеспечения (рос.)
  • Статья Гибкий подход разработки ПО — Scrum (рос.)
  • Статья Scrum — зачем заказчику знать такие непонятные слова? (рос.)
  • Agile, каталог посилань Open Directory Project
Вікіпідручник має книгу на тему
Software Engineering with an Agile Development Framework
  • Two Ways to Build a Pyramid, John Mayo-Smith (VP Of Technology At ), October 22, 2001
  • The New Methodology Martin Fowler's description of the background to agile methods
  • Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
  • A look into the PMI-ACP (Agile Certified Practitioner)

Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет

Gnuchka rozro bka progra mnogo zabezpe chennya angl Agile software development agile metodi klas metodologij rozrobki programnogo zabezpechennya sho bazuyetsya na iterativnij rozrobci v yakij vimogi ta rozv yazki evolyucionuyut cherez spivpracyu mizh bagatofunkcionalnimi komandami zdatnimi do samoorganizaciyi Gnuchka rozrobka zasib dlya pidvishennya produktivnosti rozrobnikiv programnogo zabezpechennya Bilshist gnuchkih metodologij nacileni na shlyahom zvedennya rozrobki do seriyi korotkih cikliv sho mayut nazvu iteracij yaki zazvichaj trivayut odin dva tizhni Kozhna iteraciya sama po sobi viglyadaye yak programnij proyekt v miniatyuri i vklyuchaye vsi zavdannya neobhidni dlya vidachi minimalnogo prirostu za funkcionalnistyu planuvannya analiz vimog proyektuvannya koduvannya testuvannya i dokumentuvannya Hocha okrema iteraciya yak pravilo nedostatnya dlya vipusku novoyi versiyi produktu mayetsya na uvazi te sho gnuchkij programnij proyekt gotovij do vipusku naprikinci kozhnoyi iteraciyi Pislya zakinchennya kozhnoyi iteraciyi komanda vikonuye pereocinku prioritetiv rozrobki Agile akcentuye uvagu na bezposerednomu spilkuvanni vich na vich Bilshist agile komand roztashovani v odnomu ofisi jogo inodi nazivayut bullpen Yak minimum vona vklyuchaye i zamovnikiv zamovniki yaki viznachayut produkt takozh ce mozhut buti menedzheri produktu biznes analitiki abo kliyenti Ofis mozhe takozh vklyuchati testuvalnikiv dizajneriv interfejsu tehnichnih avtoriv i menedzheriv Osnovnoyu metrikoyu agile metodiv ye robochij produkt Viddayuchi perevagu bezposerednomu spilkuvannyu agile metodi zmenshuyut obsyag pismovoyi dokumentaciyi v porivnyanni z inshimi metodami Ce prizvelo do kritiki cih metodiv yak nedisciplinovanih Istoriya1992 simejstvo metodologij stalo pochatkovoyu tochkoyu rozvitku metodiv rozrobki programnogo zabezpechennya sho i prizvelo do poyavi Agile Rozrobka Crystal nalezhit en Metodologiya bula nazvana Crystal u 1997 roci Zastosovuyetsya komandami z 6 8 cholovik yaki znahodyatsya v odnomu misci j pracyuyut nad stvorennyam programnih sistem kotri ne ye kritichnimi dlya zhittya koristuvachiv 1993 refaktoring Termin vpershe vviv en v statti pid nazvoyu Creating Abstract Superclasses by Refactoring 1994 Dynamic Systems Development Method DSDM buv rozroblenij konsorciumom sho ye ob yednannyam postachalnikiv i virobnikiv programnogo zabezpechennya Metoyu yih roboti bulo spilnimi zusillyami rozrobiti i poshiriti nezalezhnij frejmvork dlya shvidkoyi rozrobki dodatkiv z vikoristannyam nakopichenogo dosvidu Jennifer Stapleton buduchi odnim iz zasnovnikiv i chlenom DSDM vnesla istotnij vnesok u kompilyaciyu vihidnih idej i dumok Arie van Bennekum ye odnim z avtoriv Agile manifestu i brav aktivnu uchast u roboti konsorciumu DSDM pochinayuchi z 1997 roku 1995 Scrum ta Parne programuvannya SCRUM buv rozroblenij spilno Dzhefom Sazerlendom i Kenom Shvaberom Parne programuvannya yak koncepciya bula opisana odnochasno i nezalezhno kilkoma avtorami en opublikuvav stattyu A Development Process Generative Pattern Language v yakij mistitsya opis paternu Rozrobka v parah en pisav pro Dynamic Duos u svoyij knizi Constantine on Peopleware opublikovanij u tomu zh roci Dana koncepciya stala skladovoyu chastinoyu metodologiyi Extreme Programming Nezalezhno vid togo sho bulo vikonano kilka doslidzhen sho demonstruyut efektivnist programuvannya v parah dana koncepciya ne znajshla realnogo vidobrazhennya v Agile manifesti 1997 Feature Driven Development Metodologiyu Feature Driven Development FDD rozrobiv en Proces rozrobki PZ za metodologiyeyu FDD buv predstavlenij svitu za dopomogoyu publikaciyi knigi Java Modeling in Color with UML Enterprise Components and Process de Dzhef vistupiv u spivavtorstvi z en Piter zasnuvav kompaniyu TogetherSoft yaku potim prodav kompaniyi Borland 1999 Adaptivna rozrobka en sformulyuvav koncepciyu Adaptive System Development i opublikuvav knigu z takoyu zh nazvoyu Ideya virosla z jogo roboti za metodologiyami shvidkogo stvorennya dodatkiv RAD Vin zaproponuvav tri fazi zhittyevogo ciklu 1 Speculation 2 Collaboration 3 Learning Pid chas roboti v Chrysler Kent Bek rozrobiv koncepciyu ekstremalnogo programuvannya Extreme Programming Vin opublikuvav cej metod v 1999 v knizi Extreme Programming Explained Chastinoyu Extreme Programming ye koncepciya istorij koristuvacha i planuvannya relizu Release Planning Dana metodologiya opisuye najkrashi praktiki u sferi planuvannya upravlinnya proyektuvannya koduvannya i testuvannya Vord Kanningem i en takozh privnesli svoyi ideyi tak sho vsi troye vvazhayutsya zasnovnikami metodu EP 2000 Podiyi sho prizveli do manifestu Bob Martin proyaviv iniciativu i vzyavsya za organizaciyu sho stala istorichnoyu zustrichi yaka vidbulasya u lyutomu 2001 roku na girskolizhnomu kurorti Vin ye vlasnikom kompaniyi Uncle Bob Consulting Manifest gnuchkoyi rozrobkiDokladnishe Manifest gnuchkoyi rozrobki Agile rodina procesiv rozrobki a ne yedinij pidhid v rozrobci programnogo zabezpechennya i viznachayetsya manifestom gnuchkoyi rozrobki Agile ne vklyuchaye praktik a viznachaye cinnosti ta principi yakimi keruyutsya uspishni komandi Manifest gnuchkoyi rozrobki rozroblenij i prijnyatij 17 rozrobnikami 11 13 lyutogo 2001 roku na lizhnomu kurorti The Lodge at Snowbird v gorah Yuti Manifest pidpisali predstavniki nastupnih metodologij Extreme programming Scrum DSDM Adaptive software development Crystal Clear Feature driven development Pragmatic Programming Agile Manifesto mistit 4 osnovni ideyi ta 12 principiv Primitno sho Agile Manifesto ne mistit praktichnih porad Osnovni ideyi Osobistosti ta yihni vzayemodiyi vazhlivishi nizh procesi ta instrumenti Roboche programne zabezpechennya vazhlivishe nizh povna dokumentaciya Spivpracya iz zamovnikom vazhlivisha nizh kontraktni zobov yazannya Reakciya na zmini vazhlivisha nizh dotrimannya planu Principi yaki roz yasnyuye Agile Manifesto Zadovolennya kliyenta za rahunok rannoyi ta bezperebijnoyi postavki koshtovnogo programnogo zabezpechennya Vitannya zmin vimog navit naprikinci rozrobki ce mozhe pidvishiti konkurentospromozhnist otrimanogo produktu Chasta postavka robochogo programnogo zabezpechennya kozhen misyac abo tizhden abo she chastishe Tisne shodenne spilkuvannya zamovnika z rozrobnikami vprodovzh vsogo proyektu Proyektom zajmayutsya motivovani osobistosti yaki zabezpecheni potribnimi umovami roboti pidtrimkoyu i doviroyu Rekomendovanij metod peredachi informaciyi osobista rozmova vich na vich Roboche programne zabezpechennya najkrashij vimiryuvach progresu Sponsori rozrobniki ta koristuvachi povinni mati mozhlivist pidtrimuvati postijnij temp na neviznachenij termin Postijna uvaga polipshennyu tehnichnoyi doskonalosti ta zruchnomu dizajnu Prostota mistectvo ne robiti zajvoyi roboti Najkrashi tehnichni vimogi dizajn ta arhitektura vihodyat u samoorganizovanoyi komandi Postijna adaptaciya do minlivih obstavin Manifest ta Principi gnuchkoyi rozrobki mistyat visokorivnevi ideyi shodo togo yak potribno vibudovuvati proces rozrobki programnogo zabezpechennya shob uspishno zavershuvati proyekti j stvoryuvati komandi v yakih priyemno ta cikavo pracyuvati Dokumenti viznachayut sho potribno dlya cogo zrobiti ale ne govoryat yak ce zrobiti Po inshomu j ne moglo buti oskilki Manifest ta Principi narodilisya vnaslidok konsensusu predstavnikiv riznih hocha j sporidnenih napryamiv yaki mogli znajti spilnu osnovu lishe na rivni bazovih cinnostej ta principiv KritikaBagato kerivnikiv proyektiv sho pracyuyut u tradicijnih metodologiyah na kshtalt vodospadu kritikuyut agile metodi Odin z povtoryuvanih punktiv kritiki pri agile pidhodi chasto nehtuyut stvorennyam dorozhnoyi karti rozvitku produktu tak samo yak i v procesi yakogo i formuyetsya taka karta Gnuchkij pidhid do upravlinnya vimogami ne maye na uvazi dalekosyazhnih planiv po suti upravlinnya vimogami prosto ne isnuye v danij metodologiyi a maye na uvazi mozhlivist zamovnika raptom i nespodivano naprikinci kozhnoyi iteraciyi vistavlyati novi vimogi sho chasto superechat arhitekturi vzhe stvorenogo i postavlenogo produktu Take inodi prizvodit do katastrofichnih avraliv z masovim refaktoringom i pererobkami praktichno na kozhnij chergovij iteraciyi Krim togo vvazhayetsya sho robota v agile motivuye rozrobnikiv virishuvati vsi pribuli zavdannya najprostishim i najshvidshim mozhlivim sposobom pri comu chasto ne zvertayuchi uvagi na korektnist kodu z tochki zoru vimog bazovoyi platformi pidhid pracyuye ta j dobre pri comu ne vrahovuyetsya sho mozhe perestati pracyuvati pri najmenshij zmini abo zh poroditi vazhki do vidtvorennya defekti pislya realnogo rozgortannya u kliyenta Ce prizvodit do znizhennya yakosti produktu i nakopichennyu defektiv MetodologiyiIsnuyut metodologiyi yaki dotrimuyutsya cinnostej i principiv zayavlenih v Agile Manifesto deyaki z nih Agile Modeling nabir ponyat principiv i prijomiv praktik sho dozvolyayut shvidko i prosto vikonuvati modelyuvannya i dokumentuvannya v proyektah rozrobki programnogo zabezpechennya Ne vklyuchaye v sebe detalnu instrukciyu z proyektuvannya ne mistit opisiv yak buduvati diagrami na UML Osnovna meta efektivne modelyuvannya i dokumentuvannya ale ne ohoplyuye programuvannya ta testuvannya ne vklyuchaye pitannya upravlinnya proyektom rozgortannya i suprovodu sistemi Odnak vklyuchaye v sebe perevirku modeli kodom Agile Unified Process AUP sproshena versiya IBM Rational Unified Process RUP rozroblena Skottom Amblerom yaka opisuye proste i zrozumile nablizhennya model dlya stvorennya programnogo zabezpechennya dlya biznes dodatkiv Agile Data Method grupa iterativnih metodiv rozrobki programnogo zabezpechennya v yakih vimogi ta rishennya dosyagayutsya v ramkah spivpraci riznih kros funkcionalnih komand DSDM zasnovanij na koncepciyi shvidkoyi rozrobki dodatkiv Rapid Application Development RAD Yavlyaye soboyu iterativnij i inkrementnij pidhid yakij nadaye osoblivogo znachennya trivalij uchasti v procesi koristuvacha spozhivacha Essential Unified Process EssUP Ekstremalne programuvannya angl Extreme programming XP Feature Driven Development FDD funkcionalno oriyentovana rozrobka Vikoristovuvane v FDD ponyattya funkciyi abo vlastivosti angl feature Sistemi dosit blizko do ponyattya precedentu vikoristannya vikoristovuvanomu v RUP istotna vidminnist ce dodatkove obmezhennya kozhna funkciya povinna dopuskati realizaciyu ne bilshe nizh za dva tizhni Tobto yaksho scenarij vikoristannya dosit malij jogo mozhna vvazhati funkciyeyu Yaksho zh velikij to jogo treba rozbiti na dekilka vidnosno nezalezhnih funkcij Getting Real iteracijnij pidhid bez funkcionalnih specifikacij sho vikoristovuyetsya dlya veb dodatkiv U danomu metodi spershu rozroblyayetsya interfejs programi a potim yiyi funkcionalna chastina ce iteracijno inkrementnij metod rozrobki programnogo zabezpechennya Poziciyuyetsya yak legkij i gnuchkij variant RUP OpenUP dilit zhittyevij cikl proyektu na chotiri fazi pochatkova faza fazi utochnennya konstruyuvannya ta peredachi Zhittyevij cikl proyektu zabezpechuye nadannya zacikavlenim osobam ta chlenam kolektivu tochok oznajomlennya i prijnyattya rishen vprodovzh usogo proyektu Ce dozvolyaye efektivno kontrolyuvati situaciyu i vchasno prijmati rishennya pro zadovilnist rezultativ Plan proyektu viznachaye zhittyevij cikl a kincevim rezultatom ye ostatochnij dodatok Scrum vstanovlyuye pravila keruvannya procesom rozrobki ta dozvolyaye vikoristovuvati vzhe isnuyuchi praktiki koduvannya korektuyuchi vimogi abo vnosyachi taktichni zmini Vikoristannya ciyeyi metodologiyi daye mozhlivist viyavlyati i usuvati vidhilennya vid bazhanogo rezultatu na bilsh rannih etapah rozrobki programnogo produktu Berezhliva rozrobka programnogo zabezpechennya angl lean software development Vikoristovuye pidhodi z koncepciyi berezhlivogo virobnictva PrimitkiAgile manifest rozrobki programnogo zabezpechennya 18 sichen 2015 u Wayback Machine Perevireno 14 01 2015 DzherelaSmith G Improving the process of drafting families of software systems elements of agile methodologies GI Smith AL Kolesnik K Lavrischeva O Slabospitsky programming problems 2010 2 3 S 261 270 angl Istoriya Agile ros Statya Vvedenie v gibkuyu razrabotku programmnogo obespecheniya ros Statya Gibkij podhod razrabotki PO Scrum ros Statya Scrum zachem zakazchiku znat takie neponyatnye slova ros Agile katalog posilan Open Directory Project Vikipidruchnik maye knigu na temu Software Engineering with an Agile Development Framework Two Ways to Build a Pyramid John Mayo Smith VP Of Technology At October 22 2001 The New Methodology Martin Fowler s description of the background to agile methods Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary A look into the PMI ACP Agile Certified Practitioner

Дата публікації:
Топ