Kuidas, olles räpases arhitektuuris ja oskuste puudumisel Scrum'is, lõime ristis komponentide tiimid

Tere!

Minu nimi on Aleksander ja ma juhin IT arendust UBRiR-is!

2017. aastal mõistsime UBRiR-i infotehnoloogiate teenuste arenduskeskuses, et on aeg globaalseks muutuseks, täpsemalt – agile-muutuseks. Finantsturu intensiivse arengu ja kiire konkurentsi tingimustes on kaks aastat muljetavaldav aeg. Seega on aeg projekti tulemusi kokku võtta.

Kõige raskem on muuta oma mõtlemist ja järk-järgult kultuuri organisatsioonis, kus on levinud mõtteviis "aga kes on selle meeskonna juht?", "juht teab paremini, mida me tegema peame", "me oleme siin töötanud juba 10 aastat ja teame oma kliente paremini, teame, mida nad vajavad".

Agile-muutus saab toimuda ainult siis, kui inimesed ise muutuvad.
Tõstaksin välja järgmised olulised hirmud, mis takistavad inimesi muutumast:

  • Hirm kaotada võim ja 'epauletid';
  • Hirm jääda ettevõttele ebavajalikuks.

Astu transformatsiooni teele, valisime esimesteks „katsejänesteks“ retail-suunal töötavad töötajad. Esiteks tegime ümber disaini ebaefektiivseks osutunud IT-struktuurist. Leiutades sihtstruktuuri kontseptsiooni, asusime arendustiimide loomisele.

Kuidas, olles räpases arhitektuuris ja oskuste puudumisel Scrum'is, lõime ristis komponentide tiimid

Meie panga arhitektuur, nagu paljudes teistes, on õrnalt öeldes „prügine“. Suur hulk rakendusi ja komponente on monoliitselt seotud DB lingiga, olemas on ka ESB buss, kuid see ei täida oma eesmärke. Samuti on olemas mitu AHS-i.

Kuidas, olles räpases arhitektuuris ja oskuste puudumisel Scrum'is, lõime ristis komponentide tiimid

Enne scrum-meeskondade loomist tekkis küsimus: "Mille ümber peaks meeskond kokku tulema?" Idee, et pangas on toode, oli loomulikult õhus, kuid samas ulatuses kätte saamata. Pika mõtlemise järel otsustasime, et meeskond peaks olema koondatud mingisse suunda või segmendi. Näiteks „Krediitide meeskond“, mis arendab krediidiäri. Kui olime sellega määratlenud, hakkasime välja mõtlema vajalikku koosseisu rolle ja kompetentside komplekti, mis on vajalik selle suuna tõhusaks arenguks. Nagu paljud teised ettevõtted, arvestasime kõiki rolle, välja arvatud Scrum Master — tol ajal oli CIO-le selle imelise inimese rolli selgitamine peaaegu võimatu.

Lõpuks, pärast seletusi arendustegevuse meeskondade käivitamise vajadusest, käivitasime kolm meeskonda:

  1. Krediidid
  2. Kaardid
  3. Passiivsed tehingud

Koosseisuga:

  1. Arenduse juht (Tech Lead)
  2. Arendaja
  3. Analüütik
  4. Testija

järgmise sammu tarvis pidime määrama, kuidas meeskond töötab. Korraldasime kõigile meeskonna liikmetele agile-koolituse ja paigutasime nad kõik ühte ruumi. Meeskondades ei olnud PO-d. Arvatavasti mõistavad kõik, kes on teinud agile-muutusi, kui keeruline on selgitada äri PO rolli, ja veel keerulisem on istutada ta meeskonna kõrvale ning anda volitused. Kuid me astusime nende muudatuste suunas selleks, mis meil oli.

Kuna krediidiprotsessides ja muudes jaekaubanduse suundades oli kaasatud tohutu hulk rakendusi, hakkasime mõtlema, kes võiks sobida rollidesse? Ühe tehnoloogia virna arendaja, ja siis vaatad — ja on vaja arendajat teise tehnoloogia virna! Ja nii leiad inimesed, keda on vaja, kuid töötaja soov on ka oluline, ja sundida inimest töötama seal, kus talle ei meeldi, on üsna keeruline.

Pärast krediidiprotsessi töö analüüsi ja pikki arutelusid kolleegidega leidsime lõpuks kuldse kesktee! Nii said alguse kolm arendusmeeskonda.

Kuidas, olles räpases arhitektuuris ja oskuste puudumisel Scrum'is, lõime ristis komponentide tiimid

Mis edasi?

Inimesed hakkasid jagunema nende vahel, kes soovivad muutuda, ja nende vahel, kes ei soovi. Kõik on harjunud töötama olukordades „ma sain ülesande, tegin selle ära, jätke mind rahule”, kuid meeskonnatöö ei eelda seda. Kuid ka selle probleemi oleme lahendanud. Muudatuste jooksul on meie seast lahkunud 8 inimest 150-st!

Siis algas kõige huvitavam osa. Meie ristkomponentide meeskonnad hakkasid oma oskusi ise arendama. Näiteks on ülesanne, mille jaoks on vaja CRM-i arendaja oskusi. Meeskonnas on see olemas, kuid ainult üks. Samuti on olemas Oracle-i arendaja. Mis juhtub, kui tuleb lahendada 2 või 3 ülesannet CRM-is? Õppida üksteiselt! Poisid hakkasid oma teadmisi üksteisele edastama, ja meeskond laiendas oma võimalusi, minimeerides sõltuvust ühest tugevast spetsialistist (üldiselt, igas ettevõttes on superinimesed, kes teavad kõike ja ei räägi sellest kellelegi).

Praegu on meil kokku 13 arendusmeeskonda, mis katab kõiki äri ja teenuste arengusuundi. Jätkame agile-muutust ja liigume uuele tasemele. See nõuab uusi muutusi. Me kavatseme meeskondi ja arhitektuuri ümber kujundada ning arendada oskusi.

Meie lõppeesmärk on kiiresti reageerida toote muudatustele, kiiresti turule tuua uusi funktsioone ja täiustada pangasüsteeme!

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster