-Agile shunchaki “tezkor ishlab chiqish usuli” emas-
“Agile” atamasi dasturiy taʼminot ishlab chiqish muhitida keng qoʻllanadi.
Biroq Agileʼni shunchaki
“tez ishlab chiqish”
“ikki haftalik sikllarda sprintlar oʻtkazish”
“har kuni ertalab kundalik yigʻilish oʻtkazish”
deb tushunsangiz, Agile mohiyatini anglamay qolishingiz oson.
Agile Agile dasturiy taʼminot ishlab chiqish manifesti2001-yilda eʼlon qilingan.
Agile manifestida quyidagi toʻrtta qadriyatga urgʻu beriladi.
-
Jarayonlar va vositalardan koʻra shaxslar va oʻzaro munosabatlar
-
Batafsil hujjatlardan koʻra ishlaydigan dasturiy taʼminot
-
Shartnoma muzokaralaridan koʻra mijoz bilan hamkorlik
-
Rejaga amal qilishdan koʻra oʻzgarishlarga javob berish
Jarayonlar, hujjatlar, shartnomalar va rejalar ham zarur, biroq Agile quyidagilarga — odamlar va muloqotga, ishlaydigan natijalarga, mijozlar bilan hamkorlikka hamda oʻzgarishlarga javob berishga.
Agileʼning 12 tamoyili
Agile manifesti oʻzining toʻrtta qadriyati bilan birga, ularni amalda qoʻllash uchun 12 ta tamoyilni ham oʻz ichiga oladi.
1. Mijozlar qoniqishini ustuvor qoʻyish
Eng ustuvor vazifa — imkon qadar tez va uzluksiz ravishda qimmatli dasturiy taʼminotni yetkazib berish orqali mijozlarni qoniqtirish.
2. Oʻzgaruvchan talablarni xush kelibsiz deb qabul qilish
Ishlab chiqishning hatto kech bosqichlarida ham talablardagi oʻzgarishlarni qabul qiling.
Oʻzgarishlarni soʻzsiz ravishda loyiha uchun toʻsiq deb bilish oʻrniga, ularni mijozlarga raqobat ustunligini taqdim etish imkoniyati sifatida koʻring.
3. Ishlaydigan dasturiy taʼminotni tez-tez yetkazib berish
Bir necha oy davomida ishlab chiqib, hammasini birdaniga taqdim etish oʻrniga, qisqa sikllarda amalda ishlaydigan natijalarni taqdim eting.
4. Biznes manfaatdor tomonlari va ishlab chiquvchilarni birgalikda ishlatish
Rejalashtiruvchilar, biznes manfaatdor tomonlari va ishlab chiquvchilar faqat boshida uchrashish oʻrniga, loyiha davomida uzluksiz hamkorlik qilishlari kerak.
5. Loyihalarni ishga ishtiyoqi baland shaxslar atrofida qurish
Jamoa aʼzolarini zarur muhit va qoʻllab-quvvatlash bilan taʼminlang hamda ularga ishlarini mustaqil bajarishlariga ishoning.
6. Eng samarali muloqot — yuzma-yuz suhbat
Faqat hujjatlar yoki elektron xatlar almashish oʻrniga, muammolarni tezda hal qilish zarur boʻlganda bevosita suhbatlashing.
7. Ishlaydigan dasturiy taʼminot — taraqqiyotning eng muhim oʻlchovi
Yozilgan hujjatlar miqdoriga qanchalik koʻp hujjat yozilganigaemas, balki qancha funksionallik amalda ishlaydigan holga keltirilganiga eʼtibor qarating.
8. Ishlab chiqishning barqaror surʼatini saqlash
Muayyan davrlarda qayta-qayta kechgacha ishlab, ortiqcha ish qilish orqali tezlikni oshirish oʻrniga, uzoq muddat davomida saqlab turish mumkin boʻlgan ishlab chiqish surʼatiga intiling.
9. Texnik mukammallik va yaxshi dizaynga uzluksiz intilish
Funksionallikni shunchaki tez yaratishning oʻzi yetarli emas.
Yaxshi kod va dizayn, shuningdek texnik sifat ham uzluksiz takomillashtirib borilishi kerak.
10. Soddalikka intilish
Bajarilishi shart boʻlmagan ishlarni imkon qadar kamaytiring.
Boshqacha aytganda, nafaqat “Nima qilishimiz kerak?”, balki “Nimani qilmasligimiz kerak?” degan savollarni ham koʻrib chiqing.
11. Eng yaxshi arxitekturalar, talablar va dizaynlar oʻzini oʻzi boshqaradigan jamoalardan kelib chiqadi
Menejerlar har bir qarorni bir tomonlama qabul qilishlari oʻrniga, amaliy ishni bajarayotgan jamoa muammolarni hal qiladi va qaror qabul qilishda ishtirok etadi.
12. Muntazam ravishda tahlil qiling va takomillashtiring
Muammolarni faqat loyiha tugagandan keyin tahlil qilish o‘rniga, biz jamoaning ishlash usulini muntazam ravishda ko‘rib chiqamiz va takomillashtiramiz.
Bu Retrospectivedagi Agile bilan bog‘liq muhim tamoyildir.
Xo‘sh, Agile SI loyihalarida ham qo‘llanilishi mumkinmi?
Bu yerda bitta amaliy muammo mavjud.
SI loyihasining muhiti odatiy startap yoki mahsulot ishlab chiqish loyihasinikidan ancha farq qiladi.
Masalan, SI loyihalarida quyidagi holatlar ko‘p uchraydi.
-
Shartnoma muddati va tugash sanasi oldindan belgilangan bo‘ladi.
-
Alohida mijoz kompaniyasi mavjud bo‘ladi.
-
Ishlab chiqish ko‘lami taklif va shartnomada belgilangan bo‘ladi.
-
Tahlil, loyihalash, ishlab chiqish va testlash kabi bosqichlar mavjud bo‘ladi.
-
Ko‘p sonli topshiriladigan materiallar taqdim etilishi kerak.
-
Mijoz talablaridagi o‘zgarishlar qo‘shimcha xarajatlar yoki jadval o‘zgarishlarini talab qilishi mumkin.
-
Bitta loyihada bir nechta hamkor kompaniyalar ishtirok etadi.
Shuning uchun mavjud loyiha boshqaruvi tizimini butunlay bekor qilib, SI loyihasiga shunchaki Agile’ni qo‘llash va “Bugundan boshlab Scrum’dan foydalanamiz”deyish realistik emas.
Aksincha, SI loyihalarida Agile falsafasi va uning ayrim amaliyotlarini mavjud loyiha boshqaruvi yondashuviga kiritish amaliy jihatdan ma’qulroqdir.
SI loyihalariga mos Agile usullari
① Scrum
Eng vakili usul — Scrum.
Scrum empirizmga asoslanadi. Murakkab muammolarni birdaniga mukammal rejalashtirish o‘rniga, u amaldagi natijalarni tekshirish, ularni tahlil qilish va keyingi harakatni shu natijalarga asoslanib moslashtirishninazarda tutadi.
Scrum empirizmini uchta asosiy tushuncha orqali izohlash mumkin.
Shaffoflik → tekshirish → moslashtirish
Boshqacha aytganda,
bajarilayotgan ishni ko‘rinadigan qilish
→ amaldagi natijalarni tekshirish
→ natijalarga asoslanib reja va usullarni qayta ko‘rib chiqish.
Tuzilma shundan iborat.
Buni SI loyihasida qanday qo‘llash mumkin?
Masalan, olti oylik loyiha bor, deb faraz qilaylik.
An’anaviy yondashuvda,
Talablarni tahlil qilish
↓
Umumiy loyihalash
↓
Umumiy ishlab chiqish
↓
Integratsion testlash
↓
Foydalanuvchi tomonidan qabul qilish testi
↓
Ishga tushirish
Bu yondashuvdan foydalanib, ishni davom ettirish mumkin.
Bunday holda, ishlab chiqish boshida belgilangan talablar haqiqiy foydalanuvchilar uchun mos yoki mos emasligini tekshira olishingizga qadar ancha vaqt o‘tib ketishi mumkin.
Agar Scrum metodologiyasining bir qismini qo‘llasangiz, uni kichikroq birliklarga ajrating.
Masalan, bir Sprint ikki hafta davom etadi.
Sprint 1
Ro‘yxatdan o‘tish + Tizimga kirish
Sprint 2
A’zolar ma’lumotlarini ko‘rish + Tahrirlash
Sprint 3
Mahsulotlarni ko‘rish
Sprint 4
Buyurtma berish
Sprint 5
To‘lov
Shu tarzda ishlab chiqing va har bir Sprint yakunlanganda mijoz yoki biznes manfaatdor tomoniga ishlaydigan natijani ko‘rsating.
Shunda mijoz shunday deyishi mumkin:
“Bu men tasavvur qilgan narsadan biroz boshqachaga o‘xshaydi.”
Ular shunday deyishi mumkin.
O‘zgarishlarni aynan shu bosqichda kiriting.
Muammo loyiha ikkinchi yarmida aniqlangan holatga qaraganda, o‘zgarishlarni ancha kam xarajat bilan amalga oshirish mumkin.
② SI loyihalarida empirizmni qo‘llash
Shaxsan men SI loyihalaridagi eng muhim Agile tushunchalaridan biri empirizm deb hisoblayman.
Sodda qilib aytganda, empirizm quyidagilarni anglatadi:
faqat reja yoki taxminlarga tayanmasdan, haqiqiy tajriba va kuzatuvlarga asoslanib qaror qabul qilish
.
Scrum ham haqiqiy natijalarni kuzatish va keyin nima qilish kerakligini shu natijalarga asoslanib hal etish yondashuvidan foydalanadi, chunki murakkab ishlar bilan shug‘ullanganda hamma narsani oldindan mukammal bashorat qilish qiyin.
Masalan, mijoz quyidagi so‘rovni yuborgan deb faraz qilaylik:
“Iltimos, foydalanuvchilar oson ishlata oladigan buyurtma ekranini yarating.”
Agar dasturchilar faqat hujjatlarga asoslanib ishlasalar, ularning har biri “oson” so‘zini turlicha talqin qilishi mumkin.
Biroq haqiqiy ekranni yaratib, uni foydalanuvchilarga ko‘rsatganingizdan so‘ng vaziyat o‘zgaradi.
Foydalanuvchilar uni o‘zlari sinab ko‘rib, masalan, shunday deyishlari mumkin:
“Bu tugmani ko‘rish qiyin.”
“Menimcha, bu bosqich aslida kerak emas.”
“Mobil qurilmada buni shu tarzda ishlatish qulayroq.”
Ular shunday deyishlari mumkin.
Bu aynan tajriba → kuzatuv → fikr-mulohaza → takomillashtirish jarayonidir.
SI loyihasida empirizmni qo‘llash, oxir-oqibat, quyidagilarni anglatadi:
talablarni faqat hujjatlarga asoslanib yakuniy holatga keltirmasdan, imkon qadar tezroq haqiqiy natija yaratish va uni tekshirish
.
③ Juftlikda ishlashdan foydalanish
Agile ishlab chiqishda qo‘llash mumkin bo‘lgan yana bir usul — Pair Programming.
Bu ikki dasturchi bitta vazifa ustida birgalikda ishlaydigan usuldir.
Bir kishi kod yozayotganida, boshqasi uni real vaqt rejimida ko‘rib chiqadi, shu tariqa ular birgalikda ishlab chiqishlari mumkin.
Albatta, SI loyihasidagi har bir ishlab chiqish vazifasini juftlikda bajarish shart emas.
Aslida, bu xodimlar taqsimoti va xarajatlar nuqtayi nazaridan samarasiz bo‘lishi mumkin.
Shuning uchun, uni muhim yoki yuqori xavfli vazifalarga tanlab qo‘llashamaliy yondashuv hisoblanadi.
Masalan, quyidagi kabi vazifalar:
-
Asosiy biznes mantiqi
-
To‘lov modullari
-
Xavfsizlikka oid funksiyalar
-
Murakkab SQL
-
Katta ko‘lamli ma’lumotlarni o‘zgartirish
-
Keng tarqalgan freymvorklar
-
Muvaffaqiyatsizlik ehtimoli yuqori bo‘lgan funksiyalar
-
Tajribasi cheklangan dasturchilar tomonidan asosiy funksiyalarni ishlab chiqish
Masalan, Developer A to‘lov modulini ishlab chiqib, Developer B kodni keyinroq ko‘rib chiqadigan an’anaviy yondashuvdan foydalanish o‘rniga,
A + B uni boshidanoq birgalikda loyihalashtiradi va ishlab chiqadi— amal qilinishi kerak bo‘lgan yondashuv shu.
Bu bilimlarning bitta dasturchida to‘planib qolishini kamaytirishi mumkin.
④ Kundalik yig‘ilishlarni qisqa tuting
SI loyihasida Agile’ni qo‘llashni boshlash uchun eng oson joy — Daily Scrum.
Biroq bu yerda ehtiyot bo‘lish kerak bo‘lgan jihat bor.
Kundalik yig‘ilish jamoa rahbari ish hisobotlarini qabul qiladigan vaqtga aylanmasligi kerak.
Yaxshi kundalik yig‘ilish
“Kecha nima qildingiz?”
“Bugun nima qilasiz?”
kabi savollarni shunchaki takrorlaydigan yig‘ilish emas.
Muhim jihat — jamoa Sprint maqsadi sari ilgarilayotganini tekshirish va zarur bo‘lganda rejani moslashtirish.
Masalan, dasturchi quyidagicha hisobot berishidan ko‘ra,
“API taxminan 80% yakunlandi.”
quyidagilarni ulashish ancha foydaliroq:
“A va B ekranlari yakunlandi, biroq C API’da tashqi tizim bilan integratsiya muammosi yuzaga keldi. Agar bu muammo hal qilinmasa, ushbu Sprint uchun to‘lov funksiyalarini yakunlash qiyin bo‘ladi.”
.
Boshqacha aytganda, kundalik yig‘ilish hisobot sessiyasi emas, muammolarni erta aniqlash joyibo‘lishi kerak.
⑤ Sprint Review’ni mijoz bilan o‘tkazing
Bu SI loyihalarida ayniqsa muhimdir.
Sprint yakunida natijalarni faqat ishlab chiqish jamoasi ichida ko‘rib chiqish o‘rniga, imkon bo‘lsa, amaldagi ishlayotgan tizimni mijozga yoki biznes tomonidagi manfaatdor tomonlarga ko‘rsating.
Masalan, hujjatda shunchaki
“A’zolarni boshqarish funksiyasini ishlab chiqish yakunlandi,”
deb hisobot berish o‘rniga,
amaldagi tizimda quyidagilarni ko‘rsating:
Ro‘yxatdan o‘tish → Tizimga kirish → A’zo ma’lumotlarini ko‘rish → Tahrirlash
Buni bevosita namoyish eting.
So‘ng mijozdan so‘rang:
“Ushbu ekranni haqiqiy ishingizda ishlatayotganingizni tasavvur qilganingizda, unda noqulay bo‘lgan biror jihat bormi?”
Bu talablar bilan haqiqiy ish o‘rtasidagi tafovutlarni tezda aniqlash imkonini beradi.
⑥ Retrospektiva o‘tkazish
Agile’ning yana bir muhim jihatiRetrospektiva.
Sprint oxirida jamoa quyidagi savollarni birgalikda muhokama qiladi.
Nima yaxshi bo‘ldi?
Muammolarga nima sabab bo‘ldi?
Keyingi Sprintda nimani o‘zgartiramiz?
Masalan, birinchi Sprintda,
ishlab chiqish muhitini sozlash uchun uch kun ketdi.
Keyin, navbatdagi Sprintda,
umumiy ishlab chiqish muhitini oldindan shablonlashtirishimiz mumkin.
Buni takomillashtirish bandi sifatida belgilash mumkin.
Muhimi, Retrospektiva shunchaki o‘z-o‘zini tahlil qilish sessiyasiga aylanib qolmasligi kerak.
“Kim aybdor edi?” deb so‘rash o‘rniga, “Keyingi safar qanday qilib yaxshiroq ishlashimiz mumkin?” masalasini muhokama qilishimiz kerak..
Agile’ning 12-tamoyilida ham muntazam vaqt oralig‘ida jamoa qanday ishlayotganini tahlil qilishi va uni yanada samarali usullar tomon moslashtirishi kerakligi ta’kidlanadi.
SI loyihasiga tatbiq etilganda buni qanday birlashtirish mumkin
Oxir-oqibat, Agile’ni SI loyihasiga tatbiq etishning amaliy usulini quyidagicha umumlashtirish mumkin.
|
Agile usuli |
SI loyihasiga qo‘llanishi |
|---|---|
|
Scrum |
Sprintlarni ikki-uch haftalik sikllarda olib borish |
|
Empirizm |
Haqiqiy natijalarni tezda yaratish va tasdiqlash |
|
Daily Scrum |
Qisqa jarayon yangilanishlari va to‘siqlarni ulashish |
|
Sprint Review |
Mijozlar va biznes foydalanuvchilariga haqiqiy funksionallikni namoyish etish |
|
Retrospektiva |
Sprint tugagach, ishlash usulini takomillashtirish |
|
Juftlikda ishlash |
Uni asosiy va murakkabligi yuqori vazifalarga tanlab qo‘llash |
|
Backlog |
Talablarni ustuvorlik bo‘yicha boshqarish |
|
Increment |
Har bir Sprintda ishlaydigan natijani ta’minlash |
|
O‘zini o‘zi tashkil etuvchi jamoa |
Ishlab chiqish jamoasi batafsil vazifalarni qanday bajarishni o‘zi hal qiladi |
Agile SI loyihasining kaliti — “Agile usulida fikrlash”
Agile’ni SI loyihasiga qo‘llash har bir loyiha Scrum yordamida boshqarilishi kerak degani emas.
Muhimrog‘iAgile tafakkurini loyihaga qo‘llash.
Masalan, quyidagilar kabi farqlar mavjud.
An’anaviy yondashuv
“Avval talablar mukammal yakunlangandan keyingina ishlab chiqishni boshlang.”
Agile yondashuvi
“Imkon qadar tezroq biror narsa yarating va amaldagi natijalar orqali talablarni takomillashtiring.”
An’anaviy yondashuv
“Agar jadval o‘zgarsa, loyiha muvaffaqiyatsizlikka uchragan bo‘ladi.”
Agile yondashuvi
“Agar o‘zgarish yuz bersa, ustuvorliklarni moslashtiring va yanada qimmatli natija yaratish yo‘lini toping.”
An’anaviy yondashuv
“Muhimi, ishlab chiquvchi ishni yakunlaganmi yoki yo‘qmi.”
Agile yondashuvi
“Muhimi, foydalanuvchilar amalda foydalana oladigan funksionallik yaratilganmi yoki yo‘qmi.”
Xulosa
Agile shunchaki Jira’da Scrum joriy etadigan yoki Backlog yaratadigan loyiha boshqaruvi texnikasi emas.
Uning mohiyatini quyidagi to‘rt jihat bilan umumlashtirish mumkin.
Tezda yarating
↓
Amalda tekshiring
↓
Mijoz fikr-mulohazalarini oling
↓
Uni keyingi ishlab chiqish sikliga qo‘llang.
Bu jarayonni takrorlash orqali loyiha asta-sekin yaxshiroq yo‘nalishga boshlanadi.
Ayniqsa, SI loyihalarida shartnomalar, jadvallar, topshiriladigan natijalar va mijozlar kabi turli cheklovlar sababli Agile’ning barcha jihatlarini o‘z holicha qo‘llash qiyin.
Shu sababli, realistik yondashuv — SI’ning amaldagi boshqaruv tizimini saqlab qolgan holda, Scrum, empirik yondashuv, qisqa ishlab chiqish sikllari, mijoz fikr-mulohazalari, retrospektivalar va juftlikda ishlash kabi Agile amaliyotlarini zarur joylarda tanlab qo‘llashdir.
Oxir-oqibat, Agile’ning asosiy savoli ...ga emas,
“Boshida tuzgan rejamizga qanchalik yaxshi amal qildik?”
balki
“Loyiha davomida qanchalik tez o‘rgandik, moslashdik va mijozlarga qiymat yetkazib berdik?”
.
Luke