Кіріспе

Бағдарламалық жасақтаманы дамыту тәжірибелерін басқаратын көзқарас

Жылдам әдіспен бағдарламалық жасақтаманы дамыту – бұл 2001 жылы 17 бағдарламалық жасақтамашыдан тұратын Agile Alliance тобы келіскен құндылықтардан туындаған бағдарламалық жасақтаманы әзірлеуге қатысты көзқарас. Олардың Жылдам әдіспен бағдарламалық жасақтаманы дамыту манифестінде көрсетілгендей, тәжірибелілер келесілерді бағалайды:

Процестер мен құралдардан гөрі жеке тұлғалар мен өзара әрекеттесу
Кең көлемді құжаттамадан гөрі жұмыс істейтін бағдарламалық жасақтама
Келісімшарттарды талқылаудан гөрі клиенттермен ынтымақтастық
Жоспарды ұстанудан гөрі өзгерістерге жауап беру

Тәжірибелілер сол кездегі жаңа тәжірибелерден, соның ішінде экстремалды бағдарламалау, Scrum, динамикалық жүйелерді дамыту әдісі, бейімделетін бағдарламалық жасақтаманы дамытудан шабыттанды және құжаттамаға негізделген, ауыр бағдарламалық жасақтаманы дамыту процестеріне балама қажеттілігін түсінді. Бұл талаптарды, жаңалықтарды және шешімдерді өздігінен ұйымдастырылатын және өзара байланысты командалардың клиенттерімен/соңғы пайдаланушыларымен бірлескен күш-жігері арқылы жақсартуды қамтиды. Жылдамдық көзқарасы мен жылдамдыққа негізделген тәжірибелер бағдарламалық жасақтаманы дамыту процесін жақсартатынына қатысты көптеген мысалдар бар, бірақ эмпирикалық деректер шектеулі және толыққанды қорытынды жасауға мүмкіндік бермейді.

Тарих

Итеративті және инкрементті бағдарламалық қамтамасыз етуді дамыту әдістері 1957 жылға дейін жетеді, эволюциялық жобаны басқару және адаптивті бағдарламалық қамтамасыз етуді дамыту 1970-ші жылдардың басында пайда болды. 1990 жылдары сыншылардың тым реттелген, жоспарланған және микробасқарылған деп сипаттаған, ауыр салмақты әдістерге (көбінесе «су тасқыны» деп аталады) қарсылық ретінде бірқатар жеңіл бағдарламалық қамтамасыз етуді әзірлеу әдістері пайда болды. Бұл жеңіл әдістерге мыналар кірді: 1991 жылдан бастап жылдам қолданбаларды әзірлеу (RAD); 1994 жылдан бастап біріктірілген процесс (UP) және динамикалық жүйелерді дамыту әдісі (DSDM); 1995 жылдан бастап Scrum; 1996 жылдан бастап Crystal Clear және экстремалды бағдарламалау (XP); 1997 жылдан бастап мүмкіндіктерге бағытталған даму (FDD). Бұлардың барлығы Agile манифесті жарияланбастан бұрын пайда болғанмен, қазір олар жиынтығында agile бағдарламалық қамтамасыз етуді дамыту әдістері деп аталады. 1991 жылдан бастап өндіріс және басқару ойлауында Lean менеджментінен туындаған ұқсас өзгерістер болды. 2001 жылы он жеті бағдарламалық жасақтама жасаушы Юта штатының Сноубирд қаласындағы курортта жеңіл салмақты даму әдістерін талқылау үшін бас қосты. Олар: Кент Бек (Extreme Programming), Уорд Каннингэм (Extreme Programming), Дейв Томас (PragProg, Ruby), Джефф Сазерленд (Scrum), Кен Швабер (Scrum), Джим Хайсмит (Adaptive Software Development), Алистер Кокберн (Crystal), Роберт С. Мартин (SOLID), Майк Бидл (Scrum), Ари ван Беннекум, Мартин Фаулер (OOAD және UML), Джеймс Греннинг, Эндрю Хант (PragProg, Ruby), Рон Джеффрис (Extreme Programming), Джон Керн, Брайан Марик (Ruby, TDD) және Стив Меллор (OOA). The Agile Alliance тобы Agile бағдарламалық жасақтаманы дамыту манифестін жариялады, ол agile бағдарламалық қамтамасыз етуді дамыту әдістеріне сәйкес бағдарламалық жобаларды басқаруға бағытталған. 2009 жылы Мартинмен жұмыс істейтін топ бағдарламалық жасақтаманы дамыту принциптеріне толықтыру жасады – Бағдарламалық шеберлік манифесті, ол кәсіби мінез-құлық пен шеберлікке сәйкес agile бағдарламалық жасақтаманы дамытуға бағытталған. 2011 жылы Agile Alliance Agile практикаларына нұсқаулық (2016 жылы Agile Glossary деп қайта аталды) жасады, ол agile практикаларының, терминдер мен элементтердің жұмыс анықтамаларын, сондай-ақ бүкіл әлемдегі тәжірибелі мамандар қауымдастығының түсіндірмелерін және тәжірибелік нұсқаулықтарын қамтитын ашық бастапқы кодты жинақ.

Итеративті, инкременттік және эволюциялық

Көптеген икемді әзірлеу әдістері өнімді дамыту жұмысын алдын ала жоспарлау мен жобалауды барынша азайтатын шағын кезеңдерге бөледі. Итерациялар немесе спринттер – бұл әдетте бірден төрт аптаға дейін созылатын қысқа мерзімдік аралықтар (уақыт шектеулері). Әр итерация жоспарлау, талдау, жобалау, кодтау, модульдік сынау және қабылдау сынағы сияқты барлық функцияларды қамтитын кросс-функционалды команданың жұмысын қамтиды. Итерацияның соңында жұмыс істейтін өнім мүдделі тараптарға көрсетіледі. Бұл жалпы тәуекелді азайтады және өнімнің өзгерістерге жылдам бейімделуіне мүмкіндік береді. Итерация нарыққа шығаруға жеткілікті функционалдық мүмкіндіктерді қамтамасыз етпеуі мүмкін, бірақ мақсаты – әр итерацияның соңында кеміндегі қателермен қолжетімді релизді жасау. Кезеңдеп дамыту арқылы өнімдер әр итеративтік кезеңде «жиі және ерте» сәтсіздікке ұшырау мүмкіндігіне ие болады, соңғы шығарылым күніне дейін күрт сәтсіздікке ұшырамайды. Өнімді немесе жаңа мүмкіндіктерді шығару үшін бірнеше итерациялар қажет болуы мүмкін. Жұмыс істейтін бағдарламалық құрал – прогрестің басты өлшемі. Бұл, әдетте ақ тақтаның алдында, бетпе-бет әрекеттесуге мүмкіндік береді, бұл телефон, тұрақты чат, вики немесе электрондық пошта арқылы сұрақтар мен жауаптарды алмасу кезіндегі цикл уақытын қысқартады. COVID-19 пандемиясы кезінде қашықтан жұмыс істеу кеңінен таралып, құралдар өзгергендіктен, бірлесіп жұмыс істеу және таратылған жұмыс жасау саласындағы зерттеулер көбейді, олар бірлесіп жұмыс істеудің маңыздылығы азайып бара жатқанын көрсетті. Қолданылатын даму әдісіне қарамастан, әр командаға клиент өкілі (Scrum-да өнім иесі деп аталады) кіруі керек. Мүдделі тараптар осы өкілге өз атынан әрекет етуге келіседі және ол әзірлеушілерге сұрақтарға жауап беру үшін итерация бойы қолжетімді болуға міндеттеме береді. Әр итерацияның соңында жобаның мүдделі тараптары клиент өкілімен бірге прогресті қарастырып, инвестицияның қайтарымын (ROI) оңтайландыру және клиенттердің қажеттіліктерімен, компанияның мақсаттарымен үйлесімділікті қамтамасыз ету мақсатында басымдықтарды қайта бағалайды. Мүдделі тараптардың қанағаттануының маңыздылығы, әр кезеңнің соңында жиі өзара әрекеттесу және шолу арқылы егжей-тегжейлі көрсетіледі, сондықтан бұл тәсіл көбінесе клиентке бағытталған методология ретінде қарастырылады.

Ақпараттық радиатор

Агильді бағдарламалық жасақтаманы әзірлеуде ақпараттық радиатор – (көбінесе үлкен) физикалық дисплей, жабысқақ қағаздармен немесе осыған ұқсас тақта, ол әзірлеу тобының жанына анық орынға қойылады, оны кездейсоқ өтетін адамдар көре алады. Ол өнімді әзірлеудің ағымдағы жай-күйінің жиынтық ақпаратын ұсынады. Өнімді әзірлеудің қазіргі жай-күйі туралы команданы хабардар ету үшін құрылыс индикаторының жарығы да қолданылуы мүмкін.

Өте қысқа кері байланыс және бейімделу циклі

Агильді бағдарламалық жасақтаманы әзірлеудегі кең таралған ерекшелік – күнделікті жиын (Scrum аясында күнделікті скрам деп аталады). 15 минуттай қысқа уақыт ішінде команда мүшелері бірлесіп мақсатқа қалай қадам басқандарын қарастырып, тәсілдерін өзгерту қажеттігі туралы келіседі. Белгіленген уақытты сақтау үшін командалар көбінесе қарапайым, белгілі бір сұрақтарды қолданады (мысалы, өткен күні не аяқтады, бүгін не аяқтауды жоспарлап отыр, алға жылжуға кедергі келтіретін немесе тәуекел тудыратын нәрселер бар ма), ал егжей-тегжейлі талқылаулар мен мәселелерді шешуді жиыннан кейінге қалдырады.

Сапаға назар аударылады

Тұрақты интеграция, автоматтандырылған бірлік сынақтары, жұптық бағдарламалау, сынақтармен басқарылатын әзірлеме, жобалау үлгілері, мінез-құлықпен басқарылатын әзірлеме, домендік жобалау, кодты жаңарту және басқа да құралдар мен әдістер өнімді дамытудың сапасын арттыру және икемділігін күшейту үшін жиі қолданылады. Бұл бастапқыда-ақ сапалы жобалау мен құруға, сондай-ақ кез келген сәтте немесе кем дегенде әрбір итерацияның соңында клиенттерге бағдарламалық жасақтаманы көрсету мүмкіндігіне негізделген.

Философия

Дәстүрлі бағдарламалық инженериямен салыстырғанда, икемді бағдарламалық жасақтаманы әзірлеу көбінесе күрделі жүйелерді және динамикалық, белгісіз және сызықты емес қасиеттері бар өнімдерді әзірлеуге бағытталған. Бастапқы кезеңдерде нақты бағалау, тұрақты жоспарлар мен болжамдар жасау қиын болуы мүмкін, сондай-ақ оларға сенім де төмен болуы ықтимал. Икемді тәжірибешілер құндылықтың нақты дәлелі алынғанша қажетті "сеніммен секіруді" азайту үшін өз еркіндіктерін пайдаланады. Қажеттіліктер мен жобалау пайда болатын нәрселер деп есептеледі. Мұндай жағдайларда алдын ала жасалған кең спецификациялар көптеген нәрселердің ысырап болуына әкелуі мүмкін, яғни экономикалық тұрғыдан тиімді емес. Осы негізгі аргументтер және жылдар бойы жетістіктер мен сәтсіздіктерден алынған бұрынғы өнеркәсіптік тәжірибелер, икемді дамудың бейімделуге, итерацияға және эволюциялық дамуға ұмтылуын қалыптастыруға көмектесті.

Үлкен ауқымды, оффшорлық және үлестірілген

Жылдам бағдарламалық жасақтаманы әзірлеуге белгілі бір орталар, соның ішінде жаңа жобалармен айналысатын сарапшылардың шағын топтары өте қолайлы деп есептелді. Ал, мұрагерлік инфрақұрылымы бар ірі ұйымда жылдам бағдарламалық жасақтаманы әзірлеу әдістерін енгізуде кездесетін қиындықтар мен шектеулер жақсы құжатталған және түсінікті. Осыған жауап ретінде, ірі масштабты әзірлеу (>20 бағдарламашы) немесе орналаспаған даму топтары сияқты мәселелерді шешу үшін әртүрлі стратегиялар мен үлгілер пайда болды. Қазіргі таңдағыда осы қиындықтарды жеңілдетуге немесе болдырмауға бағытталған бірнеше танымал құрылымдар бар. Олардың барлығының тиімділігіне, немесе олардың жылдам дамудың нақты анықтамасына сәйкес келуіне қатысты көптеген түрлі пікірлер бар, және бұл мәселе зерттеудің белсенді және үздіксіз саласы болып қалуда. Егер жылдам бағдарламалық жасақтаманы әзірлеу орналаспаған ортада (бірнеше бизнес-орналасқан жерлерде таралған командалармен) қолданылса, онда ол әдетте орналаспаған жылдам бағдарламалық жасақтаманы әзірлеу деп аталады. Мақсаты – әрбір тәсіл ұсынатын ерекше артықшылықтарды пайдалану. Таралған даму ұйымдарға әлемнің әртүрлі бөліктерінде стратегиялық түрде командаларды құру арқылы бағдарламалық жасақтаманы жасауға мүмкіндік береді, нәтижесінде бағдарламалық жасақтаманы тәулік бойы жасауға болады (көбінесе «күнге орай жасау» моделі деп аталады). Ал, жылдам даму ашықтықты арттырады, үздіксіз кері байланыс ұсынады және өзгерістерге жауап беруде икемділікті қамтамасыз етеді.

Тәжірибе және қабылдау

Агильді бағдарламалық қамтамасыз етуді әзірлеу әдістері іс жүзінде кез келген бағдарламалау парадигмасымен немесе тілімен қолданылуы мүмкін болса да, бастапқыда олар Smalltalk, Lisp және кейінірек Java, C# сияқты объектіге бағытталған орталармен тығыз байланысты болды. Агильді әдістерді алғаш рет қабылдағандар көбінесе бұрын-соңды болмаған жүйелерде жұмыс істейтін шағын және орта командалар болды, олардың талаптарын нақтылау қиын болды және жүйе жасалып жатқанда өзгеруі ықтимал еді. Бұл бөлімде ұйымдар агильді бағдарламалық қамтамасыз етуді әзірлеу әдістерін енгізуге тырысқанда кездесетін жалпы мәселелер, сондай-ақ агильді командалардың сапасы мен өнімділігін бағалаудың әртүрлі тәсілдері сипатталады.

Ішкі бағалаулар

Агильділікті өлшеу индексі, басқалармен қатар, өнімді дамытудың бес өлшемі бойынша бағалайды (мерзімі, тәуекелі, жаңашылдығы, еңбегі және өзара әрекеттесуі). Басқа әдістер өлшенетін мақсаттарға негізделген, ал бір зерттеу жылдамдықты агильділіктің өлшемі ретінде пайдалануға болатынын ұсынады. Команданың агильді бағдарламалық жасақтаманы дамыту тәжірибесін қолданатынын анықтау үшін агильді өзін-өзі бағалаулар да бар (Nokia тесті, Karlskrona тесті, 42 ұпайлық тест).

Қоғамдық сауалнамалар

Жылдам бағдарламалық жасақтаманы әзірлеу әдістерін қолдану арқылы сапа, өнімділік және бизнес қанағаттанушылығының артуын көрсеткен алғашқы зерттеулердің бірі – Shine Technologies компаниясы 2002 жылдың қарашасынан 2003 жылдың қаңтарына дейін жүргізген сауалнама болды. 2006 жылдан бастап жыл сайын осыған ұқсас сауалнама, State of Agile, бағдарламалық жасақтаманы әзірлеу саласының мыңдаған қатысушыларымен өткізіледі. Бұл икемділіктің сезілетін пайдасы, алынған сабақтар және жақсы тәжірибелердегі үрдістерді қадағалайды. Әр сауалнама бағдарламалық жасақтаманы жылдам жеткізуге көмектесетіні, клиенттердің өзгеріп жатқан басымдықтарын басқару қабілетін жақсартатыны және өнімділікті арттыратыны туралы мәлімдемелердің көбейгенін көрсетеді. Зерттеулер классикалық жоба басқарумен салыстырғанда, өнімді дамытудың икемді әдістерімен жақсы нәтижелер алынғанын тұрақты түрде көрсетіп келеді. Дегенмен, кейбір мамандар икемді даму әдістерінің табысын кең ауқымды академиялық зерттеулерге қатыстыру үшін әлі де жас екенін айтады.

Жеңіл бағдарламалық жасақтаманы әзірлеудің жалпы тұзақтары

Жылдам бағдарламалық жасақтаманы әзірлеуді енгізетін ұйымдар мен командалар көбінесе шарлау әдісі сияқты дәстүрлі әдістерден өтуде қиындықтарға тап болады, мысалы, командаларға жылдам процестер күштеп таңылған жағдайлар. Мұндай жағдайлар көбінесе "жылдам анти-үлгілер" немесе, көбірек таралғаны "жылдам иістер" деп аталады. Төменде олардың кейбір жиі кездесетін мысалдары келтірілген:

Жалпы өнімнің дизайны жоқ

Жеңіл бағдарламалық жасақтаманы әзірлеудің мақсаты – жұмыс істейтін бағдарламалық жасақтаманы жасауға көбірек назар аудару және құжаттамаға азайту. Бұл, суарналық модельдерден өзгеше, онда процесс көбінесе қатаң бақыланады және жүйеге енгізілген шағын өзгерістер де қолдау құжаттамасын маңызды түрде қайта қарауды талап етеді. Дегенмен, мұның ешқандай талдау мен жобалаудан толығымен бас тартуға құқық беретін жағдайы жоқ. Дизайнға көңіл бөлмеу команданың бастапқыда жылдам жұмыс істеуіне, бірақ кейін жүйені кеңейтуге тырысқанда маңызды түзетулер қажет болуына әкелуі мүмкін. Жеңіл бағдарламалық жасақтаманы әзірлеудің маңызды ерекшеліктерінің бірі – итеративтілігі. Дұрыс орындалғанда, жеңіл бағдарламалық жасақтаманы әзірлеу жүйе дамып келе жатқанда жобаның қалыптасуына мүмкіндік береді және командаға ортақ элементтерді және қайта пайдалану мүмкіндіктерін анықтауға көмектеседі.

Ілеспелерді жалғасып жатқан қайталауға қосу

Агильді бағдарламалық жасақтаманы әзірлеуде, оқиғалар (пайдалану жағдайларын сипаттауға ұқсас) әдетте талаптарды анықтау үшін қолданылады, ал итерация – команданың нақты мақсаттарға қол жеткізуге міндеттенетін қысқа мерзімді кезең. Ағымдағы итерацияға оқиғаларды қосу жұмыс процесіне кедергі келтіреді. Оларды өнімнің қалдық тізіміне қосып, келесі итерацияда басымдық беру керек, немесе сирек жағдайларда итерацияны тоқтатуға болады. Бұл оқиғаны кеңейтуге болмайды деген сөз емес. Командалар жаңа ақпаратты қарастыруы керек, ол оқиға үшін қосымша міндеттерді тудыруы мүмкін. Егер жаңа ақпарат оқиғаның ағымдағы итерацияда аяқталуына кедергі келтірсе, оны келесі итерацияға ауыстыру керек. Дегенмен, жаңа ақпарат оқиғаның бастапқы басымдығын өзгерте алатындықтан, оны қалған оқиғалардың барлығынан жоғары басымдыққа қою қажет.

Демеушілердің қолдауының болмауы

Жылдам бағдарламалық жасақтаманы әзірлеу көбінесе ұйымдарда бағдарламалық жасақтаманы әзірлеу командаларының өз даму процестерін оңтайландыру және бағдарламалық жасақтаманы әзірлеу өмірлік циклындағы тұрақтылықты қамтамасыз ету үшін бастамашылықпен іске асырылады. Демеушілік қолдау болмаған жағдайда, командалар бизнес әріптестерінен, басқа әзірлеу командаларынан және басшылықтан қиындықтар мен қарсылыққа ұшырауы мүмкін. Сонымен қатар, олар жеткілікті қаржыландыру мен ресурстарсыз қиындық көруі мүмкін. Бұл сәтсіздікке ұшырау мүмкіндігін арттырады.

Жетіспейтін оқыту

VersionOne жүргізген сауалнамада жауап берушілер жеткіліксіз оқытуды сәтсіз Agile енгізудің ең маңызды себебі деп көрсетті. Командалар Agile бағдарламалық жасақтаманы әзірлеудің басқа тәсілдерге, мысалы, каскадты әдіске қарағанда процестері азайғаны себепті, нақты ережелер жоқ деп ойлау қатесіне ұшырады.

Өнім иесі рөлі дұрыс толтырылмаған

Өнім иесі даму қызметінде бизнестің өкілі болып табылады және көбінесе ең жоғары талаптар қойылатын рөлді атқарады. Жиі кездесетін қателік – өнім иесінің қызметін даму командасының мүшесіне тапсыру. Бұл команданың бизнестен нақты кері байланыс алмастан, өзінің басымдықтары бойынша шешімдер қабылдауын қажет етеді. Олар бизнес мәселелерін команда ішінде шешуге тырысады немесе бағыт алу үшін командадан тыс көмек іздегенде жұмысты кешіктіреді. Мұндай жағдай көбінесе назарды ауыстырып, ынтымақтастықтың бұзылуына әкеледі.

Командалар жұмысына назар аудармайды

Жылдам бағдарламалық жасақтаманы әзірлеу командалардан өнімге берген уәделерін орындауды қажет етеді, яғни олар тек сол өнімге қатысты жұмыстарға назар аударуы тиіс. Дегенмен, мүмкіндігі бос көрінетін команда мүшелерінен көбінесе басқа жұмыстарды алу талап етіледі, бұл олардың командасының міндеттемесін аяқтауға көмектесуін қиындатады.

Артық дайындық/жоспарлау

Командалар дайындыққа немесе жоспарлауға тым көп уақыт жұмсап, қателікке ұшырауы мүмкін. Бұл, әсіресе, шапшаң бағдарламалық жасақтаманы әзірлеумен жақсы таныс емес командалар үшін жиі кездесетін жағдай. Мұндай командалар барлық талаптарды толыққанды түсініп, нақтылауға міндетті деп ойлайды. Командалар тек сенімділіктерін білдіретін талаптармен жұмысқа кірісуге дайын болуы керек, ал итерация барысында келесі итерациялар үшін жұмысты ашуға және дайындауға көшуі керек (бұл көбінесе артта қалған талаптарды жетілдіру немесе күту деп аталады).

Күнделікті өмірде проблемаларды шешу

Күнделікті жиын назар салынған, уақтылы өткізілетін кездесу болуы керек, онда барлық команда мүшелері ақпарат алмасады. Егер мәселені шешу туындаса, көбінесе тек белгілі бір команда мүшелері ғана қатысады және бұл бүкіл команданың уақытын тиімді пайдаланудың ең жақсы жолы болмауы мүмкін. Егер күнделікті жиында команда мәселені шешуге терең бойласа, оны кіші топ талқылағанға дейін, әдетте жиын аяқталғаннан кейін бірден, кейінге қалдыру керек.

Тапсырмаларды тағайындау

Жылдам бағдарламалық жасақтаманы әзірлеудің күтілетін артықшылықтарының бірі – командаға шешімдер қабылдауға мүмкіндік беру, себебі олар мәселеге ең жақын. Сонымен қатар, олар шешімдерді мүмкіндігінше орындау кезеңіне жақын қабылдауы керек, сонда ғана шешімдерде уақтылы ақпаратты пайдалануға болады. Егер команда мүшелеріне басқалар тапсырма берсе немесе процестің басында тапсырмалар берілсе, жергілікті және уақтылы шешім қабылдаудың пайдасы жоғалуы мүмкін. Жұмыс тағайындалғанда команда мүшелері белгілі бір рөлдерге бекітіледі (мысалы, команда мүшесі А әрқашан дерекқорымен жұмыс істеуі керек), бұл өзара оқыту мүмкіндіктерін шектейді. Scrum Master бірнеше жұмысты қатар орындаса, өнімді болу үшін тым көп контексттік ауысулар болуы мүмкін. Атап айтқанда, Scrum Master команданың алға жылжуына кедергі келтіретін факторларды жоюға жауапты болғандықтан, жекелеген тапсырмалардың алға жылжуынан алынған пайда, мүмкіндіктердің жетіспеуіне байланысты кейінге қалдырылған кедергілерден кем болуы мүмкін.

Сынақты автоматтандырудың болмауы

Жылдам әзірлеудің итеративті табиғатына байланысты, көбінесе бірнеше сынақ раундтары қажет болады. Автоматтандырылған тестілеу қайта-қайта жүзеге асырылатын бірлік, интеграциялық және регрессиялық тестілеулердің салдарынан туындайтын жүктемені азайтуға көмектеседі және бағдарламашылар мен тестілеушілерді жоғары құнды жұмыстарға назар аударуға мүмкіндік береді. Тестілеуді автоматтандыру итеративті бағдарламалық жасақтаманы әзірлеу кезінде қажет болатын қайта құру процесін де қолдайды. Бағдарламашыға қайта құру қолданбаның функционалдығын өзгертпегенін тез тексеруге мүмкіндік беру, жұмыс жүктемесін азайтып, жасалған өзгерістердің жаңа қателерге әкеп соқпағанына сенімділікті арттырады.

Техникалық қарызды жинақтауға мүмкіндік беру

Жаңа функционалдылықты жеткізуге баса назар аудару техникалық қарыздың артуына алып келуі мүмкін. Команда ақауларды жою және кодты қайта құруға уақыт бөлуі керек. Техникалық қарыз жоспарлау мүмкіндіктерін шектейді, өйткені өндірістегі ақаулар команданы одан әрі дамытудан алаңдатып, жоспарланбаған жұмыстың көлемін ұлғайтады. Жүйе дами келе, оны қайта құру маңызды. Ұзақ уақыт бойы тұрақты техникалық қолдау көрсетілмесе, ақаулардың саны мен дамыту шығындары арта түседі. Бір уақытта тым көп жұмыс істеу (WIP) контекст ауыстыру және кезекте күту сияқты тиімсіздіктерге әкеледі. Команда қосымша жұмысқа мәжбүрленіп істеуден сақтану керек.

Белгіленген уақыт, ресурстар, ауқымы және сапасы

Жылдам бағдарламалық жасақтаманы әзірлеу уақытты (итерация ұзақтығын), сапаны және, мүмкіндігінше, ресурстарды алдын ала анықтайды (бірақ әзірлеушілер жиі өндірістік мәселелерді шешу үшін жұмыстарынан ауысатындықтан, ресурстарды тұрақты ұстау қиын болуы мүмкін), ал көлемі өзгермелі болып қалады. Клиент немесе өнім иесі көбінесе итерация үшін белгілі бір көлемді талап етеді. Дегенмен, командалар бекітілген уақыт, ресурстар және көлемге (көбінесе жоба басқаруының үшбұрышы деп аталады) келісуге тиіс емес. Жылдам бағдарламалық жасақтаманы әзірлеудің белгіленген уақыты мен ресурстарына көлемді қосуға тырысу нәтижесінде сапа төмендеуі мүмкін.

Дамушылардың шаршауы

Ағылшын тәжірибелерінің қарқындылығы мен үздірілмейтін сипатының салдарынан жеткізу тобының мүшелерінде шаруашылықты жою қаупі артады.

Бағдарламалық жасақтамадан тыс қосымшалар

Жан Лу Рише (ESSEC Strategic Innovation & Services институтының ғылыми қызметкері) пікірінше, "осы тәсіл бағдарламалық қамтамасыз ету емес өнімдер үшін де, жалпы жобаларды басқаруда да тиімді қолданылуы мүмкін, әсіресе инновация және белгісіздік салаларында". Нәтижесінде, өнім немесе жоба қазіргі тұтынушылардың қажеттіліктерін ең жақсы қанағаттандырады және минималды шығын, ысырап пен уақытпен жеткізіледі, бұл компанияларға дәстүрлі тәсілдерге қарағанда ертерек табысқа жетуге мүмкіндік береді. Жедел бағдарламалық жасақтаманы дамыту әдістері бағдарламалық өнімдерді жасау үшін кеңінен қолданылған, ал олардың кейбіреулері объектілік технологиялар сияқты бағдарламалық жасақтаманың нақты ерекшеліктерін пайдаланады. Дегенмен, бұл техникаларды компьютерлер, медициналық құралдар, тағам, киім және музыка сияқты бағдарламалық қамтамасыз етуді қажет етпейтін өнімдерді дамытуға да қолдануға болады. Жедел бағдарламалық жасақтаманы дамыту әдістері АТ-инфрақұрылымды дамыту және көшіру кезінде де қолданылған. Жедел бағдарламалық жасақтаманы дамытудың негізгі принциптері жалпы басқаруда (мысалы, стратегия, басқару, тәуекел, қаржы) бизнес-шапшаңдық немесе шапшаң бизнес-басқару терминдерімен қолданыс тапқан. Жедел бағдарламалық жасақтаманы дамыту парадигмаларын өмірдің басқа да салаларында, мысалы, бала тәрбиелеуде қолдануға болады. Балалардың дамуындағы оның табысы қарым-қатынас, бейімделу және хабардар болу сияқты негізгі басқару принциптеріне байланысты болуы мүмкін. TED сөз сөйлеу кезінде Брюс Фейлер үй шаруашылығын және бала тәрбиесін басқаруға жедел парадигмаларды қалай қолданғанын бөлісті.