LayihəLƏrin idarə edilməsi nədir



Yüklə 1,06 Mb.
səhifə25/26
tarix02.01.2022
ölçüsü1,06 Mb.
#36413
1   ...   18   19   20   21   22   23   24   25   26
PMen 1

    Bu səhifədəki naviqasiya:
  • Rollar
Testləşdirici (Tester) – məhsulun funksionallığını, keyfiyyətini və effektivliyini yoxlayır. Layihənin hər bir fazası üçün testlər qurur və icra edir.

  • Kitabxanaçı (Librarin) – layihənin ümumi kitabxanasını yaratmalı və onu daxil etməlidir. Layihənin bütün işçi sənədlərini saxlanılmasına, həmçinin, işçi sənədlərin standartlara uyğunluğuna cavabdehdir.

    Siyahıda göstərilmiş birinci iki mövqe sifarişçiyə və resursları planlaşdıranlara verilmişdir. Layihənin işlənməsi yalnız xarici əlaqələrə malikdir və onlar komanda üzvləri deyillər. Sifarişçi – bu o şəxsdir ki, nəticələrin alınmasına maraqlıdır. Planlaşdırıcı maliyyənin paylanması, firma daxili müxtəlif layihələr üçün əmək və texniki resurslar məsələlərini həll edir. Düzgün qurulmuş təşkilat kimi işdə fəaliyyət göstərən bu şəxslərlə yalnız layihə meneceri təmasda olur.

    Bizim inanmağa imkanımız olacaq ki, nəticələrin alınmasında maraqlı olan real tək şəxs sifarişçi deyil. Layihənin tapşırığına istehsalat sahəsinin heyəti və proqram məhsullarının istifadəçiləri və yaxud gələcək proqram məmulatının genişləndirilməsində və sıxılmasının mümkünlüyünə təsir göstərənlər – işin inisiatorları adlanırlar. (İşin inisiatorları) termini – ingilis sözü “stakeholdes” tərcüməsidir. Ədəbiyyatda onun başqa tərcümələrinə də rast gəlmək olar: işin təşkilatçısı, maraqlı şəxs və hətta aksionerlər. Bəziləri transliterə qaçırlar. Biz hesab edirik ki, hər-hansı bir həddə kiminsə layihəyə və onun nəticələrinə toxunur, onlar işin inisiatorlarıdır. Buna görə də, biz “maraqlı şəxs” terminindən istifadə edəcəyik və kim ki, layihəyə maraq göstərəcək, heç olmasa layihənin inkişafına dolayısı da olsa təsir edəcək, onların hamısını maraqlı şəxs kimi qeyd edəcəyik. Beləliklə, işin inisiatiru özündə maraqlı şəxsləri birləşdirir (xüsusilə, layihəçiləri) və bunun əksi yoxdur. Məsələn, layihənin auksioneri işin inisiatorudur, necə ki, onun marağı layihənin müqəddəratıdır, sözsüz ki, ona təsir edəcək. Onlar haqqında demək lazımdır, nə vaxt menecmentin müzakirəsi layihənin xarici tələbatının təsirinə aiddir. Elə bu planda da sifarişçini işin bütün inisiatorları kimi bərabər təsirli qəbul etmək faydalı olar, hansı ki, tələbatlar və tapşırıq razılaşdırılmaya çıxardılır. Başqa sözlə, orada, harada ki, layihəyə xarici təsiri fərqləndirməmək əlverişlidir, biz abstrakt sifarişçini təyin edirik. Menecerin sifarişçi ilə, planlaşdırıcı və işin digəri inisiatorları ilə qarşılıqlı əlaqə - layihə menecerinin bir-başa vəzifəsidir. Beləliklə, onun üçün bir sıra funksiyalar bağlanılıb, hansı ki, layihə üzərində işlərlə müqayisədə səthidir. Xarici funksiyaların yerinə yetirilməsi təkmilləşmə üçün şərait yaradır. Rollar siyahısından göründüyü kimi, menecerin üzərinə düşən funksiyanın digər dairəsi layihənin layihəçiləri komandasından fəaliyyətdə olan şəxslərlə qarşılıqlı əlaqədə olurlar. Bu, menecerin daxili funksiyasıdır.

    Bəzi hallarda layihə proqramları ilə bağlı olan rollar əhatəsində iki xarici meneceri qoşurlar: sifarişə və satışa görə. Onlardan birincisinin tapşırığı – layihəyə ərizə axınlarını təmin etməli, potensial sifarişçi ilə ilkin kontaktı təşkil etməli; ikincisinin tapşırığı – məhsulun bazara axımını təmin etməkdir. Layihə proqramlarında menecment suallarını məhdudlaşdıraraq, biz onların tərkibinə layihədə fəaliyyət göstərən şəxsi daxil etmirik, haradakı, onların funksiyası işlə ancaq dolayısı bağlıdır. Layihənin işlənməsinə menecerin təsiri sifarişlə qurtarır, nə vaxt ki, layihə menecerində işə ilkin sifariş meydana çıxır, ondan sonra sifarişin mənbəyi əhəmiyyətsiz və yaxud ikinci dərəcəli olur. Satış üzrə menecerin təsiri daha uzunmüddətlidir, ancaq o, layihəyə qoyulan tələbatları daha yaymır, daha doğrusu, işin əvvəlki inisiatorlarının aktivlikləri çərçivəsindən kənara çıxmırlar.

    Layihədən və onun rolunun yerinə yetirilməsindən asılı olaraq layihə iştirakçıları birləşə bilərlər. Son hədd halında – proqramçı layihəni özü üçün işləyir (öz sifarişi ilə), resursların paylanmasını özü planlaşdırır (işin yerinə yetirilmə müddəti, hesablama texnikalarından istifadə etmə və s.), özü layihə qərarlarını qəbul edir (özü-özünü idarə və özünə rəhbərlik edir) və özü işlərlə, ekspertiza və xidmətlərlə məşğul olur. Hətta burada da özün üçün dəqiq başa düşmək lazımdır ki, hər bir konkret halda kimin tapşırığı həll olunur (yəni rolların paylanması). Hətta burada da bəzi anlardan imtina etmək lazımdır, məsələn, heç nə başa düşülməyən sənədlərdən, ümumi fikirdən yox, motivləşdirilmiş tutuşdurulmuş xərclər nəticəsində və əldə edilmişlər baxımından (əldə edilmiş nəticələri gələcək üçün qeyd etməli, əlavə təcrübə və s.). Bu işi sistemsiz səhvlərdən xilas edir, və bu böyük layihələrdə qeyri texnolojiliyin inkişafında da mümkündür.



    Aydındır ki, rolların birləşməsi özbaşına ola bilməz. Bir birləşmə arzu olunmazdır (müxtəlif dərəcədə), digəri neytraldır, üçüncüsü layihə üçün sərfəlidir. Ümumi reqlament birləşmə üçün aşağıdakı prinsipləri təyin edir:

    1. Rolların birləşməsini buraxmaq olmaz, hansılar ki, konfliktlidirlər və yaxud bir-birinə ziddiyyətli maraqdadırlar. Əgər, hər-halda belə birləşmələr istifadə olunursa, onda elə mexanizmə baxmaq tələb olunur ki, hansı ki, ziddiyyəti necə dempferləmək (münaqişəni zəiflətmək üçün qurğu) mümkündür.

    2. Mübahisəli maraqlı müxtəlif insanların rollarının elan edilməsi ziddiyyətlilik baxımından tarazlığı təmin edir.

    3. Layihə iştirakçıları üçün rolların birləşməsinə qaçmaqda əsas məqsəd layihəni işləməkdir, yəni müvafiq işin yerinə yetirilmə müddətinin artmasının məlum olduğu deməkdir. Bu səbəbdən də, onlar üçün buraxıla bilən birləşmə, həmin anda layihənin inkişafı üçün doğurdan da vacibdir (məsələn, bəzi avara hallarda), harada ki, uzun müddət ərzində sabit fəaliyyəti tələb olunmur.

    4. Əgər işçiyə bir neçə rol həvalə olunursa, onda o, həmişə bilməlidir ki, həmin anda o, bunlardan hansını yerinə yetirməlidir.

    Əksər hallarda sifarişçi və resursların planlaşdırıcısı doğurdan da layihədə fəaliyyət göstərən şəxslərlə müqayisədə xarici şəxslər olurlar. Buna görə də bu rolların başqaları ilə birləşməsi bir qədər qeyri-adidir (qəribədir). Hər halda sifarişçinin rolu layihəçilər kollektivinin üzvlərininki kimidir, akkumulyasiya (yığılma, toplanma) baxımından bütün işin inisiatorları son dərəcə faydalıdır. Xüsusilə ekstremal proqramlaşdırma yanaşması bunu vacib hesab edir, istifadəçiyə lazım olan layihənin inkişafı həmişə həmin istiqamətdə zəmanətdə olsun. Haradakı bu yanaşmada işçilərin rollarının fərqlənməsi ikinci plana keçir, onun tərifi ekspertin xüsusi rolunu maddi (əyani, konkret) sahədə ayırmır. Hər şeydən əvvəl onlar hesab edirlər ki, onun funksiyasını sifarişçi yerinə yetirməlidir, hansı ki, bütövlükdə sistemi yoxlamaq üçün testlər tərtib edir (hər halda onların spesifik xüsusiyyətlərini göstərir) və qrupun qalan işçiləri, istifadəçilər tələbatının aktuallığının artması hesabından başa düşürlər ki, onları kodlarda necə ifadə etsinlər. Ekspertin maddilik (əyanilik, konkretlik) baxımından sahəsi bunlardır: o, istifadəçilər fəaliyyətini başa düşməlidir ki, bu fəaliyyətlər qapalı yerlərdə suallara cavab versin, qəbul edilən qərarların aktuallığı kriteriyasında, formaların saxlanılmasında, hansında ki, təqdim olunan vasitə istifadəçiyə təqdim edilməlidir. Hətta sifarişçi roluna ekspert funksiyası yükünü hesaba almasaq da, aydındır ki, sifarişçinin layihəni yerinə yetirən komandaya qoşulması və onun tezliklə kənarlaşdırılmasının elan edilməsi olduqca doğrudur. Artıq bu misaldan görünür ki, müxtəlif rollar arasında funksiyalar sərhədlər nə qədər təmizlənsə də, deməli bu komandada rolların birləşməsidir. Rolların dəqiq təyini, onların sərhədləşməsi və birləşməsi – konkret layihələrin spesifik sahəsidir. Hər halda, tövsiyəni yerində formalaşdırmaq münasibdir, hansı ki, layihələr proqramlarında menecmentin uğurlu və uğursuz təcrübələrinə əsaslanır.

    Öz təyinatına görə layihənin meneceri komandadan ayrılmış olur. O, sifarişçiresurs planlaşdırıcıları ilə qarşılıqlı əlaqədə olmağı öz öhdəsinə götürür, digər tərəfdən – komanda üzvləri arasında işləri paylayır.

    Sonuncu bildirir ki, o, layihənin dekompozisiyası haqqında tam informasiyaya malik olmalıdır. Nəticə kimi, onun rolunun layihə arxitektorunun rolu ilə birləşməsi olduqca tez arzu olunandır. Belə birləşmələr üçün yeganə şəraitin tələbatı dəqiq bilməkdir – fəaliyyətdə olan şəxs nə vaxt və kimin funksiyasını yerinə yetirir.

    Komanda rəhbərlərinin və arxitektorların rollarının birləşmələri tam məhsuldar ola bilər – bu əhəmiyyətli nəticələr verir, nə vaxt ki, komanda öz rəhbərliyi ilə kifayət qədər sıx bağlıdır. Məsələn, əvvəldə olan işlə, yalnız verilmiş layihə üçün dekompozisiya tapşırığının həddən artıq çətin olmamağı şərti ilə. Komanda rəhbərinin və menecerin rollarının birləşmələri buraxıla biləndir, ancaq o vaxt ki, bu rolların məqsədli qurğularının ziddiyyətliliyi başa düşülür və qəbul edilir: komandanın rəhbəri o şəraitdə fəaliyyət göstərir ki, hansı ki, menecer tərəfindən formalaşdırılır. Komanda rəhbərinin və hər hansı alt sistem layihəçisinin rollarının birləşdirilməsi arzu edilməzdir. Elə bu da, onların rol maraqlarının ziddiyyətli olmasına səbəb olur.



    • Alt sistem layihəçisi üçün keyfiyyət kriteriyası istifadə etmə sahəsində durur, o, tapşırığın qoyulmasına can atmalıdır, istifadə olunma tələbatını maksimal həddə tam qane etməlidir, komanda rəhbəri komandanı artıq xarici təsirlərdən qorumalıdır, o cümlədən, istifadəçilər tələbatının təsirindən.

    • Komanda rəhbəri tapşırığı həyata keçirilmiş anlayışından verməlidir, hansı ki, bütövlükdə sistemdən alt sistem məfhumundan prinsipial olaraq fərqlənir və istifadə etmə səviyyəsinə müvafiqdir. Bu səviyyə layihəçilər tərəfindən izlənir.

    • Layihəçinin və rəhbərin rollarının ayrılması istifadəçinin və altsistemi işləyənin tarazlıq baxışına köməklik edir.

    Əgər komanda rəhbəri və altsistem layihəçisi çarpaz birləşməsindən istifadə edirlərsə, onda onların rol maraqlarında daha bir ziddiyyət baş verir: rəhbərdə “öz” komponentinin xeyrinə üstünlük vermə ola bilər və nəticədə, layihədə onu təşkil edənlərdən ayrılanın xeyrinə bütövlükdə disbalans mümkündür, hansı ki, menecerin əlavə səyi hesabına kompensasiya etmək zərurətinə başa gəlir.

    Elə həmin səbəbdən də menecerlə layihə işləyənin rollarının birləşməsi də buraxıla bilməz. Burada qadağa daha ciddidir, nə qədər ki, menecerin nəzarət funksiyası layihəçinin tapşırığının icraedicisi kimi bir araya sığışa bilməyəndir. Hətta o hallarda ki, nə vaxt ki, menecer özünün birbaşa vəzifəsini icra edib qurtardıqdan sonra boş vaxtı qaldıqda belə ona, layihəçiyə “kömək” etmək olmaz. Daha yaxşı olardı ki, özünə başqa iş tapasan, xüsusilə də başqa layihədə layihəçi rolu.

    Həmin vaxt müxtəlif işçilərin rollarının birləşməsi - əksəriyyət layihələr üçün adi işdir. O, işin icraçılar arasında paylanmasının bir hissəsidir. Bu tapşırığı əsas arxitektura vəziyyəti təsdiq edildikdən sonra komanda rəhbəri və menecer birlikdə həll edirlər. Həll etmə üsulu komandanın necə formalaşmasından asılıdır. Əgər işlər hazır komandaya həvalə edilirsə, onda rəhbərin rolu artır, menecer isə yalnız onun təklifini təsdiq edir. Nə vaxt ki, layihə üçün komanda təşkil edilir, menecerin funksiyası iş üçün kadrların seçimində xüsusi çəkisi artır. Ancaq ixtiyari halda müxtəlif işçilərin rollarının birləşməsində işçilərin peşə səviyyəsini nəzərə almaq, onların digər fərdi xüsusiyyətlərinə üstünlük vermək lazımdır. Onu da bilmək lazımdır ki, fəaliyyət göstərən bir nəfərə bir neçə iş ayırdıqda tapşırığın bir cinsli olmasına və onların müqayisəli üstünlüklərini göstərməyə çalışmaq lazımdır.

    Digər rolların birləşməsi də buraxıla biləndir. Beləliklə, çox tez-tez sənədlərin yaradılması layihəni icra edən bütün işçilər arasında paylanılır, ancaq komanda rəhbərimenecerə sənədlərin inteqrasiyası (birləşməsi) tapşırığı düşür. Layihələrin təhlil edilməsi üçün kitabxanaçının funksiyasını onun fərdi tapşırığına müvafiq olaraq düzəlişlərlə layihə işçilərindən birinə həvalə etmək olar. İnterfeys istifadəçisi mütəxəssisi ola bilər ki, məsələn, menecer, necə ki, şəxsən o özü sifarişçi ilə əlaqəni həyata keçirir (verilmiş halda sifarişçi ya özü istifadə edicidir, ya da proqram məmulatının istifadəçisinin nümayəndəsi kimi daxil olur).

    Nadir hallarda interfeys mütəxəssisi və maddilik sahəsi ekspertinin rollarının birləşməsi effektiv olur. Buna səbəb – müxtəlif baxış bucaqlarının olmasıdır, hansının ki, altında sistemə baxılır. Sistem eksperti üçün hər şeydən əvvəl strukturlaşdırmış funksiya dəstəsi təqdim edilir, hansı ki, istifadəçi fəaliyyətinin saxlanılmasını təmin edir, ancaq bu funksiyaların aktivləşdirmə idarə üsulu ikincidir. Nəticə kimi, interfeysin belə aspektlərinə diqqət yetirməmək olar, digər sistemlərlə necə birləşmələri, toplanmış standartların qeydiyyatı və s. Müzakirə olunan rolların birləşməsinin effektivliyi o zaman mümkündür ki, əgər layihədə interfereys tədqiqatlarının yüksək olmayan zərurət olsun, ancaq maliyə sahəsi eksperti interferfeys təşkilatında kifayət qədər kvaliflifikasiyalı (ixtisaslı) olur. Həmişə olduğu kimi, burada da birləşmə üçün reqlamentin prinsiplərinə ciddi əməl etmək lazımdır: onu dəqiq bölmək lazımdır ki, hansı rolu həmin anda işçi yerinə yetirməlidir.

    Maddi sahə ekspertinin rolu layihə işçiləri üçün yararlı ola bilər, belə ki, əlavə olaraq onun xüsusi probleminin həllində başqa kriteriyalar verir. Lakin, hərdən bir bu əlavə rol əməkdaşı hədsiz yükləyir və bunun nəticəsi kimi layihə müddətinin və yaxud mərhələsinin uzanması təhlükəsi yaranır. Bunu həmçinin layihə işləyənlərin və interfereys üzrə mütəxəssislərin rollarının birləşməsinə də aid etmək olar. Ancaq burada birləşmə xüsusilə layihəçilərə daha məqsədəuyğundur, hansılara ki, interfeys suallarına toxunan tapşırıqlar verilir. Səbəb tamamilə aydındır: layihəçi və interfereysin keyfiyyəti ilə maraqlanan şəxs arasında əlavə bir dəstənin olmasını kənar edir.

    Testləşdirici barəsində bəzi izahatlar vacibdir. Testləşdiricini iki növ üzrə fərqləndirmək lazımdır: öz sərbəstlik mahiyyətinə görə modulların testləşdirilməsi və təqdim olunan funksiyaların testləşdirilməsi, nə vaxt ki, sistemin ayrı aspektinin iş qabiliyyəti yoxlanılırsa kompleksli (funksiyaların birgə yerinə yetirilməsinin yoxlanılması) və sərbəst (sərbəst) ola bilər. Birinci halda testləşdiricinin tapşırığını təkcə təyin olunmağa görə biliyin olmamağına görə yerinə yetirmək mümkün deyil və həm də o, yoxlanılan modulun strukturudur. Bunu ən yaxşı araşdıran modulu hazırlayandır, deməli, bu modul məxsusi onun üçündür və düzəltməlidir. İkinci halın sərbəst testləşdirilməsi, əslində modulun iş qabiliyyətinin yoxlanılmasının digər tərəfi müəyyən edilmiş funksiyanın həyata keçirilməsidir. Əksər hallarda, onu modulun testləşdirilməsindən fərqləndirməyə ehtiyac olmur. Ona görə də, elə burda da işçinin fəaliyyəti haqqında məntiqli danışmaq lazımdır. Hər iki halda özünü testləşdirmə işçi üçün layihədə əlavə rol deyil, tez-tez onun sərbəst sazlama çərçivəsində professional vəzifəsidir.

    “Sərbəst” testləşməni necə təmin etməli? Ən ağıllı üsul - faktlara əsaslanan testləşmədir, daha doğrusu testlərin yaradılması modulların kodlaşdırılmasından əvvəl olmalıdır, sonra yox. Bu ekstremal proqramlaşdırmanın tələbatlarından biridir və digər layihələrin idarə edilməsində başqa üsullar kimi yayıla bilər. Proqramçıların nişanlanmasın haqqında bəzi terminlər yaranmağa başlayıb, hansılar ki, işin hazırlanmasına qədər testlər yazmağa vərdiş ediblər: “testlərə yoluxmuş”lar adlandırılır və aydın olur ki, bu “xəstəlik” ümumilikdə prosesi sürətləndirir. Bəzi müəlliflər (Bek 4) kitablarında göstərirlər, proqram layihəsini faktlara əsaslanan testlərin köməyi ilə necə yerinə yetirmək olar, işləyib hazırlama prosesi və onun nəticələri üçün hansı üstünlüyə malikdir.

    Başqa üsul, faktlara əsaslanan testləşməyə heç bir ziddiyyət yaratmır – çarpaz testləşmə, nə vaxt ki, layihənin müstəqil komponentlərinin işçiləri bir-birinin funksionallığını testləşdirirlər. Burada layihəçilər və testləşdiricilərin rollarının çarpaz birləşməsini demək olar, harada ki, çarpaz testlərin yerinə yetirilməsi üçün yoxlanılan modul haqqında müxtəlif mülahizələr olsun.

    Təqdim olunan funksiyanın dolğun və maraqlı kompleks testləşmə tapşırığı hər şeydən əvvəl sifarişçi ilə bağlanılır, hansı ki, bu barədə tələb olunan bütün sənədləri vermək qabiliyyətinə malikdir. Layihə komandasında olmayaraq fəaliyyət göstərir, o, yoxlamanı təşkil etmə qabiliyyətinə malikdir, doğurdan da layihə işçiləri və kriteriyalar qarşısında müstəqildir. Lakin, hər şeydən əvvəl sifarişçinin testi düzgün qurmağa imkanı yoxdur. Adətən, onun üçün maksimum – istifadə olunan halın spesifikasiyasıdır, hansı ki, yoxlanışa ehtiyacı var. İstifadəçilik fəaliyyətində sifarişçinin materialına avtomatlaşdırma üçün təyin olunmuş proqram, kompleks testləşdirmə üçün informasiya bazası kimi baxılır. Bu bazanın yaradılmasında maddi sahənin ekspertinin bir başa funksional vəzifə borcudur ki, o da, layihəni işləyənlər tərəfindən çıxış edir, layihənin inkişaf istiqamətində oriyentirini təmin edir. Layihədə onun tapşırıqlarından biri – istifadəçinin sistemlə işinin rekonstruksiyasıdır, hansından ki, təqdim olunan funksiyanın yoxlanılması üçün real kompleks testlər çıxarılır. İş şəraitinə testlərin uyğunlaşdırılması, daha doğrusu, təqdimat o halda olmalıdır ki, boş sahələrin buraxılması və analizi layihəçilərdən minimal güc, testlərin təsnifatını tələb etsin və s. – bu trestçinin layihə komandasının üzvü kimi əsas tapşırığıdır. Onun əlavə tapşırığı yeni texniki köməklə və kompleks testləşdirmənin saxlanılması, testləşdirmə protokollarının aparılması və test arxivlərinin yaradılması ilə bağlıdır.

    “Sifarişçi, maddi sahənin eksperti, testləşdirici” rollar zəncirində ziddiyyətli maraqlar yoxdur, ona görə də, o dəqiqlik anına qədər ki, layihəyə görə müqayisədə sifarişçi kənar şəxs hesab edilir və burada rolların birləşmələri özünü doğrultmuşdur. O ki, qaldı ekstremal proqramlaşdırmaya, prinsip kimi layihə işçiləri qrupuna sifarişçinin daxil edilməsi elan edilmişdir, ancaq bu komandada sifarişçinin nümayəndəsinin təqdim olunmasını göstərir. Başqa sözlə, əlbəttə ki, qismən sifarişçinin səlahiyyətində maddi sahənin ekspertini əlavə nəzərdə tutur. Verilmiş sxemin məhsuldarlığı tam aydındır. Bundan başqa, onu müvəqqəti yoxlanılmış hesab etmək olar: bu sxemlə əvvəlki dövrdə (sovet dövründə) bütün proqramçılar kollektivi işləmişlər, hərbi sahənin layihələrini həyata keçirmişlər. Sifarişçinin nümayəndəsinin işin həlledici anlarında açıq-aydın iştirakı yaxşı nəticələr verir, ancaq bir şəraitdə: əgər sifarişçi öz işini kontrol-nəzarətçi funksiyasına gətirib çıxarmırsa. Buna baxmayaraq, onun mənsəb (karyera) maraqları layihənin uğurunda tez-tez kollektivlə düzgün münasibətlərin işlənməsinə imkan yaradır, nəinki işə maneçilik törədir (o da tez-tez baş verir ki, onu ekstremal layihəçilər yaddan çıxarmamalıdırlar).

    Testləşdirmə haqqında yuxarıda deyilənlərin hamısı, təkcə proqram məmulatlarının kodlarından başqa layihədə alınmış bütün nəticələrin yoxlanılması üçün paylanılmalıdır. Beləliklə, testləşdiricinin rolu fəaliyyətlə bağlıdır, hansı ki, bütün səviyyələrdə qəbul edilmiş qərarların düzgünlüyünü təsdiq etməyə imkan verir: spesifikasiyanın işlənməsinin daxil olması ilə (onlar işin inisiatorlarının tələbatlarına cavab verirmi), dekompozisiyanın qurulmasına (layihə arxitektorunun inkişafı üçün optimallıq verirmi), sənədlərin təşkil edilməsi (sistem haqqında yazılmayanları tələb etməyən istifadəçilərin işini buraxırmı), həmçinin, digər işçi məhsullarının işlənməsi, proqram məmulatlarının müşayiəti. Layihəçi üçün məhsulun xarici qiymətləndirmə üsulu kimi testləşdirilməsi olmaz. Ona görə də, tez-tez deyirlər ki, o, layihədən kənara çıxarılmalıdır. Göründüyü kimi, bu səbəbdən ekstremal proqramlaşdırma üçün xarici testləşməni sifarişçinin işi ilə bağlayırlar, hansı ki, layihə komandasının üzvüdür. Onda, sifarişçi və testləşdiricinin rollarının birləşməsi mümkündür və bu yaxşı nəticəyə gətirib çıxarır.



    Müzakirənin yekunu kimi layihədə iştirak edənlər üçün rolların birləşməsinin qısa xarakteristikası cədvəl 2.1-də verilir və menecment üçün zəmanət kimi baxıla bilər. Aydındır ki, ixtiyari layihə üçün bunu absolyutlaşdırmaq olmaz. Bir layihədə rolların paylanmasını ciddi qeyd etmək lazım deyil. Bundan başqa, rolların paylanmasına bir alət kimi baxmaq olar, hansının ki, köməyi ilə menecer kollektivi idarə edə bilər. Əgər bu alət ağılla istifadə edilsə, onda layihə iştirakçılarının fərdi xüsusiyyətlərinə uyğun olaraq əmək bölgüsünü daha effektli aparmağa nail olunar.
    Cədvəl 2.1.

    Layihədə fəaliyyət göstərən rollar və rol birləşmələri

    Rollar



    Yüklə 1,06 Mb.

    Dostları ilə paylaş:
  • 1   ...   18   19   20   21   22   23   24   25   26




    Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azkurs.org 2024
    rəhbərliyinə müraciət

    gir | qeydiyyatdan keç
        Ana səhifə


    yükləyin