Tərtibatçılar tapşırıqları qiymətləndirmək üçün hansı üsullardan istifadə edirlər?

Hamıya salam! İnkişafa başlamaq üçün tələb olunan nəzəriyyə çox genişdir. Bəzi mütəxəssislərdə (Java və digər dillərdə backend developers) daha çox, digərlərində isə (məsələn, JavaScript-də frontend developers - React Native) bir qədər azdır. Bununla belə, onların hər ikisi təkcə texniki deyil, həm də “təşkilati” biliklərin böyük ehtiyatına malik olmalıdır. Bu "təşkilati" bilik frontend və backend developers üçün kəsişmə nöqtələrindən biridir. Bu gün mən bu cür qeyri-texniki, təşkilati biliklərin bir tərəfi haqqında - tapşırıqların qiymətləndirilməsi (qiymətləndirmə) haqqında danışmaq istəyirəm. Mən yalnız Agile metodologiyasında (əslində ən populyar hesab olunur) işlədiyim üçün onun alt hissəsində, Scrumda , Scrum kontekstində tapşırıqların qiymətləndirilməsini nəzərdən keçirəcəyəm . Dərhal deyim ki, qiymətləndirmə də adlandırılan qiymətləndirmə çətindir. Şəxsən mənim üçün bir tərtibatçı kimi bu, işin ən çətin/arzuolunmaz tərəflərindən biridir. Tapşırığın qiymətləndirilməsinə təsir edə biləcək bir çox müxtəlif amilləri nəzərə almaq lazımdır. Eyni zamanda, gələcək inkişaf planları sizin proqnozlarınız əsasında qurulacaq.

Əgər reytinqi düzgün almasanız nə etməli?

Tərtibatçı bir işə sonda xərclənəcəyindən daha çox saat sərf edərsə, o, ən yaxşı mütəxəssis olmadığı görünə bilər, çünki qiymətləndirmə çox qeyri-dəqiq idi. Belə desək, göydə barmaq. Eyni zamanda, tərtibatçı proqnozlaşdırılan vaxta sərmayə qoymazsa, o, müştərinin məhsulu/yeni funksiyanı buraxmaq planlarını təhlükə altına qoyur. Bu bir işdir və biznes pul deməkdir və belə bir ponksiyonu çox az müştəri bəyənəcək. Təxmin etməyi sevmirəm, çünki bəzən tapşırığı yerinə yetirmək üçün dəqiq vaxt təyin etmək çox çətindir.

Vaxt necə qiymətləndirilir?

Bir qayda olaraq, qiymətləndirmə saatlarla və ya hekayə nöqtələrində aparılır. Şəxsən mən hekayə nöqtələrində qiymətləndirmə prosesinə daha yaxınam . Saat fiziki bir şeydirsə, səhv edilə bilən bir şeydir, hekayə nöqtələri bir az başqa, daha mücərrəd bir şeydir. Tipik olaraq, proqram təminatı inkişaf qrupları zaman formatında təxminlər verir: saatlar, günlər, həftələr, aylar. Belə vaxt təxminləri ilk növbədə şəxsi təcrübəyə, təxminlərə və ya intuisiyaya əsaslanır. Bu halda, tərtibatçılar sadəcə tapşırığa baxır və bunun nə qədər vaxt aparacağını təxmin edirlər. Nəticədə, onlar çox nadir hallarda dəqiqdirlər, çünki işin başa çatdırılması üçün son tarixə təsir edə biləcək bir çox amil var. Buna görə də, Agile metodologiyasına uyğun işləyən bir çox komanda hekayə nöqtələrindən istifadə edir. Gəlin bunu anlayaq.

Hekayə nöqtələri nədir

Hekayə nöqtəsi, müəyyən bir iş sahəsini (funksionallığı) tam həyata keçirmək üçün lazım olan ümumi səyin qiymətləndirilməsini ifadə edən ölçü vahididir. Yəni bu, belə bir nisbi mürəkkəblikdir . Komandalar işin mürəkkəbliyinə, işin həcminə və risk və ya qeyri-müəyyənliyə əsaslanaraq hekayə nöqtələrini təyin edirlər. Tipik olaraq, bu dəyərlər işi daha kiçik hissələrə bölmək və bununla da qeyri-müəyyənliyi aradan qaldırmaq üçün təyin edilir. Vaxt keçdikcə bu, komandalara müəyyən vaxt ərzində nəyə nail ola biləcəklərini anlamağa kömək edir və onlara növbəti iş sahələrini daha dəqiq planlaşdırmağa kömək edir. Bu, sizə tamamilə zidd görünə bilər, lakin bu abstraksiya əslində olduqca faydalıdır: o, komandanı işin mürəkkəbliyi ilə bağlı daha sərt qərarlar qəbul etməyə sövq edir. Planlaşdırmada hekayə nöqtələrindən istifadə etmək üçün bəzi səbəblərə baxaq:

• vaxt intervallarında qiymətləndirmənin qeyri-dəqiqliyinin qarşısını almaq olar;
• Zamanla təxmin ediləndən fərqli olaraq, əlavə məsrəflər daha yaxşı nəzərə alına bilər: komanda üzvləri ilə müştəri arasında ünsiyyət, müxtəlif komanda müzakirələri və planlaşdırma, eləcə də gözlənilməz hallar;
• Hər bir komanda işi fərqli miqyasda qiymətləndirəcək, yəni onların sürəti (balla ölçülən) fərqli olacaq;
• Hər hekayə nöqtəsini təyin etmək üçün miqyas təyin etməklə, siz çox mübahisə etmədən xalları tez bir zamanda paylaya bilərsiniz.

Hekayə nöqtələrindən necə istifadə edilməməlidir

Təəssüf ki, hekayə nöqtələri çox vaxt başqa məqsədlər üçün istifadə olunur. Hekayə nöqtələri insanları qiymətləndirmək, təfərrüatlı son tarixləri və resursları müəyyən etmək üçün istifadə edildikdə və səhvən performans ölçüsü kimi qəbul edildikdə qüsurlu ola bilər. Bunun əvəzinə, komandalar hər bir tapşırıqda işin həcmini/mürəkkəbliyini başa düşmək və prioritetləşdirmək üçün onlardan istifadə etməlidirlər. Mümkündür ki, daha çətin kimi qiymətləndirilən hissələri sprintin sonuna qədər tamamlamaq üçün əvvəlcə yerinə yetirmək lazımdır , lakin daha asan olanları sonraya itələmək olar. Scrum metodologiyası kontekstində sprintin nə olduğunu xatırlatmağa icazə verin : Bu müddətin nə qədər olması, inkişafın əvvəlində komanda və müştəri arasında razılaşma ilə müəyyən edilir. Bu, iki həftə, bir ay və ya hər hansı digər dövr ola bilər. Bir qayda olaraq, tapşırığın qiymətləndirilməsi sprintin sonuna qədər tamamlanan işin mümkün həcmini planlaşdırmaq üçün sprintin əvvəlində aparılır, tamamlanan iş müştəriyə çatdırıldıqda. Bu, məhsulun inkişafında irəliləyişinizi görməyə, müştəridən rəy almağa və layihənin inkişafını müştərinin vizyonuna uyğun olaraq tənzimləməyə kömək edir. Ancaq yenə də bir az yayınırıq: təxminlərə qayıdaq. Tapşırıqların yalnız bir tərtibatçı tərəfindən qiymətləndirilməsi çox subyektiv olardı. Buna görə də, bir qayda olaraq, bu, komanda işidir. Komanda qiymətləndirməsi üçün kifayət qədər bir neçə üsul var. Bu gün onlardan ən çox istifadə edilənlərə baxacağıq - Scrum poker . Bu texnika bu Scrum pokerinin lideri kimi biri olacaq menecer tələb edir . Bu, Scrum Master və ya PM üzrə ixtisaslaşmış şəxs ola bilər .

Scrum Poker nədir

Scrum poker - və ya planlaşdırma pokeri - razılaşma əldə etməyə əsaslanan qiymətləndirmə texnikasıdır. Əsasən qarşıda duran işin mürəkkəbliyini və ya proqram təminatının hazırlanması zamanı həll ediləcək tapşırıqların nisbi həcmini qiymətləndirmək üçün istifadə olunur. Dərhal qeyd edəcəm ki, Scrum poker inkişafda adi bir təcrübədir və siz onun hansı heyvan olduğunu mütləq bilməlisiniz. Bu proses üçün biz adətən müəyyən bir tapşırığın komanda qiymətləndirilməsini təşkil etməyə imkan verən bir növ proqram və ya vebsaytdan istifadə edirik. Bu necə baş verir? Komanda geridə qalan elementi (yeni tapşırıq, funksionallıq) götürür, mümkün tələləri və onunla əlaqəli digər nüansları qısaca müzakirə edir. Hər bir iştirakçı daha sonra çətinlik dərəcəsini əks etdirən nömrə ilə bir kart seçir. Oh, və təxmin edərkən, istifadə olunan adi seriyalar deyil, Fibonacci nömrələridir . Fibonaççi nömrələri skrum pokerdə çox populyardır , çünki zaman keçdikcə aralarındakı boşluq artır (piramida səviyyələrini xatırladır). Böyük mürəkkəbliyə malik vəzifələr var və az sayda hekayə nöqtəsinə nail olmaq mümkün deyil. Qeyri-adi kartların izahı:

son nöqtələrin naməlum sayı

sonsuz uzun bir iş

fasilə lazımdır

Daha nadir qiymətləndirmə üsulları:

• köynək ölçülərində - S, M, L, XL
• və ya itlərdə - chihuahua, pug, dachshund, bulldog və s. (mənim fikrimcə, bu, tapşırıqları qiymətləndirmək üçün ən qəribə vahiddir =D)

Komanda daha sonra fərqli tərtibatçılar tərəfindən eyni problemə verilən təxminləri müqayisə edir və əgər razılaşırlarsa, əla! Yoxdursa, qiymətləndirmələrdə (arqumentlərdə) fərqlərin səbəblərini müzakirə etmək lazımdır. Bundan sonra biz müştərək hesablamaya gələ bilərik ki, onunla müsbət və ya mənfi hər kəs razılaşacaq. Yaxşı, niyə poker hətta ciddi proqram layihəsini planlaşdırmaq üçün istifadə olunur? Axı bu nədənsə qəribədir. Əslində, bu cür oyunlaşdırma komanda üzvlərini müstəqil düşünməyə sövq edir, onlardan öz nəticələrini komanda yoldaşları ilə eyni vaxtda göstərmələrini xahiş edir. Bu, öz növbəsində, digər komanda üzvlərinin fikirlərindən asılılığın qarşısını alır. Əks təqdirdə, daha az təcrübəli tərtibatçılar daha təcrübəli komanda üzvlərinin qiymətləndirmələrinə baxacaq və onlara etibar edəcəklər ki, bu da öz qiymətləndirmələrinin faydalılığını inkar edəcək. Ancaq nəticələrin eyni vaxtda açılması ilə bu, mahiyyətcə mümkün deyil. Scrum Poker planlaşdırma proqramının nümunəsi Atlassian-dandır .

Tapşırıqların qiymətləndirilməsi nümunəsi

Təsəvvür edək ki, komandanız hekayə nöqtələrində qiymətləndirmə üçün müəyyən bir miqyas təyin edib: Scrum Poker bir tapşırığa başlayır və siz onu belə qiymətləndirirsiniz:

• əvvəllər heç vaxt oxşar funksionallığın tətbiqi ilə işləməmisiniz - +3
• orta ölçülü bir tapşırığın funksionallığı - +2
• tapşırığın həyata keçirilməsi yüksək mürəkkəbliyə malikdir - +3
• bu funksionallıq üçün yazı testlərinin yüksək mürəkkəbliyi - +3

Nəticədə 11 hekayə xalı alırsınız, lakin belə kart olmadığına görə 13 təklif edirsiniz. Başqa bir həmkarınız tapşırığı qiymətləndirir:

• əvvəl oxşar problemlə işləmişdir - +1
• orta ölçülü bir tapşırığın funksionallığı - +2
• tapşırığın icrası orta mürəkkəbliyə malikdir - +2
• bu funksionallıq üçün yazı testlərinin orta mürəkkəbliyi - +2

Nəticədə, o, 7 hekayə xalı alır, lakin Fibonaççi nömrələrində belə bir şey yoxdur və o, mümkün qədər yaxın rəqəmə - 8-ə malik bir kart yerləşdirir. Digər komanda üzvləri, müvafiq olaraq, öz subyektiv baxışlarına əsaslanaraq təxminlər verirlər. Sonra, siz öz nəticələrinizi göstərirsiniz və aşkar edirsiniz ki, demək olar ki, bütün həmkarlarınız 8-i verən bir tərtibatçıdan başqa, demək olar ki, 13-ə qiymət veriblər. Bu zaman ona söz verilir və o, səbəbləri göstərir. Və onlar, məsələn, belədirlər: o, əvvəllər eyni problemlə işləmişdir və bu, göründüyü qədər çətin deyil və sonda digər komanda üzvlərini həllini 13-dən 8-ə dəyişdirməyə inandırır. işarə edərək, kömək edəcəyini söyləyərək, bu işi kim üzərinə götürsə, başa düşəcək. Yoxsa sonda bunu özü edəcək. Ümumiyyətlə, başqalarının onun arqumentlərinə qulaq asıb-dinləməməsinin əhəmiyyəti yoxdur, çünki bu və ya digər şəkildə bu vəzifəyə reytinq veriləcək və komanda növbəti ilə tanış olmağa davam edəcəkdir. İlk dəfə təxminlər, eləcə də növbəti müddət ərzində (sprint) görməyi planlaşdırdığınız işlərin həcminin təxminləri qeyri-dəqiq olacaq. Axı bu hesablamalar dəqiq hesablamalar əsasında aparılır. Bir müddət sonra, təxminən üç aydan sonra komanda tapşırıqları daha dəqiq hesablamağa başlayacaq və komandanın hər sprint üçün yerinə yetirə biləcəyi orta iş həcmi görünəcək. Ancaq bu, işin həcminin ümumi planlaşdırılmasıdır, daha çox vaxta aiddir və bu vəziyyətdə təsir göstərən bir çox müxtəlif amillər ola bilər. Məsələn, tərtibatçılardan biri iki həftəlik tətilə getdi. Yəni, müəyyən bir planlaşdırılmış işin üstündən xətt çəkməlisiniz (planlı funksionallıq). Və ya komandaya yeni bir tərtibatçı gəldi, ancaq ona tam etibar etmək lazım deyil, çünki... onboarding adlanan layihəyə uyğunlaşmaq üçün tələb olunan vaxtı nəzərə almalısınız . Bu, layihənin mürəkkəbliyindən asılı olaraq iki həftə, üstəlik və ya mənfi bir həftə ola bilər. Bu gün üçün hamısı budur, ümid edirəm problemin qiymətləndirilməsi kimi biliyin qeyri-texniki hissəsində sizin biliklərinizi bir az təkmilləşdirdim. Bu mövzuya, eləcə də Scrum-un təfərrüatlarına daha dərindən girmək istəyirsinizsə, sizə Jeff Sazerlandın “SCRUM” kitabını oxumağı tövsiyə edirəm. Nəticələrinə zəmanət verə bilmərəm, çünki bəlkə ondan sonra sizdə Scrum Master olmaq üçün əsəbi bir arzu yaranacaq =D