Agile Transformasiya...Agile transformasiya səyahətində əməkdaşlar tərəfindən yaranan...
Transcript of Agile Transformasiya...Agile transformasiya səyahətində əməkdaşlar tərəfindən yaranan...
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
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
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
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ə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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Şə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
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
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
SƏHİFƏ 13
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Agile Transformasiya yolçuluğunda
“Məhsul Hekayəsi”ni qurmaqda
ən ideal partnyorunuz
www.sourcedagile.com [email protected]
+994 (70) 5254039