Daca lucrezi in industria IT&C mai devreme sau mai tarziu te vei afla in situatia de a prelua sau preda un proiect. De-alungul carierei mele am avut ocazia sa experimentez mai multe situatii de acest gen si ca urmare mi-am facut propriul checklist pentru a ma asigura ca nu pierd din vedere nimic si ca oricine ar fi clientul, impactul schimbarii echipelor va fi cat mai redus.

Primu lucru pe care il fac de fiecare data este sa obtin cat mai repede datele de mai jos si drepturile de acces.

Structura echipei

• Cine sunt membrii echipei
• Ierarhie si responsabilitati
• Cine raporteaza si cui
• Datele de contact ale clientului / echipelor cu care se colaboreaza / furnizorilor

Cerintele de business

• Descrierea cerintelor de business
• Documentatia folosita
• Test cases

Codul sursa

• Obtinerea URL-ului pentru repository
• Crearea conturilor cu drepturile necesare de acces
• Obtinerea tuturor script-urilor de configurare si cerintelor pentru statiile de lucru ale developerilor
• Daca este posibil, dezvoltarea de scripturi automatizate ale mediului de implementare sau crearea unor imagini ale sistemului – pentru a salva din timpul developerilor.

Documentatie tehnica

• Arhitectura sistemului
• Arhitectura sub-sistemului
• Arhitectura in termeni de primitive tehnice
• Arhitectura in termeni de sarcini de business, use cases
• “Technical debts” ale echipei
• Toate informatiile si propunerile tehnice in ceea ce priveste sistemul existent
• Putem sa facem si un experiement: roaga noua echipa sa dezvolte un “pattern” al sistemului cu scopul de a identifica componentele infrastructurii care sunt raspunzatoare de modul in care opereaza sistemul si apoi suprapune cerintele de business peste ele – din experienta mea folosind aceasta strategie oamenii se prind mult mai repede de ce au de facut.

Livrarea si mediul

• Servere CI/CD
• Infrastructura de test
• Build versions

Sistemele de informatii

• Cum sunt abordate cerintele utilizatorilor
• Sistemul de bus tracking
• Unde sunt depozitate toate informatiile legate de sistem
• Sistemul de monitorizare
• Analytics legate de actiunile utilizatorilor
• Este crucial sa identifici persoanele de contact pentru toate problemele legate de fiecare sistem
• Toate procedurile: cum sunt procesate cerintele utilizatorilor; ce aprobari si de la cine sunt necesare pentru documentatii tehnice noi

Procese si liste cu decision makers (DM)

• Proceduri si lista cu DM pentru activitatile zilnice
• Proceduri si lista cu DM implicati in incheierea de sprint-uri / iteratii / etape de munca
• Proceduri si liste DM legate de planificarea de noi release-uri / iteratii
• Proceduri legate de coordonarea Change Requests
• Proceduri legate de noi release-uri

Testare, echipa de QA

• Acces la bazele de date cu script-uri de testare
• Obtinerea descrierilor procedurilor pentru provocari legate release-uri

Conturi utilizator

• Conturile utilizatorilor pentru testare / staging / productie pentru testarea produsului
• Acces la conturile din sistemele partenerilor / furnizorilor / analytics

Diverse

• Planul de lucru
• Roadmap
• Definirea obiectivelor in termeni tehnici
• Definirea obiectivelor in termeni de produs

Servicii third party, furnizori, parteneri

• Acces admin la toate sistemele third party – pentru a putea sa adaugi proprii utilizatori
• Datele de contact ale tuturor furnizorilor si partenerilor, DM, programul intalnirilor (daca exista), structura echipelor acestora, responsabilitati si o scurta descriere a ariilor pe care interactionati si a obiectivelor acestor echipe

Sectiunea “Obiective” este foarte importanta

• Ce se doreste de la echipele de dezvoltare, testare sau support?
• Care sunt obiectivele noii echipe?

Desigur ca framework-urile actuale de implementare te pot ajuta foarte mult dar viata reala nu este perfecta astfel ca este bine sa ai propria ta lista.

Este de notat ca cea mai buna emtoda pentru a facilita transferul de cunostinte este sa mentinem doua echipe in paralel, caz in care toata echipa ar putea sa intre gradual in procesul de dezvoltare, sa vorbeasca cu persoanele mai experimentate din vechea echipa despre configurarea sistemului, process systems (gen JIRA), bug life cycle etc.

Daca echipa lucreaza dupa Scrum sau Scrumban as recomanda cel putin unul sau doua sprint-uri unde sa observi tot ceea ce se face: triaj, restrospective, demo etc.

Ivan Alyakskin
Software Consultant