Dasturiy injiniringning tezkor usullari kodni ishlab chiqishga qaratilgan. Ular kodni ishlab chiqish bilan bevosita bog'liq bo'lmagan hujjatlar va jarayonlarni minimallashtiradi va loyiha hujjatlariga asoslangan aloqa o'rniga jamoa a'zolari o'rtasidagi norasmiy aloqa muhimligini ta'kidlaydi. Sifat, tezkor ishlab chiqishda kod sifati va yuqori sifatli kod ishlab chiqarilishini ta'minlash uchun refaktoring va sinovga asoslangan ishlab chiqish kabi amaliyotlardan foydalaniladi.
Agile ishlab chiqishda sifat menejmenti hujjatga asoslangan emas, balki norasmiydir. Bu sifat madaniyatini o'rnatishga tayanadi, bunda jamoaning barcha a'zolari dasturiy mahsulotlar sifati uchun mas'uliyatni his qilishadi va sifatni saqlab qolish uchun choralar ko'rishadi. Agile hamjamiyati ISO 9001da aks ettirilgan standartlarga asoslangan yondashuvlar va sifat jarayonlarining byurokratik yuki sifatida ko'rgan narsaga tubdan qarshi .
Agile rivojlanishda sifat menejmenti rasmiy hujjatlarga emas, balki umumiy yaxshi amaliyotga asoslanadi. Ushbu yaxshi amaliyotga ba'zi misollar:
oʻtishdan oldin tekshiring. Dasturchilar kodni qurish tizimiga kiritilishidan oldin boshqa jamoa aʼzolari bilan oʻzlarining kod koʻrib chiqishlarini tashkil qilish uchun javobgardirlar.Qurilishni hech qachon buzmang. Jamoa a'zolarining tizimni umuman ishlamay qolishiga olib keladigan kodni tekshirishlari qabul qilinishi mumkin emas. Shuning uchun, odamlar o'zlarining kod o'zgarishlarini butun tizimga nisbatan sinab ko'rishlari va bu kodlar kutilganidek ishlashiga ishonch hosil qilishlari kerak. Agar qurilish buzilgan bo'lsa, mas'ul shaxs muammoni hal qilishga birinchi o'rinni berishi kutiladi.
Muammolarni ko'rganingizda ularni tuzating. Tizim kodi jismoniy shaxslarga emas, balki jamoaga tegishli. Shuning uchun, agar dasturchi boshqa birov tomonidan ishlab chiqilgan kodda muammolar yoki noaniqliklarni aniqlasa, u bu muammolarni dastlabki ishlab chiquvchiga qaytarish o'rniga to'g'ridan-to'g'ri tuzatishi mumkin.
Agile jarayonlar kamdan-kam hollarda rasmiy tekshirish yoki ko'rib chiqish jarayonlaridan foydalanadi. Scrum-da ishlab chiqish guruhi har bir iteratsiyadan keyin yig'ilib, sifat masalalari va muammolarni muhokama qiladi . Jamoa yuzaga kelgan har qanday sifat muammolarini oldini olish uchun ish uslubiga o'zgartirishlar kiritish to'g'risida qaror qabul qilishi mumkin. Yangi tizim funksiyalarini qo'shishdan ko'ra, sprint davomida refaktoring va sifatni yaxshilashga e'tibor qaratish uchun jamoaviy qaror qabul qilinishi mumkin .
Kodlarni ko'rib chiqish shaxslarning javobgarligi bo'lishi mumkin (ro'yxatdan o'tishdan oldin tekshirish) yoki juft dasturlashdan foydalanishga tayanishi mumkin. Men 3 -bobda muhokama qilganimdek , juftlik dasturi bu ikki kishi kod ishlab chiqish uchun mas'ul bo'lgan va unga erishish uchun birgalikda ishlaydigan yondashuvdir. Shuning uchun shaxs tomonidan ishlab chiqilgan kod doimiy ravishda boshqa guruh a'zosi tomonidan tekshiriladi va ko'rib chiqiladi. Ikki kishi kodning har bir satriga qaraydi va uni qabul qilishdan oldin tekshiradi.
Juftlik dasturlash dasturni chuqur bilishga olib keladi, chunki ikkala dasturchi ham rivojlanishni davom ettirish uchun dasturni batafsil tushunishi kerak. Ushbu bilim chuqurligiga ba'zan boshqa tekshirish jarayonlarida erishish qiyin, shuning uchun juft dasturlash rasmiy tekshiruvlarda ba'zida aniqlanmaydigan xatolarni topishi mumkin. Biroq, jalb qilingan ikki shaxs tashqi tekshiruv guruhi kabi ob'ektiv bo'la olmaydi, chunki ular o'z ishlarini tekshiradi. Potentsial muammolar:
O'zaro tushunmovchiliklar juftlikning ikkala a'zosi ham tizim talablarini tushunishda bir xil xatoga yo'l qo'yishi mumkin. Munozaralar bu xatolarni kuchaytirishi mumkin.
Juftlik obro'si Juftliklar xatoliklarni qidirishni istamasligi mumkin, chunki ular loyihaning rivojlanishini sekinlashtirishni xohlamaydilar.
Ish munosabatlari Er-xotinning kamchiliklarni aniqlash qobiliyati ularning yaqin ish munosabatlari bilan va'da qilingan bo'lishi mumkin, bu ko'pincha ish sheriklarini tanqid qilishni istamaslikka olib keladi.
Agar mijoz yirik kompaniya bo'lsa, u o'zining sifat menejmenti jarayonlariga ega bo'lishi mumkin va dasturiy ta'minotni ishlab chiquvchi kompaniya taraqqiyot haqida ushbu jarayonlarga mos keladigan tarzda hisobot berishini kutishi mumkin. Shu sababli, ishlab chiqish guruhi mijoz tomonidan talab qilinadigan rasmiy sifat rejasi va sifat hisobotlarini ishlab chiqishi kerak bo'lishi mumkin.
Rivojlanishda bir nechta geografik taqsimlangan jamoalar, ehtimol turli kompaniyalardan ishtirok etsa, norasmiy aloqalar amaliy bo'lmasligi mumkin. Turli kompaniyalar sifat menejmentini tanlashga har xil yondashuvlarga ega bo'lishi mumkin va siz ba'zi bir rasmiy hujjatlarni ishlab chiqishga rozi bo'lishingiz mumkin.
Uzoq muddatli tizimlar uchun rivojlanishda ishtirok etadigan jamoa vaqt o'tishi bilan o'zgaradi. Hujjatlar bo'lmasa, yangi jamoa a'zolari nima uchun rivojlanish bo'yicha qarorlar qabul qilinganligini tushunish imkonsiz bo'lishi mumkin.
Binobarin, tezkor usullarda sifat menejmentiga norasmiy yondashuv sifatni boshqarish bo'yicha ba'zi hujjatlar va jarayonlarni joriy qilish uchun moslashtirilishi kerak bo'lishi mumkin . Umuman olganda, bu yondashuv iterativ rivojlanish jarayoni bilan birlashtirilgan. Dasturiy ta'minotni ishlab chiqish o'rniga, sprint yoki iteratsiyalardan biri asosiy dasturiy ta'minot hujjatlarini ishlab chiqishga qaratilishi kerak
