Agile тарихы 2001 жылы жарияланған «Agile бағдарламалық жасақтама дамыту манифестінде» 12 қағидаттан тұратын. Күмәнсіз, Agile әдістемесінің кейбір элементтері бұған дейін пайда болды, бірақ тек осы құжат оларды жүйелеп, пайдалану үшін жеткілікті дәрежеде сипаттады. Жыл сайын жаңа компаниялар, IT мамандары және жобаларды басқарушылар манифестке бет бұрады. Agile даму жүйесінің жаңа әдістері мен нұсқалары пайда болады.
Agile (икемді) әдістеме дегеніміз не?
Agile — бұл бағдарламалық жасақтаманы жобаның бастапқы кезде кезең-кезеңмен жасау модельі, жұмыс циклі аяқталған кезде код берілетін каскадтық модельдерге қарама-қарсы.
Икемді әдістеме жобаларды пайдаланушы әңгімелері деп аталатын кішкентай операциялық бөліктерге бөлуді негізге алады. Басымдықтарға сәйкес, тапсырмалар қысқа екі апталық циклдар (итерациялар) ішінде шешіледі.
Agile әдістемесін құрайтын 12 қағидатты 4 негізгі идеяға жинақтауға болады:
- Құралдар мен процестерден гөрі адамдар мен коммуникацияның басымдығы;
- Құжаттамадан гөрі функционалды өнімнің басымдығы;
- Клиентпен ынтымақтастықтың келісім-шартты растаудан гөрі басымдығы;
- Бастапқы жоспарды орындаудан гөрі өзгерістерге дайын болудың басымдығы.
Agile-ға тән әдістер:
Scrum
Scrum термині регби спортына негізделген, онда бұл сөз командалық ойынды білдіреді. Успешное переподключение, не только хорошая физическая подготовка необходима — каждый игрок, находящийся в состоянии Scrum должен действовать согласованно с другими, с четким пониманием цели.
Бұл әдіс Microsoft, Yahoo, Siemens Healthcare сияқты компаниялармен сәтті қолданылады. Amazon-ның жобалар менеджері Scrum енгізудің тәжірибесіне негізделген оқиғаны сипаттады.
Scrum даму үшін негіз болып табылады, әрбір кейінгі мысал алдыңғыдан ерекшеленуі мүмкін.
Джефф Сазерленд, «Scrum. Жұмысты жарты уақыт ішінде екі есе жасау өнері» кітабының авторы, әдістемені қолданудың 8 кезеңін анықтады:
- Өнім иесін таңдаңыз, ол жоба мақсатын және күтілетін нәтижені біледі.
- Команданы ұйымдастырыңыз — 10 адамға дейін, операциялық өнім жасау үшін қажетті дағдылармен.
- Scrum шеберін тағайындаңыз, ол жобаның жұмыс ағынын бақылайды және жобалық команданы қиындықтармен шешуге көмектеседі.
- Жобаның жүктелуі — өнім талаптары үшін Agile тақтасында басымдықтар орнатыңыз. Осы процесте өнім иесінің рөлі маңызды, себебі ол команданың бағалауы үшін жүктеме командасы үшін өнімнің талаптарын жинайды.
- Спринттерді (итерациялар) жоспарлаңыз — белгілі тапсырмалар тізбегін орындау үшін уақыт фрагменттері.
- Күнделікті он бес минуттық кездесулер ұйымдастырыңыз — әр команданың мүшесіне 3 сұрақ қойыңыз: кеше не істеді, бүгін не істейді, тапсырманы орындауға не кедергі.
- Өнімнің операциялық бөліктерін қайта қарау жасаңыз — мүдделі тараптарды осындай тексерулерге қатыстырыңыз.
- Ретроспективалар өткізіңіз — әр спринттен кейін шешімдерді іздеу проблемаларын талқылау. Нәтижесінде алынған өзгерістер жоспарын келесі спринтте іске асырыңыз.
Ретроспектива в Agile
Scrum-да 4 негізгі элемент бар:
- Өнімнің жүктелуі — жобаның талаптарының тізімі
- Спинт жүктелуі — келесі спринтте орындалуға тиіс талаптар тізімі
- Спринт мақсаты — спринт міндеті
- Спринт күйдіру диаграммасы — тапсырмалар орындалып жатқан кезде жаңартылатын диаграмма. Ол динамика мен команда дамуының деңгейін түсінуге көмектеседі.
eXtreme Programming (XP)
Кент Бек, осы әдістеменің әзірлеушісі, икемді емес бағдарламалық өнім талаптарын шешуге және даму сапасын жақсартуға бағытталған экстремальды бағдарламалау әдісін әзірледі.
Ол тек бағдарламалық қамтамасыз етуді дамыту саласында қолданылады және 4 процестен тұрады:
- кодтау — команданың жалпы макет стандарттарына сәйкес;
- тесттеу — тесттер негізінен код жазар алдында бағдарлама жасаушылар тарапынан жасалады;
- жоспарлау — соңғы құрылыс үшін және жеке итерацияларға. Соңғы екеуі орташа екі апта сайын өтеді.
- тексеру — сондай-ақ әзірлеушілер мен клиенттерді, анық емес нүктелерді жою және талаптар мен мәндерді анықтау үшін.
Crystal әдістемелері
Бұл Alistair Cockburn әзірлеген әдістемелер отбасы «Agile бағдарламалық жасақтама дамыту манифестінің» авторларының бірі, жоба басқарудың кейбір жергілікті салаларында аз белгілі. Cockburn команданың адам санына негізделе отырып, әдістемелердің классификациясын түсінуді ұсынады: 2 (Crystal Clear) — 100 (Crystal Red). Марун, көк және күлгін түстер үлкен ауқымды жобаларға арналған.
Crystal жобалары 3 негізгі сипаттамаға сәйкес келуі тиіс:
- операциялық кодты жедел жеткізу — Agile дамуындағы итеративтік модельдер үшін дамып келе жатқан идея.
- рефлексия арқылы жақсарту — жаңа бағдарламалық нұсқа алдыңғысы туралы ақпарат негізінде жақсартылып отырады.
- «осмостық» өзара әрекеттесу — Alistair-дің инновациясы, бағдарламалық қамтамасыз етуді бір бөлмеде жасаушылар арасындағы коммуникация мен ақпарат алмасу метафорасы.
Бұл әдістемелер отбасы Alistair-дің «Crystal Clear: A Human-Powered Methodology for Small Teams» кітабында егжей-тегжейлі сипатталған.
Динамикалық бағдарламалық даму әдісі (DSDM)
DSDM-ді дамыту бойынша жұмыс істеген 17 британдық компанияның консорциумы болды. Экстремалды программалауға ұқсас DSDM негізінен бағдарламалық жасақтаманы жасау үшін қолданылады.
Дамыту процесінде соңғы тұтынушы (пайдаланушы) ерекше рөлді алады. Бұл негізгі принципке келесі негізгі қағидалар қосылады:
- өнімнің операциялық нұсқаларының жиі шығарылуы
- әзірлеушілердің шешім қабылдаудағы автономиясы
- жұмыс циклы бойында тестілеу.
DSDM технологиялардың дамуына және жаңа бағдарламалық жасақтама талаптарының пайда болуына өзгерістер енгізу аясында жаңартылатын нұсқаларға бөлінеді. Қазіргі уақытта 2007 жылы шыққан DSDM Atern соңғы нұсқасы болып табылады, дегенмен алдыңғы (2003 жылғы) нұсқа қызмет кезде.
Бастапқыда команда өтінімді дамыту мүмкіндігі мен оның пайдалану аясын қарастырады. Содан кейін жұмыс 3 байланысты циклге бөлінеді:
- функционалды модель циклы — аналитикалық құжаттар мен прототиптер жасау.
- дизайн&инженерия циклы — жүйені іске қосу.
- жүзеге асыру циклы — жүйені орналастыру.
Feature Driven Development (FDD)
Бұл әдістеме «Agile бағдарламалық жасақтама дамыту манифестінен» ертерек пайда болды.
FDD итерация моделін дамытуда қолданса да, Agile-дан келесі ерекшеліктерімен ерекшеленеді:
- алдын ала модельдеуге көбірек назар аудару
- сурет есептер мен диаграммаларды құру (Agile-мен салыстырғанда) маңыздылығы
- әдістеме корпоративті даму үшін әзірленген.
Feature Driven Development келесі циклдік кезеңдерден тұрады:
- Жалпы модель жасау — алдыңғы деректер негізінде жоба бейнесі.
- Қасиеттер тізімін дамыту — Scrum әдістемесіндегі өнімнің жүктелуіне ұқсас.
- Қасиеттер бойынша жоспарлау — қасиеттердің күрделілігін әр команда мүшесі бағалайды.
- Әр қасиет үшін — техникалық дизайн мен іске асыру — бұл, аяқталғаннан кейін, өнімге біріктірілетін соңғы кезең, цикл қайталанады.
Lean бағдарламалық дамыту
Lean бағдарламалық дамыту тиімділікті арттыруға және шығындарды азайтуға бағытталған сығымдалған басқару принциптерінің жиынтығы (әдістеме емес).
Бұл жиынтық келесі 7 қағидаттарды қамтиды:
- сығымдарды жою — соңғы тұтынушы үшін өнімге ешқандай құн қоспайтын нәрсе.
- үздіксіз оқыту —топтың үздіксіз дамуы тапсырмаларды тиімді жүзеге асыру мүмкіндіктерін арттырады.
- шешімдер қабылдауды мүмкіндігінше кешіктіру — басымдық толық өңделген, алынған білімге негізделген қажетті шешімдерге беріледі, спонтанды шешімдерге емес.
- жедел жеткізу — бұл негізінен итерациялық модельдің негізгі қағидасы.
- командалық нығайту — «Манифесттегі…» қағидаттардың бірі адамдар және олардың өзара әрекеттесулері процестер мен құралдардан гөрі маңызды екенін айтады. Жобалық команда тапсырмаларды сәтті орындаудың ең жақсы кепілі болып табылады.
- интеграция және сапа —бастапқыда сапалы өнім жасау қажет, әйтпесе уақыт пен ресурстар тек тестілеу мен қателерді жоюға жұмсалады.
- жүйелі көрініс — жобаны бөлек бөліктерге бөлу мүмкін емес, даму кезеңінің қазіргі жағдайын, сонымен қатар бағдарламалық қамтамасыз етудің мақсаттарын, концепцияларын және стратегияларын түсінбестен.
Agile даму әдістемелерінің нұсқалары
Agile моделдеу (AM)
Agile моделдеу — бағдарламалық моделдеу үшін құндылықтар, негіздер мен практикалар жиынтығы.
AM толыққанды бағдарламалық әзірлеу әдістемелерінің элементі ретінде қолданылады — мысалы, экстремальды бағдарламалау немесе жылдам қолданбалы даму.
Agile моделдеудің келесі негізгі ерекшеліктері бар:
- жоба мүдделі тараптарының тиімді өзара әрекеттесуі;
- барлық талаптарға сәйкес келетін шешімді шығаруда соңғы жағымды шешімді шығаруға ұмтылу;
- үздіксіз кері байланыс алу;
- шешім қабылдай алу батылдығы және оларға жауапкершілік алу;
- сіз бәрін білетініңізді түсіну.
Agile Біріккен Процесс (AUP)
AUP — рационалды біріккен процесс (RUP) бағдарламалық дамудың әдістемесінің қарапайым нұсқасы. 2012 жылдан бастап, Disciplined Agile Delivery (DAD) әдістемесымен ауыстырылды, бірақ AUP әлі де кездеседі.
Әдістемені жасаушы Скотт Амблер Agile Біріккен Процесінде келесі негізгі ережелерды атап өтті:
- Сіздің командаңыз не істейтіні туралы біледі;
- Сұрау алдымен келеді.
- Икемді даму әдістемесінің қағидаларына сәйкес келу.
- Жоба үшін құнды әрекеттерге назар аудару.
- Құралдарды таңдауда тәуелсіздік.
- Белгілі бір жобаның талаптарына арналған AUP конфигурациялары.
Agile деректері әдісі (ADM)
ADM — жобада әртүрлі командалардың ынтымақтастығы арқылы талаптарды және шешімдерді қалыптастыруға назар аударатын ішінара бағдарламалық даму әдістемелерінің жиынтығы. AUP сияқты, бұл әдістеме да жеке өзін-өзі қамтымайды.
Agile деректер әдісінің принципі алты қағидатпен айқындалады:
- Деректер — кез келген қолданбаны жасау негізі.
- Жобадағы мәселелер — олар тек жоба мақсаты мен концепциясы анық белгілі болған жағдайда ғана анықталады.
- Жұмыс топтары — негізгі бағдарламалық әзірлеушілер командасынан басқа, басқа жұмыс топтарын қолдайтын кәсіпорын топтары бар.
- Таңдау — мінсіз әдістеме жоқ, сол себепті әр жоба түрлі әдістемелерден құралдарды тиімді біріктіруді қажет етеді.
- Командалық жұмыс — бірлескен жұмыс өзінің жеке әрекеттерінен әлдеқайда тиімдірек.
- «Тәтті нүкте» — «тәтті нүкте» деген мәселенің оңтайлы шешімін іздеу, шет жиектерді болдырмау.
Essential Unified Process (EssUP)
Ол швед ғалымы Ивар Якобсонның рационалды біріккен процесті жетілдіруге арналған.
EssUP тәжірибе тұжырымдамасын қамтиды:
- сценарий — жүйенің әрекет ету сипаттамасы.
- итерациялық даму — бірнеше апта ішінде қысқа циклдерде операциялық код бөліктерін жасау.
- командалық практика — топты белсендіруді және оның тиімділігін арттыруға бағытталған.
- процедуралық практика — мысалы, «Глобалды түрде ойлаңыз, кішкентайдан бастаңыз» немесе «Мүдделі тараптарды бизнес процестеріне тарту».
Бір формада немесе басқа, барлық практикалар RUP және CMMI әдістемелерінде, сондай-ақ икемді даму әдістемесінде орын алған.
Getting Real (GR)
Бұл стартаптар мен бастапқы командаларға тиімді әдістеме, ол шағын жобалар мен компанияларға тән ерекше мүмкіндіктерді максималды түрде пайдалануды ұсынады, мысалы, мобильділік, икемділік, жаңа шешімдерді іздеу, қатаң және шатасқан иерархияның болмауы және т.б.
Дэвид Ханссон мен Джейсон Фрид (37signals компаниясының негізін қалаушылар, қазіргі уақытта Basecamp) Getting Real әдісін мүмкін болатын тапсырмаларды шешуге арналған жүйе ретінде анықтады, ол ең соңында қарапайым, оңай түсінікті және функционалды.
GR алдын алу:
- альтернативтер
- нұсқалар мен параметрлер
- компания құрылымы
- жиналыстар
- уәделер.
Мұндай ерекше концепция кең таралған емес, дегенмен, оның кейбір элементтері басқа әдістемелерге бірікті.
OpenUP (OUP)
Бұл құралдарға тәуелсіз, қатал құрылымнан бос бағдарламалық дамыту әдістемесі, ол келесі практикаларды ұсынады:
- команданың операция жылдамдығын өлшеу;
- күнделікті кездесулер мен итерациялар аяқталғаннан кейін ретроспективаларды өткізу;
- айқындату концепциясы мен растау тестілеу;
- Agile Model Driven Development (AMDD) әдістемесі.
Бұл практикалар төрт принципке негізделеді:
- қызығушылықтарды үйлестіру және бірлескен жұмыста жалпы көзқарасқа жету;
- үздіксіз кері байланыс арқылы жақсарту;
- қолданбаның архитектурасына назар аудара отырып, қауіптерді азайту;
- соңғы тұтынушы үшін құнды барынша көбейту.
Agile көрсеткіштері
Agile құралдарының, практикасының, әдістерінің және әдістемелерінің әртүрлілігін ескере отырып, олардың әрқайсысының тиімділігін анықтауға көмектесетін құралды таңдауымыз керек.
Метрис мұндай құрал ретінде пайдаланады.
Көптеген жобалар үшін, бұл 4 метр есептер категориялары жеткілікті:
- Өнімділік — ол Вельосит және WIP метрлермен тығыз байланысты. Біріншісі барлық жобалар үшін қолайлы емес, өйткені итерациядан орындалған тапсырмалар саныны өлшеу, бірақ итерациялар тең емес. Жұмыс процесіндегі метр тапсырмалардың шектерін белгілейді: және ол неғұрлым жоғары болса, соғұрлым нашар болады;
- Болжамдар — Капасити метрі, ол келесі спринтте қол жетімді таза уақытты анықтауға арналған. К сәйкес, жұмысқа қол жетімді уақыт мөлшерін, тапсырманы орындаудағы тиімділікті және спринт үшін тапсырмалардың санын жоспарлауды түсінуге болады;
- Сапа — Мысалы, талаптардың тұрақтылық индексі, ол формула бойынша есептеледі = (Бастапқы бизнес талаптарының жалпы саны + Берілген уақыт ішінде өзгертілген талаптар саны + Қосылған талаптар саны + Шығарылған талаптар саны) / (бастапқы талаптардың жалпы саны). Бұл метр қайта жасауға кеткен уақыт мөлшерін анықтауға пайдаланылады;
- Құндылықтар — бұл метр әр жағдайда жеке есептеледі, жобаның форматына байланысты. Мысалы, AirBnb стартапында, жүктелген сапалы фотосуреттер саны пайдаланушылар үшін өнімнің соңғы құнын анықтайтын метр ретінде таңдалды. Бұл сан өскен сайын пайдаланушылардың саны пропорционалды өсіп отырды.
Метрлер үшін қолданылатын ереже басқа Agile құралдарындағыдай болады.
Сіздің жобаларына бірден дұрыс, және меншікті метрик жоқ.
Метрлерді тұрақты түрде қарастыру керек, ескіргендерді алып тастау, қажет болған жағдайда жаңаларын қосу керек. Ол кең ауқымды және тұтастай команда үшін қолжетімді болуы керек, мақсатқа айналмауы қажет. Метрлер метрикаларды метрикалар үшін метрикалар — жаман шешім.
Мифтер: Agile
Икемді даму әдістемесінің танымы оны алдап кеткен мифтер, және Agile туралы кейбір аспектілер жайлы мифтер тіпті арнайы порталдарда көрінеді. Оларды реттейік!
Миф №1: Agile барлық жобаларға жарайды.
Бұл ең сенімді қате пікір. Бір-ақ Agile әдістемесінің өзі өнімнің құнын қосу және топты ынталандыруға мүмкіндік бермейді.
Миф №2: Agile құжаттаманы жақтырмайды.
Икемді даму әдістемесі құжаттаманы қабылдамайды, ол құжаттаманы өзі мақсат ретінде қабылдамайды. Құжаттаманы коммуникация құралы ретінде таңдаған кезде, Agile шынында да жеке коммуникацияны қолдайды.
Миф №3: Agile және жоспарлау үйлеспейді.
Бұл миф күнделікті жоспарлық істер, 10 минуттық стендпен, сондай-ақ әр екі апта сайын өтетін итерациялар жоспарлау, спринт кездесулер сияқты іс-шаралармен теріске шығарылады.
Миф №4: Agile көп қайта жасауға қажеттілік туғызады.
Икемді бағдарламалық даму әдістемесі қайта жасауға арналған екі формада: талаптарды қайта жасау (пайдаланушылар не қажет екенін түсінеді) және бағдарламалық қайта жасау (даярлау командалары қолданбаларды жазу мен жобалауда жетілдірілген жолдар табады) қамтиды. Алайда, бұл да басқа әдістемелерде кездеседі! Сонымен қатар, Agile-дің итерациялық моделі қайта жасаудың теріс әсерін төмендетуге қызмет етеді.
Agile-дің қолданыстарының артықшылықтары мен кемшіліктері
Артықшылықтары:
- мүдделі тараптарды тарту — команда клиенттің талаптарын жақсы түсініп, жоба тобасына сенім білдіреді; сонымен қатар, бағдарламаны ерте және жиі жеткізу мүдделі тараптардың жоба тобына сенімін арттырады.
- ерте және болжамды жеткізу — итерацияға негізделген даму моделі (1‑ден 6 аптаға дейінгі қысқа мерзім ішінде) икемділік береді және өнім шығаруға жеткізеді.
- бизнес құндылығына назар аудару — клиентпен ынтымақтастық командаға өнімнің тұтынушы үшін өте бағалы болуын қамтамасыз ету қабілетін береді.
- сапаның үздіксіз артуы — әр итерация кезеңінде тестілеу жүргізу және соңғы модельді операциялық кодтың бөліктеріне бөлшектеу механаиканы көмектеседі, өнім шығаруын аяқтағанға дейін қателерді жақсартуға және жоюға мүмкіндік береді.
Кемшіліктері:
- команда мен клиенттер үшін қатаң талаптар — жобалық команда мен пайдаланушылар арасындағы өзара әрекеттесу болған жағдайда, жоғары құнды өнімді шығаруға мүмкіндік жоқ. Сонымен қатар, көптеген Agile құралдары мен әдістері командадан олардың дұрыс енгізуін қажет етеді.
- аутсорс пен жоба қатысушылары тек онлайн режимінде бір-бірімен қарым-қатынас жасағанда жарамайды.
- соңғы бағдарламалық нұсқаның ешқашан шығарылуына қауіп төндіреді — өкінішке орай, бұл күрделі даму артықшылықтары болғанымен, үшінші жағымдылығы болып табылады.
- жобаның бизнес мақсаттарының айқын көрінісі болмайды — Agile команда мүдделі тараптармен басшылыққа алынса, мақсатты және концепцияны анықтаусыз өнімді жасау мүмкін емес.
Қолдану
Жобаларды басқаратын қызметтер мен бағдарламалар Agile негізіндегі жобаларды басқаруға жарамайды, өйткені олардың әрқайсысында нақты ерекшеліктері бар.
Сіздің бизнесіңіз маркетинг және жарнама, дизайн, SEO немесе цифрлық агенттіктер болса, Worksection-ның SaaS қызметін бүкіл командаңыз үшін пайдалана аласыз. Біз COXO Digital, Royal ® жарнама және Prozorro-дан ұсынылады.
Worksection-да Agile-ды конфигурациялауға арналған бірнеше өмірлік кеңестер:
- Сіздің компанияңыздағы жұмыс үшін қажетті тегтер мен статустарды конфигурациялаңыз. Статустар: іске асырылып жатқан, тексеру, аяқталған, қайта бастау қажет, критикалық, мүмкіндіктер, төлем мерзімі. Тегтер жиі былай оқылады: макет, тестілеу, өндіріс, концепция, код.
- жоба жүктелуін және жоба спринтін жасаңыз.
- жүктелуді кезеңдер мен алдын ала тексеру тізімдері, эскиздер және т.б. жасаңыз.
- кездесулер кезінде спринт тапсырмаларын белгілеңіз және оларды жүктелуден спринтке көшіру.
- жобада әрқашан кеңесшілерден тиісті пікірлер алу үшін теңестірілген пікір алысу үшін клиенттердің тапсырмаларға қатысуын қолданыңыз.
- тапсырмалардағы жауапты тұлғаларды белгілеп, әріптестерге өзінің міндеттерін білуі және спринттің нәтижесіне қызықты болуы үшін.
Сот
Икемді бағдарламалық даму әдістемесі арқасында шағын жобалық команда максималды тиімділікке жетеді. Agile Scrum, XP, Lean сияқты басқа икемді әдістер арқылы жүзеге асырылады.
Оны жылдам, тәжірибесіз командамен, қысқа мерзімде енгізу мүмкін емес,
бірақ енгізілген кезде, Agile IT мен бизнес арасындағы өзара әрекетті жақсартады, өнімнің нарыққа шығарылуын тездетеді және тұтынушы үшін өнімнің құндылығын арттырады.