Mahsulot egasi

3.3.2.1 Jamoalar


Oddiy SCRUM jamoasidagi asosiy rollar quyidagilardan iborat:
• Mahsulot egasi: manfaatdor tomonlarni ifodalaydi va mijozning ovozi hisoblanadi.
Fikr-mulohazalarni, mijozlarga yo'naltirilgan foydalanuvchi hikoyalarini taqdim etish uchun javobgar (pastga qarang),
va talablarni birinchi o'ringa qo'yish uchun

• 
  SCRUM Master: Jamoa rahbarini ifodalaydi. Rivojlanish guruhi va tashkilot rahbariyati o'rtasidagi interfeys. Yig'ilishlarga raislik qiladi, ularni amalga oshiradi
  

protokollarni tuzadi va jamoaga xalaqit berishi mumkin bo'lgan barcha to'siqlarni olib tashlaydi

• Ishlab chiqish guruhi: manba yozish uchun mas'ul bo'lgan ishlab chiquvchilar to'plami kod, testlar, UI dizayni va boshqalar. SCRUM ishlab chiquvchilarni kiritmaslikka harakat qiladi ixtisoslashgan rollar, lekin ko'p funktsiyali jamoalarga ega.


Mashq: Rivojlanish guruhlari mavzusida - nima uchun bu mantiqiyroq
Ishlab chiquvchilarni ma'lum bir narsaga ixtisoslashtirish o'rniga, intizomlararo guruhlarni ta'kidlang
test kabi sohalar?

3.3.2.2 Ish oqimi





muhim SCRUM ish oqimi 3.8-rasmda ko'rsatilgan. U quyidagi asosiy komponentlar va protseduralardan iborat:
3.3 Agile dasturiy ta'minotni ishlab chiqish
Foydalanuvchi hikoyalarining mahsulot to'plami


Kerakli dasturiy ta'minot xususiyatlari ro'yxati manfaatdor tomonlar yordamida tuziladi.
Ro'yxat foydalanuvchilarning hikoyalari bo'yicha tuzilgan. Foydalanuvchi hikoyasi qisqa shakldagi tabiiydir
Agile dasturiy ta'minotni ishlab chiqishda keng qo'llaniladigan til talabi.
Odatda quyidagi shaklni oladi:
“ sifatida men uchun ni xohlayman.


ser hikoyalari odatda bir qancha hikoya nuqtalari bilan bog'liq bo'ladi - ularni amalga oshirish uchun qancha kuch talab qilinishini raqamli baholash. Maqsad
boshqa hikoyalarga nisbatan ularning nisbiy murakkabligini aniqlash (ta'minlamaslik
talab qilinadigan harakat miqdorining mutlaq o'lchovi). Buning uchun yondashuv
5.2.6-bo'limda talab qilinadigan vaqt miqdoriga bog'langan hikoya nuqtalari ko'rib chiqiladi.
Bir qator hikoya nuqtalarini tanlash ko'pincha sezgi bilan bog'liq bo'lsa-da,
uni biz muhokama qiladigan Pokerni rejalashtirish kabi tadbirlar ham qo'llab-quvvatlashi mumkin
5.2.4-bo'limda
Mahsulot egasi butun ishlab chiqish jarayonida ushbu ro'yxatni boshqarish uchun javobgardir. Roʻyxat ustuvor boʻlib, eng yuqori qiymatli va xavfli obʼyektlar tepada, past baholi, past xavfli narsalar esa quyida koʻrinishini taʼminlaydi. Mahsulotni ishlab chiqish jarayonida orqada qolish doimiy ravishda o'zgarishi mumkin.


Mashq: Nima uchun xavf mahsulot zaxirasini tartibga solishda omil ekanligini ko'rib chiqing.


esa: Oddiy onlayn-banking tizimini va uning foydalanuvchilarini ko'rib chiqing: bank xodimlari va mijozlari. Bank xodimi uchun ikkita foydalanuvchi hikoyasini va beshtasini yozing
yon eslatmada keltirilgan shablondan foydalanib, mijoz uchun foydalanuvchi hikoyalari.


Sprintlar


Sprint - bu har doim mahsulotning ishlaydigan versiyasini berishi kerak bo'lgan vaqtli rivojlanish davri. Sprintning tugash sanasi har doim qat'iy va muddat
bir haftadan bir oygacha o'zgarib turadi.


Sprintni rejalashtirish


Sprintni rejalashtirish seansi sprint uchun maqsadni kelishib olishni va mahsulotning orqada qolgan qismidan sprint uchun mos elementlarni tanlashni o'z ichiga oladi. Seans odatda
sakkiz soatdan ortiq davom etmaslik bilan cheklangan. Vaqtning yarmi butun jamoani o'z ichiga oladi,
va ikkinchi yarmi rivojlanish strategiyasini kelishish, yuqori darajadagi arxitektura masalalarini muhokama qilish va vazifalarni taqsimlash uchun rivojlanish guruhini kuzatishni o'z ichiga oladi.
Kundalik Scrum
Taxminan 10 daqiqa davom etadigan kundalik stend yig'ilishi. Har bir a'zosi
Rivojlanish guruhi uchta savolga javob beradi:
1. Oxirgi kunda nima qildim?
2. Bugun nima qilishni rejalashtiryapman?
3. To'siqlar bormi?
Stend-up uchrashuvlari, ayniqsa, tezkor loyihalarda keng tarqalgan. Bir muhitda
Agar talablar tez-tez o'zgarishi mumkin bo'lsa, rejalarni o'zgartirish va amalga oshirish oqibatlarini muhokama qilish kerak, buning uchun yuzma-yuz muhokama qilinadi.
aloqaning eng yaxshi shakli bo'ling. Muammo shundaki, muntazam ravishda yuzma-yuz
yig'ilishlarni shunday o'tkazingki, yig'ilishlar juda uzoq davom etmaydi va samarasiz bo'lib qolmaydi. Doimiy yig'ilishning asosi shundaki, bu noqulaylik
juda uzoq vaqt turish ishtirokchilar uchun noqulay bo'lib qoladi, shuning uchun ta'minlaydi
uchrashuvni qisqa tutish uchun tabiiy turtki.
Agile dasturiy ta'minotni ishlab chiqish orqali ommalashgan bo'lsa-da, doimiy uchrashuvlar uzoq davom etadi
uchrashuvlarni qisqa tutishning mashhur usullari bo'lgan. Misol uchun, Buyuk Britaniya Maxfiylik kengashi a
qirol yoki qirolichaning hukumat maslahatchilaridan iborat rasmiy organi (1708 yilda tuzilgan)
har oy uchrashing. Qirolicha Viktoriya konventsiyani 19-asrda kiritgan
yig'ilish ularni iloji boricha qisqa tutish uchun tik turgan holda o'tkazilishi kerak. Bu
odat hozirgi kungacha saqlanib qolgan16.


Ko'rib chiqish va retrospektiv
Sprint oxirida jamoa foydali mahsulotni ishlab chiqishi kerak edi. Bu
keyin mahsulot egasi va ideal holda manfaatdor tomonlar bilan ko'rib chiqiladi. Har qanday fikr-mulohaza
mahsulot zaxirasiga kiritiladi va yangi iteratsiya boshlanadi
Mashq: Ish jarayoni va asosiy SCRUM faoliyatini hisobga olgan holda, siz bog'lay olasizmi?
bular Agile manifestida bayon etilgan 12 ta tamoyilga (3.3.1-bo'limga qarang)?



3.3.3 Umumiy sifat menejmenti bilan aloqasi


Agile texnikasi va usullari an'anaviy dasturiy ta'minotni ishlab chiqishdan farq qiladi
ish oqimlari, chunki ular asosiy e'tiborni rejalashtirish va spetsifikatsiyadan ishlab chiqish va takomillashtirishga o'tkazadi. Ishlab chiquvchilar endi kanonik spetsifikatsiyaga tayanmaydilar
va qo'shimcha hujjatlar ular qilayotgan ishlari uchun ma'lumotnoma sifatida. Spetsifikatsiya
Bu "jonli hujjat" bo'lib, mahsulot qoldiqlarida, yopishqoq yozuvlari bo'lgan kanban taxtalarida va kundalik skrumlar orqali bildiriladi.
Ushbu tamoyillar o'zlarining oldingi ishlab chiqarishlariga juda ko'p qarzdor. Bizga imkon bering
Umumiy sifat menejmenti tamoyillarini qayta ko'rib chiqing (3.1-bo'limga qarang) va ularni muhokama qiling epchil nuqtai nazardan:


Mijozlarga e'tibor qaratish: erta va uzluksiz yetkazib berishning birinchi epchil printsipi va ikkinchi tamoyilni o'z ichiga olgan mijozning qoniqishidir.
talablarning muntazam o'zgarishi. Mijoz bilan muntazam aloqada bo'lish rag'batlantiriladi. SCRUM-da mahsulot egasi mijozning qarashlarini ta'minlash uchun mavjud
rivojlanish jarayonida markaziy bosqichga o'ting.
• Jarayon - o'zgarishlarni kamaytirish va doimiy yaxshilanishga erishish: Bir
tezkor rivojlanish ortidagi asosiy omillardan biri bu jarayonlarning mavjudligi
engil - ularni qabul qilish va kuzatish oson. Bu ularni to'g'ridan-to'g'ri qabul qilishga majbur qiladi va ko'pincha sifat nuqtai nazaridan kuchli rag'batlar mavjud.
Nihoyat, tez-tez epchil rivojlanish guruhlarida (masalan, scrum master) rollar mavjud bo'lib, ularning asosiy vazifasi jarayonlarga rioya etilishini ta'minlash va ularni olib tashlashdir.
bunga to'sqinlik qiladigan har qanday to'siqlar.
• Sifatning insoniy tomoni: mas'uliyatning boshqaruvdan ishlab chiquvchilarga o'tishi tezkor rivojlanishning asosiy xususiyati hisoblanadi. tamoyillaridan biri
Agile manifestida aytilishicha, "loyihalar g'ayratli shaxslar atrofida quriladi
Kimga ishonish kerak" va yana biri jamoa muntazam ravishda aks ettirishi kerakligini ta'kidlaydi
qanday qilib samaraliroq bo'lish haqida. Jamoalar o'z-o'zini tashkil qilishlari kerak. SCRUM uchrashuvlari
odamlarga muammo yoki to'siqlarni ko'tarish va har biriga yordam berish imkoniyatini bering
boshqa.
• O'lchash va tahlil qilish: Agile rivojlanishi foydalanish atrofida aylanadi
taraqqiyot holatini kuzatib borish uchun Kanban taxtalari, shuningdek taraqqiyotni ko'rsatadigan yonish jadvallari kabi taraqqiyotni ko'rsatadigan texnikalar.

Mashq: Biz Agile usullari va TQM o'rtasidagi munosabatni ko'rib chiqdik. Toyota ishlab chiqarish tizimi uchun shunga o'xshash mashqni bajara olasizmi?


Agile yondashuvlar ko'pchilikdan oldingi eng yaxshi amaliyotlarni qamrab oladi
dasturiy ta'minotni ishlab chiqishning an'anaviy uslublari. Bu nuqta ba'zan o'tkazib yuborilishi mumkin;
tez-tez epchil yondashuvlar tomonidan qo'llab-quvvatlanadigan ko'plab tamoyillar degan fikr mavjud
etarli asosga ega emaslar - masalan, ular etarli darajada eksperimental dalillar bilan qo'llab-quvvatlanmagan. Garchi bu bevosita empirik dasturiy ta'minot muhandisligi ma'nosida to'g'ri bo'lishi mumkin bo'lsa-da, ko'pincha boshqa sohalarda o'nlab yillar davomida erishilgan muvaffaqiyatlar tufayli asosiy mantiqiy asoslar juda yaxshi tasdiqlangan. ishlab chiqarish sohalari.
3.3.4 Nega har doim chaqqon bo'lmaslik kerak?


Agile dasturiy ta'minotni ishlab chiqish tamoyillari juda intuitivdir. Ular
to'g'ridan-to'g'ri yoki bilvosita ishlab chiqarishning o'n yillik tajribasiga asoslanadi
sanoat. Umuman olganda, ko'plab empirik tadqiqotlar [45] bo'lgan
dasturiy ta'minot yuqori sifatga ega ekanligini va agar jamoalar samaraliroq bo'lsa
dasturiy ta'minot tezkor muhitda ishlab chiqilgan. Nega shunday bo'lsa, har doim ham bo'lmaydi
eng og'ir, markazlashtirilgan, hujjatlashtirish va o'rniga tezkor yondashuvni tanlang
spetsifikatsiyaga asoslangan "an'anaviy" yondashuv?
Ba'zi salbiy tomonlari bor. Arxitektura va dizaynga e'tiborni olib tashlash
Agile dasturiy ta'minot tizimlari yakunlanishi mumkin bo'lgan (ajablanmaydigan) natijaga ega
kamroq intuitiv bo'lgan arxitektura va dizaynlar [113]. Bundan tashqari, idrok mavjud
tezkor usullar kichikroq loyihalarni afzal ko'radi, lekin kattaroq loyihalar yaxshiroq
markaziy nazorat va rejalashtirishni ta'kidlaydigan texnikalar bilan o'chiring [33] (ehtimol
quyidagi amaliy tadqiqot orqali).


3.3.4.1 Buyuk Britaniya hukumatining universal kredit loyihasi
Agile muvaffaqiyatsizlikka uchraganiga qiziqarli misolni nisbatan yaqinda bo'lgan katta hajmda topish mumkin
Buyuk Britaniya hukumati tomonidan IT loyihasi. “Dunyodagi eng katta chaqqon” deb hisoblangan
dasturiy ta'minot loyihasi", 2,4 milliard funt sterlinglik sxema dasturiy ta'minotning qanchalik tezkorligini namoyish qilish uchun mo'ljallangan edi
rivojlantirish yirik loyihalarga taalluqli bo‘lishi mumkin.
Loyiha murakkab edi. Maqsad IT infratuzilmasini ta'minlash edi
Britaniya farovonlik tizimidagi bir qator muhim o'zgarishlarni qo'llab-quvvatlash. Bular kerak edi
davlat nafaqalarini olish uchun ariza berish jarayonini soddalashtirish va nazoratni kuchaytirish imkonini beradi
shaxslar nafaqa olishlari mumkin bo'lgan shartlar, masalan, ularning kuzatuvi
ish uchun ish o'rinlari uchun arizalar, shuningdek, nogironlikning ayrim turlarini hisobga olish;
ularning qaramog'ida bo'lganlar bo'lganmi va hokazo.
Ikki yil ichida loyiha jiddiy qiyinchiliklarga duch keldi. Hukumatning
Asosiy loyihalar boshqarmasi loyihani ko'rib chiqdi va jiddiy tashvishlarni aniqladi,
ular ochiq hisobotda bayon etilgan [35]. Quyida birgalikda ba'zi iqtiboslar keltirilgan.
loyiha nima uchun muvaffaqiyatsizlikka uchraganining rasmini chizing:
Agile metodologiyasini etishmayotgan muhitda joriy etish
tezkor rivojlanish tajribasi.
2010 yil oxirida Departament dasturni boshqarish uchun "chaqqon" metodologiyadan foydalanishga qaror qildi. Agile yondashuvlar dasturlarga texnik ishlarni talablardan oldin boshlash imkonini beradi
an'anaviy "palapartishlik" yondashuvlaridan farqli ravishda yakunlandi. . . . 2010 yilda departament unchalik tanish emas edi



Tizimning murakkabligi va uning ko'plab tizimlar bilan bog'langanligi
ular tezkor kontekstda ishlab chiqilmagan.
Departament tezkor yondashuv tashkilot uchun xavflarni oshirishini tan oldi
bu yondashuv bilan tanish emas edi. Xususan, boshqarma:
• 1000 dan ortiq odamga yetgan dasturni boshqarayotgan edi
ko'pincha kichik hamkorlikdagi jamoalarda qo'llaniladi;
• taraqqiyotni qanday kuzatishi yoki qarorlarni hujjatlashtirishi aniqlanmagan;
• Universal Creditni mavjud tizimlar bilan integratsiya qilish zarur bo'lib, ular o'zgarishlarni boshqarish uchun palapartishlikdan foydalanadi; va
• mavjud shartnoma, boshqaruv va tasdiqlash tuzilmalari doirasida ishlagan.
Dasturni boshqarish bilan bog'liq muammolarni hal qilish uchun Departament qayta-qayta aniqladi
uning yondashuvi. Departament 2012 yil yanvar oyida o'z yondashuvini "Agile 2.0" ga o'zgartirdi. Agile 2.0
Bu avvalgi tezkor yondashuvning evolyutsiyasi bo'lib, mavjud bilan yaxshiroq ishlashga harakat qilish uchun mo'ljallangan
Departament eski tizimlarga o'zgartirishlar kiritish uchun foydalanadigan sharshara yondashuvlari.
Ko'pgina muammolarning manbai qanday qilib Universal ekanligi haqida batafsil tasavvurning yo'qligi edi
Kredit ishlash uchun mo'ljallangan.
Yuqoridagi parchalardan ko'rinib turibdiki, bu erda ko'plab muammolar o'ynagan va bu
Muammoning ildizlarini faqat agile dasturiy ta'minotni ishlab chiqishni qabul qilish bilan bog'lash mutlaqo adolatsiz bo'lar edi. Oxirgi iqtibos ayniqsa ochib beradi - bu go'yo edi
manfaatdor tomonlar va vazirlarga tizimning qanday ishlashini to'g'ri etkazish qiyin
ishlashi kerak edi.
Bunday holda, tezkor rivojlanishning kuchli tomonlari bo'lib chiqdi
muammoning ildizlari. Talablardagi o'zgarishlarni qabul qilish qobiliyati - bu kuchli.
Biroq, hech qanday moslashuvchanlik talablar mavjud bo'lgan vaziyatlarni qoplay olmaydi
umuman ma'lum emas.
Ushbu zaiflik - manfaatdor tomonlar tomonidan aniq tushunchaning yo'qligi - ehtimol an'anaviy dasturiy ta'minotda ilgari fosh qilingan bo'lishi mumkin.
rivojlanish konteksti. Takomillashtirish maqsadida rivojlanishni boshlash o'rniga
Ular kelganda, loyiha hatto sharsharada boshlanmagan bo'lar edi
kontekst. Va bu vaziyatda, ehtimol, bu stsenariy afzalroq bo'lar edi.

3.4 Dasturiy ta'minot jarayonini takomillashtirish - Imkoniyatlarning etukligi
Model
Dasturiy ta'minotni ishlab chiqish jarayonlarini "qutidan tashqari" qo'llash mumkin emas. Jarayonlar har doim ma'lum bir biznes kontekstiga mos keladigan tarzda o'zgartirilishi kerak
tashkilot, mijoz yoki muammoli domen (bu SCRUMni Universal Credit loyihasiga qo'llashga urinishning oldingi misolidan aniq). Butun davomida
80-yillarda, takomillashtirish loyihalarini moslashtirish vazifasi vaqtinchalik jarayon edi,
bir tashkilotdan boshqasiga farq qiladigan.



80-yillarning oxiriga kelib, amaliyotchilar va akademiklar ko'proq harakat qilishdi
doirasida juda muvaffaqiyatli bo'lgan jarayonni takomillashtirish tushunchalariga tayanish
ishlab chiqarish sektori. Bu boradagi yorqin misol uchun ushbu intervyuga qarang
Stiv Jobs17 Jozef Jurandan so'rashganda unga ta'siri haqida
Jobs o'sha paytda prezidenti bo'lgan NeXT korporatsiyasiga tashrif buyuring. Unda Jobs beradi
Juran ishining asosiy tamoyillarining ajoyib xulosasi. Qizig'i shundaki, Jobs ham
Yaponiyada ishlab chiqarishning o'sishiga hurmat to'laydi (avval muhokama qilinganidek) va qanday qilib
u bu borada AQShni tortib olingan deb hisobladi.
Bu ishlab chiqilgan Imkoniyatlarning etuklik modeli (CMM) [69] ga olib keldi
Karnegi Mellon dasturiy muhandislik institutida. Undan qattiq ilhomlangan
Umumiy sifat menejmenti tamoyillari (3.1.4-bo'limga qarang). CMM dasturiy ta'minot imkoniyatlarini baholash uchun ishlatilishi mumkin bo'lgan vosita sifatida ishlab chiqilgan
rivojlanish tashkilotlari.
So'nggi 20 yil ichida model turli xil versiyalar orqali rivojlandi
(dasturiy ta'minot sifati bo'yicha turli xil darsliklar ko'pincha turli versiyalarga murojaat qilishi mumkin). The
joriy versiya CMMI 1.3 [127] (CMMIdagi I "Integratsiya" degan ma'noni anglatadi, chunki
yangi CMMI modeli turli xil oldingi versiyalar va variantlarning integratsiyasidir
CMM).
Hozirgi CMMI dasturiy ta'minotni ishlab chiqishning keng amaliyotini 17 ga ajratadi
asosiy "jarayon sohalari" (ma'lum bir domenga qarab qo'shimcha hududlar bilan,
masalan xizmatlar yoki sotib olish uchun). Bular 3.10-rasmda ko'rsatilgan. Ko'tarilish uchun
CMMI zinapoyasida tashkilotlar tobora qattiqroq protokollarni joriy qilishlari kerak
bu 17 ta sohani qamrab oladi.

• Sabablarni tahlil qilish va hal qilish (CAR)
• Konfiguratsiyani boshqarish (CM)
• Qarorlarni tahlil qilish va
Ruxsat (DAR)
• Integratsiyalashgan mehnat boshqaruvi (IWM)
• O'lchash va tahlil qilish
(MA)
• Tashkiliy jarayon
Ta'rif (OPD)
• Tashkiliy jarayon markazi (OPF)
• Tashkiliy faoliyatni boshqarish
(OPM)
• Tashkiliy jarayon
Ishlash (OPP)
• Tashkiliy trening
(OT)
• Loyiha monitoringi va
Nazorat (PMC)
• Loyihani rejalashtirish (PP)
• Jarayon va mahsulot sifatini ta'minlash (PPQA)
• Loyiha rahbarining miqdoriy boshqaruvi (QPM)
• Talablarni boshqarish (REQM)
• Risklarni boshqarish
(RSKM)
• Yetkazib beruvchi shartnomasi bo‘yicha menejer (SAM)
3.10-rasm 17 CMMI 1.3 uchun asosiy jarayon sohalari.

Har bir jarayon sohasida tashkilotning "etukligi" shunga ko'ra o'lchanadi
besh daraja, ular 3.9-rasmda ko'rsatilgan. Har bir etuklik darajasi a bilan bog'liq
savollarni tanlash, ulardan ba'zilari "asosiy savollar" sifatida belgilangan. a erishish uchun
berilgan darajada, tashkilot buning uchun savollarning 80% ga ijobiy javob berishi kerak
darajasi, shu jumladan asosiy savollarning 90%. Darajalar bir-biriga bo'ysunadi. Tartibda; ... uchun
ma'lum darajaga erishish uchun tashkilot quyidagi darajaga ham erishgan bo'lishi kerak.
Dunyo bo'ylab minglab kompaniyalar ushbu ma'lumotlarga ko'ra baholangan
CMMI ramkasi. Ko'pgina tashkilotlar CMMI sertifikatidan tender talablarini belgilash uchun asos sifatida foydalanadilar, ulardan biri AQSh departamentidir.
Himoya.
Mashq: CMMI-ni qabul qilish tizimli asosni ta'minlaydi
dasturiy ta'minotni ishlab chiqish jarayonlarini baholash. Qanday salbiy tomonlari bor?


Tashkilotlar uchun o'zlarini sertifikatlash uchun ko'plab kuchli haydovchilar mavjud bo'lsa-da
CMMI (va boshqa dasturiy ta'minot jarayonlarini takomillashtirish ramkalari) ko'ra, ko'p
qilmaslikni tanlang. Tashqi ko'rinishiga ko'ra, bu teskari samarasi - bu tashkilot
potentsial daromad keltiruvchi dasturiy ta'minotni ishlab chiqish shartnomalari uchun raqobatdan voz kechishi mumkin. Nima uchun bunday bo'lganini tushunish uchun Staples va boshqalar. [126] amalga oshirildi
maxsus sertifikatlashmagan 73 ta tashkilot o'rtasida so'rov o'tkazildi
CMMI-ga (bu 2007-yilda bo'lgan, shuning uchun CMMI-ning 2007-yildan oldingi versiyalariga nisbatan qo'llaniladi)
joriy versiya).
Bir tomondan, ularning topilmalari kutilgandek edi; 35% a'zolar uchun asosiy sabab bu juda qimmat, 25% uchun esa juda qimmat.
vaqt oluvchi. CMMI sertifikati, albatta, ko'p vaqt va kuch talab qiladi. Tashkilot ichidagi biznes jarayonlarini o'zgartirish juda qimmatga tushishi mumkin,
va foydali deb hisoblanmasligi mumkin (hatto bu o'zgarishlar yaxshilangan bo'lsa ham
va uzoq muddatda katta rentabellikka olib kelishi kerak). Asosiy omil ammo, CMMI katta tashkilotlarga qaratilganligi haqiqat edi. 43%
Respondentlar kichik tashkilot sifatida sertifikatlash talab qiladigan qo'shimcha xarajatlarni o'zlashtirish uchun juda yuqori ekanligini ta'kidladilar.
CMMI tizimi tashkilotning dasturiy ta'minotni ishlab chiqish qobiliyatini baholashning yagona usuli emas. Boshqa ramkalar va standartlar mavjud
shunga o'xshash maqsadlarga erishadi. Bularga ISO9001 standarti, Motorola's Six kiradi
Sigma ramkasi, SPICE va Malkolm Baldrijni baholash (MBNQA). Biz
bu erda faqat CMMI-ni qamrab oladi. Boshqa yondashuvlarning (ehtimol biroz eskirgan) umumiy ko'rinishi uchun Kanning dasturiy ta'minot sifati muhandisligi haqidagi kitobiga murojaat qilishingiz mumkin [80].
Biroq, oxir-oqibat, bu muqobil yondashuvlarning barchasi bir xil ildizlarga ega
ishlab chiqarish sanoatidan olingan turli saboqlar. Hamma targ'ib qiladi
rivojlanish jarayonlarini nazorat qilishning kuchayishi (differensiallikni kamaytirish). Ular
ish faoliyatini kuzatib borish uchun o'lchov va ko'rsatkichlardan foydalanishni rag'batlantirish, the
tartib-qoidalarni intizomli qo'llash va jarayonlarni hal qilishga moslash qobiliyati
Muammolar.
3.5 Asosiy fikrlar
• Mahsulot sifati va uning sifatini nazorat qilish qobiliyatiga bog'liq
uni ishlab chiqarish uchun ishlatiladigan jarayonni tanlashda.
• Dasturiy ta'minotni ishlab chiqishning shakllanish yillarida sharshara modeli hukmronlik qildi. U keng qamrovli hujjatlar va rivojlanish g'oyasini o'zida mujassam etgan
bosqichma-bosqich jarayon. Bu moslashuvchan bo'lmagani uchun ko'p qoralangan va ko'pincha bunga olib kelgan
ortiqcha xarajatlar.
• Iterativ va ortib boruvchi (IID) texnikasi sharshara modelidan farq qiladi
mahsulotni ishlab chiqishni uzluksiz, iterativ jarayon sifatida shakllantirish orqali. Ularda bor edi
katta muvaffaqiyatlarga erishdi, ammo kechgacha keng qo'llanilmadi
80-yillar. IID texnikasi ko'proq moslashuvchanlikni taklif qiladi va vaqt bo'yicha boksni osonlashtiradi. IID shakllandi
agile texnikasi uchun asos.
• Jarayonni takomillashtirish ishlab chiqarishni takomillashtirish harakatidan kelib chiqdi
jarayonlar. Ushbu yondashuvlar birinchi navbatda iqtisodiyotning asosiy omili sifatida e'tirof etildi
AQShda ilg'or ishlab chiqarishning paydo bo'lishi bilan muvaffaqiyat qozondi (masalan, Ford
Yig'ish liniyasi).
• Valter Shewhart birinchi bo'lib rivojlanish jarayonlarini o'rganish va takomillashtirishni PDCA tsikli bilan tizimlashtirdi. PDCA tsikli o'z mohiyatiga ko'ra asoslanadi
hozirgi sifatni yaxshilash texnikasi. Shewhartning darslari yanada takomillashtirildi
Yaponiya kompaniyalari tomonidan Yaponiyaning "iqtisodiy mo''jizasi" davrida. Toyota TPS
bugungi ishlab chiqarish va dasturiy ta'minotni ishlab chiqish jarayonlari uchun ko'plab oldingi kursorlarni o'z ichiga olgan.
• Yaponiyada jarayonni takomillashtirish muvaffaqiyati bu sohadagi rivojlanishni ilhomlantirdi
AQSh va Yevropa umumiy sifat menejmenti (TQM) tushunchasi. TQM
bir nechta dasturiy ta'minotga xos jarayonni takomillashtirish ramkalarini ilhomlantirdi, shulardan
CMMI yetakchi misoldir.


• CMMI dasturiy ta'minotni ishlab chiqish uchun jarayonni takomillashtirish asosidir. Bu
keng qo'llaniladi, lekin ko'pincha kichik tashkilotlar tomonidan qo'llaniladi, chunki
sertifikatlashtirish bilan bog'liq qo'shimcha xarajatlar.
• Agile dasturiy ta'minotni ishlab chiqish iterativ, engil dasturiy ta'minotni ishlab chiqish jarayonlari oilasiga tegishli. Ular izlayotgan ma'noda "engil"
sifat uchun mas'uliyatni jarayonning o'zidan ishlab chiquvchilarga o'tkazish. Ko'pchilik
chaqqonlik texnikasi tomonidan qo'llab-quvvatlangan "yaxshi amaliyot" misollaridan ilhomlantirildi
ishlab chiqarish jarayonidagi yutuqlar, masalan, Toyota Pro ishlab chiqarish tizimidagi amaliyotlar orqali.
• SCRUM eng mashhur tezkor usullardan biridir. U yuzma-yuz uchrashuvlarga va takrorlash uchun vaqt bo'yicha "sprint"larga alohida e'tibor beradi.
dasturiy ta'minot tizimining versiyalari.