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

Katta tizimlar uchun tezkor usullar

Keng ko'lamli dasturiy ta'minotni ishlab chiqishda foydalanish uchun tezkor usullar rivojlanishi kerak. Buning asosiy sababi shundaki, katta hajmdagi dasturiy ta'minot tizimlari kichik o'lchamli tizimlar yoki dasturiy mahsulotlarga qaraganda ancha murakkab va tushunish va boshqarish qiyinroq. Oltita asosiy omil (3.13-rasm) ushbu murakkablikka yordam beradi:

Brownfield development - atrof-muhit ifloslanishidan ta'sirlangan tijorat ob'ekti.

Diverse stakeholders - Turli manfaatdor tomonlar
Prolonged procurement - Uzoq muddatli xaridlar
Regulatory constraints - Normativ cheklovlar

1. 
   Katta tizimlar odatda tizimlar tizimi - alohida, aloqa tizimlarining yig'indisi bo'lib, bu erda alohida guruhlar har bir tizimni ishlab chiqadi. Ko'pincha, bu jamoalar turli joylarda, ba'zan turli vaqt zonalarida ishlaydi. Har bir jamoaning butun tizimni ko'rishi deyarli mumkin emas. Binobarin, ularning ustuvor yo'nalishlari odatda tizimning o'z qismini kengroq tizim muammolarini hisobga olmasdan bajarishdir.
   
2. 
   Katta tizimlar Brownfield tizimlari (Xopkins va Jenkins 2008); ya'ni ular bir qator mavjud tizimlarni o'z ichiga oladi va ular o'zaro bog’langan bo’ladi. Ko'pgina tizim talablari ushbu o'zaro ta'sirga bog'liq va shuning uchun moslashuvchanlik va bosqichma-bosqich rivojlanish uchun o'zlarini qarzga olmaydi. Bu erda siyosiy masalalar ham muhim bo'lishi mumkin - ko'pincha muammoning eng oson yechimi mavjud tizimni o'zgartirishdir. Biroq, bu o'zgarishlar tizimning ishlashiga xavf tug'dirmasdan amalga oshirilishi mumkinligiga ishontirish uchun ushbu tizim menejerlari bilan muzokaralar olib borishni talab qiladi.
   
3. 
   Tizimni yaratish uchun bir nechta tizimlar birlashtirilgan bo'lsa, rivojlanishning muhim qismi original kodni ishlab chiqish emas, balki tizim konfiguratsiyasi bilan bog'liq. Bu bosqichma-bosqich rivojlanish va tez-tez tizim integratsiyasi bilan mos kelishi shart emas.
   
4. 
   Katta tizimlar va ularning rivojlanish jarayonlari ko'pincha ularni ishlab chiqish yo'llarini cheklaydigan tashqi qoidalar bilan cheklanadi, bu tizim hujjatlarining ayrim turlarini ishlab chiqarishni talab qiladi va hokazo. Mijozlar bajarilishi kerak bo'lgan maxsus muvofiqlik talablariga ega bo'lishi mumkin va ular jarayon hujjatlarini to'ldirishni talab qilishi mumkin.
   
5. 
   Katta tizimlar sotib olish va ishlab chiqish uchun uzoq vaqtga ega. O'sha davr mobaynida tizim haqida biladigan izchil guruhlarni saqlab qolish qiyin, chunki insonlar muqarrar ravishda boshqa ishlar va loyihalarga o'tadilar.
   
6. 
   Katta tizimlar odatda turli nuqtai nazar va maqsadlarga ega bo'lgan turli xil manfaatdor tomonlar to'plamiga ega. Masalan, hamshiralar va ma'murlar tibbiy tizimning oxirgi foydalanuvchilari bo'lishi mumkin, ammo yuqori darajali tibbiyot xodimlari, shifoxona menejerlari va boshqalar ham tizimning manfaatdor tomonlari hisoblanadi. Ushbu turli manfaatdor tomonlarning barchasini ishlab chiqish jarayoniga jalb qilish deyarli mumkin emas.
   

Agile usullarini masshtablashda katta tajribaga ega bo'lgan Din Leffingvell keng ko'lamli, ko'p jamoali dasturiy ta'minotni ishlab chiqishni qo'llab-quvvatlash uchun Scaled Agile Framework (Leffingwell 2007, 2011) ni ishlab chiqdi. U bu usul bir qator yirik kompaniyalarda muvaffaqiyatli qo‘llanilgan. IBM kompaniyasi Agile Scaling Model (ASM) deb nomlangan tezkor usullardan keng miqyosda foydalanishda asosni ishlab chiqdi. Ambler ning ASM (Ambler 2010) 3.14-rasmda ushbu modelning umumiy ko'rinishi ko'rsatilgan.


ASM masshtablashni bosqichma-bosqich jarayon ekanligini tan oladi, unda ishlab chiqish guruhlari bu yerda muhokama qilingan asosiy tezkor amaliyotlardan Intizomli Agile yetkazib berish deb atagan. Asosan, bu bosqich ushbu amaliyotlarni tartibli tashkiliy sharoitga moslashtirishni va jamoalar shunchaki rivojlanishga e'tibor bera olmasligini, balki dasturiy ta'minotni yaratish jarayonining talablar va arxitektura dizayni kabi boshqa bosqichlarini ham hisobga olishlari kerakligini tan olishni o'z ichiga oladi.
ASM-da masshtablashning yakuniy bosqichi - bu katta loyihalarga xos bo'lgan murakkablik tan olingan Agility at Scale-ga o'tishdir. Bu taqsimlangan rivojlanish, murakkab muhitlar va me'yoriy muvofiqlik talablari kabi omillarni hisobga olishni o'z ichiga oladi. Intizomli tezkor yetkazib berish uchun qo'llaniladigan amaliyotlar ularni hisobga olish uchun har bir loyiha asosida o'zgartirilishi va ba'zan jarayonga qo'shimcha rejaga asoslangan amaliyotlar qo'shilishi mumkin.
Barcha yirik masshtabli agile-mahsulotlar uchun yagona model mos kelmaydi, chunki mahsulot turi, mijoz talablari va xodimlarning barchasi boshqacha bo’ladi. Biroq, agile usullarini masshtablash yondashuvlari bir nechta umumiy xususiyatlarga ega:

1. 
   Muhandislik talablariga to'liq bosqichma-bosqich yondashish mumkin emas. Dasturiy ta'minotning dastlabki talablari bo'yicha ba'zi bir dastlabki ishlarni qilish juda muhimdir. Turli guruhlar tomonidan ishlab chiqish mo’ljallangan tizimning turli qismlarini aniqlash uchun tizimni ishlab chiqish bo'yicha shartnomaning bir qismi bo'lishi kerak. Biroq, bu talablar odatda batafsil ko'rsatilmasligi mumkin; Tafsilotlarning eng yaxshisi bosqichma-bosqich ishlab chiqiladi.
   
2. 
   Bitta mahsulot egasi yoki mijoz vakili bo'lishi mumkin emas. Tizimning turli qismlari uchun turli xodimlar jalb qilinishi kerak va ular rivojlanish jarayonida doimiy ravishda muloqot qilishlari va muzokaralar olib borishlari kerak.
   
3. 
   Faqat tizim kodiga e'tibor qaratish mumkin emas. Ko'proq oldindan loyihalash va tizim hujjatlarini bajarish kerak. Dasturiy ta'minot arxitekturasi ishlab chiqish kerak va tizimning muhim jihatlarini, masalan, ma'lumotlar bazasi sxemalari va jamoalar bo'yicha ishlarning taqsimlanishini tavsiflash uchun hujjatlar ishlab chiqilishi kerak.
   
4. 
   Jamoalararo aloqa mexanizmlari ishlab chiqish va ishlatish kerak. Bu jamoa a'zolari o'rtasida muntazam telefon va videokonferentsiyalarni va tez-tez, qisqa elektron uchrashuvlarni o'z ichiga olishi kerak, bunda jamoalar bir-birlarining qilgan ishlari haqida ma'lumot beradi. Muloqotni osonlashtirish uchun elektron pochta, lahzali xabar almashish, ijtimoiy tarmoq tizimlari kabi bir qator aloqa kanallari taqdim etilishi kerak.
   
5. 
   Har qanday ishlab chiquvchi dasturda o'zgarish kiritganda keyin uzluksiz integratsiya qilish, tizimni hosil qilishda bir nechta alohida dasturlarni birlashtirish deyarli mumkin emas. Biroq, tizimni tez-tez birlashtirish va tizimning muntazam versiyalarini chiqarish juda muhimdir. Ko'p jamoali dasturiy ta'minotni ishlab chiqishni qo'llab-quvvatlaydigan konfiguratsiyani boshqarish vositalari muhim ahamiyatga ega.
   

Scrum keng masshtabli ishlab chiqish uchun moslashtirilgan. Aslida, 3.3-bo'limda tasvirlangan Scrum jamoasi asosiy tarkibi ko’rsatilgan, biroq bir nechta turdagi Scrum jamoalari tashkil etilgan. Ko'p jamoali Scrumning asosiy xususiyatlari:

1. 
   Rolni takrorlash. Har bir jamoa o'zining ish komponenti va ScrumMasterga ega. Butun loyiha uchun bosh mahsulot egasi va ScrumMaster bo'lishi mumkin.
   
2. 
   Mahsulot arxitektorlari. Har bir jamoa mahsulot arxitektorini tanlaydi va bu arxitektorlar umumiy tizim arxitekturasini loyihalash va rivojlantirish uchun hamkorlik qiladilar.
   
3. 
   Versiyalarni joylashtirish. Har bir jamoaning mahsulot versiyalarini chiqarish sanalari ko'rsatiladi va to'liq tizim ishlab chiqish uchun moslashtiriladi.
   
4. 
   Scrum of Scrum. Har kuni Scrum of Scrum mavjud bo'lib, u erda har bir jamoa vakillari rivojlanishni muhokama qilish, muammolarni aniqlash va o'sha kuni qilinadigan ishni rejalashtirish uchun uchrashadilar. Zarurat tug'ilganda boshqa jamoalar vakillari ham hozir bo'lishi uchun shaxsiy jamoalarning skrumlari vaqt o'tishi bilan o'zgartirilishi mumkin.
   

3.