Çevik xərcləmə. Çevik inkişaf metodologiyası (Agile)

12 prinsipdən ibarətdir. Əlbəttə ki, Çevik yanaşmanın müəyyən müddəaları bundan əvvəl ortaya çıxdı, lakin yalnız bu sənəd onları istifadə üçün kifayət qədər sistemləşdirdi və qeyd etdi. Hər il yeni şirkətlər, İT mütəxəssisləri və layihə menecerləri manifest imzalayır. Çevik inkişaf sisteminin yeni üsulları və modifikasiyaları var.

Çevik Metodologiya (çevik metodologiya) nədir?

Çevik, kodun iş dövrünün sonunda çatdırıldığı şəlalə modellərindən fərqli olaraq, proqram təminatının layihənin əvvəlindən tədricən qurulduğu iterativ inkişaf modelidir.

Çevik metodologiyanın əsası layihələri istifadəçi hekayələri adlanan kiçik iş parçalarına bölməkdir. Prioritetə ​​uyğun olaraq, vəzifələr iki həftəlik qısa dövrlər (iterasiyalar) çərçivəsində həll edilir.

Çevik Metodologiyanı təşkil edən 12 prinsipi 4 əsas fikrə bölmək olar:

• İnsanların və ünsiyyətin alətlər və proseslərdən üstünlüyü;
• İşləyən məhsulun tam sənədlərdən üstünlüyü;
• Müqavilənin təsdiqindən daha çox müştərilərlə əməkdaşlığın üstünlüyü;
• Dəyişiklik etmək istəyini ilkin plana əməl etməkdən üstün tutun.

Agile-də mövcud olan üsullar:

Reqbi "Scrum" termininə borcludur, burada bu söz rəqiblərin hər biri tərəfindən üç xətt qurmaq və topu tutmağa çalışmaq şəklində komanda oyunu metodu deməkdir. Uğurlu tutma təkcə yaxşı fiziki hazırlıq deyil, həm də döyüşün hər bir iştirakçısının ahəngdarlığı və məqsədi aydın başa düşməsini tələb edir.

Metod Microsoft, Yahoo, Siemens Healthcare kimi şirkətlər tərəfindən uğurla istifadə olunur və Amazon-un layihə meneceri hətta qazanılmış təcrübəyə əsaslanaraq bunu təsvir etdi.

Scrum bir inkişaf çərçivəsi olduğundan, hər bir sonrakı nümunədə əvvəlkindən əhəmiyyətli dərəcədə fərqlənə bilər.

Jeff Sutherland, müəllif texnikadan istifadə üçün 8 addım müəyyən etdi:

1. seçin məhsul sahibi- Layihənin məqsədini və gözlənilən nəticəni bilir.
2. toplayın əmr- işlək məhsul yaratmaq üçün lazım olan bacarıqlara malik 10 nəfərə qədər.
3. tapın Scrum Masters— layihənin gedişatını izləyir, layihə komandasına çətinliklərin öhdəsindən gəlməyə kömək edir.
4. Bəstələmək məhsul geriliyi- Çevik lövhədə hər bir məhsul tələbinə üstünlük verin. Burada məhsul sahibinin böyük rolu var, o, məhsulla bağlı istəkləri geridə qalan qrup tərəfindən qiymətləndirilmək üçün toplayır.
5. Cədvəl sprintlər(iterasiyalar) - müəyyən sayda tapşırıqları yerinə yetirmək üçün vaxt müddətləri.
6. Təşkil et gündəlik on beş dəqiqəlik "görüşlər"- komandanın hər birinə 3 sual verin: dünən nə etdiniz, bu gün nə olacaq, tapşırığı yerinə yetirməyə nə mane olur.
7. Et məhsulun işçi hissələrinə baxış- maraqlı tərəflərin baxışında və müzakirəsində iştirak etməklə.
8. xərcləyin retrospektiv— hər sprintdən sonra problemin müzakirəsi və həll yolunun axtarışı. Yaranan dəyişiklik planını növbəti sprintdə həyata keçirin.

Agile-də retrospektiv

Scrum-un 4 əsas elementi var:

• məhsul geriliyi- layihə üçün tələblərin siyahısı
• Sprint Backlog- növbəti sprintdə yerinə yetirilməli olan tələblərin siyahısı
• Sprint Məqsədi- sprint məqsədi
• Sprint Burndown Diaqramı- Tapşırıqlar tamamlandıqca yenilənən diaqram. Layihədə komandanın dinamikasını və irəliləyiş səviyyəsini başa düşmək asandır.

(XP)

Metodologiyanın yaradıcısı Kent Beck, məqsədi proqram məhsulu üçün daim dəyişən tələblərin öhdəsindən gəlmək və inkişafın keyfiyyətini artırmaqdan ibarət olan Ekstremal Proqramlaşdırma metodunu yaratmışdır.

Bu, yalnız proqram təminatının inkişafı sahəsində tətbiq edilir və 4 proses ətrafında qurulur:

1. kodlaşdırma— komandada vahid dizayn standartlarına uyğun olaraq;
2. sınaq- sınaqdan keçiriləcək kodu yazmazdan əvvəl testlər proqramçıların özləri tərəfindən yazılır;
3. planlaşdırma- həm son quruluş, həm də fərdi təkrarlamalar. Sonuncu orta hesabla iki həftədə bir dəfə baş verir.
4. eşitmə- həm tərtibatçılar, həm də müştəri, bu müddət ərzində qeyri-müəyyənliklər yox olur, tələblər və dəyərlər müəyyən edilir.

Metodologiyalar

“Agile Software Development Manifesto”nun müəlliflərindən biri olan Alistair Cockburn tərəfindən hazırlanmış layihə idarəetməsinin daxili sahələrində az tanınan metodologiyalar ailəsi. Cockburn komandadakı insanların sayı meyarına görə rəngə görə təsnif etməyi təklif edir: 2-dən (Crystal Clear) 100-ə qədər (Kristal Qırmızı). Maroon, Blue və Violet rəngləri daha böyük layihələr üçün ayrılmışdır.

Kristal layihələri 3 əsas göstəriciyə cavab verməlidir:

1. iş kodunun sürətli çatdırılması— iterativ Çevik inkişaf modeli ideyasının inkişafı.
2. əks etdirmə yolu ilə mükəmməllik- proqram təminatının yeni versiyası əvvəlkindən alınan məlumatlar əsasında təkmilləşdirilmişdir.
3. "osmotik" qarşılıqlı təsir- Alistair-in yeniliyi, eyni otaqda proqram təminatçıları arasında ünsiyyət və məlumat mübadiləsi üçün metafora.

Dinamik Proqram İnkişafı Metodu (DSDM)

DSDM-nin inkişafı üzərində bir nəfər və ya hətta bir komanda deyil, 17 İngilis şirkətindən ibarət konsorsium çalışdı. DSDM, Extreme Programming kimi, ilk növbədə yaratmaq üçün istifadə olunur proqram təminatı.

İnkişaf prosesində son istehlakçının (istifadəçinin) iştirakına xüsusi rol verilir. Bu prinsipə əlavə olaraq, əsaslara aşağıdakılar daxildir:

• məhsulun işləyən versiyalarının tez-tez buraxılması
• qərarların qəbulu baxımından tərtibatçıların muxtariyyəti
• bütün iş dövrü ərzində sınaqdan keçirmək.

DSDM texnologiya inkişaf etdikcə yenilənən versiyalara bölünür, proqram təminatının inkişafı üçün yeni tələblər ortaya çıxır. Bu gün üçün sonuncusu 2007-ci ildə buraxılmış DSDM Atern-dir, baxmayaraq ki, əvvəlki (2003) hələ də xidmətdədir.

Başlanğıcda komanda tətbiqin inkişafının reallığını və əhatə dairəsini araşdırır. Sonrakı iş bir-biri ilə əlaqəli üç dövrə bölünür:

1. funksional model dövrü— analitik sənədlərin və prototiplərin yaradılması.
2. dizayn və tikinti dövrü- sistemin işlək vəziyyətə gətirilməsi.
3. icra dövrü- sistemin yerləşdirilməsi.

Xüsusiyyətlərə əsaslanan İnkişaf (FDD)

Hətta Çevik Manifestdən əvvəl gələn metodologiya.

FDD həm də iterativ inkişaf modelindən istifadə etsə də, Agile-dən aşağıdakı cəhətləri ilə fərqlənir:

• əvvəlcədən modelləşdirməyə daha çox diqqət yetirin
• hesabatın və qrafikin əhəmiyyətini artırdı (Agile ilə müqayisədə).
• korporativ inkişafa yönəlmişdir.

Xüsusiyyətlərə əsaslanan inkişaf aşağıdakı tsiklik mərhələlərdən ibarətdir:

1. Paylaşılan model yaradın— ilkin məlumatlar əsasında layihənin baxışı.
2. Əmlak siyahısının tərtib edilməsi- Scrum metodologiyasındakı məhsul ehtiyatının analoqu.
3. Əmlak üzrə Planlaşdırma- Komandanın hər bir üzvü tərəfindən əmlakın mürəkkəbliyinin qiymətləndirilməsi.
4. Hər bir əmlak üçün- texniki layihələndirmə və həyata keçirmə - yekun mərhələ, sonunda əmlak məhsula daxil olur və dövr təkrarlanır.

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

Lean Software Development - metodologiya deyil, prinsiplər toplusu arıq istehsal, inkişaf prosesinin səmərəliliyini artırmaq, xərcləri minimuma endirmək məqsədi daşıyır.

Komplektə aşağıdakı 7 prinsip daxildir:

1. itkilərdən qurtulmaq- son istehlakçı üçün məhsula dəyər qatmayan hər şey.
2. davamlı öyrənmə– komandanın davamlı inkişafı imkanları artırır effektiv həyata keçirilməsi tapşırıqlar.
3. mümkün qədər gec qərar qəbul etmək- prioritet kortəbii qərarlar deyil, düşünülmüş, əldə edilmiş biliklər əsasında işlənmişdir.
4. sürətli çatdırılma- əslində iterativ modelin əsasını təşkil edir.
5. komandanın gücləndirilməsi- "Manifestin ..." prinsiplərindən biri deyir ki, insanlar və qarşılıqlı əlaqə proseslər və vasitələrdən daha vacibdir. Layihə komandası tapşırıqların uğurla yerinə yetirilməsi üçün əsasdır.
6. bütövlük və keyfiyyət- sonrakı sınaqlara və səhvlərdən qurtulmağa vaxt və resurslar sərf etməmək üçün əvvəlcə keyfiyyətli məhsul hazırlamalısınız.
7. bütün şəkili görür- layihənin ayrı-ayrı hissələrə bölünməsi hazırkı proqram təminatının hazırkı inkişaf vəziyyətini, məqsədlərini, konsepsiyasını və strategiyasını başa düşmədən mümkün deyil.

Çevik inkişaf metodologiyalarının növləri

Çevik Modelləşdirmə (AM)

Çevik Modelləşdirmə proqram təminatının modelləşdirilməsi üçün dəyərlər, prinsiplər və təcrübələr toplusudur.

AM, Extreme Programming və ya Rapid Application Development kimi tam proqram təminatının inkişaf etdirilməsi metodologiyasının bir hissəsi kimi istifadə olunur.

Çevik Modelləşdirmənin prinsipləri bunlardır:

• layihənin maraqlı tərəfləri arasında effektiv qarşılıqlı əlaqə
• ən sadəini inkişaf etdirməyə çalışır mümkün həllər ki, bütün tələblərə cavab verir
• daimi rəy
• qərarlar vermək və məsuliyyət daşımaq cəsarəti
• hər şeyi bilmədiyini başa düşmək.

Çevik Vahid Proses (AUP)

AUP digər proqram təminatının inkişaf etdirilməsi metodologiyasının sadələşdirilmiş versiyasıdır, Rasional Vahid Prosesin (RUP). 2012-ci ildən, o, Disiplinli Çevik Çatdırılma (DAD) ilə əvəz edilmişdir, lakin AUP hələ də bəzi yerlərdə tapılır.

Metodologiyanın müəllifi Scott Ambler Agile Unified Process-in aşağıdakı əsas mövqelərini müəyyən etmişdir:

• Komandanız nə etdiklərini bilir;
• Sadəlik hər şeydən üstündür.
• Çevik inkişaf metodologiyası prinsiplərinə uyğunluq.
• Layihə üçün dəyərli olan fəaliyyətlərə diqqət yetirin.
• Alətlərin seçimində müstəqillik.
• Müəyyən bir layihənin ehtiyacları üçün AUP-nin fərdi tənzimlənməsi.

Agile Data Method (ADM)

ADM fərdi komandaların əməkdaşlığı vasitəsilə tələblərin və layihə qərarlarının yaradılmasını vurğulayan iterativ çevik proqram təminatı inkişaf metodologiyaları toplusudur. AUP kimi, bu da özlüyündə dəyərli bir texnika deyil.

Çevik Məlumat Metodunun mahiyyəti altı müddəa ilə müəyyən edilir:

1. Data- hər hansı bir proqram yaratmaq üçün əsas.
2. Layihə ilə bağlı problemlər— onları yalnız layihənin məqsədi və konsepsiyasının aydın başa düşülməsi ilə aşkar etmək olar.
3. İşçi qrupları- birbaşa inkişaf komandası ilə yanaşı, digər işçi qruplarını dəstəkləyən müəssisə qrupları da var.
4. Unikallıq— mükəmməl metodologiya yoxdur, hər bir layihə üçün müxtəlif metodologiyalardan alətləri birləşdirməlisiniz.
5. Komanda işi — komanda işi birdən çox daha təsirli olur.
6. "Şirin yer"- Axtar optimal həll problemlər ("şirin nöqtə"), ifratlardan qaçınmaq.

Əsas Vahid Proses (EssUP)

Rasional Vahid Prosesi təkmilləşdirmək üçün yaradılmış isveçli alim İvar Yakobsonun inkişafı.

EssUP aşağıdakıları ehtiva edən təcrübə konsepsiyası ilə işləyir:

• istifadə vəziyyəti - sistemin davranışının təsviri.
• iterativ inkişaf - bir neçə həftəlik qısa dövrlərdə iş kodu hissələrinin yaradılması.
• komanda təcrübələri - komandanı birləşdirmək və effektivliyini artırmaq məqsədi daşıyır.
• proses praktikaları - məsələn, "Böyük düşün, kiçik başla" və ya "Maraqlı tərəfləri biznes proseslərinə cəlb et".

Bu və ya digər formada olan bütün təcrübələr RUP, CMMI və çevik metodologiyalarda mövcuddur.

Real əldə etmək (GR)

Kiçik layihələrin və şirkətlərin xüsusiyyətlərindən maksimum istifadə etməyi təklif edən startaplar və təcrübəsiz komandalar üçün effektiv metodologiya: mobillik, çeviklik, yeni həllərin axtarışı, sərt çaşdırıcı iyerarxiyanın olmaması və s. 37signals-ın (indi Basecamp) təsisçiləri Jason Fried və David Hansson Getting Real-i real problemlərin həlli üçün bir sistem olaraq təyin etdilər: mümkün qədər sadə, başa düşülən və funksional.

GR, minimuma endirmək üçün istifadə olunan bir çox çevik inkişaf alətinin bir hodgepodge edir:

• imkanlar
• seçimlər və parametrlər
• şirkət strukturları
• görüşlər
• vədlər verir.

Qeyri-adi konsepsiya geniş şəkildə qəbul edilməmişdir, baxmayaraq ki, fərdi elementlər digər üsullardan istifadə edir.

OpenUP (OUP)

Aşağıdakı təcrübələri ehtiva edən sərt bir quruluşa malik olmayan alətdən müstəqil proqram inkişaf metodologiyası:

• komandanın sürətinin ölçülməsi;
• iterasiyaların sonunda gündəlik görüşlərin və retrospektivlərin keçirilməsi;
• mikro addımlar konsepsiyası və yoxlama siyahılarından istifadə edərək erkən sınaq;
• çevik modelləşdirmə texnikası (AMDD).

Təcrübələr dörd prinsip əsasında həyata keçirilir:

Çevik Metriklər

Agile-də alətlərin, təcrübələrin, metodların və metodologiyaların müxtəlifliyini nəzərə alaraq, onların hər birinin effektivliyini müəyyən etməyə kömək edəcək alət seçməlisiniz. Metriklər belə bir vasitədir.

Əksər layihələr üçün 4 ölçü sahəsi kifayət edəcək:

1. Performans- bura Sürət və WIP daxildir. Birincisi bütün layihələr üçün uyğun deyil, çünki hər iterasiya üzrə tamamlanmış tapşırıqların sayı ölçülür və onlar ekvivalent deyil. “İş-in-Progress” metrikası müxtəlif mərhələlərdə tapşırıqların həddini müəyyən edir: nə qədər yüksəkdirsə, bir o qədər pisdir;
2. Proqnozlaşdırma- tutum metrikası: növbəti sprintdə mövcud olan ideal saatların sayının müəyyən edilməsi. Müvafiq olaraq, iş üçün nə qədər vaxtın olduğunu, tapşırıqların icrasının nə qədər səmərəli olduğunu və sprint üçün tapşırıqların sayını necə planlaşdıracağınızı başa düşə bilərsiniz;
3. Keyfiyyət- məsələn, düsturu ilə hesablanan tələblərin sabitlik indeksi = (İlkin biznes tələblərinin ümumi sayı + Bu vaxta qədər dəyişmiş tələblərin sayı + Əlavə edilmiş tələblərin sayı + Silinmiş tələblərin sayı) / (orijinalların ümumi sayı tələblər). Metrik tapşırıqların yenidən yerinə yetirilməsinə sərf olunan vaxtın miqdarını ölçür;
4. Dəyərlər- hər bir halda layihənin formatından asılı olaraq fərdi hesablanır. Məsələn, başlanğıc AirBnb istifadəçilər üçün məhsulun son dəyərini müəyyən edən metrik olaraq yüklənmiş fotoşəkillərin sayını seçdi. Yüksək keyfiyyət. Onların artması ilə istehlakçıların sayı da mütənasib olaraq artdı.

Eyni qaydalar digər Çevik alətlər üçün olduğu kimi ölçülərə də aiddir.

Layihəniz üçün vahid sağ və ya sağ metrik yoxdur.

Onları daim nəzərdən keçirmək, köhnəlmişləri atmaq və lazım olduqda yenilərini əlavə etmək lazımdır. O, başa düşülən və bütün komanda üçün əlçatan olmalıdır, özlüyündə bir məqsədə çevrilməməlidir. Metriklər üçün ölçülər pis qərardır.

Mif avcıları: Çevik

Çevik inkişaf metodologiyası ailəsinin populyarlığı onunla qəddar bir zarafat etdi və hətta ixtisaslaşmış portallarda Agile-in bu və ya digər aspektləri haqqında miflər var. Biz anlayacağıq!

Mif №1: Çevik bütün layihələr üçün yaxşıdır.

Ən inadkar yanlış fikir. Heç bir Çevik metod məhsula dəyər qatmayacaq və ya komandanı təkbaşına motivasiya etməyəcək.

Mif №2: Çevik və sənədləşdirmə.

Çevik sənədləşdirməyə qarşı deyil, özlüyündə bir məqsəd kimi sənədləşdirməyə qarşıdır. Ancaq sənədləri ünsiyyət vasitəsi kimi seçərkən, Agile həqiqətən canlı ünsiyyətə üstünlük verir.

Mif №3: Çeviklik və planlaşdırma bir araya gəlmir.

Bu mif 10 dəqiqəlik stand-uplarla gündəlik planlaşdırma, hər iki həftədən bir təkrarlanan planlaşdırma, sprint görüşləri və s.

Mif №4: Çeviklik çoxlu yenidən iş tələb edir.

Çevik proqram təminatının işlənib hazırlanmasında yenidən dizayn iki formada olur: tələblərin yenidən yazılması (istifadəçilər həqiqətən nəyə ehtiyac duyduqlarını başa düşürlər) və proqram təminatının yenidən yazılması (inkişaf qrupları proqram yazmaq və dizayn etmək üçün daha yaxşı yollar tapırlar). Ancaq başqa üsullarla da bununla məşğul olmalısınız! Üstəlik, yenidən işin mənfi təsirini azaltmaq üçün Agile-in xüsusiyyəti olan iterativ model lazımdır.

Agile istifadə etməyin müsbət və mənfi cəhətləri

Müsbət cəhətləri:

1. maraqlı tərəflərin iştirakı- komandanın müştərinin istəklərini anlamaq üçün daha çox imkanları var. Proqram təminatının erkən və tez-tez çatdırılması maraqlı tərəflərin layihə komandasına inamını və layihədə daha da dərindən iştirakını artırır.
2. erkən və proqnozlaşdırıla bilən çatdırılma- təkrarlamalar vasitəsilə inkişaf modeli (1 həftədən 6 həftəyə qədər qısa fasilələr) çeviklik verir, məhsulun buraxılışını sürətləndirir.
3. biznes dəyərinə diqqət yetirin- Müştəri ilə əməkdaşlıq komandanın məhsulu istehlakçı üçün mümkün qədər qiymətli etmək üçün necə başa düşdüyünü təmin edir.
4. keyfiyyətin davamlı təkmilləşdirilməsi- hər bir iterasiya zamanı sınaqdan keçirilməsi, son quruluşun ayrı-ayrı işçi kodu hissələrinə bölünməsi son məhsulun buraxılmasından əvvəl proqram təminatının səhvlərini təkmilləşdirməyə və həll etməyə imkan verir.

Minuslar:

• komanda və müştərilər üçün artan tələblər– layihə komandası və istifadəçilər arasında sıx qarşılıqlı əlaqə olmadan yüksək dəyərə malik yüksək keyfiyyətli məhsul əldə etmək mümkün deyil. Tətbiq üçün Agile-də çoxlu alət və üsullar təcrübəli komanda tələb edir.
• autsorsing üçün uyğun deyil və iştirakçıların bir-biri ilə yalnız onlayn əlaqədə olduğu layihələr.
• proqram təminatının son versiyasını heç vaxt buraxmamaq riski- bu mənfi cəhət, qəribə də olsa, məhsulun iterativ inkişafı və davamlı təkmilləşdirilməsi nəticəsində yaranır - Agile-in üstünlükləri.
• layihənin biznes məqsədlərinə aydın baxış olmadan işləmir- Agile komandası maraqlı tərəflərə yönəldiyi üçün məqsədlər və məhsul konsepsiyası inkişaf etdirmədən inkişaf mümkün deyil.

Proqramlar

ilə layihələri idarə etmək Agile bütün xidmətlər və ya layihələrin idarə edilməsi üçün proqramlar üçün uyğun deyil, çünki hər birinin öz xüsusiyyətləri var.

Əgər biznesiniz varsamarketinq və reklam, dizayn, seo və ya rəqəmsal agentliklər , sonra saas xidməti bütövlükdə bütün kollektivin işinə tətbiq oluna bilər. Bizə tövsiyə olunur .

Budur, Agile-i qurmaq üçün bir neçə həyat hiyləsi

1. etiketləri və statusları fərdiləşdirinşirkətinizin fəaliyyəti üçün zəruridir.
   Statuslar ola bilər: davam edir, yoxlama, tamamlandı, təkmilləşdirməyə ehtiyacı var, kritik, xüsusiyyət, ödəniş.
   Etiketlər çox vaxt belə görünür: tərtibat, sınaq, istehsal, konsepsiya, kod.
2. geridə qalan layihə yaradın və bahar layihəsi.
3. tapşırıqlar yaradın və ilkin yoxlama siyahıları, eskizlər və s geridə qalmışdır.
4. görüşlərdə müəyyənləşdirin bahar tapşırıqları və onları geridə qalan işlərdən uzaqlaşdırın sprintdə.
5. istifadə edin müştəri qonaq girişi tapşırıqlara həmişə layihə haqqında ardıcıl və aktual şərhlər vermək.
6. qeyd etmək tapşırıqlara cavabdehdir belə ki, hər bir həmkar öz məsuliyyət sahəsini bilsin və sprint nəticəsində özünü hiss etsin.

Hökm

Çevik proqram təminatının inkişaf etdirilməsi metodologiyası ilə kiçik layihə qrupları maksimum səmərəliliyə nail olurlar. Agile digər çevik üsullarla həyata keçirilir: Scrum, XP, Lean və s.

Təcrübəsiz bir komanda tərəfindən qısa müddətdə həyata keçirilə bilməz, lakin Agile-in tətbiqi İT və biznes arasında qarşılıqlı əlaqəni yaxşılaşdıracaq, məhsulun bazara çıxarılmasını sürətləndirəcək və son istifadəçi üçün məhsulun dəyərini artıracaq.

• Tərcümə

"Hofstadter qanununu nəzərə alsanız belə, istənilən iş həmişə gözləniləndən daha uzun çəkir."
- Hofstadter qanunu

Ən çox baxılan çevik YouTube videosu. Bu məqalənin dərci zamanı 744,625 baxış olub. Yüngül təqdimat tərzi, şəkillər və cəmi 15 dəqiqə - gördüyüm ən yaxşısı. TED istirahət edir.

Rollar

Bant

Bu ritmi saxlamaq və əllə reqressiya testində batil olmamaq üçün komanda çox çalışır. avtomatik sınaq və davamlı inteqrasiya. Buna görə də, hər bir xüsusiyyət üçün avtotestlər yazmalısınız və kodun əksəriyyətində daxili avtotestlər var.

Hər dəfə biz istifadəçi hekayəsini həyata keçirəndə onlar daha bir neçə fikir irəli sürürlər və onlardan daha çox sorğu gəlir.

Onların bizdən tələb etdiyi hər şeyi etsək nə olar? Biz həddindən artıq yüklənəcəyik.

Scrum və XP bu halda “dünən hava” metodundan istifadə edir. Komanda deyir: "Son vaxtlar həftədə 4-6 funksiya edirik, gələn həftə hansı 4-6 funksiyanı edəcəyik?"

Məhsul sahibinin vəzifəsi bu həftə hansı istifadəçi hekayələrinin həyata keçiriləcəyini ağıllı şəkildə seçməkdir.

Kanban özünüzü bir neçə vəzifə ilə məhdudlaşdırmağı tövsiyə edir - WIP limiti. Deyək ki, komanda 5-in eyni vaxtda yüklənmədən, birindən digərinə keçmədən işləyə biləcəyi məqbul sayda istifadəçi hekayəsi olduğuna qərar verdi.

Bu növbəni də idarə etmək lazımdır.Maraqlı tərəflər həftədə 10 hekayə tələb etsələr və komanda 4-6 hekayə həyata keçirsə, bu növbə getdikcə böyüyəcək. Və tezliklə sizin Backlogunuz altı aya planlaşdırılacaq. Yəni bir hekayə 6 ayın çıxmasını gözləyəcək.

Görüləcək işlər siyahınızı nəzarətdə saxlamağın yalnız bir yolu var və bu, "yox" sözüdür.

Bəli demək asandır. Ancaq daha vacib vəzifə budur nə etməyəcəyinə qərar verin və bunun üçün məsuliyyət götürün. Məhsul sahibi bizim indi və sonra nə edəcəyimizin ardıcıllığını da müəyyən edir. o çətin iş və inkişaf qrupu və ən azı bir maraqlı tərəflə həyata keçirilməlidir.

Qərarların qəbulu

Hekayənin ölçüsü onun dəyəri ilə necə müqayisə olunur? Heç bir şəkildə. Daha çox daha yaxşı demək deyil. Tapşırığın dəyəri və mürəkkəbliyi Patın prioritetləşdirməsinə kömək edir.

Məhsul sahibi hekayənin dəyərini və əhatəsini necə müəyyən edir? Heç bir şəkildə. Bu təxmin oyunudur. Və hər kəsin orada iştirak etməsi daha yaxşıdır. Pat hər hekayənin dəyərini bilmək üçün daim maraqlı tərəflərlə əlaqə saxlayır, işin həcmini bilmək üçün inkişaf qrupu ilə əlaqə saxlayır, lakin bunların hamısı təxmini təxminlərdir, dəqiq rəqəmlər yoxdur. Başlanğıcda həmişə itkilər olacaq və bu, yaxşıdır. Ünsiyyət çox dəqiq rəqəmlərdən daha dəyərlidir.

Tərtibatçılar hər dəfə yeni bir şey buraxdıqda, biz daha çox məlumat öyrənirik və daha yaxşı naviqasiya edə bilərik.

Təkcə prioritetləşdirmə kifayət deyil. Hekayələri tez və tez-tez yayımlamaq üçün bir neçə gün ərzində edilə bilən hissələrə bölünməlisiniz. Biz huninin əvvəlində kiçik və aydın hekayələr, sonunda isə böyük və qeyri-müəyyən hekayələr istəyirik. Bu bölgüsü vaxtında etməklə biz məhsul və istifadəçi ehtiyacları ilə bağlı ən son kəşflərimizdən faydalana bilərik. Bütün bunlara Arxa planın təmizlənməsi deyilir.

Pat hər çərşənbə günü səhər saat 11:00-dan 12:00-a qədər yığıncaqların təmizlənməsi toplantısına ev sahibliyi edir.O, adətən bütün komandanı və bəzən bir neçə maraqlı tərəfi bir araya gətirir. Görüşlərin məzmunu müxtəlifdir. Qiymətləndirməyə, hekayələrin bölünməsinə, qəbul meyarlarına diqqət yetirin.

İT məhsulunun sahibi hər kəslə daim ünsiyyətdə olmalıdır

İnkişafın mürəkkəbliyi və istifadəçi hekayəsinin dəyəri arasında balans

Risklər

Sosial risk: "Elməli olanı edə bilərikmi?"

Texniki risk: "Layihə bu platformada işləyəcəkmi?"

Xərcləri və həyata keçirilmə vaxtı ilə bağlı risklər: "Uğur qazanacağıq və kifayət qədər pul olacaqmı?"

Bilik riskin əksi kimi görünə bilər. Qeyri-müəyyənlik böyük olduqda, biz biliklərin əldə edilməsinə diqqət yetiririk - interfeys prototipləri, texniki təcrübələr,

Müştəri üçün bilik dəyərləri və dəyərlər arasında ticarət

Qısa müddətli və uzunmüddətli düşüncə arasında mübadilə

Doğru şeylər edin, işləri düzgün edin, yoxsa işləri tez edin?

Scrumdakı rollar arasında sağlam bir müxalifət var.

Ayrıca, sürətin vacibliyini vurğulamağa dəyər, çünki qısa bir geribildirim dövrü öyrənməni sürətləndirir. Bu, bizə nəyin doğru olduğunu və onları necə düzgün quracağımızı tez öyrənməyə imkan verir.

Yeni bir məhsulun hazırlanması ilə köhnə məhsulun təkmilləşdirilməsi arasında mübadilə

Tarixi məhv etmə cədvəli

Tutaq ki, maraqlı tərəf bu xüsusiyyətin nə vaxt hazırlanacağını soruşur?

Adətən layihənin məzmununu azaltmaq vaxtı artırmaqdan daha yaxşıdır. Məzmunu azaltsaq, son tarixləri geri çəkmək imkanımız olacaq. Bəzilərini burada, qalanlarını isə sonra buraxa bilərik.

Məhsul sahibi həftəlik hesablamalar aparır və yalnız empirik məlumatlardan istifadə edir və heç bir istəklə düşünmür. O, qeyri-müəyyənlik haqqında səmimi danışır. Komanda iş tempini qoruyur və Pat onlara təzyiq göstərmir, onları sürətləndirməyə məcbur edir.

Hörmətlə rəftar etmək istəməyən bir insan tapmaq çətindir. Amma bu vəziyyətin bir səbəbi olmalıdır. Məsələn, bir şəxs proqram təminatının inkişafı sahəsində yüksək ixtisaslı tanınmış mütəxəssis olduqda. Və bunun üçün oxumaq lazımdır. Və bu məqalə çərçivəsində Agile nədir, ondan nə istifadə olunur və bu texnologiyanı necə başa düşəcəyimizi nəzərdən keçirəcəyik.

ümumi məlumat

Əvvəlcə texniki məsələlərlə məşğul olaq. Agile nədir? Bu sözün tərcüməsi (hərfi). ingilis dili- "canlı, mobil", "çevik" bir az daha az xatırlanır. Yeri gəlmişkən, bu bir abbreviaturadır. Bu yanaşmanın tam adı Çevik proqram təminatının inkişafı. Amma çox uzun olduğu üçün kəsilməyə qərar verilib. İndi isə sadəcə Çevik deyirlər. "Çevik" kimi tərcümə real vəziyyətə ən çox uyğun gəldiyi üçün istifadə olunur.

Buraya nə daxildir?

Agile'nin nə olduğunu düşünməyə davam edirik. Burada bir çox fərqli XP, "Kanban", Lean-a əsaslanan çevik bir yanaşma olduğuna diqqət yetirmək istəyirəm). Mövzunu daha yaxşı başa düşmək üçün paralellər aparaq. Deyək ki, Agile texnologiyaları Kainatın yaranması prosesidir. Son məhsul faktiki dünyanın özüdür. Böyük partlayış isə qarşılaşmalı olduğunuz ən ağrılı problemdir - məhsul tələblərinin siyahısını dəyişdirmək. Tipik olaraq, yaradılış prosesləri istifadəni əhatə edir şəlalə modeli. Bu vəziyyətdə hər şey ardıcıl və mərhələlərlə gedir. Bu yanaşmanı qısaca ifadə etmək olar: Mən məqsədi görürəm - ona gedirəm. Son nəticəyə olan tələblər dəyişirsə, bəzən demək olar ki, hər şeyi yenidən etməli olursunuz. Bu vəziyyəti daha da çətinləşdirən hər şeyin qaydasında olduğunu və irəli getməyimiz lazım olduğunu iddia etmək cəhdidir.

Və budur, çevikliyi sayəsində bütün bunlarla məşğul olmaq üçün hazırlanmış idarəetmə. Bu hodgepodge prinsiplər dəstindən istifadə etməklə müxtəlif riskləri minimuma endirir. Onların hamısı 2001-ci ildə buraxılmış Çevik Manifestdə öz əksini tapıb. Qısaca belə səslənirlər:

1. Əsas olan şeylər deyil, insanlardır.
2. Əməkdaşlıq edin, müqaviləni oxumayın.
3. Sənədlər işə mane olmamalıdır.
4. Mümkün qədər tez dəyişdirin.

Çox qeyri-müəyyən və dəqiq görünə bilər, amma gəlin ətraflı danışaq.

Proses dizaynı

Çevikliyin nə olduğunu nəzərə alaraq, gəlin "Scrum" (Scrum) kimi tanınan ən məşhur metodologiyalardan birinə müraciət edək. O nə təklif edir? Başlamaq üçün sizə lazımdır:

1. Məhsul sahibini seçin. Bu rol, hansı məqsədə getməyiniz lazım olduğunu və sonunda nə olacağını görən bir insan üçün uyğundur.
2. Komandaya qərar verin. Bunun üçün nəticə əldə etmək bacarığı olan üç-on nəfərdən ibarət qrup lazımdır.
3. seçin məsul mütəxəssis. Bu, layihənin inkişafına nəzarət edəcək və komandaya çətinliklərin öhdəsindən gəlməyə kömək edəcək bir şəxsdir.
4. Çətinliklərlə məşğul olun. Bütün mövcud məhsul tələbləri bir yerdə toplanmalı və prioritetləşdirilməlidir. Məhsul sahibi bütün arzularını burada toplamalıdır. Sonra komanda onları qiymətləndirir və bunun həyata keçirilə biləcəyini və bunun üçün nə qədər vaxt lazım olduğunu başa düşür.
5. Bütün iş həcmini bir və ya iki həftəlik müddətlərə ayırmalısınız, bu müddət ərzində komanda müəyyən tapşırıqlar dəstini yerinə yetirəcəkdir.
6. İclaslar hər gün, on beş dəqiqədən çox olmamalıdır. Gündəmdə dünən nələr görülüb, bu gün üçün hansı planlar var, yüksəkliyə qalxmağımıza mane olan maneələr müzakirə olunmalıdır.
7. Həftənin sonunda (iki) nəzərdən keçirin, bu müddət ərzində komanda görülən işlər barədə danışır. Eyni zamanda, məhsulun hissələrinin performansını nümayiş etdirmək lazımdır.
8. Hər bir müddətdən sonra problemlər müzakirə edilməli və həll yolları axtarılmalıdır. Üstəlik, bütün inkişaflar dərhal həyata keçirilməlidir.

Agile'i necə tanımaq olar?

İdarəetmə metodologiyası, seçilmiş istiqamətdən asılı olmayaraq, həmişə aşağıdakı xüsusiyyətlərə malikdir:

1. Riskin minimuma endirilməsi. o əsas məqsəd ki, istənilən çevik yanaşma həyata keçirir.
2. İterativ inkişaf. Bu vəziyyətdə, kiçik dövrlərdə işləmək nəzərdə tutulur.
3. Ən əsası insanlar və onlar arasında ünsiyyətdir.

Gəlin bir çay təsəvvür edək. Müştərinin bir tərəfində. İkincisi komandadır. Bu halda çevik inkişaf metodologiyası hər kəs üçün üstünlüklərə malikdir:

1. Müştəri minimum məhsuldar olmasını istəyir. Eyni zamanda, onun yaradılması zamanı şərtlər dəyişə bilər.
2. Komandanın həmkarları və müştəri ilə ünsiyyət qurması faydalıdır. Bu zaman səhv başa düşülmə riski minimuma endirilir, proseslərin şəffaflığı artır, problemlər tez həll edilir və məhsul yaratarkən sürprizin olma ehtimalı azalır.

sosial amil

Çevikliyin nə olduğu haqqında danışarkən adətən yalnız müsbət şeylərdən danışırlar. Həqiqətən də komandadaxili ünsiyyət yaxşılaşır. Bütün insanlar bir fikir üzərində cəmləşirlər, öz aralarında sirr yaratmırlar, öhdəliklər götürürlər. Nəticədə komanda rahat şəraitdə və yüksək templə işləyir. Bu yanaşma xaosu tənzimləməyə imkan verir.

Yarandığı gündən texnologiya sənayesində tanınmağı bacarmışdır. Hal-hazırda yeni proqram məhsullarının dizaynı üçün geniş istifadə olunur. Lakin ümumi iş təcrübəsində bu yanaşma hələ də az məlumdur. Ona görə də əvvəllər Agile ilə tanış olmayanlar bu barədə ehtiyatlı davranırlar. Onu da başa düşmək lazımdır ki, ondan yalnız insanların əqli əmək vəzifəsi ilə üzləşdiyi hallarda istifadə edilməlidir.

Kiçik misal

Gəlin bu proqram inkişaf metodologiyalarının necə işlədiyinə nəzər salaq. Tutaq ki, bizdə məhsulun sahibi Peter var. Texniki detalları bilməsə də, görmə qabiliyyəti var ümumi şəkil. Məhsulun nə üçün lazım olduğunu, hansı problemləri həll edəcəyini, kimi qane edəcəyini bilir. Maraqlananlar da var. Onlar məhsuldan istifadə edə, onun yaradılmasını dəstəkləyə və ya başqa şəkildə onun yaradılmasında iştirak edə bilərlər. Siz həmçinin maraqlı tərəflərin istəklərini ifadə edən istifadəçi hekayələri əlavə edə bilərsiniz. Məsələn: Moskva-Sankt-Peterburq müntəzəm avtobuslarına bilet sifariş etmək sistemində uçuşlar üçün axtarış olmalıdır. Peter maraqlananlara kömək edəcək. O, istifadəçi hekayə ideyalarından həyata keçirilməsinə nəzarət edəcək. İnkişaf qrupu da var. Bunlar iş sistemini quracaq insanlardır.

Çevik inkişaf metodologiyasından istifadə edildiyi üçün istifadəçi hekayələri böyük buraxılışdan əvvəl yığılmır, lakin tamamlandıqdan dərhal sonra və mümkün qədər tez-tez buraxılır. İşlənmiş sorğuların sayı komandanın həftəlik ötürmə qabiliyyətidir. Təcrübəni itirməmək və əllə sınaqdan keçməmək üçün komanda avtomatlaşdırılmış inteqrasiya üzərində işləməlidir. Bu nədir? Hər bir iş anı üçün avtomatik sınaq yazılır. Çox hekayələr varsa, tələskənlik, motivasiya itkisi, məhsuldarlıq və keyfiyyət itkisi ola bilər. Belə hallar üçün “dünənki hava” üsulu nəzərdə tutulub. Bu, işin həcminə ciddi məhdudiyyətlər qoymağınız və dəqiq nəyin həyata keçiriləcəyini diqqətlə seçmək lazımdır. Daha əvvəl qeyd olunan "Kanban" tapşırıq limiti təyin etməyi təklif edir.

Növbə ilə nə etməli?

Yaxşı, komanda həftədə dörd hekayə işləyə biləcəyinə qərar verdi. Bəs hər şeydə necə naviqasiya etmək olar? Tutaq ki, istifadəçilər həftədə on hekayə yükləyirlər. Dördü emal olunur. Beləliklə, növbə daim artacaq. Bu vəziyyətdə yalnız bir var təsirli üsul- "yox" sözü. Məhsul sahibi üçün bu son dərəcə vacibdir. “Bəli” demək çətin deyil. Nə etməyəcəyinə qərar vermək daha çətindir və daha vacibdir. Üstəlik, bunun üçün də məsuliyyət daşımaq lazımdır. Ona görə də indi nəyə diqqət etmək, nəyi təxirə salmaq lazım olduğuna qərar vermək lazımdır. Düzgün başa düşmək üçün məhsul sahibi hər hekayənin dəyərini və əhatə dairəsini başa düşməlidir.

Biz qərarlar veririk

Bəzi hekayələr son dərəcə zəruridir. Digərləri sadəcə olaraq gözəl bonus. Bəzi hekayələrin hazırlanması bir neçə saat çəkəcək. Digərlərinin tamamlanması aylar çəkəcək. Çoxları tez-tez hekayənin ölçüsü ilə onun dəyəri arasında əlaqə qurur. Ancaq bu həmişə düzgün deyil. Daha çox ilə daha yaxşı eyni deyil. Tapşırığın mürəkkəbliyi və dəyəri Peterə düzgün prioritet qoymağa kömək edir. Bu xüsusiyyətləri necə qiymətləndirmək olar? Heç bir şəkildə. o real oyun bir təxminə çevrilir. Və daha yüksək effektivlik üçün ona çoxlu insan cəlb etmək lazımdır. Bu, işin həcmi və maraqlı tərəflər haqqında məlumat verəcək inkişaf qrupudur. Ancaq başa düşmək lazımdır ki, bu şəkildə əldə edilən bütün məlumatlar təxmini təxminlərdir. Burada dəqiq rəqəmlər yoxdur. Əvvəlcə itkilər olacaq. Amma təcrübə qazandıqca onların sayı və miqyası azalacaq.

Mümkün risklər

Problemlərdən qaçmaq üçün bir sıra suallara dürüst cavab vermək lazımdır. O:

1. Biz düzgün işlər görürükmü? Bu biznes riskidir.
2. Bizə lazım olanı həyata keçirə bilərikmi?
3. Layihə bu platformada işləyəcək. Bu texniki riskdir.
4. Kifayət qədər pul varmı və vaxtımız olacaqmı? Bunlar icra şərtləri və qiymət riskləridir.

Bu vəziyyətdə bilik tələb olunur. Onlara risklərin əksi kimi baxmaq olar. Əhəmiyyətli qeyri-müəyyənlik səviyyəsi müəyyən edildikdə, biz bilik əldə edirik - məsələn, interfeys prototipləri və ya texniki təcrübələr yaradırıq. Onsuz da onlara sahib olduğumuz üçün hansı istiqamətdə hərəkət etməyimiz barədə qərarlar qəbul edirik.

Necə öyrənmək olar?

İT sənayesi son dərəcə sürətlə inkişaf edir və sonda uduzmamaq üçün daim öyrənmək, bacarıqları artırmaq və iş səmərəliliyini artırmaq lazımdır. Buna görə də təlim və tətbiq məsələləri həmişəkindən daha aktualdır. Haradan başlamaq lazımdır? Ən çox ən yaxşı variantdır- bu, Agile-in artıq tətbiq olunduğu şirkətlə əməkdaşlıqdır. Bu vəziyyətdə təlim çevik inkişafın nə olduğunu şayiə ilə bilməyən insanlar tərəfindən aparılacaq. Ancaq təəssüf ki, bu həmişə mümkün olmur. Çox vaxt Agile-nin nə olduğunu bilən üçüncü tərəf mütəxəssisi cəlb olunur. Bu yanaşmanın həyata keçirilməsi onun nəzarəti altında həyata keçirilir. Düzdür, belə bir mütəxəssisin xidmətləri pula başa gəlir. Amma həqiqətən alsanız bilən insan, onda bütün xərclər gözəl şəkildə ödəyəcək. Həqiqətən də müasir dünyada işçilərin səmərəliliyi mühüm rol oynayır.

Gələcək üçün nə gözləyir?

Proqram təminatının inkişafı metodologiyaları daim inkişaf edir. Fəaliyyətlərin və işlərin səmərəliliyini artırmaq üçün yeni yollar və imkanlar axtarmaq. Gələcəyin bizi nə gözlədiyini söyləmək olduqca problemlidir. Yəqin ki, çevik inkişaf sistemi avtomatlaşdırma vasitələri ilə inteqrasiya olunacaq istehsal prosesləri. Məsələn, şirkətin yerləşdiyi yerdən uzaqda olsa belə, problemləri həll etmək mümkün olacaq. Bir çox cəhətdən gələcək yeni ilə müəyyən edilir İnformasiya texnologiyaları. Axı, onlar yarandıqda, onlarla işləməyin yeni üsullarını mənimsəmək lazımdır. Və bu vəziyyətdə bir dövrə bağlanan bir inkişaf var.

Nəhayət

Beləliklə, çevik olanlara ekskursiya başa çatdı.Lakin xatırlatmaq lazımdır ki, nəzəriyyə bir şeydir, təcrübə isə tamam başqa şeydir. Daim yaranan yeni informasiya texnologiyaları böyük developer icmasına meydan oxuyur. Komandanızı necə daha səmərəli edə bilərsiniz? Bu sualın cavabını hər kəs özü tapır. Burada təqdim olunan məlumatlar onurğa sütununu yaratmaq üçün istifadə edilə bilər. Ancaq praktikada mövcud modellə işləməli və vəziyyəti mövcud çağırışlara uyğunluq vəziyyətinə gətirməli olacaqsınız. O zaman komanda qarşıya qoyduğu məqsədləri səmərəli şəkildə həyata keçirə biləcək.

Müasir idarəetmədə “çevik” idarəetmə modeli üç fərqli kontekstdə nəzərdən keçirilir ki, bu da (hər biri özünəməxsus şəkildə) Çevikliyin nə olduğunu müəyyən edir.

Çevik Mənasının Üç Cildi

Birinci, daha dar mənada, bu termin proqram təminatının inkişafı sahəsində 2000-ci illərin əvvəllərindən, sənaye mütəxəssisləri ABŞ-ın Yuta ştatında, dağ kurortunda toplaşaraq, proqram məhsullarının yaradılması üsullarını və təcrübələrini müzakirə etdikdə istifadə edilmişdir. tələbat var. son istifadəçi. Həmin görüşün nəticəsi, ilk növbədə, müəlliflərin dar fəaliyyət sahəsinə aid olan, lakin potensial olaraq bəzi digər biznes layihələrinə də şamil edilə bilən 12 prinsipdən ibarət proqram təminatının inkişafı Manifestidir (Agile Manifest).

Termin ikinci, daha geniş mənasında Agile prinsipləri demək olar ki, istənilən biznesin aparılmasına tətbiq edilir və komponentlər kimi, məsələn, “yalın başlanğıc” (Lean Startup) anlayışında istifadə olunur. Bu mənada, Çevik Model bir neçə addımda xarakterik bir nümunəni izləyən çevik layihə inkişaf metodologiyasına əməl etmək kimi başa düşülür.

1. Layihə üzərində iş iterasiyalarda - qısa dövrlərdə (sprintlər) həyata keçirilir. (Proqram təminatının inkişafı vəziyyətində bu dövrlər 1 həftədən 1 aya qədər dəyişir).
2. Hər dövrün sonunda artıq biznesdə istifadə oluna bilən məhsul buraxılır. Proqram təminatı üçün proqram və ya onun yalnız bir hissəsi belə məhsula çevrilə bilər, lakin hətta “xam” proqram təminatı praktikada sınaqdan keçirilə bilər və edilməlidir.
3. Məhsul, tərtibatçılarla daimi əlaqə saxlayan müştəri və ya istifadəçilər tərəfindən sınaqdan keçirilir. rəy. Layihə boyu müştəri yönümlü yanaşma tətbiq olunur (bütün təkrarlamalar).
4. İstənilən şərh tez bir zamanda revizyona daxil edilir və məhsulun inkişafını dərhal düzəltməyə imkan verən dəyişikliklər xoşdur, çünki bu, qlobal sistem səhvlərini toplamağa imkan verir.

Üçüncü, daha geniş mənada, Çevik Toyota zavodlarında istifadə edilən idarəetmə modelinin bir hissəsidir və indi demək olar ki, istənilən uğurlu istehsalın idarə edilməsinin əsas komponentlərindən biridir. Bu kontekstdə Agile-in əsasları digər kontekstlərdə texnologiyanın başa düşülməsinin əsaslarına bənzəyir.

Toyota zavodlarında son istehsal formatının qurulması ilə bağlı sürətli rəy konveyerin dayandırılmasına təşəbbüs göstərə bilən və yenidən konfiqurasiya üçün düzəlişlərin müəllifi tərəfindən təmin edilmişdir. istehsal dövrü. İstehsal miqyasında, Çevik transformasiya, əgər məhsul müştərinin cari ehtiyaclarına canlı cavabın nəticəsidirsə, bütün istehsal fəaliyyətinin yenidən qurulmasına səbəb ola bilər. Belə ki, əgər fabrik plastik qablar istehsal edirsə və müştəri rəyi vedrələrə ehtiyac olduğunu göstərirsə, onda nüansların paralel tənzimlənməsi (qulpun forması, ölçüsü, rəngi) ilə sürətli uyğunlaşma yalnız Çevik idarəetmə üslubunda olacaq (digər prinsiplərə əməl olunarsa).

Çevik İdarəetmə Prinsipləri

Layihə idarəçiliyində çevik bir iş prosesinin idarə edilməsi modeli kimi dünyada minlərlə komanda tərəfindən istifadə olunur və aşağıdakılar hər yerdə mövcuddur: fərqləndirici xüsusiyyətlər bu yanaşma:

1. İstehlakçı və onun nəticənin yaradılmasında iştirak dərəcəsi məhsulun fərdiləşdirilməsi üçün həlledicidir.
2. Komandalar qərar qəbul etmək üçün yüksək effektiv və vahid olmalıdır.
3. Mərhələli və dövri iş prosesin əsasını təşkil edir. Layihə bütövlükdə layihənin tamamlanmasından əvvəl müəyyən bir tarixə qədər tamamlanan kiçik hissələrə bölünür.
4. Performansın qiymətləndirilməsinin əsas məqsədi tez-tez aralıq layihə vəziyyətlərini təqdim etməkdir.
5. Komanda öz işində Pareto qanununa əsaslanır, buna görə səylərin 20% -i 80% səmərəlilik verir ki, bu da nəticəni istehlakçıya təqdim etməzdən əvvəl hər bir fərdi dövrü mükəmməlliyə çatdırmamağa imkan verir. Məhsul hər yeni iterasiya ilə təbii şəkildə yaxşılaşır.
6. Növbəti mərhələyə keçməzdən əvvəl bir mərhələnin tamamlanmalı olduğu güman edilir.

“Çevik” yanaşma bir-birindən fərqlənən, lakin Agile ideyalarını özündə birləşdirən bir sıra metodoloji təcrübələr üçün əsas olmuşdur: Scrum, Kanban, Lean, Crystal və s. Məsələn, Scrum metodologiyası demək olar ki, həmişə proqram təminatının inkişafı üçün vahid layihə idarəetmə sistemi kimi Agile ilə birlikdə.

Scrum metodu "çevikliyin" xüsusi əməliyyatlarda necə tətbiq oluna biləcəyini nümayiş etdirir. Beləliklə, məsələn, layihə tələbləri ilə iş dörd "artifakt" istifadə edərək həyata keçirilir:

• Məhsul ehtiyatı vahid şablon (İstifadəçi Hekayəsi) üzrə yaradılmış və prioritetlər üzrə çeşidlənmiş tələblər siyahısının formalaşmasını nəzərdə tutur. Tələblər yoxdursa, layihə başa çatır.
• Sprint geriliyi növbəti sprintin (mərhələsinin) tələbləridir, sprint zamanı yeni tələblər əlavə etmək imkanı olmadan tapşırıqlara bölünür. Agile idarəetmə növü olan komandanın növbəti mərhələ üçün götürdüyü öhdəliklər lövhədə (Kanban adlanır) qeyd olunur.
• Sprint Məqsədi - sprintin ümumi məqsədi - alternativ qərarlar qəbul etmək üçün təlimat.
• Sprint Burndown Chart - "burndown chart". Bu, komandanın mərhələ ərzində nə qədər irəlilədiyini göstərir.

Çevik layihə idarəetmə formatı hər kəs üçün uyğun deyil və həmişə deyil. Fəaliyyəti dəyişməz qanunvericiliyə əsaslanan, məqsəd və həyata keçirilməsində mühafizəkar olan dövlət strukturlarının belə optimallaşdırmaya ehtiyacı yoxdur.

Ümumi Çevik Tətbiq Səhvləri və Yanaşma Çatışmazlıqları

Bəzi hallarda nəzərə alınan eyni amil güclü nöqtə yanaşma başqalarında problem yarada bilər. Beləliklə, "çeviklik" tez-tez diqqətin bulanmasına səbəb olur. Metodoloji əsas olmadıqda, istinad nöqtələrinin itirilməsi və ikincil üçün əsasın əvəz edilməsi var. Bu cür “təhriflərin” qarşısını almaq üçün onlar layihənin icrası zamanı əməliyyatların məzmununu və ardıcıllığını daha ciddi tənzimləyən hazır metodologiyalardan və ya öz inkişaflarından istifadə edirlər. Lakin, bu halda, Agile-idarəetmə də səhv edə bilər.

Ümumi icra səhvlərinə aşağıdakılar daxildir:

Ümumilikdə çevik yanaşmanın tətbiqinin bütün çətinliklərinə baxmayaraq, müştəri yönümlü yeni məhsulun sürətlə yaradılmasına gəldikdə, ənənəvi “ləng” sənayelərdən daha effektivdir. Ənənəvi istehsal qırmızı lentə düşsə də, Agile yanaşması layihənin başlanmasından dərhal sonra təbii axını təmin edir.

Başlamaq. Scrum və Agile - fərq nədir? Bir sözlə, Çevik bir fəlsəfədir, proqram təminatının hazırlanmasına çevik yanaşmalar ailəsidir. Scrum belə bir yanaşmadır. Onun bir qardaşı var - Kanban. Bu həm də Agile-də istifadə olunan yanaşmadır.

Elena Truskova deyir:

Bu həftə mən iki günlük Çevik/Scrum təlimi ("çevik" və "scrum" kimi oxunur) keçdim. Çevik proqram təminatının inkişaf etdirilməsi metodologiyaları haqqında çoxlu mücərrəd və o qədər də çox olmayan ədəbiyyat yazılmışdır, mən çox oxudum. Ancaq yalnız iki günlük mövzuya daldıqdan sonra, nəhayət, bu qeydi yazdığım mövzu haqqında əsas anlayışa sahib oldum.

Agile və Scrum, istifadəçi üçün müntəzəm və tez-tez maraqlı olan məhsulu buraxacaq şəkildə komanda işi prosesini təşkil etməyə kömək edir.

Bəzi banklarda çeviklik sayəsində istifadəçilərə ideyanın yolu iki ildən altı aya endirildi - digər şirkətlərdə altı aylıq inkişaf dövrü üçə sıxıldı. Bizim gərgin dövrümüzdə bu, doğrudur rəqabət üstünlüyü xüsusilə kiçik oyunçular üçün.

Scrum prinsipləri tamamilə hər şeyə tətbiq edilə bilər: məsələn, yaradıcı məhsul üzərində işləmək. Bu, əlbəttə ki, "kanonik çevik" deyil, Scrum evangelistləri dişlərini qıcayacaqlar, lakin prosesləriniz daha şən hərəkət edəcək. Dama yoxsa getmək?

Agile və Scrum-dan bəziləri hətta fərdi işə götürülə bilər. Yazıların müntəzəm dərcini təmin edin, ifaçının yükünü ölçün, gələcək vəzifələri vaxt baxımından qiymətləndirin və görülən işin keyfiyyətini təhlil etməyi unutmayın - baxın, bizim üçün hər şey artıq düşünülüb. Həyata keçirmək qalır.

Çevik

(İngilis agile - "çevik, ağıllı, çevik")

Çeviklik konsepsiyası:

"İnkişaf" sözünün əvəzinə fəaliyyət növünüzü əvəz edin - və bu prinsiplər yaxın və başa düşülən olacaqdır.

“İşləyən məhsul tərəqqinin əsas göstəricisidir”, “lazımsız işi minimuma endirmək sənəti kimi sadəlik” və “insanlar və qarşılıqlı əlaqələr proseslər və alətlərdən daha vacibdir” - bu ağlabatan səslənirmi?

Scrum

(ing. scrum - reqbidə top uğrunda mübarizədə əzmək)

Burada xatırlatmaq yerinə düşər ki, bu mənim Scrum-a şəxsi və subyektiv baxışımdır. Burada mən Scrum elementlərinin həm İT-dən uzaq, həm də yaradıcı layihələrdə tətbiqi haqqında düşünürəm fərdi iş(məsələn, bir blogun üstündə). Bunun üçün bir çox dəqiq detallar buraxılmalı olacaq; Mətni sadə saxlamağa və oxucunu terminologiya ilə həddən artıq qidalandırmamağa çalışıram.

Scrum-un sərtliyi strukturdadır. Ayrılıqdan daha yaxşı işləyən müəyyən yanaşmalar dəsti var. Bir şeyi çıxarın və sizin üçün istifadə edin, ümid edirəm heç kim qadağan etməz.

Scrum adətən istifadəçilər və müştərilər üçün dəyəri olan müəyyən bir məhsulun olduğu yerdə baş verir və siz məqsədə gedən yolda düzgün istiqamətdə hərəkət etdiyimizi və ya kursu düzəltməli olduğumuzu mümkün qədər tez başa düşməlisiniz. Scrum formatı növbəti versiyanı daha tez-tez buraxmağa, müntəzəm rəylər almağa və məhsulu tez bir zamanda təkmilləşdirməyə, həmçinin iş prosesini təkmilləşdirməyə imkan verir.

Bir komandada işləyirsinizsə, Scrum prosesin bütün iştirakçılarından bir-birini əvəz etmək üçün səy göstərməyi, qonşu xəstədirsə, sallanan tapşırığı "götürmək" bacarığını, bacarıq mübadiləsini və məhsul üçün kollektiv məsuliyyəti tələb edir. Scrumda fərdiyyətçilik azdır. Qərarlar kollektiv şəkildə (sərt prinsiplərə uyğun olaraq) qəbul edilir, əgər komanda düzgün yolda qərarlaşdığına əmindirsə, heç kim onlara təzyiq göstərə və başqa həll yolu seçməyə məcbur edə bilməz.

Scrum-a bu cür inamın olması qorxulu deyil, çünki hər bir yürüş tam olaraq bir sprint (aydın bir müddət, adətən bir həftədən dörd həftəyə qədər) davam edir. Sprint başa çatdıqdan sonra bir təhlil anı gəlir: biz bunun öhdəsindən necə gəldik? Növbəti dəfə daha yaxşı nə etmək olar?

Buna görə də hamımız inamla səhv istiqamətə qaçsaq belə, sprintin sonunda onu düzəltmək və bizi yanlış istiqamətə aparan şeyi düzəltmək imkanımız olacaq. Scrum-dakı komanda özünü təşkil edir və özünü tənzimləyir.

Scrum-da komanda

Scrum komandasının standart ölçüsü 7 plus və ya mənfi 2 nəfərdir. Bu, beşdən doqquza qədərdir. Skrum miqyası var: 25 komandadan nəhəng bir tapşırıq üzərində iş sistemi qura bilərsiniz. Lakin Scrum-un əsas vahidi komandadır.

Hər komanda var:

• iştirakçılar (İT vəziyyətində - tərtibatçılar, sizdə olan bu yeddi nəfər kimlərdir - özünüz qərar verin)
• məhsul sahibi (məhsul sahibi, məhsul sahibi). Onun rolu: bazarı və istifadəçini başa düşmək, biznes və istifadəçilərin dilində tapşırıqlar tərtib etmək, dəyər və faydanın hansı istiqamətdə inkişaf etməli olduğunu bilmək, məhsulun inkişafı üçün tapşırıqlar icad etmək və seçmək. Məhsul (komanda deyil) lideri kimi bir şey.
• scrum master (skrum master, scrum evangelist). Onun rolu: prosesi izləmək, komandanın daxili həyatını müşahidə etmək, insanları motivasiya etmək, maneələri aradan qaldırmaq. Bir növ məşqçi kimi.
  Komandanın ətrafında istifadəçilər və maraqlı tərəflər (maraqlı tərəflər, müştərilər) var. Məhsul sahibi məsləhət üçün bu insanların yanına gedir.

Cihaz sprint

Scrum işi sprintlərdən ibarətdir. Bütün sprintlər eyni şəkildə qurulur. Güman edilir ki, hər növbəti sprint ilə komanda daha əməkdaşlıq və səmərəli olur. Scrum-da siz səhvlərinizdən öyrənirsiniz, lakin tez - hər sprintdə dəqiq nə etdiyinizi və onu necə düzəltmək istədiyinizi təhlil edirsiniz.

Məhsul sahibinin istifadəçiləri xoşbəxt etmək üçün biznes ideyalarının siyahısı var. Bu, "məhsulların geridə qalması" (məhsul ideyalarının siyahısı) adlanır. Burada fikirlər əhəmiyyət və əhəmiyyətə görə sıralanır.

Hər bir sprintin sprint geriliyi (sprint geriliyi, sprint üçün tapşırıqların siyahısı) var - komandanın növbəti sprintdə etmək qərarına gəldiyi ideyaların çeşidlənmiş siyahısı. Scrum-un mənası odur ki, komanda özü hər tapşırığın mürəkkəbliyini qiymətləndirir və növbəti sprintə hansı tapşırıqların daxil ediləcəyinə qərar verir.

Sprintdə tapşırığın komandaya məlum olan çəkisi var (bunun nə qədər çəkəcəyi məlumdur), ona ifaçı bağlıdır, başa düşüləndir və vacibdir. Bir tapşırığın nə qədər vaxt aparacağını bilmirsinizsə, onu daha kiçik hissələrə ayırmalısınız.

Həyatlarının əvvəlində komanda həmişə pis planlar qurur. Bu, obyektiv reallıqdır. Lakin o, sprintdə bacardıqlarının statistikasını aparır və zamanla daha dəqiq planlaşdırır. Ona sprintin son görüşü kömək edir - retrospektiv. Orada siz gedən sprintin zəif tərəflərini müzakirə edə və bunu fərqli şəkildə etməyin yollarını tapa bilərsiniz.

Adətən sprintə 5 artı və ya mənfi 2 fikir uyğun gəlir. İdeyalar çox böyükdürsə, komanda onları bölür ki, hər sprintdə kiçik bir şey göstərilsin.

Scrum-da ideyalar istifadəçi hekayələri (istifadəçi hekayələri, istifadəçilər haqqında hekayələr) adlanır və aşağıdakı kimi formalaşdırılır: “Mən (rol?) istəyirəm (nə?) (niyə?) üçün”. Beləliklə, komanda təkcə funksionallığı deyil, həm də onun yaradılmasının mənasını və müəyyən bir rol üçün: istifadəçi, müştəri, alıcı görür.

Sprintin nəticəsi həmişə göstərmək üçün bir şeydir. Sprintin sonunda demoda komandanın işini göstərir.

Fikrimcə, Scrum prosesi komanda bloqunda işləməyə bənzəyir. Belə bir proses müntəzəmliyi qorumağa, müəlliflərin təcrübəsini bir araya gətirməyə və bunu edə bilməyəcəyiniz qədər işə götürməməyə kömək edəcəkdir.

Sprint strukturu

Sprint planlaşdırma ilə başlayır: komanda oturur və müzakirə edir: biz bu fikri qəbul edirik, onu qəbul etmirik. İT-də bu proses bir neçə saat uzana bilər, çünki müzakirə detallara qədər gedir. Bir blogla işləmək vəziyyətində, bu, mövzuların müzakirəsinə və məqalələr planına çevrilə bilər, sonra oturub yazmağa buraxılacaq - nə yazdığımızı, nə vaxt və niyə yazdığımızı başa düşmək.

Hər gün 15 dəqiqəlik bir stand-up iclası (stand-up iclası, daimi iclas) olur. Dayanarkən bunu etmək vacibdir: kimsə danışırsa, qalanları fəsahətli şəkildə ayaqdan ayağa keçəcək və qulağını cızacaq. Siz hər hansı bir obyektdən istifadə edə bilərsiniz ki, eyni anda yalnız bir iştirakçı danışsın və onu bir dairədə keçirə bilərsiniz.

Hər bir stand-up iştirakçısı növbə ilə üç suala cavab verir:

• dünən nə etdim
• bu gün nə edəcəm
• məni nə ləngidir

Prosesdə bağlı olan bütün təfərrüatlı söhbətlər stand-up hüdudlarından kənara çıxır. Stand-up, problemləri tuta biləcəyiniz və ya nədənsə bir həmkarımla eyni şeyi eyni vaxtda etdiyimizi öyrənə biləcəyiniz bir nöqtədir, yəni birimiz başqa bir şey edə bilər.

Ümumiyyətlə, bütün bu aydın davranış qaydalarının saxlanması Scrum Master tərəfindən həyata keçirilməlidir. Bunlar adətən texnologiyanın ideoloqlarıdır, ona inanırlar və birlikdə keçirdikləri vaxtın maksimum səmərəliliyi üçün bir proses qurmağa hazırdırlar. Scrum Master olmadan proseslər mümkün olan minimuma enəcək, çünki insan tənbəl və qənaətcildir.

Sprintin sonunda, sprint zamanı nələr yarada bildiyimizi göstərən demo (demo, nümayiş), məhsulun geriyə baxılması ilə sprint baxışı (sprint baxışı, sprint baxışı) və NƏ etdiyimiz haqqında danışan, eləcə də retrospektiv (retro ) - bütün sprintdə ən yaxşı şəkildə etmədiyimiz və daha da təkmilləşdirmək istədiyimiz şey - bunu NECƏ etdiyimiz haqqında.

"Bir ağacı kəsmək üçün səkkiz saatım olsaydı, altı saatımı baltanı itiləmək üçün sərf edərdim." (Odunçuya və Prezident Abraham Linkolna aid edilir)