Çoxları bu suala cavab verərkən Kanban-ı inkişaf metodologiyası alandırırlar. Görəsən, bu həqiqətən belədir? Mən bu məsələyə aydınlıq gətirmək istərdim.
Vahid axın ideyası
Əvvəla, bunun nə olduğunu və hansı məqsədlərlə yarandığını başa düşmək lazımdır. Kanban Toyota zavodlarında məhsul istehsalı prosesinin (bu halda, avtomobil) daha şəffaf olması üçün layihə menecerləri tərəfindən icad edilmişdi. O dövrdə istifadə edilən klassik sxem bir sıra ehtiyat hissələrinin bir-biri ilə əlaqəsi olmayan müxtəlif emalatxana və ya müəssisələrdə istehsalını nəzərdə tuturdu. Tam yığıma qədər günlər, həftələr və hətta aylar keçə bilərdi. Beləliklə, şöbələrdən biri səhvə yol verdikdə, bu yalnız bir neçə həftə sonra aşkar olunurdu və bütün bu vaxt ərzində qüsurlu komponentlər hazırlanırdı. Bu vəziyyətdə çox böyük itkilər olurdu: ödənilmiş iş, korlanmış material, daşınma, saxlanma, emal və vaxt. Nəticədə vahid axın yaratmaq ideyasına ehtiyac yaranır.
Axın tamamlanmamış tapşırıqlar sayəsində boşdayanmanın olmadığı istehsal prosesidir. Bu zaman fasilə olmur, bu yalnız irəliyə doğru gedən bir hərəkətdir. Əsl estafet yarışı: tapşırıq, yarışdakı çubuq kimi, şöbələr tərəfindən dəqiqlikdə əldən-ələ ötürülür. Bu zaman əvvəlki mərhələnin səhvləri dərhal özlərini göstərir. Bu, lazımsız xərclərin qarşısını alır, məhsulun keyfiyyətini yüksəldir, qiymətini azaldır və icra vaxtını qısaldır.
Belə bir axının olması üçün nə etmək lazımdır? İlk növbədə, klassik itələmə modelini dartma modeli ilə əvəz etmək lazımdır. Bu nə deməkdir? Yəni istehsal prosesinin hər növbəti mərhələsi əvvəlkinin nəticələrini qəbul etməyə hazırdır, müvafiq olaraq, ötürücülük imkanlarına görə bərabərdir və ya ondan irəlidədir.
Misal üzərində izah edək.
Kanban-dan istifadə nümunəsini nəzərdən keçirək. Məsələn, istehsal zamanı iterasiya üsulundan istifadə edən adi bir İT şirkətimiz var və iş prosesini izləmək üçün sprint daxilində Kanban lövhəsindən istifadə olunur.
To do — sprint backlog (yaxın dövr üçün işlərin əvvəlcədən müəyyənləşdirilmiş siyahısı).
In progress — hazırda icra olunan tapşırıqlar.
Ready for deploy — artıq yerinə yetirilmiş, lakin sınaqlar üçün təqdim edilməmiş tapşırıqlar.
QA — sınaqlara hazır tapşırıqlar.
PO/PM approving — hazır tapşırıqlar layihə sahibi və ya meneceri tərəfindən yoxlanılır.
Done — cari sprint-in yerinə yetirilmiş (tamamlanmış) tapşırıqları.
Burada sprint prosesləri bu qaydada həyata keçirilir: işə başladıqda icraçı tapşırığı To do-dan aşağı In progress-ə çəkir. Eyni vaxtda onun yalnız bir tapşırığı olur, belə ki, tapşırıqların paralel yerinə yetirilməsi müsbət nəticə vermir. Öz işini bitirdikdən sonra, o tapşırığı Ready for deploy sütununa çəkir.
Bu andan başlayaraq sınaqların aparılması şöbəsi işi öz üzərinə götürür. İş QA sütununa gəlib çıxdıqda mühəndis bild, server və digər qurğular üzərində sınaqlara başlayır. Bunun üçün, məsələn, Jenkins kimi davamlı inteqrasiya alətinə malik olmaq ideal olardı. Həmçinin sadəcə icraçıdan bild yığmaq və ya serveri yeniləməyi xahiş etmək də olar. Sınaqlar müsbət nəticələndikdə tapşırıq PO/PM approving sütününa keçir, burada final təsdiqini alır və sonuncu Done sütununa ötürülür. Tapşırıq sınaqlardan yaxşı keçmədikdə, müvafiq rəylərlə yenidən To do sütununa düşür. Bug report-dan sonra da prosesin müddəti eynidir.
Bu prosesi qurmaq üçün bütün komanda üzvlərinin notifikasiyaları düzgün qurulmalıdır. Belə olduqda, icraçılar arasında tapşırıqların ötürülməsi zamanı boşdayanmanın qarşısı alınır.
Həmçinin kodun Ready for deploy sütununa qısamüddətli keçidi (çatdırılma) arzuolunandır, bu daha operativ əks əlaqəni təmin edəcək. Tapşırıqların sütunların hər hansı birində toplanması “şüşə boynu” adlanır. Bu o deməkdir ki, bu sahədə keçicilik imkanı kifayət deyildir, səbəbi tapmaq və həll etmək lazımdır.
Sürətli əks əlaqə üçün QA mühəndisi DB, API, front-end, back-end kimi ayrı-ayrı komponentləri sınaqdan keçirtmək imkanına malik olmalıdır.
Niyə məhz Kanban?
Bu alətlə şirkətin işləri uğurla nəticələnir, hər kəs ümumi xəritədə öz yerini bilir.
Onun qarşısında Kanban-ın bütün aşağıdakı imkanları açılır:
— Hər müəyyən tapşırığın icra vaxtının, nəticə etibarilə bütünlükdə layihənin müddətinin qısalması;
— Sınaqların aparılması şöbəsindən sürətli əks əlaqə;
— Sınaqçıların erkən cəlb edilməsi sayəsində təhvil zamanı lazımsız baş ağrıların qarşısının alınması;
— Hazırlanma prosesində komandanın fəal iştirakı;
— Boşdayanmanın azalması və inteqrasiyanın avtomatlaşdırılması sayəsində layihənin vaxtında yerinə yetirilməsi;
— Yüksək keyfiyyətli məhsul.
Kanban-ı metodologiya adlandırmaq düzgün deyil, çünki biz layihəni əvvəldən axıradək həyata keçiririk və burada sənədləşmə və görüşlər haqda bir kəlmə belə yoxdur. Kanban problemləri həll etməyə kömək edən alətdir və bu alət cari prosesin hansı mərhələsində problem olduğunu aydın şəkildə göstərir. Kanban-dan düzgün istifadə edin.
