Release package

Un proces prost definit înseamnă pierdere de timp și frustrare. Înseamnă implicarea mai multor oameni decât este necesar și o mulțime de email-uri.

De exemplu, procesele de change management și release management pentru o aplicație APEX ar trebui să fie simple și clare.

Lucrurile ar trebui să funcționeze așa:

  • se strâng, se analizează ( tehnic, cost, beneficiu, impact ) și se prioritizează noile cerințe
  • se definește release package, se dezvoltă și se testează
  • se definesc roluri și responsabilități ( cine, ce va face )
  • se definește fluxul de lucru și ce e de făcut în diverse situații

Toate persoanele implicate trebuie să cunoască fluxul, responsabiltățile proprii dar și ale celorlalți. Simplu, nu?

Am lucrat pentru o companie mare în care procesele erau respectate și totul mergea bine de la cap la coadă. Nu mi-am dat seama atunci cam cum ar fi dacă procesele nici măcar nu sunt definite, însă acum da, știu cum e:

  • este mai greu să gestionezi versiunile aplicației
  • primești mail-uri care îți solicită să rezolvi probleme pe care nu le poți rezolva pentru că nu ai acces pe server
  • în cazul în care sunt erori în release package nu le poți corecta pt că nu ai mediu de testare
  • analistul de business vrea implementarea cât mai repede, DBA-ul nu poate face implementarea pt că sunt erori în pachet și dezvoltatorul nu poate corecta erorile pt că nu are un mediu unde să poată testa pachetul de implementare ca și când ar fi executat de DBA.

Lasă un răspuns

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.