Agile-дің тарихы 2001 жылы жарияланған «Agile бағдарламалық қамтамасыз ету даму үшін манифест» атты 12 негізгі қағидаттан бастау алады. Ақиқатында, Agile тәсілінің кейбір элементтері одан бұрын пайда болған, бірақ тек бұл құжат оларды жүйелеп, пайдалану үшін жеткілікті дәрежеде ұсынды. Жылдан-жылға жаңа компаниялар, IT мамандары және жобаларды басқарушылар манифестке қосылады. Agile даму жүйесінің жаңа әдістері мен нұсқалары пайда болуы жалғасуда.
Agile (икемді) әдістеме дегеніміз не?
Agile — бағдарламалық қамтамасыз етуді жобаның басынан бастап кезең-кезеңімен жасауды қамтитын интерактивті даму үлгісі, яғни код жұмыс циклідің соңында жеткізілетін каскадтық модельдерден айырмашылығы.
Икемді әдістеме жобаларды пайдаланушы әңгімелері деп аталатын шағын операциялық бөлшектерге бөлуге негізделеді. Приоритеттерге сәйкес, тапсырмалар қысқа екі апталық циклдарда (итерациялар) шешіледі.
Agile әдістемесін құрайтын 12 принципті 4 негізгі идеяға айналдыруға болады:
- Құралдар мен процестерден гөрі адамдар мен коммуникацияларға басымдық;
- Кең көлемді құжаттамадан гөрі функционалды өнімге басымдық;
- Шартты растаудан гөрі клиенттермен ынтымақтастыққа басымдық;
- Алғашқы жоспарды орындаудан гөрі өзгерістерге дайын болуға басымдық.
Agile-ге тән әдістер:
Scrum
Scrum термині регбиден алынған, онда бұл сөз қарсылас командалардың допты алу үшін үш қатарға орналастыру әдісін білдіреді. Сәтті қайта алуда тек жақсы физикалық форма ғана емес, әр ойыншы басқа ойыншылармен келісілген әрекетпен, мақсатты нақты түсінуімен әрекет етуі керек.
Бұл әдіс Microsoft, Yahoo, Siemens Healthcare сияқты компаниялармен сәтті қолданылады. Amazon-ның жоба менеджері тіпті Scrum-ды енгізу жағдайын талдады.
Scrum даму үшін рамка болғандықтан, оған қатысты әртүрлі мысалдар бір-бірінен ерекшеленуі мүмкін.
Jeff Sutherland, «Scrum. Жұмысты жарты уақыт ішінде екі есе орындау өнері» кібетінің авторы, әдістемені қолдану үшін 8 қадамды бөлді:
- Жобаның мақсаты мен күтілетін нәтижесін білетін өнім иесін таңдаңыз.
- Басқарылатын команда құрыңыз — операциялық өнім жасауда қажетті дағдылары бар 10 адамға дейінгі команда.
- Жобаның жұмыс барысын бақылап, командаға қиындықтарға жәрдемдесетін Scrum мастығын тағайындаңыз.
- Әр өнім талабына сәйкес басымдықтарды Agile тақтасында бекітіп, өнім жиналысын жасаңыз. Бұл процессте қажетті өнім иесінің рөлі маңызды, себебі ол жиналыс тобына баға беру үшін өнімге арналып талаптарды жинайды.
- Определять спринттер (итерациялар) — нақты тапсырмалар тізбегін аяқтау үшін уақыт фрагменттерін белгілеңіз.
- Күнделікті он бес минуттық кездесулерді ұйымдастырыңыз — әр команда мүшесіне 3 сұрақ қойыңыз: кеше не істеді, бүгін не істейді, тапсырманы орындауға кедергі келтіретін не.
- Өнімнің операциялық бөлімдерін тексерулер жасау — мүдделі тараптарды мұндай тексерулерге қатыстыру арқылы.
- Спринттен кейін әр спринтке өзгертулер енгізу жоспарын енгізіп, референс өткізуді өткізіңіз.
Референс In Agile
Scrum төрт негізгі элементтен тұрады:
- Өнім жиналысы — жобаның талаптары тізімі
- Спринт жиналысы — келесі спринтте орындалуы тиіс талаптар тізімі
- Спринт мақсаты — спринт мақсаты
- Спринт Burndown диаграммасы — тапсырмалар аяқталуына байланысты жаңартылатын диаграмма. Ол динамика мен команданың жобадағы алға жылжудағы деңгейін түсінуіне көмектеседі.
eXtreme Programming (XP)
Kent Beck, бұл әдістеменің жасаушысы, бағдарламалық продукт талаптарын ескеретін және дамыту сапасын жақсартатын экстремалды бағдарламалау әдісін жасады.
Бұл тек бағдарламалық қамтамасыз ету даму саласында қолданылады, және 4 процестен тұрады:
- кодтау — команданың бірдей орналасу стандарттарына сәйкес;
- тестілеу — тесттер негізінен код жазылмай тұрып бағдарламашылармен іске асырылады;
- жоспарлау — біріншіден, соңғы құрылым үшін, екіншіден, жеке итерациялар үшін. Соңғысы орташа екі апта сайын болады.
- аудит — Developer мен клиенттің, анықталмаған мәселелерді жою және талаптар мен құндылықтарды анықтау.
Crystal әдістемелері
Бұл әдістемелер отбасы, «Agile бағдарламалық қамтамасыз ету даму үшін манифестінің» авторларының бірі, Alistair Cockburn-мен әзірленген, жобаларды басқарудың кейбір жергілікті салаларында аз таныс. Cockburn командалар санына негізделген түсірілім бойынша классификациялауды ұсынады: 2 (Crystal Clear) ‑ден 100 (Crystal Red) ‑ге дейін. Maroon, Blue және Violet түстері үлкен жобаларға тағайындалады.
Crystal жобалары 3 негізгі қасиетке сай болуы тиіс:
- операциялық кодтың жылдам жеткізілуі — Agile дамуындағы итерациялық модельдің дамушы идеясы.
- рефлексия арқылы жетілдіру — жаңа бағдарламалық нұсқа алдыңғы ақпарат негізінде жақсарады.
- “осмостық” өзара әрекеттесу — Alistair-дің инновациясы, бағдарламалық әзірлеушілер арасындағы ақпарат алмасу метафорасы.
Бұл әдістемелер отбасы Alistairдың «Crystal Clear: Кішкентай командалар үшін адаммен басқарылатын әдістеме» атты кітапта толық сипатталған.
Динамикалық бағдарламалық қамтамасыз ету даму әдісі (DSDM)
DSDM дамуына тек 17 британдық компаниялардың консорциумы емес, тек адамдар жұмыс істеді. Экстремалды бағдарламалауға ұқсас, DSDM негізінен бағдарламалық қамтамасыз етеді.
Даму процесінде соңғы тұтынушыға (пайдаланушы) ерекше рөл беріледі. Бұл негізгі принцип келесі негізгі принциптермен толықтырылды:
- өнімнің операциялық нұсқаларын жиі шығарылым
- қабылдаушылардың шешімдер қабылдауда дербестігі
- жұмыс циклі барысында тестілеу.
DSDM технологиялардың дамуына және жаңа бағдарламалық қамтамасыз ету талаптарының пайда болуына байланысты жаңартылатын нұсқаларға бөлінеді. Қазіргі кезде ең соңғысы 2007 жылы шыққан DSDM Atern, ал алдыңғысы (2003 жылғы) әлі де қызмет көрсетуде.
Басында команда қосымшаны дамыту мүмкіндігін және пайдалану аясын қарастырады. Содан кейін жұмыс үш өзара байланысты циклге бөлінеді:
- функционалдық модель циклі — аналитикалық құжаттар мен прототиптер жасау.
- дизайн&инженерия циклі — жүйені іске асыру.
- жүзеге асыру циклі — жүйенің орнатылуы.
Міндеттерге бағытталған даму (FDD)
Бұл әдістеме «Agile бағдарламалық қамтамасыз ету даму үшін манифестінен» бұрын пайда болды.
FDD, сондай-ақ даму итерация моделімен қолданса да, Agile-ден келесі ерекшеліктермен ерекшеленеді:
- алдын ала моделдеу үшін көп көңіл бөлінеді
- (Agile-мен салыстырғанда) есептер мен диаграммалардың маңызы артады
- методология корпоративтік дамуға арналған.
Міндеттерге бағытталған даму келесі циклдік кезеңдерден тұрады:
- Жалпы модель құру — жобаның алдын ала деректер негізінде.
- Міндеттер тізімін әзірлеу — Scrum әдістемесінде өнім күйі секілді.
- Міндеттер бойынша жоспарлау — әр команда мүшесі міндердің қиындығын бағалайды.
- Әр міндет үшін — техникалық дизайн мен жүзеге асыру — міндеттердің соңғы кезеңі, ол аяқталғаннан кейін міндет өнімге қосылады, цикл қайталанады.
Lean бағдарламалық қамтамасыз ету даму
Lean бағдарламалық қамтамасыз ету дамуы — даму процесінің тиімділігін арттыру мен шығындарды минималдауға бағытталған жетілген басқару принциптерінің жиынтығы (методология емес).
Бұл жиынтық келесі 7 негізгі қағидаттан тұрады:
- шығындарды жою — өнімге соңғы тұтынушы үшін құн қоспайтын барлық нәрсе.
- үздіксіз оқыту — команда дамуы тапсырмаларды тиімді орындау мүмкіндіктерін арттырады.
- шешімдерді мүмкіндігінше кеш қабылдау — алдын ала дайындалған, жинақталған білімдерге негізделген шешімдерге басымдық беріледі, спонтанды шешімдерге емес.
- жылдам жеткізу — бұл итерациялық моделдің негізгі қағидаты.
- команда күшейту — «Манифест екенін» ұстау үшін адамдар мен олардың өзара әрекеттері процестер мен құралдардан маңыздырақ. Жобалық команда тапсырмаларды тиімді аяқтау үшін ең жақсы кепілдік болып табылады.
- тұтастық және сапа — уақыт пен ресурстарды тексеру мен қателерді жою үшін айырылған жоғары сапалы өнім жасау қажет.
- жиынтық суретті көру — жоба дәл қазіргі даму жағдайын, сонымен қатар әзірленген бағдарламалық қамтамасыз ету мақсаттары, концепциялары мен стратегияларын түсіндірмей бөлуге болмайды.
Agile даму әдістемелерінің нұсқалары
Agile моделін (AM)
Agile моделін бағдарламалық қамтамасыз етуді моделдеуге арналған құндылықтар, қағидаттар мен тәжірибелер жиынтығы.
AM толыққанды бағдарламалық қамтамасыз ету әдістемелерінде — мысалы, экстремалды бағдарламалауда немесе жылдам қолданба дамуында элемент ретінде қолданылады.
Agile моделінің келесі негізгі ерекшеліктері бар:
- жобалық мүдделес тараптармен тиімді өзара әрекеттесу;
- бәрінен де талаптарды қанағаттандыратын барлық мүмкін шешімдердің ең қарапайым бірі;
- кері байланысты үздіксіз алу;
- шешімдер қабылдауға батылдық және оларға жауапкершілік алу;
- Сіз бәрін білгеніңізді түсіну.
Agile біріккен процесс (AUP)
AUP — Rational Unified Process (RUP) бағдарламалық қамтамасыз ету әдістемесінің қарапайымдалған нұсқасы. 2012 жылдың берілмесіне қарсы, Disciplined Agile Delivery (DAD) естелікке бағдарламаланған, бірақ AUP әлі де жақын және алыс жерде қолданыста.
Scott Ambler, әдістеменің авторы, Agile Unified Process-тегі келесі маңызды мәліметтерді бөліп көрсетті:
- Сіздің командаңыз не істейтінін біледі;
- Жеңілдік бірінші орында.
- Икемді даму әдістемесінің қағидаларына сәйкестілік.
- Жобаның құнды қызметтеріне назар аудару.
- Құралдар тандауда дербестік.
- Арнайы жобаның талаптарына AUP конфигурациясын бөлу.
Agile Data Method (ADM)
ADM түрлі командалардың ынтымақтаса отырып, жобаға көрсетілімдер мен шешімдері қалыптастыруды ерекше назар аударатын итерациялық бағдарламалық қамтамасыз ету әдістемелерінің жиынтығы. AUP сияқты, бұл әдістеме де толық емес.
Agile Data Method принципі алты қағидатпен анықталады:
- Деректер — кез келген қосымшаны жасау негізі.
- Жобадағы мәселелер — жобаның мақсаты мен концепциясы анықталғаннан кейін ғана анықталады.
- Жұмыс топтары — негізі әзірлеушілер тобының сыртында, басқа жұмыс топтарына қолдау көрсететін кәсіпорын топтары бар.
- Бірегейлік — мінсіз әдістеме жоқ, сондықтан әр жоба түрлі әдістемелерден құралдарды біріктіруді талап етеді.
- Командалық жұмыс — бірге жұмыс жасау жеке жұмыстардан әлдеқайда тиімді.
- “Тәтті нүкте” — мәселенің оңтайлы шешімін (“тәтті нүкте”) іздеу, шамадан тыс жағдайларды болдырмау.
Негізгі бірлескен процесс (EssUP)
Бұл Ивар Якобсон, швед ғалымы, Рассир естелігін жақсарту үшін әзірледі.
EssUP тәжірибе концепциясын қолданады, оған мыналар кіреді:
- қолдану сценарийі — жүйенің мінез-құлқын сипаттау.
- итерациялы даму — бірнеше апта көлемінде кодтың операциялық бөліктерін жасау.
- командалық тәжірибелер — команданы жинауға және оның тиімділігін арттыруға арналған.
- процедуралық тәжірибелер — мысалы, “Бүкіл әлем туралы ойла, алысырақ баста” немесе “Мүдделі тараптарды бизнес процестеріне тарту”.
Барлық тәжірибелер RUP және CMMI әдістемелерінде, сонымен қатар икемді даму әдістемесінде ауытқып кетеді.
Шындыққа айналу (GR)
Бұл шағын жобалар мен компанияларында ерекше сипаттамаларына барынша қолданып, стартаптар мен бастауыш командалар үшін тиімді методология.
Jason Fried және David Hansson, 37 сигналдар компаниясының (қазіргі Basecamp) негізін қалаушылары, GR-ды жүзеге асыруға тиімді тапсырмаларды шешу жүйесі ретінде анықтады, ол мінсіз, анық, әрі функционалды.
GR қажетсіздіктерді минималдандыру үшін қолданылатын он шақты Agile дамыту құралдарының микстингі:
- баламалар
- параметрлері мен параметрлері
- компания құрылымы
- жиналыстар
- умтылулар.
Бұл ерекше концепция негізгі поток, бірақ бірқатар элементтері басқа методологиялармен біріктірілуде.
OpenUP (OUP)
Бұл құралдарға тәуелсіз және қатал құрылымнан бос бағдарламалық дамыту методологиясы, келесі тәжірибелерді ұсынады:
- команданың жұмыс жылдамдығын анықтау;
- күнделікті кездесулер өткізу және итерациялар аяқталғанда референстар өткізу;
- микрокадрлар мен тексеру тізімдерін пайдаланып, ертерек тестілеу концепциясы;
- Agile Model Driven Development (AMDD) методологиясы.
Бұл тәжірибелер төрт принциптерге негізделеді:
- мүдделерді татулау және ортақ көріністі жүзеге асыру;
- үздіксіз қайта байланыс арқылы жетілдіру;
- қолданбаның архитектурасына ертерек түзету жасау арқылы тәуекелдерді минималдау;
- құнды максималдау соңғы тұтынушы үшін.
Agile көрсеткіштері
Agile құралдарының, тәжірибелерінің, әдістерінің және методологияларының алуандығымен, әрбіреуінің тиімділігін анықтауға көмек көрсететін құралды таңдауға тиіс.
Параметрлер осындай құрал ретінде пайдаланылады.
Көптеген жобалар үшін, осы 4 параметр топтары жеткілікті болады:
- Өнімділік — ол Velocity және WIP параметрлеріне жатады. Біріншісі барлық жобаларға жарамды емес, өйткені итерация бойынша орындалған тапсырмалар саны өлшенеді, бірақ итерациялар теңестіру қажет. Жұмыс-тәжірибе метрикасы түрлі сатылардағы тапсырмалар шегін анықтайды: қаншалықты жоғары болса, соғұрлым нашар өтеді;
- Болжам жасау — импорт параметрі, ол келесі спринтте жетілген сағат саны болжамын анықтауды қамтиды. Өз кезегінде, бұл жұмыс үшін ашық уақыт көлемін, тапсырмаларды өткізу тиімділігін, сонымен бірге спринттегі тапсырмалар санын жоспарлауға мүмкіндік береді;
- Сапа — мысалы, талаптардың тұрақтылық индексі, оны формуламен есептейміз = (Бастапқы бизнес талаптарының жалпы саны + Берілу мерзіміне қарай өзгерген талаптардың саны + Қосқан талаптардың саны + Төмендетілген талаптардың саны) / (бастапқы талаптардың жалпы саны). Бұл параметр тапсырмаларды қайта өңдеуге жұмсалған уақытты анықтау үшін пайдаланылады;
- Құндылықтар — бұл параметр жобаның форматына байланысты әрбір жағдайда жеке есептеледі. Мысалы, AirBnb стартапында, жүктелген жоғары сапалы фотосуреттер саны пайдаланушылар үшін өнімнің соңғы құндылығын анықтау үшін параметр ретінде таңдалды. Бұл сан өскен сайын, пайдаланушылардың саны да арта түсті.
Параметрлерге қолданылатын ережелер басқа Agile құралдармен бірдей.
Сіздің жобаңызға нақты дұрыс және маңызды бірлік параметр жоқ.
Параметрлер үнемі қайта қаралуы керек, ескіргендері шетке шығарылуы керек, ал қажет болғанда жаңалары қосылуы керек. Ол барлығына қолжетімді болуы керек, онымен жүзеге асырылмаған міндет ретінде қабылданбауы керек. Жай параметрлер үшін параметрлер нашар шешім болып табылады.
Мифтерді жою: Agile
Икемді даму әдістемесінің танымалдылығы белгілі бір жағдайларда ол туралы мифтердің пайда болуына төменде қалды. Оларды түсіндіріп алайық!
Миф №1: Agile барлық жобаларға сәйкес келеді.
Бұл ең терең түсініксіздік. Тек бір Agile әдісі өзі өнімнің құндылығын қоспайды, және командаға мотивация бермейді.
Миф №2: Agile құжаттамаларды қаламайды.
Икемді даму әдістемесі құжаттамаға қарсы емес, тек құжаттаманы өз мақсатын жоққа шығарады. Коммуникация құрал ретінде құжаттама таңдағанда, Agile жеке коммуникацияға ең көп қолдау көрсетеді.
Миф №3: Agile пен жоспарлау бір-біріне қайшы келеді.
Бұл миф күнделікті жоспарлау шараларын 10 минуттық стендаптар және итерацияны жоспарлаумен, спринт кездесулерімен түсіндіреді.
Миф №4: Agile көп қайта өңдеуді талап етеді.
Agile бағдарламалық даму әдістемесі қайта өңдеуді екі түрде қамтиды: талаптарды қайта өңдеу (пайдаланушылар не керек екенін анықтайды) және бағдарламалық қайта өңдеу (әзірлеуші топтары қосымшаларды жазуға және жобалауға жақсартылған тәсілдерді табады). Бірақ бұл басқа әдістемелерде де орын алуы мүмкін! Бұдан басқа, итерация моделі сияқты Agile жаңалығы қайта өңдеудің теріс әсерін азайту үшін қызмет етеді.
Agile-дің пайдалану артықшылықтары мен кемшіліктері
Артықшылықтар:
- мүдделі тараптарды тарту — команда клиенттің талаптарын түсінуге қабілетті бола түсті. Сонымен қатар, бағдарламалық қамтамасыз етудің ерте және жиі жеткізілуі мүдделі тараптардың жобалық топқа сенімін нығайтады және жобадағы тартылуды тереңдетеді.
- ерте және болжамды құру — итерацияларға негізделген даму моделі (1‑ден 6 аптаға дейінгі қысқа мерзім) икемділік береді жәânea нұсқасын шығаруды алдын алады.
- кәсіптік құнға назар аудару — клиентпен ынтымақтастық командаға тұтынушы үшін өнімнің құнды болуын түсінуге мүмкіндік береді.
- үздіксіз сапаны жетілдіру — итерация сайын тестілеу, соңғы құрылымды операциялық кодтың бөлек бөліктеріне бөлу өнімнің сапасыз өнімдерін босануға дейін жақсартуға және жоюға жеңілдетеді.
Кемшіліктер:
- команда мен клиенттер үшін қатал талаптар — жобалық команда мен пайдаланушылар арасында тығыз өзара әрекеттесу болмаса, жоғары құнды сапалы өнім шығару қамтамасыз етілмейді. Сонымен қатар, мол Agile құралдар мен әдістемелер командадан дұрыс енгізу үшін тәжірибені талап етеді.
- сыртқы тапсырыстар мен тек онлайн режимінде өзара әрекеттесетін жобаларды қабылдамайды.
- соңғы бағдарламалық нұсқаның ешқашан шығарылуының қатері — қызықты, бұл кемшілік Agile-дің итерациялық өндіруші даму мен өнімнің үздіксіз жетілдіру артықшылықтарының нәтижесінде шығарылады.
- бизнес мақсаттарының анық көрінуі болмайынша өтеді — Agile командасы мүшелері мүдделі тараптармен бағытталуы, мақсаттары мен концепциялары айқын түрде анықталмаған өнімді дамыту мүмкін болмайды.
Білімдер
Бәрі болмаса, барлық жобаларды басқару қызметтері мен бағдарламалары Agile-негізделген жобаларды басқаруға сәйкес келмейді, өйткені олардың әр қайсысының арнайы ерекшеліктері бар.
Егер сіздің бизнесіңіз маркетинг&жарнама, дизайн, SEO немесе цифрлы агенттік болса, Worksection-нен SaaS қызметін командамызбен жұмыс істеу үшін пайдалануға болады. Біз COXO Digital, Royal ® жарнамасы және Prozorro бойынша ұсынылулармен мақұлдандық.
Worksection-да Agile-ды конфигурациялау үшін бірнеше өмір хактары:
- Компанияңызда қажетті тегтер мен статустарды олардың жұмысы үшін конфигурациялаңыз.Статустар: жұмыс істеп жатыр, тексеру, дайын, қайта өңдеу қажет, критикалық, функционалдар, төлем мерзімі. Тегтер көбіне былай болады: орналастыру, тексеру, өндіру, концепция, код.
- Жоба жиналысы мен жобалық спринт жасаңыз.
- Орындалатын тапсырмаларды және алдын ала тексеру тізімдерін, эскиздерді және т.б. жиналыста жасаңыз.
- Кездесулер барысында спринт тапсырмаларын анықтаңыз және оларды жиналыстан шығарыңыз.
- Тапсырмаларға клиенттердің демалыс уақытын пайдалану, осылайша жоба бойынша әрқашан келісілген және өзекті сергек пікірлерді алуыңыз қажет.
- Әр әріптес үшін тапсырмаларда жауапты адамдарды белгілеңіз, сонда әркім өз жауапкершілік аумағын білетін болады және спринт нәтижесіне қатысуға сезім туындайды.
Сот
Agile бағдарламалық қамтамасыз ету даму әдістемесі арқасында шағын жобалық топ максималды тиімділікті алады. Agile-ды Scrum, XP, Lean сияқты басқа икемді әдістер арқылы жүзеге асырады.
Оны асығыс енгізу, тәжірибесіз командамен, қысқа мерзім ішінде қолдану мүмкін емес,
бірақ енгізілген кезде Agile IT-мен бизнес арасында өзара әрекеттестікті жақсартады, өнімді нарыққа шығаруға ынталандырады, және тұтынушы үшін өнімнің құндылығын арттырады.