Proqram təminatının inkişafı metodologiyaları

Salam. Son iki müsahibədə məndən metodologiyalar haqqında soruşdular. Bu ən vacib və ya çətin sual deyil, amma cavab üçün bir fırıldaqçı vərəqinin olması gözəl olacaq. Bu yazıda mən bir inkişaf metodologiyasının nə olduğu barədə fikir verməyə və şəxsən tanış olduğum və ya soruşulanları müqayisə etməyə çalışacağam. Proqram təminatının hazırlanması metodologiyası konkret məhsulun necə hazırlanacağını təsvir edən bir prosesdir, yəni komandanın inkişafının təşkili yollarından biridir. Belə bir prosesin çoxlu müxtəlif modelləri var, hər biri öz yanaşmasını təsvir edir və onların arasında hər bir layihədə istifadə edilməli olan birinin olduğunu söyləmək olmaz, hər şey sırf situasiyadır. Onlardan üçünü daha ətraflı nəzərdən keçirməyi təklif edirəm.

Şəlalə

Şəlalə (şəlalə, şəlalə) ən qədim metodologiyalardan biridir və növbəti mərhələ başlamazdan əvvəl hər biri tamamlanmalı olan bütün mərhələlərin ciddi ardıcıllıqla həyata keçirilməsini nəzərdə tutur. Yəni növbəti mərhələyə keçid əvvəlki ilə bağlı işlərin tam başa çatdırılması deməkdir. Şəkil göstərir ki, əvvəlcə tapşırığı təhlil edirik (sənəd tapşırıqları, çətinlikləri müzakirə edirik), sonra dizayn baş verir (bu mərhələdə layihə strukturu formalaşır), sonra kodlaşdırma və sınaqdan keçir. Sonrakı mərhələlər üçün geri qaytarılmır. Tələblərin əvvəlcədən məlum olduğu və onların dəyişmə ehtimalının az olduğu kiçik layihələrdə belə bir sistemdən istifadə etmək tövsiyə olunur. Üstünlüklər:

• Hər mərhələdə tam və ardıcıl sənədlər;
• İstifadə rahatlığı;
• Sabit tələblər.
• Büdcə və son tarixlər əvvəlcədən müəyyən edilmişdir

Qüsurlar:

• Böyük miqdarda sənədlər;
• Çox çevik sistem deyil;
• Müştəri məhsulun demo versiyasına baxa bilməz;
• Bir addım geri çəkilmək mümkün deyil.

Scrum

Scrum, bütün prosesi iterasiyalara bölməyə əsaslanan bir proqram inkişaf sistemidir, burada hər birinin sonunda komanda məhsulun demo versiyasını təqdim etməyə hazırdır. Şəkil göstərir ki, komanda paralel olaraq inkişafın bütün mərhələlərini keçir, bu da bizə hər təkrarlamanın sonunda layihənin bitmiş hissəsinə sahib olmağa imkan verir. Metodologiyanın mahiyyətini sadə sözlərlə qısaca izah etməyə çalışacağam, lakin burada çoxlu terminlər var. Məncə, ən başlıcası mahiyyəti dərk etməkdir və terminlər təcrübə ilə yadda qalacaq. Bütün inkişaf sprintlərə bölünür (tez-tez 2-3 həftə). Bütün inkişaf dövrü və hər bir sprint üçün ayrıca geriləmə (tapşırıqların siyahısı) var . Hər tapşırığın öz hekayə nöqtəsi var (çətinlik reytinqi). Prosesdə hər bir iştirakçının rolu var:

• Scrum komandası bir layihə üzərində işləyən komandadır (inkişafçılar, sınaqçılar, dizaynerlər).
• Scrum Master, Scrum prinsiplərinə əməl olunmasını təmin edən şəxsdir.
• Məhsul sahibi - müştəri.

Bu sistemdə diqqət ünsiyyətə verildiyi üçün çoxlu sayda mitinqlər var:

• Stand-up qısa görüşdür, hər gün keçirilir, bütün komanda üzvləri iştirak edir və hər bir iştirakçı 3 suala cavab verir: nə etdin? Bu nə edəcək? Bəs blokerlər hansılardır?
• Planlaşdırma – sprintin əvvəlində keçirilir və bu iclasda növbəti sprintdə hansı tapşırıqların yerinə yetirilməli olduğu müəyyən edilir.
• Retrospektiv sprintin sonunda keçirilir və onun mahiyyəti nəyin yaxşı edildiyini və nəyin yaxşılaşdırıla biləcəyini tapmaqdır.

Üstünlüklər:

• Müştəri inkişaf prosesi zamanı nəticəni müşahidə edə bilər.
• İnkişaf prosesinə gündəlik nəzarət.
• İnkişaf zamanı düzəlişlər etmək bacarığı.
• Bütün komanda üzvləri ilə yaxşı qurulmuş ünsiyyət.
• Kiçik miqdarda sənədlər.

Qüsurlar:

• İnkişaf üçün tələb olunan əmək və dəyəri qiymətləndirmək çətindir
• İnkişaf başlamazdan əvvəl ən böyük darboğazları müəyyən etmək çətindir.
• Hər kəsi digər komanda üzvlərinin inkişafına cəlb etmək ehtiyacı.

Kanban

Kanban, komanda tapşırıqlarının yerinə yetirilməsi prosesinin vizuallaşdırılması üzərində qurulmuş bir sistemdir. Bu sistemdə əsas ideya hal-hazırda davam edən tapşırıqların sayını azaltmaqdır (“davam etməkdə” sütununda).Scrum-da komanda sprintləri uğurla tamamlamağa yönəlib, Kanbanda isə tapşırıqlar birinci yerdədir. Əsas funksionallığın artıq işlənib hazırlandığı və minimal təkmilləşdirmələrin və səhvlərin aradan qaldırılmasının qaldığı dəstək mərhələsində olan layihələr üçün yaxşıdır. Kanbanda tapşırıqlar fərdi şəkildə təqdim olunur. Tapşırıq, digər tapşırıqlardan asılı olmayaraq, lövhədə bütün mərhələlərdən keçir və tamamlanan kimi müştəriyə göstərilə bilər. Kanban lövhəsi hər biri ayrıca inkişaf prosesini təmsil edən sütunlardan ibarətdir. Bəzi sütunlar (məsələn, davam edir) orada ola biləcək tapşırıqların sayına məhdudiyyətlər qoyur. Bu, tapşırıqların bölüşdürülməsində problemli sahələri asanlıqla və tez tapmağa kömək edir. Şəkildə belə sadə bir lövhənin nümunəsi göstərilir. Sütunların və adların sayı dəyişə bilər, lakin mən ən ümumi olanları adlandıracağam:

• Ediləcək - yerinə yetirilməli olan işlərin siyahısı
• Davam edir – hazırda üzərində işlənilən vəzifələr
• Kod baxışı – tamamlanmış və baxılmaq üçün göndərilmiş tapşırıqlar
• Testdə - sınaq üçün hazır tapşırıqlar
• Tamamlandı - tamamlanmış tapşırıqlar.

Üstünlüklər:

• İstifadə rahatlığı.
• Vizuallaşdırma (darboğazları tapmağa kömək edir, başa düşməyi asanlaşdırır)
• Prosesin özündə yüksək komanda iştirakı.
• İnkişafda yüksək çeviklik.

Qüsurlar:

• Qeyri-sabit tapşırıq siyahısı.
• Uzunmüddətli layihələrdə istifadə etmək çətindir.
• Sərt son tarixlər yoxdur.

Proqram təminatının inkişafı metodologiyası haqqında yekunda

Fikrimcə, rəhbər vəzifələrdə çalışan və ya onlara can atan insanlar proqram təminatının hazırlanması metodologiyalarını hərtərəfli başa düşməlidirlər, lakin hər kəsin ən azı əsasları başa düşməsi məsləhətdir. Bu, inkişaf prosesinin tərkib hissəsidir və təkcə İT sahəsində istifadə olunmur. Məqaləmi oxumağa vaxt ayırdığınız üçün təşəkkür edirəm, ümid edirəm ki, faydalı oldunuz. Yalnız əsas məqamları mümkün qədər aydın və qısa şəkildə təsvir etməyə çalışdım, buna görə məqalə tam deyil. Bu barədə fikirlərinizi eşitməkdən və suallarınızı cavablandırmaqdan şad olaram. Hər vaxtınız xeyir!