3-mavzu. “Agile” (tezkor moslashuvchan) dasturiy ta’minot ishlab chiqish

Agile loyiha boshqaruvi

Har qanday dasturiy ta'minot biznesida menejerlar nima sodir bo'layotganini va loyiha o'z maqsadlariga erishish yoki yo'qligini bilishi va dasturiy ta'minotni taklif qilingan byudjet bilan o'z vaqtida etkazib berishi kerak. Dasturiy ta'minotni ishlab chiqishda rejaga asoslangan yondashuvlar ushbu ehtiyojni qondirish uchun ishlab chiqilgan. Menejerlar loyiha rejasini tuzadilar, unda nima yetkazilishi kerak, qachon yetkazilishi kerakligi va loyiha natijalarini ishlab chiqishda kim ishlaydi. Rejaga asoslangan yondashuv menejerdan ishlab chiqilishi kerak bo'lgan hamma narsani va rivojlanish jarayonlarini barqaror ko'rishni talab qiladi.
Agile usullarining dastlabki tarafdorlari tomonidan taklif qilingan norasmiy rejalashtirish va loyiha nazorati ko'rinishga bo'lgan ushbu biznes talabiga zid edi. Jamoalar o'z-o'zini tashkil qilishdi, hujjatlarni ishlab chiqarmadilar va juda qisqa davrlarda ishlab chiqishni rejalashtirdilar. Garchi bu dasturiy mahsulotlarni ishlab chiquvchi kichik kompaniyalar uchun ishlasa ham, o'z tashkilotida nimalar bo'layotganini bilishi kerak bo'lgan yirik kompaniyalar uchun bu nomaqbuldir.
Boshqa har qanday professional dasturiy ta'minotni ishlab chiqish jarayoni singari, tezkor ishlab chiqish ham jamoaga mavjud vaqt va resurslardan eng yaxshi tarzda foydalanish uchun boshqarilishi kerak. Ushbu muammoni hal qilish uchun Scrum agile usuli ishlab chiqilgan (Schwaber and Beedle 2001; Rubin 2013) agile loyihalarni tashkil qilish uchun asos yaratish va hech bo'lmaganda ma'lum darajada nima bo'layotganini tashqi ko'rinishini ta'minlash. Scrum-ni ishlab chiquvchilar Scrum an'anaviy ma'noda loyihalarni boshqarish usuli emasligini aniq aytishni xohladilar, shuning uchun ular ataylab ScrumMaster kabi yangi terminologiyani ixtiro qildilar, bu esa loyiha menejeri kabi nomlarni almashtirdi. 3.8-rasmda Scrum terminologiyasi va u nimani anglatishini umumlashtiradi.

Scrum atamasi	Ta'rifi
Rivojlanish jamoasi	O'z-o'zini tashkil etuvchi dasturiy ta'minot ishlab chiqaruvchilar guruhi, ular etti kishidan oshmasligi kerak. Ular dasturiy ta'minot va boshqa muhim loyiha hujjatlarini ishlab chiqish uchun mas'uldirlar.
Potentsial jo'natilishi mumkin bo'lgan mahsulot o'sishi	Sprintdan yetkazib beriladigan dasturiy ta'minot o'sishi. G'oya shundan iboratki, bu "potentsial jo'natish mumkin" bo'lishi kerak, ya'ni u tayyor holatda va uni yakuniy mahsulotga kiritish uchun sinov kabi boshqa ish kerak emas. Amalda, bunga har doim ham erishib bo'lmaydi.
Mahsulot zaxirasi	Bu Scrum jamoasi hal qilishi kerak bo'lgan "bajarish" narsalar ro'yxati. Ular dasturiy ta'minot uchun xususiyat ta'riflari, dasturiy ta'minot talablari, foydalanuvchi hikoyalari yoki arxitektura ta'rifi yoki foydalanuvchi hujjatlari kabi zarur bo'lgan qo'shimcha vazifalar tavsifi bo'lishi mumkin.
Mahsulot egasi	Vazifasi mahsulot xususiyatlari yoki talablarini aniqlash, ishlab chiqish uchun ularga ustuvorlik berish va loyiha biznesning muhim ehtiyojlarini qondirishda davom etishini ta'minlash uchun mahsulotning orqada qolgan qismini doimiy ravishda ko'rib chiqishdan iborat bo'lgan individual (yoki ehtimol kichik guruh). Mahsulot egasi mijoz bo'lishi mumkin, lekin dasturiy ta'minot kompaniyasida mahsulot menejeri yoki boshqa manfaatdor tomonlar vakili ham bo'lishi mumkin.
Scrum	Scrum jamoasining kunlik yig'ilishi, taraqqiyotni ko'rib chiqadi va o'sha kuni qilinadigan ishlarga ustuvorlik beradi. Ideal holda, bu butun jamoani o'z ichiga olgan qisqa yuzma-yuz uchrashuv bo'lishi kerak.
ScrumMaster	ScrumMaster Scrum jarayonining bajarilishini ta'minlash uchun mas'uldir va Scrum-dan samarali foydalanishda jamoaga rahbarlik qiladi. U kompaniyaning qolgan qismi bilan aloqa o'rnatish va Scrum jamoasi tashqi aralashuv bilan chalg'itmasligini ta'minlash uchun javobgardir. Scrum ishlab chiquvchilari ScrumMasterni loyiha menejeri deb hisoblamaslik kerakligiga qat'iy ishonadilar. Boshqalar esa har doim ham farqni ko'rish oson bo'lmasligi mumkin.
Sprint	Rivojlanish iteratsiyasi. Sprintlar odatda 2 dan 4 haftagacha davom etadi.
Tezlik	Bitta sprintda jamoa qancha mahsulot orqasida qolishi mumkinligi haqidagi taxmin. Jamoaning tezligini tushunish ularga sprintda nimani qamrab olish mumkinligini taxmin qilishga yordam beradi va ish faoliyatini yaxshilashni o'lchash uchun asos bo'ladi.

Scrum 3.2-rasmda ko'rsatilgan Agile manifestidagi tamoyillarga amal qilgani uchun tezkor usuldir. Biroq, u tezkor loyihani tashkil qilish uchun asos yaratishga e'tibor qaratadi va u juftlik bilan dasturlash va sinovdan oldin ishlab chiqish kabi maxsus rivojlanish amaliyotlaridan foydalanishni talab qilmaydi. Bu shuni anglatadiki, uni kompaniyadagi mavjud amaliyot bilan osonroq birlashtirish mumkin. Shunday qilib, tezkor usullar dasturiy ta'minotni ishlab chiqishda asosiy yondashuvga aylanganligi sababli, Scrum eng keng tarqalgan usul sifatida paydo bo'ldi.

Scrum jarayoni yoki sprint sikli 3.9-rasmda ko'rsatilgan. Har bir jarayon iteratsiyasi mijozlarga yetkazib berilishi mumkin bo'lgan mahsulot rivojini ishlab chiqaradi.

Review work to be done - Bajarilishi kerak bo'lgan ishlarni ko'rib chiqish
Product backlog – maxsulotni orqada qolishi
Potentsial jo'natiladigan dasturiy ta'minot
Scrum sprint tsiklining boshlang'ich nuqtasi mahsulotning orqada qolishi - Scrum jamoasi tomonidan ishlashi kerak bo'lgan mahsulot xususiyatlari, talablari va injiniringni takomillashtirish kabi narsalar ro'yxati. Mahsulot zaxirasining dastlabki versiyasi talablar hujjatidan, foydalanuvchi hikoyalari ro'yxatidan yoki ishlab chiqiladigan dasturiy ta'minotning boshqa tavsifidan olinishi mumkin.
Mahsulotlar ro'yxatidagi yozuvlarning aksariyati tizim xususiyatlarini amalga oshirish bilan bog'liq bo'lsa-da, boshqa tadbirlar ham kiritilishi mumkin. Ba'zan, takrorlashni rejalashtirayotganda, osonlikcha javob berib bo'lmaydigan savollar paydo bo'ladi va mumkin bo'lgan echimlarni o'rganish uchun qo'shimcha ish talab etiladi. Jamoa muammo va yechimni tushunish uchun ba'zi prototiplar yoki sinov ishlarini amalga oshirishi mumkin. Bundan tashqari, tizim arxitekturasini loyihalash yoki tizim hujjatlarini ishlab chiqish uchun orqada qolgan narsalar bo'lishi mumkin.
Mahsulot zaxirasi turli darajadagi tafsilotlarda ko'rsatilishi mumkin va spetsifikatsiyadagi tafsilotlar darajasi bajariladigan ishlarga mos kelishini ta'minlash uchun mahsulot egasi javobgardir. Misol uchun, orqada qoldirilgan element 3.5-rasmda ko'rsatilgandek to'liq foydalanuvchi hikoyasi bo'lishi mumkin yoki oddiygina "Refactor foydalanuvchi interfeysi kodi" kabi ko'rsatma bo'lishi mumkin, bu esa amalga oshiriladigan refaktoringni tanlashni jamoaga qoldiradi.
Har bir sprint tsikli odatda 2 dan 4 haftagacha bo'lgan ma'lum vaqt davom etadi. Har bir tsiklning boshida Mahsulot egasi ushbu tsiklda ishlab chiqilishi kerak bo'lgan eng muhim elementlarni aniqlash uchun mahsulot zaxirasidagi elementlarga ustuvorlik beradi. Sprint hech qachon tugallanmagan ishlarni hisobga olgan holda uzaytirilmaydi. Agar ular sprint uchun ajratilgan vaqt ichida bajarilmasa, mahsulotlar zaxiraga qaytariladi.
Keyin butun jamoa eng muhim vazifalardan qaysi biri bajarilishi kerakligi tanlashda ishtirok etadi. Keyin ular ushbu elementlarni bajarish uchun zarur bo'lgan vaqtni ajratishadi. Ushbu hisob-kitoblarni amalga oshirish uchun ular oldingi sprintda erishilgan tezlikdan foydalanadilar, ya'ni bitta sprintda orqada qolganlarning qancha qismini qoplash mumkin. Bu sprint davomida bajarilishi kerak bo'lgan ish orqada qolishiga olib keladi. Jamoa kim nima ustida ishlashini o'zi hal qiladi va sprint boshlanadi.
Sprint paytida jamoa taraqqiyotni ko'rib chiqish va kerak bo'lganda ishni qaytadan vazifalarni ustuvorligini aniqlash uchun qisqa kunlik uchrashuvlar (Scrums) o'tkazadi. Scrum davomida barcha jamoa a'zolari ma'lumot almashadilar, so'nggi uchrashuvdan buyon erishgan yutuqlarini tavsiflaydilar, yuzaga kelgan muammolarni ko'taradilar va keyingi kun uchun nima rejalashtirilganligini aytadilar. Shunday qilib, jamoadagi har bir kishi nima bo'layotganini biladi va agar muammolar yuzaga kelsa, ularni engish uchun qisqa muddatli ishni qayta rejalashtirishi mumkin. Ushbu qisqa muddatli rejalashtirishda hamma ishtirok etadi.
Scrum jamoalari o'rtasidagi kundalik o'zaro munosabatlar Scrum taxtasi yordamida muvofiqlashtirilishi mumkin. Bu ofis doskasi bo'lib, unda Sprintning orqada qolishi, bajarilgan ishlar, xodimlarning mavjud emasligi va hokazolar haqida ma'lumot va post-it qaydlar mavjud. Bu butun jamoa uchun umumiy manba bo'lib, har kim doskadagi narsalarni o'zgartirishi yoki ko'chirishi mumkin. Bu shuni anglatadiki, har qanday jamoa a'zosi bir qarashda boshqalar nima bilan shug'ullanayotganini va nima qilish kerakligini ko'rishi mumkin.
Har bir sprint oxirida hisobot yig'ilishi bo'lib, unda butun jamoa ishtirok etadi. Ushbu uchrashuv ikki maqsadni ko'zlaydi. Birinchidan, bu jarayonni takomillashtirish vositasi. Jamoa qanday qilganliklarini ko'rib chiqadi va ishlarni qanday qilib yaxshiroq qilish mumkinligi haqida fikr yuritadi. Ikkinchidan, u mahsulot haqida ma'lumot va keyingi sprint oldidan mahsulotning holatini ko’riladi.
ScrumMaster rasmiy ravishda loyiha menejeri bo'lmasa-da, amalda ScrumMasters an'anaviy boshqaruv tuzilmasi bo'lgan ko'plab tashkilotlarda bu rolni bajaradi. Ular yuqori boshqaruvga erishilgan yutuqlar haqida hisobot beradilar va uzoq muddatli rejalashtirish va loyiha byudjetini tuzishda ishtirok etadilar. Ular loyiha boshqaruvi (xodimlar uchun bayramlar haqida kelishish, HR bilan aloqa qilish va hokazo) va apparat va dasturiy ta'minotni xarid qilishda ishtirok etishlari mumkin.
Scrumning turli xil muvaffaqiyatli tarixida (Schatz va Abdelshafi 2005; Mulder va van Vliet 2008; Bellouiti 2009) foydalanuvchilar Scrum usuli haqida quyidagilarni yaxshi ko'radilar:

1. 
   Mahsulot manfaatdor tomonlar bog'lashi mumkin bo'lgan boshqariladigan va tushunarli bo'laklar to'plamiga bo'lingan.
   
2. 
   Beqaror talablar taraqqiyotni to'xtatilmaydi.
   
3. 
   Butun jamoa hamma narsani ko'radi va natijada jamoaviy muloqot va ruhiy holat yaxshilanadi.
   
4. 
   Mijozlarga qo'shimchalarni o'z vaqtida yetkazib beriladi va mahsulot qanday ishlashi haqida fikr-mulohazalarini olishadi. Jamoa dasturiy ta'minot kutilganidek yetkazib berilmaganligi haqidagi xabarni so'nggi daqiqalarda kutilmagan holatda duch kelmaydilar.
   
5. 
   Mijozlar va ishlab chiquvchilar o'rtasida ishonch o'rnatiladi va ijobiy madaniyat yaratiladi, unda hamma loyiha muvaffaqiyatli bo'lishini kutadi.
   

Scrumning dastlabki ko’rinishida barcha jamoa a'zolari har kuni stend-up uchrashuvlarida to'planishadi. Biroq, dasturiy ta'minotni ishlab chiqishning ko'p qismi endi taqsimlangan jamoalarni o'z ichiga oladi, jamoa a'zolari dunyoning turli joylarida joylashgan. Bu kompaniyalarga boshqa mamlakatlardagi arzonroq xodimlardan foydalanish imkonini beradi, mutaxassislik ko'nikmalariga ega bo'lish imkonini beradi va ish turli vaqt zonalarida olib borilayotgan 24 soatlik rivojlanish imkonini beradi.
Shunday qilib, taqsimlangan ishlab chiqish muhitlari va ko'p jamoali ishlash uchun Scrum ishlanmalari mavjud. Odatda, OFFSHOR metodida mahsulot egasi ishlab chiqish guruhidan boshqa mamlakatda bo'ladi. 3.10-rasmda Taqsimlangan Scrum uchun talablar ko'rsatilgan (Deemer 2011).

Videoconferencing between the product owner and the development team - Mahsulot egasi va ishlab chiqish guruhi o'rtasida videokonferentsiya
The ScrumMaster should be located with the development team so that he or she is aware of everyday problems - ScrumMaster kundalik muammolardan xabardor bo'lishi uchun ishlab chiqish guruhi bilan birga bo'lishi kerak.
The Product Owner should visit the developers and try to establish a good relationship with them. It is essential that they trust each other - Mahsulot egasi ishlab chiquvchilarga tashrif buyurishi va ular bilan yaxshi munosabatlar o'rnatishga harakat qilishi kerak. Ular bir-biriga ishonishlari juda muhimdir.
A common development environment for all teams - Barcha jamoalar uchun umumiy rivojlanish muhiti.
Continuous integration, so that all team members can be aware of the state of the product at any time - Barcha jamoa a'zolari istalgan vaqtda mahsulot holatidan xabardor bo'lishlari uchun uzluksiz integratsiya.
Real-time communications between team members for informal communication, particularly instant messaging and video calls - Norasmiy muloqot, xususan, lahzali xabar almashish va video qo'ng'iroqlar uchun jamoa a'zolari o'rtasidagi real vaqtda aloqa.