Agile Transformasiya...Agile transformasiya səyahətində əməkdaşlar tərəfindən yaranan müqaviməti aradan qaldırmaq üçün Agile Düşüncəli menecer və liderlər yetişdirilməlidir

Sourced Agile® Modeli ilə Agile Transformasiya Smart Solutions şirkəti nümunəsi

C A S E S T U D Y

2020

SƏHİFƏ 1

C A S E S T U D Y Agile Transformation with Sourced Agile® Model

WWW.SOURCEDAGILE.COM

[email protected]/ +994(70) 5254039 www.sourcedagile.com

.

RƏQƏMSAL MƏHSULLAR

Əvvəllər sadəcə proqram təminatı adlandırdığımız elektron

məhsullar, son dövrdə ən gəlirli sahələrdən birinə çevrilmişdir. Buna

görə də proqram təminatlarının bazar dəyərini artırmaq üçün daha

özəl bir termin vermək lazım idi: “Rəqəmsal Məhsullar”. Rəqəmsal

Məhsulların hazırlanması üçün ilk öncə “Məhsul Hekayəsi”

qurulmalıdır. Bədii hekayələrdə olduğu kimi burada da sujet xətti,

fəsillər, paraqraflar, əsas hədəf nöqtəsi, rollar, kulminasiya nöqtəsi

və s. olmalıdır. Lakin bədii hekayədən fərqli olaraq “Məhsul

Hekayəsi” real hadisələr üzərində qurulub səhnələşdirilməlidir.

Rəqəmsal Məhsullar təzahür (virtual) məhsul olduğu üçün, onun

prototipini, modelini, 3D maketini və s. qurmaq mümkün deyil. Ona

görə də “Məhsul Hekayəsi” cümlələr ilə deyil 2-ölçülü şəkil, diaqram,

xəritələrlə ifadə edilməlidir. Ən qəliz və çətin məsələ elə məhz

şəkillərlə real hekayələri izah və təsvir etməkdir.

Agile Tansformasiya 1

Agile Transformasiya nədir?

Rəqəmsal Məhsulların tələb olan şərtlər altında ən qısa zamanda bazara çıxarılması prosesinə Agile deyə bilərik. Başqa sözlə desək Çeviklik.

Komanda şəklində baş-başa verib “Məhsul Hekayəsi” quraraq, rolları təyin edərək, aradakı kommunikasiya baryerlərini və müqavimətləri aradan qaldıraraq, sürətli və minimal xəta ilə proqram kodlarını yazaraq, avtomatik test edərək Rəqəmsal Məhsulun ən qısa zamanda, tələb olunan maddi və keyfiyyət göstəriciləri daxilində hazırlanması prosesinə Agile İdarəetmə deyə bilərik.

Ənənəvi idarəetmədən Agile İdarəetmə prosesinə keçidə isə Agile Transformasiya deyə bilərik.

SƏHİFƏ 2




Sujet-xətti Rəqəmsal Məhsulun tərkib hissəsi olan biznes proseslərin, informasiya axışının, iş axışının, master data analizinin və digər əməliyyatların paralel və ya ardıcıl təsvir olunmasıdır. Təsvirlər üçün müxtəlif UML diaqramlar və mock-up sistemləri mövcuddur.

Rollar şirkətin “Təşkilat Strukturunda” (Organizational Chart) mövcud olan bütün vəzifələrdən (şirkət rəhbəri, İR şöbəsi rəhbəri, əməliyyatçı, anbardar, kassir, operator və s.) ibarətdir.

Rəqəmsal Məhsullarda sujet xətti adətən a) səhifələr, b) hər bir səhifədə yerləşən komponentlərdən (xanalar), c) hər komponent üzrə şərtlər və qaydalar, d) API-lər, e) istifadəçi hüquqları, g) mesajlar, h) funksionallıq, e) istifadəçi interfeysi (User Interface), və digər subyektlərdən ibarət olur.

“Məhsul Hekayəsi” elə yazılmalıdır ki, onu həm biznes dünyasının nümayəndələri, həm də proqramlaşdırma dünyasının nüməyəndələri də (proqramçılar, testerlər, dizaynerlər, arxitektorlar və s) rahat başa düşməlidirlər.

“Məhsul Hekayəsi”ndə

Sujet Xətti və Rollar

Aşağıda göstərilən faktorlar müştəri

məmnuniyyətinə, biznes dəyərlərə, məhsulun

vaxtında təhvil verilməsinə, keyfiyyətə,

məhsuldarlığa, proseslərin daimi inkişaf

etdirilməsinə, layihənin daimi izlənilməsinə,

layihə tələbinin icrasına birbaşa müsbət təsir

etməlidir:

■ Biznes və IT əlaqəsinin möhkəmliyi

■ Dəyişikliklərin qısa zamanda nəzərə alınması

■ Proqram təminatının qısa zamanda təhvil

verilməsi

■ Proqram təminatının keyfiyyətinin daim

inkişaf etdirilməsi

■ Layihələndirmənin cari gedişini izləmək

■ Komandanın əhval-ruhiyyəsini yüksək tutmaq

■ Layihə risklərinin azaldılması və s.

.

“Məhsul Hekayəsi”nin

yazılmasında nəzərə alınacaq

əsas faktorlar

Time to Market Rəqəmsal Məhsulun hazırlanmasında “Məhsul Hekayəsini” qurmaq üçün ən önəmli və vacib amillərdən biri məhsulun ən qısa zamanda bazara çıxarılmasıdır. Yəni Time to Market. Məhsulu bazara ilk çıxaran çox zaman ilklər kimi bazarda lider oyunçu ola bilir. Time to Marketin icrasına mənfi təsir edən əsas amillər bunlardır:

■ Detallı sənədlərin tələbi ■ Kompleks planlama ■ Departamentlər arası dar-boğaz yaradan tələblər ■ Proqramçıların tez-tez kodlaşdırma kontentinin dəyişməsi ■ Dəyişikliklərin tez olması ilə Proqramçıların “beyinlərininin” Setup

Cost-larının artması ■ Proqram təminatının hazırlanması prosesinin qeyri-optimal olması ■ Test mühiti ilə zəif inteqrasiya

SƏHİFƏ 3




Rəqəmsal Məhsullun hazırlanması hekayəsində əsas obrazlar Proqramlaşdırma komanda üzvləridir. Əgər onlar olmasa “Məhsul Hekayəsini” qurmağın bir mənası yoxdur. “Məhsul Hekayəsi” ən azından 30-40% dəqiq hazır olandan sonra “səhnələşdirmək” – layihələndirmək olar. Göründüyü kimi Rəqəmsal Məhsulların layihələndirilməsi zamanı çox vaxt 60-70% risk ilə yola çıxılır. “Məhsul Hekayəsi”nin layihələndirilməsi zamanı adətən aşağıdakı çətinliklərlə rastlaşılır: ■ Proqramlaşdırma standartlarının yaradılması ■ Proqram təminatının dayanıqlığının artırılması ■ Xətaların minimuma endirilməsi ■ Komandanın idarə edilməsi ■ Müxtəlif şöbələr arasında ünsiyyət forması qurmaq ■ Digər şöbələr ilə proqramlaşdırma komandası

arasında ünsiyyət forması qurmaq ■ Rəqəmsal Məhsullar qısa zaman zərfində istifadəyə

verilməsinin tələb edilməsi ■ Məhsul hər zaman keyfiyyətli olmalıdır ki, müştəri

şikayət etməsin ■ Biznesin inkişafı üçün ixtiyarı dəyişiklik Rəqəmsal

Məhsulda öz əksini tapmalıdır ■ Şirkətdaxili burokratiya ■ Şirkətdaxili çoxlu sənədləşmə prosesləri ■ Qərar qəbul edən orqanların çox olması və s.

“Məhsul Hekayəsi”nin “Səhnələşdirilməsi”

LAYİHƏLƏNDİRİLMƏSİ

SƏHİFƏ 4




Agile Transformasiyada Rollar

Agile transformasiya yolçuluğunda orta səviyyəli menecerlərin rolu tam aydın olmur. Buna görə də rollar dəqiqləşdirilməlidir. Eyni zamanda fərqli-fərqli komandalar arasında əlaqə və onların idarə olunmasında ciddi çətinliklər yaranır.

Bürokratiyanın, çoxlu sənədləşmə proseslərinin, qərar qəbul edən orqanların çox olduğu bir şirkət Agile transformasiya müddətində ciddi müqavimət və çətinliklərlə üzləşirlər. Bunun üçün ilk öncə Agile Mind (Çevik Zəkanın) konseptinin rəhbər işçilər tərəfindən mənimsənilməsi çox vacibdir. Bura əsasən a) Agile haqqında ümumi məlumat, b) Agile dəyərlərinin aşılanması və c) daimi inkişaf (Continuous Development) və digər konseptlər daxil edilir.

Agile transformasiya səyahətində əməkdaşlar tərəfindən

yaranan müqaviməti aradan qaldırmaq üçün Agile

Düşüncəli menecer və liderlər yetişdirilməlidir.

Şəlalə prinsipi ilə idarə olunan müəssisələrdə Agile

prinsipləri tətbiq etmək üçün ciddi əmək tələb olunur.

Bunun üçün ilk öncə biznes tərəfdən tələblərin dəqiq

analiz edilməsi və vizuallaşdırılması çox önəmlidir.

Texniki Tapşırıq Sənədlərinin Hazırlanması

“Məhsul Hekayəsi”nin yazıldığı sənədə Texniki Tapşırıq deyilir.

Biznes dünyası ilə proqramlaşdırma dünyası arasında effektiv kommunikasiya yaratmaq üçün bütün tələbləri xırda tapşırıqlara kimi bölmək lazımdır. Əks halda proqramlaşdırma komandasına təhvil verilən texniki tapşırıq sənədi aydın olmayacaqdır. Bu halda proqramlaşdırma komandası ilə Məhsul Sahibi və Biznes Analist arasında mütəmadi görüşlər və dəyişikliklər davam edəcəkdir.

Unutmaq lazım deyil ki, proqramlaşdırma dünyasının terminologiyası ilə biznes düynasının terminologiyaları arasında 180 dərəcə fərq vardır. Heç bir proqramlaşdırma komandası maliyyə, satış, İR, satınalma və digər sahələrdəki terminologiya və prosesləri bilmək məcburiyyətində deyil. Onların işi və öhdəliyi verilən tələblər əsasında proqram təminatının kodlarının yazılmasıdır.

SƏHİFƏ 5




Müştəri tələblərini yüksək dəqiqliklə analiz edib və onları doğru

formada Proqramlaşdırma komandasının başa düşəcəyi dilə

tərcümə etmək 80-ci illərdən başlayaraq ən aktual məsələlərdən biri

olub. Bunun üçün yüzlərlə model və metodologiyalar təklif

edilmişdir. Şəlalə modeli, Scrum, XP (Extreme Programming),

Kanban, Scrum Kanban və digərlərini buna misal göstərə bilərik.

Sourced Agile® Modeli də bunlardan biridir. Demək olar ki, bütün

model və metodologiyalar a) müştəri tələblərini ən kiçik elementlərə

qədər parçalanmasını, b) onları tapşırıq (Task) formasında

proqramlaşdırma komandası arasında bölünməsi, c) tapşırıqlaırn

ardıcıl/paralel icra edilməsi, d) testlərin aparılması, e) dəyişik

tələblərinin (Change Request) icra edilməsi, f ) xətaların həll edilməsi

(Bug Fixing) və digər məsələləri özündə ehtiva edir.

Bütün modellər “Güclü oyunçuların olması, güclü komandanın

olması demək deyil” prinsipi ilə işləyirlər. Yəni güclü proqramçılar,

testerlər və dizaynerləri bir araya yığmaq, güclü proqramlaşdırma

komandası əmələ gətirməz. Onları bir araya yığaraq “paslaşmağı”

öyrətmək üçün müəyyən bir model/taktika seçilməlidir. Əks halda bu

komanda oyunu olmaz. Nəzərə alsaq ki, ölkəmizdə Proqram

Arxitektoru (Software Architect, Solution Architect) və Proqramçı

Mühəndis (Software Engineer) və Senior Proqramçı qıtlığı var, hər

hansı bir Agile idarəetmə modelinin seçilməsində birmənalı diqqətli

olmalıyıq. İnkişaf etməkdə olan ölkələrdəki şirkətlər kadr

çatışmazlığından demək olar ki, əziyyət çəkmirlər. Hər bir halda

bütün dünyadan onlara istiqamətlənən beyin köçü mövcuddur.

Agile Transformasiyada Agile İdarəetmə Modelləri

SƏHİFƏ 6




Agile Transformasiyada 4/5/3 Prinsipini

Rəqəmsal Məhsulların istehsalatını əsasən 3 yerə bölmək olar:

1) Front-End, 2) Back-End və 3) Database (Verilənlər Bazası)

Bütün rəqəmsal texnologiyalar əsasən bu 3 canlı beyin istehsalatı üzərində qurulub. Onlara dəstək olaraq Keyfiyyətə Nəzarət, Testing, Analiz, və digərləri işin içərisinə daxil olur.

Mobil, Veb, desktop və digər platformadan asılı olmayaraq bütün Front-end Proqramçılara beyinlərini işlətmələri üçün 4 mənbə məlumatları zəruridir:

1. Page name (səhifənin adı) 2. Components and Labels (Xana və Sahələr) 3. Validation on each Components (Hər bir xanalar üzrə şərt və yoxlamalar, Required,

isİnteger, isString kimi) 4. Event on each Component (Hər bir xanalar üzrə hadisələr, onclick(), onchange() kimi)

İxtiyari tip layihələr üçün bütün Back-end Proqramçılar beyinləri işlətmələri üçün 5 mənbə məlumatları zəruridir:

1. Function/Method name (Funksiya/metodun adı) 2. Input parameters (Giriş arqumentləri) 3. Input Validations (Giriş arqumentləri üzərində şərtlər) 4. Operation Description (Əməliyyatın izahı) 5. Outputs (Çıxış məlumatları)

Verilənlər bazası ilə bağlı olan layihələrdə isə Verilənlər bazası mütəxəssisi beynini işlətməsi üçün minimum 3 mənbə məlumatları zəruridir.

1. Tablename (Cədvəlin adı) 2. Fieldname (Sahələr) 3. Relation (Əlaqələr)

4/5/3 Prinsipi məhz elə Front-end/Back-end proqramçının və Verilənlər bazası mütəxəssisinin beynini işlətməsi üçün zəruri məlumatların təmin edilməsidir. Kodlaşdırma bacarığı olan insanlar zəkalı və IQ-lu insanlardır. Əgər müştəri 20 səhifəlik bir layihə istəyirsə, 20x4 = 80 maddəni Front-end üçün təqdim etmək lazımdır. Əgər 80 maddədən 50-60 maddə başlanğıcda təqdim edilərsə, yerdə qalan 20-30 maddə isə ya Change Request-də və ya Bug kimi geri qayıdacaq. 4/5/3 Prinsipi ilə düşünmək o deməkdir ki, Front-end/Back-end proqramçı və ya Verilənlər bazası mütəxəssisi texniki tapşırığı oxuduğu zaman beyinləri işlətmələri üçün zəruri mənbə məlumatlarını əldə edə bilsinlər. Bunu 5 dəqiqə içində də etmək mümkündür, 1 həftə içində də. Ona görə də 4/5/3 Prinsipi əsasında danışmaq və düşünmək çox önəmlidir.

“Məhsul Hekayəsi” elə yazılmalıdır ki, oradan 4/5/3 prinsipi tətbiq edilə bilinsin. Yəni proqramçı komandanın hər bir üzvü özlərinə zəruri mənbə məlumatlarını əldə etməyi bacarmalıdırlar.

SƏHİFƏ 7




Sourced Agile® Modeli 2

Şəkil 1. Sourced Agile® Modelinin ümumi sxemi

Sourced Agile® Modelinin əsas məqsədi Rəqəmsal Məhsulların hazırlanması üçün “Məhsul

Hekayəsi”ni dəqiq qurmaq və rollar arasında effektiv ünsiyyət yaratmaqdır. Sourced Agile®

Modelinin üstün cəhətlərindən biri, məhz bu model əsasında hazırlanmış Sourced Agile®

User Story Management System-idir. Sourced Agile® Modeli və İdarəetmə sistemi

vasitəsilə, Rəqəmsal Məhsulun bütün səhifələrini, hər səhifədəki giriş məlumatları

(xanalar), onların xüsusiyyətləri, kriteriyaları, biznes prosesləri, master data analizləri,

dəyişikliklərin tarixçəsi və digər subyektləri rahat analiz edib və “Məhsul Hekayəsi”ni tam

qurmağın mümkün olmasıdır.

Şəkil 1-də Sourced Agile® Modelinin ümumi sxemi verilmişdir.

SƏHİFƏ 8




Proqramlaşdırma Şöbəsinin Rəhbəri (Development Team Leader) isə proqramlaşdırma komandasını

idarə edən şəxsdir. Onun proqramlaşdırma sahəsində texniki biliklərinin olması zəruridir. Yarana

biləcək hər bir texniki konfliktləri birbaşa özü və ya kimin həll edə biləcəyini təyin edən birisidir.

Proqramlaşdırma Şöbəsinin Rəhbərinin idarəetmə bacarıqlarının olması zəruridir. Proqramlaşdırma

Şöbəsinin Rəhbəri a) Proqram Arxitektoru (Software Architect, Solution Architect) və ya b) Proqramçı

Mühəndislərdən (Software Engineer) biri olması daha məqsədəuyğundur. Çünki onlar biznes

dünyasının tələblərini bilən və biznes dünyasının terminlərini başa düşüb effektiv ünsiyyət qurmağı

bacarırlar. Bura vəzifə üçün sadəcə proqramlaşdırma sahəsində dərin biliklərə sahib olmaq kifayət

etmir. Eyni zamanda biznes proseslərin xəritələnməsi və onların optimallaşdırılması ilə bağlı fikirlər

səsləndirməyi də bacarmalıdır.

Məhsul sahibi (Product Owner) tələbləri

bildirən şəxsdir. O, təmsil etdiyi qurumun,

şöbənin biznes proseslərini və ya məhsul ilə

bağlı qanunu, iş axışlarını, status dəyişikliyi və

digər məsələləri ən yaxşı bilən şəxsdir. Məhsul

Sahibi (Product Owner) Rəqəmsal Məhsulun

tətbiq ediləcəyi sahədə nə qədər çox bilik və

təcrübəyə malik olarsa “Məhsul Hekayəsi”ni

qurmaq bir o qədər dəqiq olar. Məhsul Sahibi

(Product Owner) adətən möcvud problemləri,

problemlərin özəyini analiz edə bilən,

kriteriyalar və həll yolları ortaya qoyan birisidir.

Məhsul Sahiblərinin (Product Owner) texniki

biliklərinin olması zəruri deyil. Lakin texniki

biliklərin olması qənaət bəxş edəndir. Eyni

zamanda Məhsul Sahiblərinin rəqəmsal

psixologiyaya aid bilik və bacarıqlarının olması

da arzuolunandır.

Məhsul Sahibi

Proqramlaşdırma Şöbəsinin Rəhbəri

Sourced Agile® Modeli 4 əsas roldan ibarətdir

Məhsul Sahibi

Biznes Analist

Agile Layihə Rəhbəri

Proqramlaşdırma Şöbəsinin Rəhbəri

SƏHİFƏ 9




Biznes Analist

Agile Layihə Rəhbəri

Biznes Analist (Business Analyst) isə biznes və proqramlaşdırma dünyası arasında effektiv ünsiyyəti quran birisidir. Onlar arasında tərcüməçi rolunu oynayır.

Sourced Agile® Modelində Biznes Analist (Business Analyst) müştəridən tələbləri User Story (İstifadəçi Hekayəsi) formasında qəbul edir. Hər bir User Story-nin səbəbinin göstərilməsi məcburi deyil, sadəcə məqsədə uyğun olmalıdır. User Story-nin səbəbi göstərildiyi zaman tələbin dəqiq hansı problemə aid olduğunu rahat müəyyən etmək mümkündür.

Ümumi olaraq isə Agile İdarəetmə metodolo-giyasında müxtəlif terminlər istifadə edilir: package, epic, issues, activities, user story, requirement və digərləri.

Sourced Agile® Modelində isə yalnız User Story istifadə edilir. Bununla həm ünsiyyəti rahatlaşdırmış oluruq, həm də fərqli-fərqli terminlərin istifadəsində çətinliklər yaranmamış olur. Sourced Agile® Modelində digər terminlərə User Story-lərin qruplaşdırmış halı kimi baxılır.

Agile Layihə Rəhbəri isə bütün layihənin idarə olunmasından məsuldur. Onun həm texniki, həm də idarəetmə bilik və bacarıqları olmalıdır. Məhsul Sahibi, Biznes Analist, proqramlaşdırma komandasının ümumi idarəedilməsi, uyğun idarəetmə metodunun seçilməsi, yaranan konfliktlərin həll edilməsi, squadlara komandaların təyin edilməsi, zamanların və risklərin hesablanması və s. məsələlərə görə məsuliyyət daşıyır. Agile Layihə Rəhbəri eyni zamanda bir necə layihəyə rəhbərlik edə bilər.

SƏHİFƏ 10




Sourced User Story

Sourced Agile® Modelində yalnız Sourced User Story-lər nəzərə alınır. Sourced User Story formatında olmayan tələblər qeyri-dəqiq tələblərdir. Sourced User Story olmayanda “Məhsul Hekayəsi”ni qurmaq mümkün deyil. Nəticə etibari ilə Layihələndirmə ciddi problemlər və risklər yaranır.

Sourced Agile® Modelində hər bir tələb bir sadə cümlədən ibarət olan User Story-lərdən ibarətdir. Hər bir

User Story SVO (Subject –Verb-Object) konseptinə uyğun olmalıdır. Yəni hər bir User Story-də mübtəda və

xəbərin olması zəruridir. Burada mübtəda Master Datanı göstərir. İcraçının görsətirilməsi isə arzuolunandır.

Məsələn: Sifarişlərin qəbul edilməsi, tenderin yaradılması, tenderin ləğvi və s. “Ödəniş”, “Tender” kimi

yazılmış qısa tələblər qəbul olunmur

Sourced Agile ® Modelində User Story-lər 3 hissədən ibarət olur:

■ Initial User Story (İlkin İstifadəçi hekayələri)

■ Bound User Story (Əlaqələnmiş İstifadəçi hekayələri)

■ Sourced User Story (Mənbəli İstifadəçi Hekayələri)

Müştərinin tələbləri qəbul edildiyi zaman ilkin statusda olur (Initial User Story). Əgər həmin User Story-ə

input əlavə etmək mümkündürsə, o zaman bu User Story-lərə Sourced User Story-lər statusu alır. Məsələn:

"Menu hissədə sarı rəngdən istifadə edilməsin" tələbi Front-end hissədə giriş məlumatlarından birinin izahını

əks etdirir. Buna heç bir input əlavə etmək mümkün deyil. Lakin "İşçi məlumatlarının daxil edilməsi"

tələbində işçinin adı, soyadı, yaşı və s. tipli input-lar (giriş məlumatlarını) vermək mümkündür. Bir halda ki

input məlumatlar daxil edilir, orda 100% şərt və yoxlamalar olmalıdır. Və nəhayət input-lar verildikdən

sonra, əməliyyatın izahı qeyd edilməlidir.

Sourced User Story-lərin daha rahat hazırlanması üçün Şəkil 2-də göstərilmiş Sourced User Story Card forması hazırlanmışdır. Sourced User Story Card 3 hissədən ibarətdir:

1. Input 2. Input Description 3. Process Description

Sourced User Story formasında yazılan bütün tələblər çox rahatlıqla Proqramlaşdırma komandasına ötürülə bilir.

Tələblər Sourced User Story formasında yazıldığı halda Change Request və Bug-lar daha rahat idarə olunur. Çünki Change Request-lər 1 - Input, 2 - Input Description, 3 - Process Description, Buglar isə yalnız 2 - Input Description, 3 - Process Description hissələrindən birində olur.

Biznes Analistlər yalnız Sourced User Story-ləri proqramlaşdırma komandasına tərcümə edir. Başqa sözlə desək, Biznes Analistin hazırladığı Texniki Tapşırıq məhz elə Sourced User Story Card-ların doldurulmuş variantından ibarətdir.

Sourced User Story formasında yazılan bütün tələblər avtomatik olaraq 4/5/3 prinsipini özündə ehtiva edir. Buna görə də Sourced Agile® Modeli ilə daha dəqiq “Məhsul Hekayəsi” yazmaq mümkündür.

SƏHİFƏ 11




Şəkil 2. Sourced User Story Card forması

Biznes Analist Sourced User Story-ləri Tapşırıq Tiplərinə (Task Type) tərcümə edir. Yəni hər bir Sourced User Story proqramlaşdırma komandası arasında Front-end, Back-end, Verilən bazası, UI/UX, Testing kimi tapşırıq tiplərinə bölünür.

Sourced Agile® Modelində proqramlaşdırma komanda üzvünün performansı hər bir Tapşırıq Tipləri (Task Type) üzrə Sərf Olunacaq Zaman (SOZ) ilə Sərf Edilən Zaman (SEZ) əsasında hesablanır. Əgər komanda üzvü təyin olunmuş tapşırıqlara Sərf Olunacaq Zaman (SOZ) ilə Sərf Edilən Zaman (SEZ) arasında fərq çox olarsa, o zaman bu müsbət hal kimi qiymətləndirilməməlidir. Hər bir kəs öz bilik və bacarlıqları əsasında dəqiq tərtib edilmiş Sourced User Story Card-a görə təqribi də olsa Sərf Olunacaq Zamanı (SOZ) deməyi bacarmalıdır. Bu vərdiş adətən 1-2 ay çəkir. 1-2 ay müddətdən sonra artıq hər bir komanda üzvi öz performasını hesablaya bilir. Hər bir Tapşırıq Tipi (Task Type) üçün SOZ-u təyin etmək çox önəmlidir. Çünki bu zamanlar əsasında hər bir Sourced User Story-lərə Sərf Olunacaq Zaman hesablanır. Eyni zamanda layihənin təqribi müddətini də hesablamaq mümkündür.

Bir layihədə Sourced User Story-lər nə qədər çox olarsa, bir o qədər risk payı azalmış olur. Başqa sözlə desək ümumi Product Backlog-dakı Initial User Story-lərin sayı çox olarsa, layihənin risk payı bir o qədər çox olur. Çünki initial User Story-lərdən nə qədər əlavə User Story-lərin çıxması məlum deyil.

SƏHİFƏ 12




Sourced Agile® Modelinin mövcud Agile idarəetmə yanaşmalarından fərqli və ən üstün cəhəti ondan ibarətdir ki, bu model əsasında Sourced Agile Training and Simulation Systemi qurulmuşdur. Yəni Sourced Agile® modelini öyrənmək və tətbiq etmək üçün hazır sistem mövcuddur. Sistemin cloud variantına www.sourcedagile.com saytından qeydiyyatdan keçməklə istifadə edə bilərsiniz. Sourced Agile® Training and Simulatin Systemi ilə yanaşı, Sourced Agile® User Story Management Sistemy-də mövcuddur. Bu sistemin iş prinsipini, növbəti fəsildə Smart Solution MMC-də tətbiqi hissəsində izah edilib.

Digər Agile Metodologiyaları ilə inteqrasiya

Sourced Agile® Modelinin həll etdiyi ən əsas problemlərdən biri

müştəri tələblərinin dəqiq təyin edilməsi və onları proqramlaşdırma

komandasına doğru formada təqdim edilməsidir. Sourced Agile ®

User Story Management System-ndə Rəqəmsal Məhsulların canlı

prototipini qurmaq, səhifələr arasında əlaqə yaraqmaq, master

datalar arasındakı əlaqə, iş axışını göstərmək (Flow Chart) imkanı

olduğu üçün müştəri tələblərini daha çox dəqiqliklə təyin etmək

mümkündür. Başqa sözlə desək “Məhsul Hekayəsi”ni yüksək

dəqiqliklə qurmaq mümkündür.

Sourced Agile® Modelinin həll etdiyi ən əsas problemlər

http://www.sourcedagile.com/

SƏHİFƏ 13




Smart Solutions şirkətində Agile Transformasiya

3

Smart Solutions şirkəti Smart Solutions Group-una daxildir. SMART SOLUTIONS - istehsalat, neft, pərakəndə satış və turizm də daxil olmaqla geniş biznes sahələrində müştərilərə inteqrasiya olunmuş müasir İKT xidmətləri təqdim edən aparıcı şirkətlərdən biridir. 2006-cı ildən bəri xüsusi həll yolları yaradır, tətbiq edir və dəstəkləyir. Müştərilərinə bizneslərini daha effektiv idarə etməyə və rəqəmsal dünyanın təklif etdiyi imkanlardan maksimum faydalanmağa köməklik edir. Onlara yeni məhsul və xidmətlər yaratmaqda, yeni bazar seqmentlərinə və yeni gəlir axınlarına çatmaq üçün dəstək olur. O, bazarda 12+ illik təcrübəyə sahib olan, müxtəlif beynəlxalq şirkətlərdə isə 15 illik təcrübəyə dayanan mütəxəssislər komandasıdır.

Şirkət Profili

Şirkətin REDIMO (satınalma və tədarük zəncirinin

idarə olunması), e-Bidding (Azərbaycan

Respublikasının qaydaları ilə tənzimlənən sifarişi

tədarük edən iştirakçılar (təchizatçılar) arasında

müasir ticarət onlayn platformasıdır), HRPayroll

(İR idarəedilməsi sistemi) və s. tipli məhsulları

vardır. Müştərilər siyahısına isə Kapital Bank, Pasha

Bank, AR Təhsil Nazirliyi, Azercell Telekom, BP,

Socar CAPE, Elektron Hökumətin İnkişaf Mərkəzi,

AGBank, Port of Baku, və digər böyük şirkətlər

daxildir.

Şirkət Portfiliosu

Smart Solutions şirkətinin rastlaşdığı ən böyük çətinliklərdən biri a) ənənəvi və mərkəzi idarəetmə sistemi ilə işləyən, b) bürokratiya və sənədləşmə işləri çox olan, c) şəlalə (waterfall) layihələndirmə metodu tətbiq edən müştərilərdən “Məhsul Hekayə”lərini analiz edib və onları Agile metodologiyası ilə işləyən daxili komanda üçün xırda tapşırıqlar halına gətirməkdir.

Digər çətinlik isə Proqramlaşdırma Prosesini (Software Development Process) optimallaşdırmaq və standartlaşdırmaqdan ibarət idi. Bunun üçün proqramlaşdırma komandasını “vahid bədən” kimi idarə etmək üçün Agile Metodologiyalarından biri tətbiq edilməli idi. Agile Metodologiyasının seçilməsi eyni zamanda doğru idarəetmə taktikasının seçilməsi deməkdir.

Məhsul Sahibləri ilə proqramlaşdırma komandası arasındakı iclasların sayını və hər iclasa sərf olunan zamanın minimuma endirilməsi və effektiv olması da ən əsas prioritetlərdən biri idi.

Çətinliklər

Azərbaycan bazarında Proqram Arxitektoru

(Software Architect, Solution Architect), b)

Proqramçı Mühəndis (Software Engineer), c)

Senior Proqramçı çatışmazlığı olduğu üçün Smart

Solutions şirkəti də güclü kadrların

formalaşdırılmasında çətinlik çəkir. Buna

baxmaraq, şirkət 60+ güclu oyunçuları bir araya

toplamağa nail olmuşdur. İndi isə şirkət qarşısında

əsas prioritet dünya standartlarını tətbiq etmək

üçün Kadrların İnkişafı üzrə islahatların

verilməsidir.

Proqramlaşdırma Komandası

SƏHİFƏ 14




Check-up Müayinə 1 2019-cu il avqust ayında Agile Transformasiya yolçuluğuna başlayanda şirkət qarşısında əsas 4 sual

yaranmışdır:

1. Şirkət nə üçün Agile Transformasiyanı tətbiq etməlidir? 2. Transformasiya prosesi necə baş verməlidir? 3. Şirkət hansı çətinliklərlə qarşılaşa bilər? 4. Bu çətinlikləri aradan qaldırmaq üçün hansı addımlar atılmalıdır?

Bu sualları cavablandırmaq üçün ilk olaraq şirkətin “check-up müayinəsi” aparıldı. Komanda üzvləri ilə

təkbətək görüşlər oldu. SWOT analiz, AS-IS analiz və digər analizlər aparılaraq şirkətin cari vaziyyətinin

“böyük xəritəsi” göstərildi. Eyni zamanda yuxarıda göstərilən sualların mümkün ola biləcək cavabları və

həlləri müzakirə edilərək, Agile Transformasiya üçün yol xəritəsi təsdiqləndi.

2019-cu il sentyabr ayında “Kick-off meeting” ilə

Agile Transformasiyaya start verildi. İlk öncə

Məhsul Sahibi, Biznes Analist, Proqramlaşdırma

Komanda Rəhbəri, Agile Layihə Rəhbəri rolları

təyin edildi. Növbəti 1.5-2 ay Sourced Agile®

User Story Management System-ində “Məhsul

Hekayəsi”nin dəqiq qurulmasına sərf edildi.

Bunun üçün Sourced User Story Card

formalarının hazırlanması mərhələsi

başlanmışdır. Real layihələr əsasında təlim,

konsultasiya və praktiki məşğələlər ilə Sourced

User Story-lər hazırlandı. İlkin olaraq Məhsul

Sahibləri və Biznes Analistlər ilə bərabər Sourced

User Story-lər hazırlandı. Bəzi layihələrdə

Sourced User Story-lər elə birbaşa Məhsul

Sahibləri tərəfindən, bəzilərində isə Biznes

Analistlər tərəfindən doldurulur.

Smart Solutions böyük layihələrin əksəriyyəti

satınalma prosesləri ilə bağlı olduğu üçün

Məhsul Sahibləri adətən qanunda verilmiş

maddələri User Story formasına salmağa

çalışırlar. Biznes Analistlər isə bu işdə onlara

köməklik edirlər. Bəzi hallarda Biznes Analist ilə

Məhsul Sahibi birgə User Story-lərin adlarını

təyin etməyə çalışırdılar. İnput, İnput

Descriptions, Proses Description və Mockup-lar

isə Biznes Analist tərəfindən detallı

doldurulurdu.

Sourced Agile® Modelinin Tətbiqi 2

SƏHİFƏ 15




Sourced User Story-dən 4/5/3 Prinsipi əsasında proqramlaşdırma komandası üçün tapşırıqların rahat

təyin edildiyini qeyd etmişdik. Buna görə də, Front-end/Back-end proqramçılar, UI/UX dizayner, və

testerlər üçün təlim və praktiki məşğələlər çox qısa zaman aldı. Təqribən 2-ci ayın sonunda

proqramlaşdırma komandası ilə Biznes Analist/Məhsul Sahibi arasında ünsiyyətdə heç bir çətinlik

yaranmırdı. Başqa sözlə desək, qanunvericiliyi oxuyub, təhlil edib, onları Sourced User Story formasına

salıb, proqramlaşdırma komandası arasında tapşırıqlara bölünməsi prosesi artıq çox rahat şəkildə tətbiq

edilirdi.

Proqramlaşdırma komandasına tapşırlıqlar (Task) JIRA Task Management sistemində icra edilirdi.

Sourced Agile® sistemi ilə JIRA sistemi arasında inteqrasiya növbəti səhifələrdə izah edilir.

4/5/3 Prinsipi Əsasında Tapşırıqların Təyini 3

SƏHİFƏ 16




Sprint-lərin təşkili və idarəedilməsi 5 İlk öncə onu vurğulamaq lazımdır ki, komanda şəklində “vahid bədən” kimi işləmək üçün Agile

metodologiyalarından Scrum Hybrid modeli seçilmişdir. Bürokratik və ənənəvi idarəetmə prinsipləri ilə

işləyən müştərilərin sayı çox olduğu üçün, hər bir layihə üçün bəzi hallarda xüsusi idarəetmə metodu

tətbiq etmək məcburiyyətində qalır. Bunları nəzərə alaraq şirkətin idarəedilməsi üçün ən ideal yanaşma

Scrum Hybrid modeli idi.

Sprint Planning-də yalnız və yalnız Sourced User Story-lərə baxılır. Sprintlər adətən 1-2 həftəlik

intervallarda təyin edilir. User Story-lər bacardıqda dəqiq yazıldığı üçün Sprint Planning-də müzakirələr

daha dəqiq mövzular üzərində aparılır. Yəni biznes prosesdə, input descriptionda, statuslarda, rollarda

və yarana biləcək texniki problemlər ətraflında müzakirələr aparılır. Hər bir səhifənin dizaynı, Input-lar,

Input description-lar Sprint Planning-də müzakirə edilmir. Hal-hazırda Məhsul Sahibləri, Biznes

Analistlər ilə proqramlaşdırma komandası arasında 30-60 dəqiqəlik görüş kifayət edir ki, baxılan Sprint

daxilində bütün tələbləri proqramlaşdırma komandasına izah etsinlər. Mürəkkəb prosesli User Story-lər

olduğu halda Sprint Planning-in müddəti üzanmış olur. Ümumidünya praktikasında bir çox

standartlarda isə Sprint planining müddəti maksimum 4 saat kimi qəbul edilir.

Əgər kodlaşdırmadan öncə UI/UX məsələləri tələb olunarsa, sərf olunacaq zamanı nəzərə alıb onun

üçün ayrıca Sprint təşkil olunur. Ümumi qayda olaraq şirkət daxilindəki Agile Management qaydasına

görə proqramlaşdırma komandası ilə olan Sprintlərdə UI/UX məsələləri hazır formada gəlməlidir. UI/UX

üçün artıq şirkət standartları olduğu üçün Sprint Planning-də dizayn məsələləri proqramçı komanda ilə

müzakirə edilmir. Lakin yenə də ağıl-ağıldan üstündür deyiblər. Gözdən qacan nüansları bildirə bilirlər

(geniş müzakirə mözvusuna çevirməmək şərti ilə). Başqa sözlə desək, UI/UX Sprintlərində Məhsul

Sahibi, Biznes Analist və UI/UX dizayner qatılır. Xüsusi hallarda isə Front-end Solution Architect işin

içinə daxil olur.

Product Backlog Sourced Agile® sistemində qeyd edilir. Tapşırıqlar isə həm Sourced Agile® sistemində,

həm də JIRA sistemində qeyd edilir. Hər iki sistem sinxron işlədiyi üçün tapşırıqlar və User Story-lər üzrə

status, sərf olunacaq zaman və sərf olunmuş zaman hər iki sistemdə eyni olur. Buna görə Məhsul

Sahibləri/Biznes Analistlər Sourced Agile® sistemini, proqramçı komanda isə JIRA sistemini istifadə

etməsi kifayət edir.

C-Level Rəhbərlikdən Dəstək 4 Şirkətlərin Agile Transformasiya yolçuluğuna çıxmaları üçün ilk öncə C-Level rəhbərliyinin güclü iradəsi

və dəstəyi lazımdır. Əks halda bu yolçuluğa çıxmağın bir mənası yoxdur. Smart Solutions şirkətinin

rəhbəri Kənan Tabasaranski gələcək vizyon və strategiyalarını nəzərə alaraq, şirkətin idarəedilməsində

Agile Transformasiyanı tətbiq etməyi qərara almış və bu prosesə ciddi dəstək göstərmişdir. Eyni

zamanda digər C-Level rəhbərlər 7 aylıq Agile Transformasiya yolçuluğunda yaranmış və yarana biləcək

problem, baryerləri, müqavimətləri aradan qaldırmağa ciddi köməklik etmişdilər. Əks halda “arıqlamaq

üçün dietoloqun yanına gedib, lakin pəhriz saxlamayıb, bütün növ yemək yeyən pasient” effekti olmuş

olacaqdır.

SƏHİFƏ 17




Change Request/Bug-ların İdarə Edilməsi 6 Sourced Agile® Modelində qeyd etdiyimiz kimi tələblər Sourced User Story formasında hazırlandığı halda Change Request və Bug-lar daha rahat idarə olunur. Çünki Change Request-lər 1 - Input, 2 - Input Description, 3 - Process Description hissələrində; Bug-lar isə yalnız 1 - Input Description, 2 - Process Description hissələrindən birində olur. Hər hansı bir Bug və ya Change Request gəldiyi zaman əlaqəli Sourced User Story-də qeyd edilir. Qeyd edilən Bug və Change Requestlər avtomatik olaraq JIRA-da Bug və Change Request issue type olaraq yaradılır. Əlavə olunan şəkillər, videolar və digər fayllarda JIRA sisteminə inteqrasiya edilir. Bug və Change Request-lər eyni Sourced User Story-yə əlaqələndiyi üçün tarixcəsini rahatlıqda Sourced Agile® sistemindən izləmək mümkündür. Bunun üçün sistemdə özəl analitik hesabatlar mövcuddur.

Ayrıca Scrum Master Vəzifəsi Yoxdur 7 Biznes Analist və Məhsul Sahibləri ilə Proqramlaşdırma Komandası arasında ünsiyyət tam dəqiq alındığı üçün Sprint Plannning-də proqramlaşdırma komandası arasında iş bölgüsü tam dəqiq təyin etmək mümkün olduğunu qeyd etmişdik. Sadəcə olaraq Sprint Plannning, Daily Meeting/Stand-up, Sprint Review və digər fəaliyyətləri ya Biznes Analist, ya Məhsul Sahibi, yada Proqramlaşdırma Şöbəsinin Rəhbəri icra edir. Bu rol layihə və müştəriyə görə qərar verilir. Təsdiqlənmiş Agile idarəetmə konsepti yazılı şəkildə daxili WiKi sistemində qeyd edildiyi üçün əksər sualların cavablarını ordan əldə etmək mümkündür. İclasların təyini, proqramlaşdırma komandasının ehtiyaclarının təmini, məlumat alış-verişinin təmini və digər fəaliyyətlər üçün ayrıca Scrum Master vəzifəsi yaradılmamışdır. Bu rol digər əməkdaşlar arasında bölünmüşdür.

Görüşlərin təşkil edilməsində nəzərə alınacaq bir neçə əsas faktorlar mövcuddur: a) minimal vaxt sərf olunmalıdır, b) Sourced User Story-dəki məlumatlar, c) eyni zamanda tapşırıqların statusları müzakirə edilməlidir, d) problemlər təyin edilməlidir və s. Texniki problemlərin həlli üçün ayrıca bir görüş keçirilməlidir.

Texniki görüşlər hər zaman ayrıca təşkil edilir. Bu görüşlərdə yaranan məsələnin texniki və çətinlik dərəcəsindən asılı olaraq Proqram Arxitektorun (Software/Solution Arcitect) iştirak təyin edilir. Sprint Review, Sprint Respospective, Core Review, Test Case-lərin nəticələrinin müzakirəsi eyni formada təşkil edilir.

Sourced Agile® siste-mində hər səhifə üçün Versiya (Reliz nömrəsi) yaratmaq mümkün olduğu üçün Change Request-ləri idarə etmək daha rahatdır. Yəni proqramlaşdırma komandasına konkret olaraq, hansı səhifədə nə dəyişikliklər olacağını dəqiq demək mümkündür.

SƏHİFƏ 18




JIRA Task Management Sistemi ilə İnteqrasiya 8 JIRA Task Management sistemi çox geniş funksional imkanlara malik olduğu üçün Front-End/Back-End Proqramlaşdırma kimi paralel əməliyyatları, UI/UX Design, Testing, deployment və s. kimi ardıcıl əməliyyatı idarəetmək üçün prosesləri müxtəlif və fərqli şəkildə təşkil etmək mümkündür. Eyni şirkətdə, fərqli komandalar JIRA-nı fərqli cür istifadə edirlər. Bunun əsas səbəbi isə JIRA-nın özünə məxsus idarəetmə modelinin olmamasıdır. JIRA bütün tip idarəetmə modellərini dəstəkləyir. Ona görə də JIRA sistemində layihələrin idarəetmə modelini istifadəçilər özləri təyin etməlidirlərr. Təbii ki, JIRA sisteminində tövsiyə etdiyi modellər mövcuddur.

Sourced Agile® sistemi Sourced Agile® Modeli üzərində qurulduğu üçün nəzəriyyə ilə praktika vəhdət təşkil edir. Bunun üçün JIRA sistemində idarəetmə modelinin ilkin variantını Sourced Agile® modeli əsasında təşkil etdik. Belə ki, JIRA ilə yalnız və yalnız Sourced User Story-ləri inteqrasiya etmək mümkündür. Sourced User Story-lər JIRA sistemində Epic kimi qeyd edilir.

Sourced Agile® sistemində təyin edilən hər bir Tapşırıq (Task), Bug, Change Request JIRA sistemində uyğun Epic-in daxilində Task, Bug və Change Request issue type kimi avtomatik olaraq yaradılır. Hər bir issue type üçün Assignee, Reportper, Description, Related Issue, Child İssue , Story Card View, Estimation Hours avtomatik yaradılır. Bu eyni zamanda proqramçı komandası üçün tapşırıqların tam dolğun və hazır forması hazırlanması deməkdir.

JIRA sistemində əgər əlavə Issue yaradılarsa, onlar sinxronizasiya vaxtı Sourced Agile® sisteminə avtomatik yerləşmiş olur. Eyni zamanda JIRA sistemində hər bir Task, Bug, Change Request üçün təyin edilən Estimation Hours, Spent Hours və Statuslar da avtomatik olaraq sinxronizasiya ilə Sourced Agile® sisteminə əlavə edilir.

JIRA sistemində istənilən sayda Board yaratmaq mümkündür. İxtiyarı paralel və ardıcıl əməliyyatları Epic - Task Type birləşməsi ilə rahat idarə etmək və sinxronlaşdırmaq mümkündür.

Bu formada “Məhsul Hekayəsi” analiz etmək və qurmaq üçün Sourced Agile® sistemi və proqramlaşdırma proseslərini isə JIRA sistemində quraraq effektiv iş axışı qurulmuş oldu. Release, Deployment, Testing hər ikisi sistemdə sinxron aparılır. Test Case ssenariləri və nəticələri isə Sourced Agile® sistemində qurulur. Bug yarandığı zaman avtomatik JIRA sistemində əks olunur. Bug həll edildiyi zaman nəticələri Sourced Agile® sistemində avtomatik görsənir.

SƏHİFƏ 19




Daimi İnkişaf, Software Architecture və DevOps 9

Agile Tranformasiya yolçuluğuna çıxdıqdan 3 ay müddətində Smart Solutions şirkəti qarşıya qoyulan məsələlərdən aşağıdakıları artıq təmamilə həll etmişdir:

■ Bürokratiya və sənədləşmə işləri çox olan, şəlalə (waterfall) layihələndirmə metodu tətbiq edən müştərilərdən “Məhsul Hekayə”lərini alıb proqramlaşdırma komandası arasında xırda tapşırıqlara bölmək;

■ Məhsul Sahibləri ilə proqramlaşdırma komandası arasındakı iclasların sayını və hər iclasa sərf olunan zamanın minimuma endirilməsi və effektiv olmasını təmin etmək.

Növbəti aylarda isə Agile Transformasiya strategiyası Proqramlaşdırma Prosesini (Software Development Process) optimallaşdırmaq və standartlaşdırmaqdan ibarət idi. Bunun üçün proqramlaşdırma komandasını “vahid bədən” kimi idarəedilməsi çox önəmlidir. Qarşıya qoyulan məqsədə çatmaq üçün şirkət daxilində ciddi şəkildə Daimi İnkişaf (Continous Improvement), Daimi İnteqrasiya (Continous Integration), Proqram Arxitekturasının (Software Architecture) inkişafı, DevOps alətlərinin tətbiqi davam edir. Bunlar daimi inkişaf prosesi olduğu üçün detallı şərhə ehtiyac yoxdur. Daimi inkişaf prosesində ən əsas məsələ “Nəyi hardan tapıb və necə tətbiq etməyi bilmək” prinsipidir. Smart Solutions şirkəti isə artıq bunu həzm edərək və mədəniyyət halına gətirməyə çalışır.

Agile Transformasiya Meyarları 10 Smart Solutions şirkətində Agile Transformasiya və Agile metodunun tətbiqini ölçmək üçün aşağıdakı meyarlar istifadə edilir. Bu meyarlar müzakirələrdə və görüşlərdə ən çox istifadə edilən göstəricilərdir. İşçilərin, Sprintlərin, Məhsulların dəyərləndirilməsində də bu meyarlar ciddi şəkildə tətbiq edilir. Meyarlar haqqında statistik məlumatlar JIRA və Sourced Agile® sistemindən əldə edilir.

■ Müştəri məmnuniyyəti

■ Biznes dəyərlərin çatdırılması

■ Planlaşdırılmış və Real User Story-lər

■ User Story-lərin təhvil tarixləri

■ İterasiyaların sayı

■ Defektlərin sayı

■ Defektlərin mütəmadi təkrarlanması

■ Müştərilərin daimi müdaxiləsi

■ Sərf olunacaq zamanın dəqiqliyi

■ Test nəticələri

■ Tapşırıqlar üzrə sərf olunan zaman

■ Hər reliz üzrə dəyişiklikər

■ Proqramlaşdırma xətalarının az olması

■ Proqramçıların eyni dildə danışması

SƏHİFƏ 20




NƏTİCƏ

Agile Transformasiya yolçuluğunda Smart Solutions şirkəti qarşıya qoyduğu məsələlərdən “Məhsul

Hekayəsi” qurmaq, biznes və proqramlaşdırma dünyası arasında effektiv kommunikasiya və meyarlar

əsasında idarəetmə əsasında məsələlərin həllinə uğurla nail olmuşdur. Şirkət daxilində effektiv ünsiyyət

sistemi mövcuddur. Bu müddət ərzində C-Level rəhbərliyinin ciddi dəstəyi olmuşdur. Əks halda bəzi nüanslar

uğurlu olmaya bilərdi. Effektiv ünsiyyətin təmin edilməsi Sourced Agile® Modeli və sistemi əsasında həyata

keçmişdir.

Agile Transformasiya yolçuluğunda ən uğurlu addımlardan biri büroktariya və çoxlu sənədləşmə ilə işləyən

müştərilər ilə daxildə Agile modeli ilə işləyən komanda arasında harmoniyanın yaradılması olmuşdur.

Daxildə bütün komanda üzvləri hər zaman görəcəkləri işin nədən ibarət olduğunu və necə həll ediləcəyini

bilirlər. İclaslarda artıq və mənasız müzakirələr demək olar ki, yer almır.

“Məhsul Hekayəsi”nin dəqiq qurulması və effektiv ünsiyyət sistemi qurulduqdan sonra, şirkətin növbəti aylar

və illər üzrə qısa və uzun müddətli strategiyası ̶ Daimi İnkişaf Strategiyası olmuşdur. Buna görə də,

komandanın Fərdi İnkişaf Planı, Daimi İnteqrasiya (Contionus Integration), Proqram Arxitekturasının

(Software Architecture) inkişafı, DevOps alətlərinin mütəmadi tətbiqi və digər fəaliyyətlər qarşıya qoyulan

əsas hədəflərdir.

Scrum Hybrid artıq şirkət mədəniyyəti formasını almağa başlamıdır. Smart Solutions şirkətinin öz

proseslərinə uyğun Agile yanaşması olduğu üçün daha çevik və sürətli addımlarla irəliləməyi bacarır.

Sourced Agile® Modeli və sistemi “Məhsul Hekayəsi”nin qurulması və komanda arasında effektiv ünsiyyət

yaratmaq üçün ən ideal sistemlərdən biridir.

SƏHİFƏ 21




TÖVSİYƏ 4

Agile Transformasiya yolçuluğuna start verin.

Rəhbər işçiləri Agile konsepti və faydası haqqında məlumatlandırın və Agile

Transformasiya yolçuluğuna hazırlayın.

“Məhsul Hekayəsi”ni dəqiq qurmağa çalışın.

Məhsul Sahibi, Biznes Analist, Proqramlaşdırma Şöbəsi Rəhbəri, Agile Layihə Rəhbəri üçün özəl

yanaşma tətbiq edin.

Proqramlaşdırma komandasına Proqram Arxitekti (Software Architect, Solution Architect) və

Proqramçı Mühəndis (Software Engineer) daxil edin. Əgər yoxdursa, yetişdirin.

İşlərin gedişatını izləmək üçün meyarlar təyin edin.

Komandanın “Vahid Bədən” kimi hərəkət etməsini təmin edin.

Sourced Agile® Modeli və sistemini tətbiq edin ünsiyyət problemlərinizin 70-80%-i həll olsun.

Daimi İnkişafa önəm verin.

Daimi İnteqrasiya (Continous Integration), Proqram Arxitekturasının (Software Architecture)

inkişafı, DevOps alətlərinin mütəmadi tətbiqini şirkət strategiyasının ayrılmaz bir parçası halına

gətirin.

SƏHİFƏ 22




Agile Transformasiya yolçuluğunda

“Məhsul Hekayəsi”ni qurmaqda

ən ideal partnyorunuz

www.sourcedagile.com [email protected]

+994 (70) 5254039

Documents

Agile Transformasiya...Agile transformasiya səyahətində əməkdaşlar tərəfindən yaranan müqaviməti aradan qaldırmaq üçün Agile Düşüncəli menecer və liderlər yetişdirilməlidir