Scaling agile methods


Katta tizimlar uchun Agile usullari


Download 82.73 Kb.
bet4/5
Sana16.01.2023
Hajmi82.73 Kb.
#1094591
1   2   3   4   5
Bog'liq
Scaling agile methods 3.4

3.4.3 Katta tizimlar uchun Agile usullari
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. Ushbu murakkablikka oltita asosiy omil (3.13-rasm) yordam beradi:


3.13-rasm Katta loyiha xarakteristikalari





  1. Katta tizimlar odatda tizimlar tizimi - alohida aloqa tizimlarining yig'indisi bo'lib, har bir tizimni alohida guruhlar ishlab chiqadi. Ko'pincha, bu jamoalar turli joylarda, ba'zan esa turli vaqt zonalarida ishlaydi. Har bir jamoaning butun tizimni ko'rishi amalda mumkin emas. Binobarin, ularning ustuvor yo'nalishlari odatda tizimning o'z qismini kengroq tizim muammolarini hisobga olmasdan bajarishdir.

  2. Katta tizimlar jigarrang maydon tizimlari (Xopkins va Jenkins 2008); ya'ni ular bir qator mavjud tizimlarni o'z ichiga oladi va ular bilan o'zaro ta'sir qiladi. Ko'pgina tizim talablari ushbu o'zaro ta'sirga taalluqlidir va shuning uchun moslashuvchanlik va bosqichma-bosqich rivojlanishga mos kelmaydi. 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.




  1. Tizimni yaratish uchun bir nechta tizimlar birlashtirilganda, 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.

  2. Katta tizimlar va ularning rivojlanish jarayonlari ko'pincha ularni ishlab chiqish usullarini cheklovchi tashqi qoidalar va qoidalar bilan cheklanadi, ular tizim hujjatlarining ayrim turlarini ishlab chiqarishni talab qiladi va hokazo. Mijozlarda bajarilishi kerak bo'lgan maxsus muvofiqlik talablari bo'lishi mumkin va ular jarayon hujjatlarini to'ldirishni talab qilishi mumkin.

  3. Katta tizimlar uzoq vaqt xarid qilish va ishlab chiqish vaqtiga ega. O'sha davr mobaynida tizim haqida biladigan izchil guruhlarni saqlab qolish qiyin, chunki odamlar muqarrar ravishda boshqa ishlar va loyihalarga o'tadilar.




  1. Katta tizimlar, odatda, turli istiqbol va maqsadlarga ega bo'lgan turli manfaatdor tomonlarga 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 jamoaviy 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 qanday muvaffaqiyatli qo‘llanilgani haqida xabar beradi. IBM shuningdek, Agile Scaling Model (ASM) deb nomlangan tezkor usullardan keng miqyosda foydalanish uchun ramka ishini ishlab chiqdi. Amblerning ASM (Ambler 2010) haqidagi oq qog'ozidan olingan 3.14-rasmda ushbu modelning umumiy ko'rinishi ko'rsatilgan.


ASM miqyoslash bosqichma-bosqich jarayon ekanligini tan oladi, unda ishlab chiqish guruhlari bu erda muhokama qilingan asosiy tezkor amaliyotlardan Intizomli Agile yetkazib berish deb ataladigan narsaga o'tadi. Aslida, bu bosqich ushbu amaliyotlarni tartibli tashkiliy sharoitga moslashtirishni va jamoalar shunchaki rivojlanishga e'tibor qaratishlari mumkin emasligini, balki dasturiy ta'minotni yaratish jarayonining talablar va arxitektura dizayni kabi boshqa bosqichlarini ham hisobga olishlari kerakligini tan olishni o'z ichiga oladi.
ASMda masshtablashning yakuniy bosqichi - bu katta loyihalarga xos bo'lgan murakkablik tan olingan Agility at Scale-ga o'tishdir. Bu taqsimlangan rivojlanish, murakkab eski 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 keng miqyosli tezkor mahsulotlar uchun yagona model mos emas, chunki mahsulot turi, mijozlar talablari va mavjud odamlarning barchasi boshqacha. Biroq, agile usullarini masshtablash yondashuvlari bir qancha umumiy jihatlarga ega



  1. Muhandislik talablariga to'liq bosqichma-bosqich yondashish mumkin emas. Dastlabki dasturiy ta'minot talablari bo'yicha ba'zi bir erta ishlash juda muhimdir. Ushbu ish turli guruhlar tomonidan ishlab chiqilishi mumkin bo'lgan tizimning turli qismlarini aniqlash va ko'pincha tizimni ishlab chiqish bo'yicha shartnomaning bir qismi bo'lish uchun kerak. Biroq, bu talablar odatda batafsil ko'rsatilmasligi kerak; Tafsilotlar eng yaxshi bosqichma-bosqich ishlab chiqilgan.

  2. Bitta mahsulot egasi yoki mijoz vakili bo'lishi mumkin emas. Tizimning turli qismlari uchun turli xil odamlar jalb qilinishi kerak va ular rivojlanish jarayonida doimiy ravishda muloqot qilishlari va muzokaralar olib borishlari kerak.

  3. Faqat tizimning kodiga e'tibor qaratish mumkin emas. Siz ko'proq oldindan dizayn va tizim hujjatlarini bajarishingiz kerak. Dasturiy ta'minot arxitekturasi ishlab chiqilishi kerak va tizimning muhim jihatlarini, masalan, ma'lumotlar bazasi sxemalari va jamoalar bo'ylab ishlarning taqsimlanishini tavsiflovchi hujjatlar ishlab chiqilishi kerak.

  4. Jamoalararo muloqot mexanizmlari ishlab chiqilishi va ishlatilishi 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 taraqqiyoti haqida ma'lumot beradi. Muloqotni osonlashtirish uchun elektron pochta, lahzali xabar almashish, wiki va ijtimoiy tarmoq tizimlari kabi bir qator aloqa kanallari taqdim etilishi kerak.

  5. Har qanday ishlab chiquvchi o'zgarishlarni tekshirganda butun tizim quriladigan uzluksiz integratsiya, tizimni yaratish uchun bir nechta alohida dasturlarni birlashtirish kerak bo'lganda amalda mumkin emas. Biroq, tizimni tez-tez qurish va tizimning muntazam relizlarini saqlab turish juda muhimdir. Ko'p jamoali dasturiy ta'minotni ishlab chiqishni qo'llab-quvvatlaydigan konfiguratsiyani boshqarish vositalari muhim ahamiyatga ega.

Scrum keng ko'lamli rivojlanish uchun moslashtirilgan. Aslida, 3.3-bo'limda tasvirlangan Scrum jamoasi modeli saqlanib qolgan, biroq bir nechta Scrum jamoalari tashkil etilgan.


Ko'p jamoali Scrumning asosiy xususiyatlari:

  1. Rollarni takrorlash Har bir jamoa o'zining ish komponenti va ScrumMaster uchun Mahsulot egasiga 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. Chiqarishlarni moslashtirish Har bir jamoaning mahsulot chiqarish sanalari ko'rsatiladigan va to'liq tizim ishlab chiqarilishi uchun moslashtiriladi.

  4. Scrum of Scrum Kundalik Scrum of Scrum mavjud bo'lib, u erda har bir jamoa vakillari taraqqiyotni muhokama qilish, muammolarni aniqlash va o'sha kuni qilinadigan ishni rejalashtirish uchun yig'ilishadi. Agar kerak bo'lsa, boshqa jamoalarning vakillari ishtirok etishi uchun individual Scrums jamoasi o'z vaqtida o'zgartirilishi mumkin.

3.4.4 Tashkilotlar bo'ylab tezkor usullar


Dasturiy ta'minot mahsulotlarini ishlab chiqadigan kichik dasturiy ta'minot kompaniyalari tezkor usullarni eng ishtiyoqli qabul qiluvchilar qatoriga kiradi. Ushbu kompaniyalar tashkiliy byurokratiya yoki jarayon standartlari bilan cheklanmaydi va ular yangi g'oyalarni qabul qilish uchun tezda o'zgarishi mumkin. Albatta, yirik kompaniyalar ham aniq loyihalarda tezkor usullarni sinab ko'rishgan, ammo ular uchun tashkilot bo'ylab bu usullarni "kengaytirish" ancha qiyinroq.
Bir necha sabablarga ko'ra yirik kompaniyalarga tezkor usullarni joriy etish qiyin bo'lishi mumkin:

  1. Agile usullari bo'yicha tajribaga ega bo'lmagan loyiha menejerlari yangi yondashuv xavfini qabul qilishni istamasligi mumkin, chunki bu ularning alohida loyihalariga qanday ta'sir qilishini bilishmaydi.

  2. Yirik tashkilotlarda ko'pincha barcha loyihalar amal qilishi kutilayotgan sifat tartib-qoidalari va standartlariga ega va ularning byurokratik tabiati tufayli ular tezkor usullar bilan mos kelmasligi mumkin. Ba'zan, ular dasturiy vositalar (masalan, talablarni boshqarish vositalari) tomonidan qo'llab-quvvatlanadi va bu vositalardan foydalanish barcha loyihalar uchun majburiydir.

  3. Agile usullari jamoa a’zolari nisbatan yuqori malaka darajasiga ega bo‘lsa, eng yaxshi natija beradi. Biroq, yirik tashkilotlarda ko'nikma va ko'nikmalarning keng doirasi mavjud bo'lishi mumkin va mahorat darajasi past bo'lgan odamlar tezkor jarayonlarda samarali jamoa a'zosi bo'la olmaydi.

  4. Agile usullarga madaniy qarshilik bo'lishi mumkin, ayniqsa an'anaviy tizim muhandislik jarayonlaridan uzoq tarixga ega bo'lgan tashkilotlarda

O'zgarishlarni boshqarish va sinovdan o'tkazish tartib-qoidalari tezkor usullarga mos kelmasligi mumkin bo'lgan kompaniya protseduralariga misollardir. O'zgarishlarni boshqarish - bu tizimdagi o'zgarishlarni nazorat qilish jarayoni bo'lib, o'zgarishlarning ta'sirini oldindan aytish mumkin va xarajatlar nazorat qilinadi. Barcha o'zgarishlarni amalga oshirishdan oldin ularni oldindan tasdiqlash kerak va bu refaktoring tushunchasiga zid keladi. Refaktoring tezkor jarayonning bir qismi bo'lsa, har qanday ishlab chiquvchi har qanday kodni tashqi ma'qullamasdan yaxshilashi mumkin. Katta tizimlar uchun tizimni qurish tashqi sinov guruhiga topshiriladigan sinov standartlari ham mavjud. Bu tezkor rivojlanish usullarida qo'llaniladigan birinchi sinov yondashuvlariga zid bo'lishi mumkin.


Katta tashkilotda tezkor usullarni joriy etish va qo'llash madaniy o'zgarishlar jarayonidir. Madaniy o'zgarishlarni amalga oshirish uzoq vaqt talab etadi va ko'pincha uni amalga oshirishdan oldin boshqaruvni o'zgartirishni talab qiladi. Tezkor usullardan foydalanishni istagan kompaniyalar o'zgarishlarni targ'ib qilish uchun xushxabarchilarga muhtoj. Agile usullarini istamagan ishlab chiquvchilarga majburlashdan ko'ra, kompaniyalar agileni joriy etishning eng yaxshi yo'li asta-sekin ishlab chiquvchilar guruhidan boshlab ekanligini aniqladilar. Muvaffaqiyatli agile loyihasi boshlang'ich nuqta bo'lishi mumkin, loyiha jamoasi butun tashkilot bo'ylab tezkor amaliyotni tarqatadi. Agile tushunchasi keng ma'lum bo'lgach, uni butun tashkilot bo'ylab tarqatish uchun aniq choralar ko'rish mumkin.

Download 82.73 Kb.

Do'stlaringiz bilan baham:
1   2   3   4   5




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2024
ma'muriyatiga murojaat qiling