Программалық жүйені жасаудағы Agile басқару әдіснамасы
- maqsat
- Жобаларды басқару / 27 ақпан 2016, 18:59
- 2477
Бүгінгі таңда елімізде IT- саласы қарқынды дамуда және соның нәтижесінде ауқымды жобалар дүниеге келуде. Жоба жасаудағы өзекті мәселердің бірі жоба процесін басқару. Жоба басталғаннан бастап керекті өнім шыққанға дейінгі әр кезеңнін өз қиындықтары бар. Жобаны жасайтын топты жасақтаудан бастап, олардың қандай құралдармен жұмыс жасайтыны, жоба мақсатын анықтау, негізгі талаптарды шешу және т.б мәселелерді жобалау керек. Бірақ сол үлкен жобаларды жобалау елімізде қалыс қалып отыр. Оған бірсыпыра жобалардың жартылый тоқтап қалуы, басқаларының сұранысқа ие бола алмауы дәлел болады. Мысалы мемекеттік «электронды кітап» жобасы қыруар қаржы жұмсалып жасалынса да сұранысқа ие бола алмады. Жобалау мәселесін толық қарастырып өтейін.
Егер ПЖ ауқымды болса ол әрине бірнеше адамның қатысуымен жасалады, яғни жобаны жасайтын топ. Осы жерде мәселенің басы шығады, себебі командалық жұмыс жеке адамның жұмысына қарағанда әлде қайда күрделі. Әртүрлі түсініспеушіліктер орын алу, жасалынған жұмыстардың синхронизациялануы, белгіленген уақыттың жетіспеушілігі, басқарушы білімінің жетіспеушілігі, топ мүшелерінің білімінің жетіспеушілігі, нәтиженің тапсырыс беруші күткеніндей болмауы және тағы баска мәселелер бар.
Үлкен жобаны жобалауда қазіргі таңда сарқырама басқару әдіснамасы қолданылып жүр. Соған қысқаша тоқтала кетейін.
Сарқырама басқару әдіснамасы бойынша жоба төмендегідей жасалады.
• Талап қойылады
• Талапқа анализ жасалынады
• Жоба архитектурасы жасалады
• Код жазылады
• Тест жүргізіледі
• Жоба аяқталып тапсырыс берушіге тапсырылды
Сарқырама әдіснамасының ең бірінші кемшілігі — процесінің ұзақ орындалуы және оның сатылай жүргізілуінде. Мысалы анализ жасалып, жоба архитектурасы жасалып біткенше AGILE бойынша жасалып жатқан бәсекелес жоба екі-үш ай ерте қосылып кетуі мүмкін. Кейінгі кезде сарқырама әдісін жетілдіретін екі немесе одан да көп процесті бір – біріне тәуелсіз жүргізетін әдістер ойлап табылды бірақ бұл негізгі мәселелерді шеше алмады. XXI ғасырдың басында батыс елдерінде жобаны жүргізуге деген басқа бағыт ұсынылды.
Agile (англ “тірі”,”қозғалмалы”) — икемді бағдарламалау әдістерінің тобы. Code-And-Fix ( бірінші жазамыз, одан сон тексереміз және қайта дұрыстаймыз) және сарқырама әдістерінен кейінгі сатыдағы тұрған методология. 2001 жылы АҚШ-та ЮТА штатында методология манифестері жарияланды.
Өзінің қағидаларына қарай Agile алдынғы аталған екі әдіснама арасында жатады. Ол Code-And-Fix әдіснамасы сиякты тез өзгертіледі бірақ міндетті түрде бір негізге сәйкестеледі және ол сарқырама әдісі сияқты қатаң құрылымдалған.
Agile манифесі
Agile манифесі баламасы бар төрт құндылықтардан тұрады
• Адамдар және өзара іс-қимыл процестер мен құралдарға қарағанда әлдеқайда маңызды
• Істеп тұрған өнім кешенді құжаттамаға қарағанда әлдеқайда маңызды
• Клиенттермен ынтымақтастық келісім-шартта жасалған келіссөздерден әлдеқайда маңызды
• Өзгертулерге дайын болу бастапқы жоспарға қарағанда әлдеқайда маңызды
Осылайша манифест бағдарламалаушыларға кейбір құндылықтардың басқаларына қарағанда маңызды екенін көретеді.
Яғни, бағдарламалау кезінде кездесетін қиын таңдаулар кездескенде осы құндылықтарға сүйене отырып қалай таңдау жасау керектігін көрсетіп берді.
Agile принциптері
Agile принциптері бағдарламалық қамтамасыз етуді дамытуға нұсқау ретінде манифестте баяндалған құндылықтарға негізделген:
1. Ерте және үздіксіз құнды бағдарламалық өзгерістермен қамтамасыз етуді арқылы тапсырыс берушіні қанағаттандыру.
2. Қажетті өзгерістер болса бағдарламалаудың соңына келіп қалса да өзгерістерді жүзеге асыру (бұл өнімнің бәсекеге қабілеттілігін арттыру мүмкін)
3. Жасалған жұмысты жиі жеткізу, шығару, көрсету (ай сайын немесе апта, немесе одан да жиі)
4. Жобаның жасалу барысында тапсырыс беруші мен бағдарламалаушылар арасындағы күнделікті тығыз қарым-қатынас.
5. Жобаны жасауға ынталандырылған, қажетті жағдайлары жасалған, сенімге ие қызметкерлер қатысады
6. Ақпаратпен алмасудағы негізгі ұсынылған әдіс — бетпе-бет әңгімелесу
7. Жұмыс жасап тұрған ПЖ – үдерісті өлшеудегі ең жақсы өлшеуіш.
8. Демеушілер, әзірлеушілер, және пайдаланушылар белгісіз мерзімге дейін тұрақты қарқынын сақтауға қабілетті болуы тиіс.
9. Техникалық шеберлік және дизайн ыңғайлылығын жақсартуға үздіксіз көңіл бөлу.
10. Қарапайымдылық — қажетсіз жұмыс істемеу өнері.
11. Үздік техникалық талаптар, жобалаулар және дизайн өзін-өзі ұйымдастыра алатын командаларға тән.
12. Жағдайдың өзгеруiне тұрақты бейімделу.
Дәстүрлі әдіс пен Agile-дың маңызды айырмашылығы: Agile-да бастапқы жасалған жоспар ерекше маңызды емес, маңыздысы тапсырыс беруші идеясы мен қойылған бизнес талаптарды орындау. Бұл ПЖ жасаудағы дәстүрлі үш негізгі шектеуге(бюджет, уақыт, талаптар көлемі) әдістерге түбірімен қарама қарсы.
Agile-дағы әртүрлі жобалардағы бір жобаға кететін уақыт әртүрлі( 1-ден 6-аптаға дейін). Мысала екі жоба бірдей болуы мүмкін бірақ екеуі екі түрлі мерзімде бітуі мүмкін. Бірақ мерзім қаншалықты аз болса ол соншалықты жақсы. Сонымен қатар жобаның өмірлік айналымы тапсырыс берушімен кері байланысқа негізделген. Жоба процесінің негізгі мақсаттары нәтижеге анализ жасау, кері байланысқа қол жеткізу және жұмыс процесін жақсарту. Мұндағы басқаларға қарағанда маңыздысы кері байланыс, себебі ішкі немесе сытрқы факторғы байланысты кез-келген жаңа мәлімет маңызды. Тікелей байланыс нәтижелілігімен ерекшеленеді. Бұл деген сөз хат алмасулардан тікелей бастарту емес тек байланысу кезіндегі артықшылықтарыды көрсетеді. Agile – да жобаны жасаушы топқа өз-өзін ұйымдастыру қабілетін жоғарғы дәрежеде болуына көңіл бөлуге кеңес береді. Топ кез-келген мәселе шешімін жоба менеджерінің нұсқауынсыз бірге келісіле отырып шешілуі керек. Айта кететіні икемді жобаларда жоба менеджері деген қызмет жоқ. Agile – да жоба бірқалыпты жүруі керек, овертаймға(мерзімінен тыс жұмыс) тыйым салынады. Бүкіл жоба кемшіліксіз және мерзім – мерзіммен орындалуы тиіс.
Осының бәрін ескере отырып қиын мәселелерді шешуде жүйе құрылысын қиындатпау ұсынылада, себебі жоғарғы дәрежелі жүйе құрылысын(архитектура) құру ПЖ жасаудағы өзекті мәселелердің бірі.
ПЖ туралы айту, баға беру тек ол толық дайын болғанда ғана емес оның әр жұмыс істеп тұрған бөлігіне берілуі керек, яғни жоба толық аяқталмаса да жасалып қойылған бөліктеріне баға беліледі. Бұл өз кезегінде кейбір қиындықтарға әкеліп соғады. Әдетте көптеген мәселелер тек бағдарламалаудың, жобаның соңғы кезеңінде кездеседі. Алайда, ол аралық кезеңдердегі жұмысқа ісер етпегендіктен жобаны өміршең етеді.
Жүйе құрылысы мен дизайнының маңыздылығы икемді бағдарламалау кезінде ПЖ-ға жобаның соңғы кезеңдерінде де өзгерістер енгізеле берілетіндігімен айқындалады. Егер код құрылысы түсінікті болса ол өзгерістер енгізуге кететін уакытты азайтады. Бұл принціпті іске асыру үшін кодқа рефакторинг жасалып тұрады.
Қорытындылай айтқанда ПЖ – жасауды қарапайым киім алумен салыструға болады. Егер киімді интернеттен онлайн сатып алсаңыз, яғни ақшасын төлеп қойып күтіп жатсаңыз оның нәтижесі күткендей болмауы мүмкін. Ал дүкендерге барып таңдап, киіп көріп алынған киім әлбетте көңілден шығады. Сол сияқты ПЖ – ны тапсырыс беруші де оны жасауға қатысатын болса ол онда бәсекеге қабілетті өнім болары сөзсіз.
Егер ПЖ ауқымды болса ол әрине бірнеше адамның қатысуымен жасалады, яғни жобаны жасайтын топ. Осы жерде мәселенің басы шығады, себебі командалық жұмыс жеке адамның жұмысына қарағанда әлде қайда күрделі. Әртүрлі түсініспеушіліктер орын алу, жасалынған жұмыстардың синхронизациялануы, белгіленген уақыттың жетіспеушілігі, басқарушы білімінің жетіспеушілігі, топ мүшелерінің білімінің жетіспеушілігі, нәтиженің тапсырыс беруші күткеніндей болмауы және тағы баска мәселелер бар.
Үлкен жобаны жобалауда қазіргі таңда сарқырама басқару әдіснамасы қолданылып жүр. Соған қысқаша тоқтала кетейін.
Сарқырама басқару әдіснамасы бойынша жоба төмендегідей жасалады.
• Талап қойылады
• Талапқа анализ жасалынады
• Жоба архитектурасы жасалады
• Код жазылады
• Тест жүргізіледі
• Жоба аяқталып тапсырыс берушіге тапсырылды
Сарқырама әдіснамасының ең бірінші кемшілігі — процесінің ұзақ орындалуы және оның сатылай жүргізілуінде. Мысалы анализ жасалып, жоба архитектурасы жасалып біткенше AGILE бойынша жасалып жатқан бәсекелес жоба екі-үш ай ерте қосылып кетуі мүмкін. Кейінгі кезде сарқырама әдісін жетілдіретін екі немесе одан да көп процесті бір – біріне тәуелсіз жүргізетін әдістер ойлап табылды бірақ бұл негізгі мәселелерді шеше алмады. XXI ғасырдың басында батыс елдерінде жобаны жүргізуге деген басқа бағыт ұсынылды.
Agile (англ “тірі”,”қозғалмалы”) — икемді бағдарламалау әдістерінің тобы. Code-And-Fix ( бірінші жазамыз, одан сон тексереміз және қайта дұрыстаймыз) және сарқырама әдістерінен кейінгі сатыдағы тұрған методология. 2001 жылы АҚШ-та ЮТА штатында методология манифестері жарияланды.
Өзінің қағидаларына қарай Agile алдынғы аталған екі әдіснама арасында жатады. Ол Code-And-Fix әдіснамасы сиякты тез өзгертіледі бірақ міндетті түрде бір негізге сәйкестеледі және ол сарқырама әдісі сияқты қатаң құрылымдалған.
Agile манифесі
Agile манифесі баламасы бар төрт құндылықтардан тұрады
• Адамдар және өзара іс-қимыл процестер мен құралдарға қарағанда әлдеқайда маңызды
• Істеп тұрған өнім кешенді құжаттамаға қарағанда әлдеқайда маңызды
• Клиенттермен ынтымақтастық келісім-шартта жасалған келіссөздерден әлдеқайда маңызды
• Өзгертулерге дайын болу бастапқы жоспарға қарағанда әлдеқайда маңызды
Осылайша манифест бағдарламалаушыларға кейбір құндылықтардың басқаларына қарағанда маңызды екенін көретеді.
Яғни, бағдарламалау кезінде кездесетін қиын таңдаулар кездескенде осы құндылықтарға сүйене отырып қалай таңдау жасау керектігін көрсетіп берді.
Agile принциптері
Agile принциптері бағдарламалық қамтамасыз етуді дамытуға нұсқау ретінде манифестте баяндалған құндылықтарға негізделген:
1. Ерте және үздіксіз құнды бағдарламалық өзгерістермен қамтамасыз етуді арқылы тапсырыс берушіні қанағаттандыру.
2. Қажетті өзгерістер болса бағдарламалаудың соңына келіп қалса да өзгерістерді жүзеге асыру (бұл өнімнің бәсекеге қабілеттілігін арттыру мүмкін)
3. Жасалған жұмысты жиі жеткізу, шығару, көрсету (ай сайын немесе апта, немесе одан да жиі)
4. Жобаның жасалу барысында тапсырыс беруші мен бағдарламалаушылар арасындағы күнделікті тығыз қарым-қатынас.
5. Жобаны жасауға ынталандырылған, қажетті жағдайлары жасалған, сенімге ие қызметкерлер қатысады
6. Ақпаратпен алмасудағы негізгі ұсынылған әдіс — бетпе-бет әңгімелесу
7. Жұмыс жасап тұрған ПЖ – үдерісті өлшеудегі ең жақсы өлшеуіш.
8. Демеушілер, әзірлеушілер, және пайдаланушылар белгісіз мерзімге дейін тұрақты қарқынын сақтауға қабілетті болуы тиіс.
9. Техникалық шеберлік және дизайн ыңғайлылығын жақсартуға үздіксіз көңіл бөлу.
10. Қарапайымдылық — қажетсіз жұмыс істемеу өнері.
11. Үздік техникалық талаптар, жобалаулар және дизайн өзін-өзі ұйымдастыра алатын командаларға тән.
12. Жағдайдың өзгеруiне тұрақты бейімделу.
Дәстүрлі әдіс пен Agile-дың маңызды айырмашылығы: Agile-да бастапқы жасалған жоспар ерекше маңызды емес, маңыздысы тапсырыс беруші идеясы мен қойылған бизнес талаптарды орындау. Бұл ПЖ жасаудағы дәстүрлі үш негізгі шектеуге(бюджет, уақыт, талаптар көлемі) әдістерге түбірімен қарама қарсы.
Agile-дағы әртүрлі жобалардағы бір жобаға кететін уақыт әртүрлі( 1-ден 6-аптаға дейін). Мысала екі жоба бірдей болуы мүмкін бірақ екеуі екі түрлі мерзімде бітуі мүмкін. Бірақ мерзім қаншалықты аз болса ол соншалықты жақсы. Сонымен қатар жобаның өмірлік айналымы тапсырыс берушімен кері байланысқа негізделген. Жоба процесінің негізгі мақсаттары нәтижеге анализ жасау, кері байланысқа қол жеткізу және жұмыс процесін жақсарту. Мұндағы басқаларға қарағанда маңыздысы кері байланыс, себебі ішкі немесе сытрқы факторғы байланысты кез-келген жаңа мәлімет маңызды. Тікелей байланыс нәтижелілігімен ерекшеленеді. Бұл деген сөз хат алмасулардан тікелей бастарту емес тек байланысу кезіндегі артықшылықтарыды көрсетеді. Agile – да жобаны жасаушы топқа өз-өзін ұйымдастыру қабілетін жоғарғы дәрежеде болуына көңіл бөлуге кеңес береді. Топ кез-келген мәселе шешімін жоба менеджерінің нұсқауынсыз бірге келісіле отырып шешілуі керек. Айта кететіні икемді жобаларда жоба менеджері деген қызмет жоқ. Agile – да жоба бірқалыпты жүруі керек, овертаймға(мерзімінен тыс жұмыс) тыйым салынады. Бүкіл жоба кемшіліксіз және мерзім – мерзіммен орындалуы тиіс.
Осының бәрін ескере отырып қиын мәселелерді шешуде жүйе құрылысын қиындатпау ұсынылада, себебі жоғарғы дәрежелі жүйе құрылысын(архитектура) құру ПЖ жасаудағы өзекті мәселелердің бірі.
ПЖ туралы айту, баға беру тек ол толық дайын болғанда ғана емес оның әр жұмыс істеп тұрған бөлігіне берілуі керек, яғни жоба толық аяқталмаса да жасалып қойылған бөліктеріне баға беліледі. Бұл өз кезегінде кейбір қиындықтарға әкеліп соғады. Әдетте көптеген мәселелер тек бағдарламалаудың, жобаның соңғы кезеңінде кездеседі. Алайда, ол аралық кезеңдердегі жұмысқа ісер етпегендіктен жобаны өміршең етеді.
Жүйе құрылысы мен дизайнының маңыздылығы икемді бағдарламалау кезінде ПЖ-ға жобаның соңғы кезеңдерінде де өзгерістер енгізеле берілетіндігімен айқындалады. Егер код құрылысы түсінікті болса ол өзгерістер енгізуге кететін уакытты азайтады. Бұл принціпті іске асыру үшін кодқа рефакторинг жасалып тұрады.
Қорытындылай айтқанда ПЖ – жасауды қарапайым киім алумен салыструға болады. Егер киімді интернеттен онлайн сатып алсаңыз, яғни ақшасын төлеп қойып күтіп жатсаңыз оның нәтижесі күткендей болмауы мүмкін. Ал дүкендерге барып таңдап, киіп көріп алынған киім әлбетте көңілден шығады. Сол сияқты ПЖ – ны тапсырыс беруші де оны жасауға қатысатын болса ол онда бәсекеге қабілетті өнім болары сөзсіз.
-
+3