🥇İT layihəsində komandada iş axınının təşkili

Salam dostlar. Çox vaxt, xüsusən də autsorsingdə eyni mənzərəni görürəm. Müxtəlif layihələr üzrə komandalarda aydın iş axınının olmaması.

Ən əsası odur ki, proqramçılar müştəri ilə və bir-biri ilə necə ünsiyyət qurmağı başa düşmürlər. Keyfiyyətli məhsulun inkişafı üçün davamlı prosesi necə qurmaq olar. İş gününüzü və sprintlərinizi necə planlaşdırmalısınız.

Və bütün bunlar son nəticədə pozulmuş müddətlər, əlavə iş vaxtı, kimin günahkar olduğuna dair daimi hesablaşmalar və müştərilərin narazılığı - hər şeyin hara və necə getməsi ilə nəticələnir. Çox vaxt bütün bunlar proqramçıların, hətta bütün komandaların dəyişməsinə səbəb olur. Müştərinin itirilməsi, reputasiyasının pisləşməsi və s.

Bir vaxtlar bütün bu ləzzətlərin olduğu belə bir layihəyə qoşuldum.

Heç kim layihənin məsuliyyətini öz üzərinə götürmək istəmədi (böyük xidmət bazarı), dövriyyə dəhşətli idi, müştəri sadəcə cırıb atdı. Baş direktor birtəhər mənə yaxınlaşıb dedi ki, sən lazımi təcrübən var, ona görə də kartları sənin əlindədir. Layihəni özünüz üçün götürün. Əgər pislik etsəniz, layihəni bağlayacağıq və hamını qovacağıq. Çıxacaq, sərin olacaq, sonra ona rəhbərlik edin və uyğun gördüyünüz kimi inkişaf etdirin. Nəticədə layihə üzrə komanda lideri oldum və hər şey mənim çiynimdə oldu.

Etdiyim ilk iş, o vaxtkı baxışıma uyğun gələn iş axınını sıfırdan tərtib etmək və komanda üçün iş təsviri yazmaq oldu. Onu həyata keçirmək asan deyildi. Ancaq bir ay ərzində hər şey düzəldi, tərtibatçılar və müştəri buna öyrəşdilər və hər şey sakit və rahat keçdi. Komandaya bunun sadəcə bir stəkanda fırtına deyil, vəziyyətdən real çıxış yolu olduğunu göstərmək üçün komandadan xoşagəlməz rutini aradan qaldıraraq maksimum öhdəlik götürdüm.

Artıq bir il yarım keçdi və layihə əlavə vaxt olmadan, "siçovul yarışları" və hər cür stress olmadan inkişaf edir. Köhnə komandada kimsə belə işləmək istəmədi və getdi, əksinə, kimsə həqiqətən işə qarışdı ki, şəffaf qaydalar ortaya çıxdı. Ancaq nəticədə, komandadakı hər kəs çox motivasiyalıdır və nəhəng layihəni həm ön, həm də arxa hissə ilə tam şəkildə bilir. Həm kod bazası, həm də bütün biznes məntiqi daxil olmaqla. Hətta o yerə gəldi ki, biz sadəcə “avarçəkənlər” deyilik, biz özümüz bir çox biznes prosesləri və biznesin bəyəndiyi yeni xüsusiyyətlər təklif edirik.

Bizim tərəfimizdən bu yanaşma sayəsində müştəri şirkətimizdən başqa bazar yeri sifariş etmək qərarına gəldi ki, bu da yaxşı xəbərdir.

Bu mənim layihəmdə işlədiyi üçün, bəlkə də kiməsə kömək edər. Beləliklə, layihəni xilas etməyimizə kömək edən prosesin özü:

"Mənim sevimli layihəm" layihəsi üzrə komanda işi prosesi

a) Komanda prosesi çərçivəsində (inkişafçılar arasında)

Bütün tapşırıqlar Jira sistemində yaradılmışdır
Hər bir tapşırıq mümkün qədər təsvir edilməli və ciddi şəkildə bir hərəkəti yerinə yetirməlidir.
Hər hansı bir xüsusiyyət, kifayət qədər mürəkkəbdirsə, bir çox kiçik vəzifələrə bölünür
Komanda funksiyalar üzərində vahid tapşırıq kimi işləyir. Əvvəlcə bir funksiyanı birlikdə edirik, onu sınaq üçün veririk, sonra növbətisini götürürük.
Hər bir tapşırıq backend və ya frontend üçün etiketlənir
Tapşırıq növləri və səhvlər var. Onları düzgün müəyyənləşdirməlisiniz.
Tapşırıq tamamlandıqdan sonra o, kodun nəzərdən keçirilməsi statusuna köçürülür (həmkarı üçün çəkmə sorğusu yaradılır)
Tapşırığı yerinə yetirən şəxs dərhal bu iş üçün vaxtını izləyir
Kodu yoxladıqdan sonra PR təsdiqlənir və bundan sonra bu tapşırığı yerinə yetirən şəxs müstəqil olaraq onu master filialına birləşdirir, bundan sonra statusunu dev serverə yerləşdirilməyə hazır vəziyyətinə dəyişir.
Təchizat serverinə yerləşdirilməyə hazır olan bütün tapşırıqlar komanda lideri (onun məsuliyyət sahəsi), bəzən təcili bir şey olarsa, komanda üzvü tərəfindən yerinə yetirilir. Yerləşdirmədən sonra, yerləşdirməyə hazır olandan proqrama qədər bütün tapşırıqlar statusa ötürülür - inkişaf etdiricidə sınaq üçün hazırdır
Bütün tapşırıqlar müştəri tərəfindən sınaqdan keçirilir
Müştəri tapşırığı devdə sınaqdan keçirdikdən sonra onu istehsala yerləşdirməyə hazır vəziyyətə köçürür.
İstehsala yerləşdirmək üçün, yerləşdirmədən dərhal əvvəl masterı birləşdirdiyimiz ayrıca filialımız var
Müştəri sınaq zamanı səhvlər aşkar edərsə, o, tapşırığı yenidən baxılmaq üçün qaytarır, vəziyyətini yenidən baxılmaq üçün qaytarır. Yeni tapşırıqları sınaqdan keçirilməmiş tapşırıqlardan belə ayırırıq.
Nəticədə, bütün tapşırıqlar yaradılandan tamamlanana qədər davam edir: Görüləcək işlər → İnkişafda → Kod Baxışı → Devə yerləşdirməyə hazır → Dev üzərində QA → (Təlifə qayıt) → Məhsula yerləşdirməyə hazır → Məhsulda QA → Hazırdır
Hər bir tərtibatçı öz kodunu müstəqil olaraq, o cümlədən saytın istifadəçisi kimi sınaqdan keçirir. Kodun işlədiyi dəqiq bilinmirsə, filialı əsas filialla birləşdirməyə icazə verilmir.
Hər bir işin prioritetləri var. Prioritetlər ya müştəri, ya da komanda rəhbəri tərəfindən müəyyən edilir.
Tərtibatçılar ilk növbədə prioritet tapşırıqları yerinə yetirirlər.
Sistemdə müxtəlif səhvlər aşkar edilərsə və ya bir tapşırıq bir neçə mütəxəssisin işindən ibarət olarsa, tərtibatçılar bir-birlərinə tapşırıqlar verə bilərlər.
Müştərinin yaratdığı bütün tapşırıqlar komanda rəhbərinə göndərilir, o, onları qiymətləndirir və ya müştəridən onları tamamlamağı xahiş edir, ya da komanda üzvlərindən birinə tapşırır.
İnkişaf etdirməyə və ya istehsala yerləşdirilməyə hazır olan bütün tapşırıqlar həmçinin nə vaxt və necə yerləşdiriləcəyini müstəqil olaraq təyin edən komanda rəhbərinə çatır. Hər yerləşdirmədən sonra komanda rəhbəri (və ya komanda üzvü) bu barədə müştəriyə məlumat verməlidir. Həm də tapşırıqların statuslarını dev / məhsulda sınaqdan keçirmək üçün hazır vəziyyətə gətirin.
Hər gün eyni vaxtda (saat 12.00-da var) bütün komanda üzvləri arasında mitinq keçiririk.
Mitinqdə olan hər kəs, o cümlədən komandanın rəhbəri dünən nə etdiyini, bu gün nə etməyi planlaşdırdığını bildirir. Nə işləmir və niyə. Beləliklə, bütün komanda kimin nə etdiyini və layihənin hansı mərhələdə olduğunu bilir. Bu, lazım gələrsə, təxminlərimizi və son tarixlərimizi proqnozlaşdırmaq və tənzimləmək imkanı verir.
Yığıncaqda komanda rəhbəri həmçinin layihədəki bütün dəyişiklikləri və müştəri tərəfindən tapılmayan cari səhvlərin səviyyəsini elan edir. Bütün səhvlər sıralanır və onları həll etmək üçün hər bir komanda üzvünə verilir.
Mitinqdə komanda rəhbəri, tərtibatçıların cari iş yükünü, onların peşəkar hazırlıq səviyyəsini, həmçinin müəyyən bir tapşırığın tərtibatçının hazırda gördüyü işlərə yaxınlığını nəzərə alaraq hər biri üçün tapşırıqlar verir.
Yığıncaqda komanda rəhbəri memarlıq və biznes məntiqi üçün ümumi strategiya hazırlayır. Bundan sonra bütün komanda bunu müzakirə edir və düzəlişlər etmək və ya bu strategiyanı qəbul etmək qərarına gəlir.
Hər bir tərtibatçı vahid arxitektura və biznes məntiqi çərçivəsində müstəqil şəkildə kod yazır və alqoritmlər qurur. Hər kəs həyata keçirmək üçün öz baxışını ifadə edə bilər, lakin heç kim heç kimi bunu bu şəkildə etməyə məcbur etmir, başqa cür deyil. Hər bir qərar əsaslıdır. Daha yaxşı bir həll varsa, amma indi bunun üçün vaxt yoxdursa, kodun müəyyən bir hissəsinin gələcəkdə refaktorinqi üçün yağda bir tapşırıq yaradılır.
Tərtibatçı bir vəzifə götürdükdə onu inkişaf statusuna keçir. Müştəri ilə tapşırığın aydınlaşdırılması ilə bağlı bütün ünsiyyət tərtibatçının çiyinlərinə düşür. Texniki suallar komanda rəhbərinə və ya həmkarlarına verilə bilər.
Tərtibatçı tapşırığın mahiyyətini başa düşmürsə və müştəri bunu ağıllı şəkildə izah edə bilmirsə, o zaman növbəti tapşırığa keçir. Komanda rəhbəri isə cari olanı götürüb müştəri ilə müzakirə edir.
Hər gün tərtibatçı müştərinin çatında dünən hansı tapşırıqlar üzərində işlədiyini və bu gün hansı tapşırıqlar üzərində işləyəcəyini yazmalıdır.
İş prosesi Scrum-a əsaslanır. Hər şey sprintlərə bölünür. Hər sprint iki həftə davam edir.
Sprintlər komanda lideri tərəfindən yaradılır, doldurulur və bağlanır.
Layihənin ciddi müddətləri varsa, biz bütün tapşırıqları təxmini olaraq qiymətləndirməyə çalışırıq. Və onlardan bir sprint toplayırıq. Müştəri sprintə daha çox tapşırıq əlavə etməyə çalışırsa, biz prioritetləri təyin edirik və bəzi digər tapşırıqları növbəti sprintə köçürürük.

b) Müştəri ilə iş prosesi

Hər bir tərtibatçı müştəri ilə ünsiyyət qura bilər və etməlidir
Müştərinin öz oyun qaydalarını tətbiq etməsinə icazə verə bilməzsiniz. Müştəriyə bizim öz sahəmizdə mütəxəssis olduğumuzu və yalnız iş prosesləri qurmalı və müştərini onlara cəlb etməliyik ki, nəzakətli və mehriban şəkildə başa salmaq lazımdır.
İdeal olaraq, hər hansı bir funksionallığın həyata keçirilməsinə davam etməzdən əvvəl, bir xüsusiyyət (iş axını) üçün bütün məntiqi prosesin axın sxemini yaratmaq lazımdır. Və təsdiq üçün müştəriyə göndərin. Bu, yalnız mürəkkəb və aşkar olmayan funksionallıqlara aiddir, məsələn, ödəniş sistemi, bildiriş sistemi və s. Bu, müştərinin tam olaraq nəyə ehtiyac duyduğunu daha dəqiq başa düşməyə, xüsusiyyət üçün sənədləri saxlamağa, həmçinin müştərinin gələcəkdə onun xahişini yerinə yetirmədiyimizi söyləyə biləcəyindən özünüzü sığortalamağa imkan verəcəkdir.
Bütün diaqramlar / axın sxemləri / məntiq və s. biz Confluence/Fat-da qənaət edirik, burada şərhlərdə müştəridən gələcək tətbiqin düzgünlüyünü təsdiqləməsini xahiş edirik.
Biz texniki detallarla müştərini yükləməməyə çalışırıq. Müştərinin necə istədiyini başa düşməyə ehtiyacımız varsa, o zaman müştərinin hər şeyi özü başa düşə və düzəldə / dəyişdirə biləcəyi bir axın sxemi şəklində primitiv alqoritmlər çəkirik.
Müştəri layihədə bir səhv tapsa, onu Fat-da ətraflı təsvir etməyinizi xahiş edirik. Sınaq zamanı müştəri tərəfindən hansı hallarda, nə vaxt, hansı ardıcıllıqla həyata keçirildi. Zəhmət olmasa skrinşotları əlavə edin.
Biz hər gün, maksimum hər gün, dev serverə yerləşdirməyə çalışırıq. Müştəri daha sonra funksionallığı sınamağa başlayır və layihə boş qalmır. Eyni zamanda, bu, müştəri üçün layihənin tam inkişaf mərhələsində olduğunu və heç kimin ona nağıl danışmadığını göstərən bir işarədir.
Çox vaxt olur ki, müştəri ümumiyyətlə ona nə lazım olduğunu tam başa düşmür. O, özü üçün yeni bir iş yaratdığından, hələ düzəldilməmiş proseslərlə. Buna görə də, çox yaygın bir vəziyyət, bütün kod parçalarını zibil qutusuna atmaq və tətbiq məntiqini yenidən formalaşdırmaqdır. Buradan belə çıxır ki, testlərlə tamamilə hər şeyi əhatə etmək lazım deyil. Yalnız kritik funksionallığı testlərlə, sonra isə rezervasiyalarla əhatə etmək məntiqlidir.
Elə vəziyyətlər olur ki, komanda bizim son tarixlərə uyğun gəlmədiyimizi anlayır. Sonra biz tapşırıqların tez auditini aparırıq və bu barədə dərhal müştəriyə məlumat veririk. Vəziyyətdən çıxış yolu olaraq, vacib və kritik funksionallığı vaxtında işə salmağı, qalanını isə buraxılışdan sonra buraxmağı təklif edirik.
Müştəri başından fərqli tapşırıqlar qoymağa başlayırsa, xəyal qurmağa və barmaqları ilə izah etməyə başlayırsa, biz ondan bizə səhifənin tərtibatı və bütün tərtibatın davranışını və onun fəaliyyətini tam təsvir etməli olan məntiqlə axmasını xahiş edirik. elementləri.
Hər hansı bir tapşırığı yerinə yetirməzdən əvvəl, bu xüsusiyyətin müqaviləmizin / müqaviləmizin şərtlərinə daxil edildiyinə əmin olmalıyıq. Əgər bu, ilkin razılaşmalarımızdan kənara çıxan yeni bir xüsusiyyətdirsə, o zaman bu xüsusiyyəti mütləq qiymətləndirməliyik ((təxmini tədarük müddəti + 30%) x 2) və müştəriyə onu tamamlamaq üçün bizə çox vaxt lazım olduğunu bildirməliyik. son tarix ikiyə vurulan təxmin edilən vaxta dəyişdirilir. Tapşırığı daha tez yerinə yetirək - əla, hər kəs bundan yalnız faydalanacaq. Yoxdursa, biz sığortalanmışıq.

c) Komandada qəbul etmədiyimiz şeylər:

Uyğunsuzluq, uyğunsuzluq, unutqanlıq
"Səhər yeməyi". Tapşırığı yerinə yetirə bilmirsinizsə, necə edəcəyinizi bilmirsinizsə, bu barədə dərhal komanda rəhbərinə məlumat verməli və sonuncuya qədər gözləməməlisiniz.
Brovada və öz imkanlarını və peşəkarlığını hələ əməli ilə sübut etməmiş bir adamdan öyünmək. Sübut olunubsa, ədəb çərçivəsində mümkündür 🙂
Bütün təzahürlərində fırıldaqçılıq. Tapşırıq tamamlanmayıbsa, onun statusunu tamamlandı kimi dəyişdirməməli və müştərinin çatında hazır olduğunu yazmalısınız. Kompüter qəzaya uğradı, sistem çökdü, it noutbuku çeynədi - bütün bunlar qəbuledilməzdir. Əgər real fors-major hadisə baş verərsə, o zaman dərhal komanda rəhbərinə məlumat verilməlidir.
Mütəxəssis hər zaman oflayn olduqda və iş saatlarında ona çatmaq çətin olduqda.
Komandada zəhərlənməyə icazə verilmir! Əgər kimsə nə iləsə razılaşmırsa, o zaman hamı bir yerə yığışıb mitinq edir, müzakirə edir, qərar verir.

Və bəzən müştərimdən bütün anlaşılmazlıqları aradan qaldırmağı xahiş etdiyim bir sıra suallar / tezislər:

Keyfiyyət meyarlarınız hansılardır?
Layihənin problemli olub-olmadığını necə müəyyənləşdirmək olar?
Sistemin dəyişdirilməsi/təkmilləşdirilməsi ilə bağlı bütün tövsiyələrimizi və tövsiyələrimizi pozaraq, bütün risklər yalnız sizin üzərinizdədir.
Hər hansı bir böyük layihə dəyişikliyi (məsələn, hər cür əlavə axın) səhvlərin mümkün görünüşünə səbəb olacaq (əlbəttə ki, düzəldəcəyik)
Layihədə hansı problemin baş verdiyini bir neçə dəqiqə ərzində başa düşmək mümkün deyil, hətta onu orada düzəltmək mümkün deyil.
Biz konkret məhsul axını üzərində işləyirik (Zhirada Tapşırıqlar - İnkişaf - Test - Yerləşdirmə). Bu o deməkdir ki, biz söhbətdəki bütün sorğu və şikayət axınına cavab verə bilmərik.
Proqramçılar peşəkar testerlər deyil, sadəcə proqramçılardır və layihə testinin lazımi keyfiyyətini təmin edə bilməzlər
Satışda son sınaq və tapşırıqların qəbulu üçün məsuliyyət tamamilə sizin üzərinizdədir
Əgər biz artıq bir tapşırığı öhdəsinə götürmüşüksə, indiki işi tamamlayana qədər dərhal başqalarına keçə bilmərik (əks halda bu, daha çox səhvlərə və inkişaf müddətinin artmasına səbəb olur)
Komandada daha az insan var (məzuniyyət və ya xəstəliklərə görə) və daha çox iş var və istədiyiniz hər şeyə cavab verməyə fiziki olaraq vaxtımız olmayacaq.
Dev üzərində sınaqdan keçirilmiş tapşırıqlar olmadan istehsala yerləşdirmənizi xahiş etmək yalnız sizin riskinizdir, tərtibatçının deyil
Siz qeyri-səlis tapşırıqlar təyin edərkən, düzgün axın olmadan, dizayn sxemləri olmadan, bu, bizdən daha çox səy və icra vaxtı tələb edir, çünki sizin əvəzinə əlavə iş görməliyik.
Səhvlərlə bağlı hər hansı tapşırıq, onların baş verməsi və skrinşotları ətraflı təsvir edilmədən bizə nəyin səhv getdiyini və bu səhvi necə buraxa biləcəyimizi anlamağa imkan vermir.
Layihə performansı və təhlükəsizliyi yaxşılaşdırmaq üçün daimi təkmilləşdirmə və təkmilləşdirmə tələb edir. Buna görə də komanda vaxtının bir hissəsini bu təkmilləşdirmələrə sərf edir.
Əlavə iş saatlarımız olduğuna görə (təcili düzəlişlər) digər günlərdə onları kompensasiya etməliyik

Bir qayda olaraq, müştəri dərhal başa düşür ki, proqram təminatının hazırlanmasında hər şey o qədər də sadə deyil və təkcə arzu kifayət deyil.

Ümumiyyətlə, hamısı budur. Pərdə arxasında çoxlu danışıqları və bütün proseslərin ilkin düzəlişlərini buraxıram, amma nəticədə hər şey nəticə verdi. Deyə bilərəm ki, bu proses bizim üçün bir növ “Gümüş güllə” oldu. Layihəyə gələn yeni insanlar artıq ilk gündən işə başlaya bilərdilər, çünki bütün proseslər təsvir olunur və diaqramlar şəklində sənədləşmə və memarlıq dərhal hamımızın nə etdiyimiz barədə bir fikir verir. burada.

P.S. Aydınlaşdırmaq istəyirəm ki, bizim tərəfimizdə layihə meneceri yoxdur. Müştəri tərəfindədir. Heç bir texniki adam deyil. Avropa layihəsi. Bütün ünsiyyət yalnız ingilis dilindədir.

Hər kəsə layihələrinizdə uğurlar. Canınızı yandırmayın və prosesləri yaxşılaşdırmağa çalışın.

mənbə mənim blog yazı.

Mənbə: www.habr.com

İT layihəsi üzrə komandada iş axınının təşkili