Prezentare generală a procesului și procedurilor de dezvoltare

Acest document va oferi o prezentare generală a proceselor și procedurilor de dezvoltare Leading2Lean. Acest proces descrie responsabilitățile, politicile și procedurile care trebuie urmate de Leading2Lean atunci când se efectuează modificări ale serviciului și infrastructurii de producție. Toți angajații trebuie să respecte această politică.

Echipa de tehnologie Leading2Lean are sarcina de a furniza o infrastructură IT stabilă și fiabilă pentru clienții noștri. Scopul procesului de dezvoltare este de a minimiza întreruperile serviciilor în mediul centrului nostru de date și de a promova disponibilitatea și integritatea sistemului. Directorul Tehnic (CTO) este responsabil pentru menținerea și actualizarea procesului și procedurilor de dezvoltare, după cum este necesar. Acest proces este guvernat în continuare de controalele organizaționale definite ca parte a programului nostru de conformitate AICPA SOC 2 Type 2. Aceste controale sunt auditate anual de auditorul nostru extern.

Procesul de dezvoltare începe cu revizuirea tichetului de către un dezvoltator, coordonarea cu colegii în ceea ce privește arhitectura și designul, scrierea codului, primirea feedbackului din partea echipei QA și, în final, lansarea software-ului către clienți. 

Domeniu de aplicare

Acest document definește ciclul de viață al solicitărilor de funcții și al erorilor. De asemenea, descrie procesele și procedurile utilizate pentru a asigura testarea și validarea corespunzătoare pentru fiecare lansare. Acest document nu descrie procesul de gestionare a modificărilor, așa cum este definit în Prezentarea generală a politicii de control al modificărilor.

Definiții

Backlog: O colecție de erori și funcții a căror dezvoltare nu a început. Backlogul este locul în care se află toate tichetele cu prioritate redusă. 

Bug: O funcție care nu funcționează așa cum a fost concepută. Erorile pot varia de la negrave la extrem de grave. Lista de erori este locul în care se află toate erorile cu prioritate redusă. Tichetele sunt plasate în lista de erori în timpul ședinței de triere. Tichetele sunt atribuite membrilor echipei de dezvoltare din lista de erori.

Funcție sau îmbunătățire: Comportament care nu a fost dezvoltat pentru software. Acesta poate fi o modificare a funcționalității existente sau crearea unei funcționalități noi.

Proiect sau Epic: O colecție de erori și funcții. Proiectele sunt gestionate în foaia de parcurs. 

Foaie de parcurs: O colecție de proiecte. Foaia de parcurs este panoul de planificare pentru proiecte mai mari. Foaia de parcurs ghidează dezvoltarea funcțiilor noi, mari și mici. 

Triaj: Colectarea tichetelor noi. Lista de Triaj este locul unde sunt create toate tichetele noi. Echipa de Triaj va plasa apoi tichetele fie în lista Bug-urilor, Foaia de parcurs sau Backlog.

Prezentare generală

Există 3 faze principale pentru fiecare tichet de dezvoltare: 1. Planificare, 2. Dezvoltare și 3. Testarea asigurării calității. Fiecare fază va fi discutată mai jos.

Planificare

Utilizăm o abordare de triaj multidisciplinară pentru procesul de planificare. Echipele noastre de Asistență, Dezvoltare și Calitate se întâlnesc periodic pentru o întâlnire de Triaj, pentru a evalua problemele noi, cererile de funcții și îmbunătățirile. În funcție de gravitate, aceste probleme pot declanșa un ciclu escaladat de răspuns la întreruperi/remedieri pentru a restabili serviciul în cazul elementelor cu prioritate ridicată sau pot reprezenta o degradare a serviciului. În caz contrar, li se atribuie o prioritate inițială și sunt transmise echipei noastre de Produs pentru planificare, prioritizare și programare suplimentare.

Funcțiile sunt de obicei planificate cu contribuția unui număr mic de persoane.  Acestea pot include membri ai echipei de Produs, experți în domeniu, clienți etc. Acest proces este coordonat de echipa noastră de management al produsului.

Majoritatea cererilor de funcții vor fi discutate în cadrul întâlnirii de Planificare a Foii de parcurs. În cadrul acestei întâlniri, proiectele și cererile de funcții escaladate vor fi discutate. Proiectele vor fi prioritizate în raport cu alte proiecte, iar cererile de funcții vor fi analizate și mutate în backlog. Cererile de funcții pot fi asociate unui proiect din foaia de parcurs.

Dezvoltare

Odată ce procesul de planificare este finalizat, această activitate este atribuită echipei de Dezvoltare. Echipa de Dezvoltare are propriul set de medii de dezvoltare, care este o replică a mediului nostru de Producție. Aceasta este o parte esențială a programului nostru de calitate. La fiecare etapă a ciclului nostru de dezvoltare (Dezvoltare, Asigurarea calității, Staging șiamp; Producție) menținem infrastructuri separate pentru a ne asigura că orice activitate finalizată va fi testată și verificată corespunzător înainte de a intra în mediul nostru de Producție.

Folosim un set complet de instrumente de dezvoltare standard în industrie, concepute pentru controlul versiunilor, testarea automatizată, analiza statică a codului și menținerea curățeniei codului. Aceste instrumente oferă dezvoltatorului feedback timpuriu și frecvent pentru a asigura cea mai bună Calitate posibilă a codului. De asemenea, acestea ajută la menținerea unei separări corespunzătoare a ramurilor de dezvoltare, pentru a evita contaminarea încrucișată între dezvoltatorii care lucrează la proiecte, sarcini și elemente diferite ale bazei de cod. Aceste instrumente oferă o metodă standardizată pentru evaluările codului de către colegi și procesele de aprobare, pentru a asigura că orice cod pregătit pentru Testarea asigurării Calității a trecut toate verificările automatizate de testare și validare.

Dezvoltatorii noștri comunică direct cu echipa de asistență, echipa de produs sau alți dezvoltatori atunci când apar întrebări despre modul de implementare a unui tichet. Toate modificările UI necesită aprobarea echipei de produs. Deoarece modificările UI au impact asupra clienților și pot necesita Antrenament, colaborăm cu clienții, echipa de asistență și echipa de produs pentru a ne asigura că se acordă atenția necesară proiectării oricăror modificări UI, astfel încât impactul asupra clienților să fie minimizat. Toate modificările UI sunt, de asemenea, verificate de echipa noastră de asistență în timpul fazei de Testare a asigurării Calității, pentru a valida existența funcționalității corespunzătoare și pentru a ne asigura că clienților le sunt furnizate notificările și Antrenamentul corespunzătoare.

Dezvoltatorii trebuie să ruleze cu succes suita noastră de teste automatizate pentru orice modificare, ca parte a procedurilor lor operaționale obișnuite. Odată ce tichetul trece aceste teste automatizate, acesta este pregătit pentru a fi verificat de altcineva decât dezvoltatorul. Acest eveniment le permite membrilor-cheie ai echipei să știe că este momentul pentru feedback și indică, de asemenea, faptul că tichetul se apropie de lansare.

Tot codul este verificat de un alt dezvoltator înainte de a fi transmis echipei QA. Acest lucru ajută la asigurarea faptului că mai mult de o persoană știe și înțelege ce se modifică și de ce. Scopul unei verificări a codului ar trebui să fie analizarea obiectivului general al modificărilor, verificarea codului pentru erori simple, scanarea codului pentru ineficiențe, solicitarea de clarificări atunci când ceva nu pare în regulă și încercarea de a menține coerența cu standardele de codare și cele mai bune practici. Uneori, dezvoltatorul inițial va refactoriza codul ca urmare a feedbackului din faza de testare. Dacă acest lucru duce la o modificare semnificativă a codului, se efectuează o verificare suplimentară. Atunci când consensul privind verificarea codului este înregistrat și documentat, codul este pregătit pentru a fi transmis echipei QA

Testarea asigurării Calității

Odată ce suita de teste automatizate s-a finalizat cu succes, fără erori, iar verificarea codului a fost finalizată cu succes, echipa QA poate începe procesul de Testare a asigurării Calității.

Cele două activități principale implicate în procesul de testare sunt rularea scripturilor de testare automatizată și testarea manuală. L2L are o suită de cazuri de testare UI și unitare care sunt rulate din linia de comandă. Există, de asemenea, un proces de linting care rulează asupra codului pentru a verifica erorile de bază de codare. Toți dezvoltatorii ar trebui să ruleze atât suita de teste, cât și procesul de linting înainte de a trimite codul spre revizuire. Echipa QA efectuează propria revizuire a rezultatelor suitei de teste automatizate după implementarea codului în mediul de testare QA. Acest lucru ne asigură că avem un mediu de testare curat pentru a evalua capacitatea actualizării codului de a funcționa conform proiectării și standardului nostru de Calitate.

Echipa QA va coordona testarea manuală a codului pentru a asigura o Calitate suplimentară. Feedbackul echipei QA va fi inclus în tichetul de dezvoltare. Adesea, codul va necesita refactorizare și actualizare înainte ca QA să acorde aprobarea. QA va indica faptul că codul este pregătit pentru a fi fuzionat prin aprobarea cererii pull. QA va fuziona codul în baza principală de cod odată ce totul a fost aprobat. Acest lucru asigură că dezvoltatorii nu pot fuziona cod în baza noastră principală de cod și evita procesul QA.

În timpul fazei de testare pentru asigurarea Calității, echipa QA va utiliza, de asemenea, membri ai echipei de asistență și clientul pentru a efectua testarea de acceptanță a utilizatorilor. Aceste teste sunt esențiale pentru a ne asigura că modificările codului sunt utilizabile, corespund nevoilor clienților și respectă orice reglementări și cerințe din industrie.

Procesul de control al modificărilor și implementarea în Producție

Pentru a ne asigura că orice modificare adusă mediului de Producție urmează un proces standard, am implementat un Proces de gestionare a modificărilor, așa cum este definit în Prezentarea politicii de control al modificărilor. Acest lucru ne asigură că avem verificările și echilibrele corespunzătoare în organizație pentru a garanta Calitatea, Securitatea și disponibilitatea mediului de Producție. Pentru mai multe informații despre acest proces, consultați linkul de mai sus.

Este important de reținut că, în cadrul procesului de control al modificărilor, L2L utilizează un script automatizat de implementare pentru a lansa software-ul din depozitul de cod pe serverele clienților. În niciun moment angajații nu actualizează manual mediul de Producție. Acest sistem automatizat creează o pistă de audit pentru fiecare nouă versiune/implementare și verifică existența aprobărilor corespunzătoare. După finalizarea acestui pas, scripturilor de lansare li se va permite să actualizeze serverele de Producție. Acest script automatizat oferă, de asemenea, notificări interne ale implementărilor. După finalizarea implementării, acest sistem automatizat efectuează și „teste de fum” pentru a valida faptul că implementarea a fost realizată cu succes și că mediul de Producție funcționează corespunzător.

Întâlnirea retrospectivă

În cazul în care codul lansat readuce la suprafață o problemă veche sau determină sistemul să emită o alertă, va avea loc o întâlnire retrospectivă, denumită și analiză post-incident. Scopul întâlnirii va fi colectarea faptelor referitoare la lansarea codului problematic, discutarea modalităților de prevenire a unor evenimente similare în viitor, atribuirea sarcinilor legate de prevenirea evenimentelor viitoare și instruirea echipei cu privire la incident. Aceste întâlniri ar trebui să aibă loc în termen de 36 de ore de la eveniment și ar trebui să implice cât mai mulți dezvoltatori și membri ai echipei de asigurare a calității pentru analiza cauzei principale și în scopuri de instruire. 

Notificarea clienților

Notificările clienților pot avea loc în mai multe momente pe parcursul acestui proces. Clienții sunt adesea consultați în timpul etapelor de planificare, dezvoltare și Calitate, precum și după lansarea codului. Clientul va fi notificat prin următoarele metode:

• Contact personal / Întâlniri programate. Clienții implicați în proiecte de dezvoltare specifice pot fi invitați să participe la întâlniri regulate de actualizare pentru a analiza planurile, proiectele și stadiul proiectului.
• Mesaj personal către clienți. Toate tichetele de asistență inițiale vor fi actualizate pentru a informa clientul că modificarea a fost lansată pe serverele de Producție, iar tichetul va fi închis. Dacă nu a fost creat un tichet de asistență, un reprezentant de asistență poate contacta direct clientul. Dacă un singur client a fost afectat de o modificare, este posibil să nu fie utilizate alte forme de notificare.
• Jurnalul modificărilor. Toate modificările care afectează clienții vor include un jurnal al modificărilor. Acesta include remedieri de Bug-uri, actualizări minore și cereri de funcții. Atunci când o modificare a afectat un singur client, iar impactul a fost minor, și dacă un client a fost contactat direct, este posibil să nu fie adăugat un jurnal al modificărilor. Clienții pot accesa jurnalul modificărilor din meniul Asistență al aplicației.
• Mesaj de e-mail în masă. Pentru toate modificările majore ale aplicației, tuturor administratorilor li se va trimite un mesaj de e-mail. Mesajele de e-mail în masă sunt utilizate în principal pentru anunțuri despre produs și îmbunătățiri majore ale interfeței, dar pot fi folosite și în alte situații.
• Notificări în aplicație pot fi utilizate pentru modificările cu impact.