Guvernanța dezvoltării în comun

Stabilirea unui cadru eficient de guvernanță a dezvoltării în comun este o parte importantă pentru a asigura coerența și repetabilitatea în proiectele definite de creator și echipele multidisciplinare. Acest articol descrie o abordare pentru definirea unei organigrame a guvernanței.

Definirea procesului de la un capăt la altul

Puteți utiliza următorul proces ca exemplu și îl puteți particulariza conform celor mai bune practici ale organizației dvs. Nu este necesar să finalizați fiecare pas, atât timp cât obțineți rezultatul dorit.

Adăugați caracteristici la lucrările în curs

Lucrările în curs vă permit să vă planificați proiectul adăugând caracteristicii care impulsionează experiența generală. Lucrările în curs oferă, de asemenea, foaia de parcurs generală pe care echipa intenționează să o livreze.

Când se adaugă o nouă caracteristică la lucrările în curs, scopul este de a descrie domeniul de aplicare general. Fiecare caracteristică definește apoi valoarea de business, titlurile schiței de poveste, domeniul de aplicare și modificările modelului de date care conduc eforturile de dezvoltare a codului.

În plus, atunci când adăugați o caracteristică de business critică, vi se recomandă să identificați orice scenarii critice pentru a vă automatiza testarea. După ce ați adăugat caracteristica (caracterisiticle), vă puteți planifica întâlnirea de aliniere a domeniului de aplicare.

Întâlnirea de aliniere a domeniului de aplicare

Accentul acestei întâlniri ar trebui să se limiteze la revizuirea fiecărei caracteristici noi propuse, apoi la verificarea oricăror aplicații, scenarii sau modele de date existente care oferă deja această funcționalitate pentru a evita dublarea eforturilor. Această întâlnire oferă, de asemenea, ocazia de a discuta despre impactul asupra altor aplicații. În cele din urmă, ar trebui să verificați dacă această caracteristică necesită o Revizuire a experienței.

Adăugați povești și rezumate la lucrările în curs

După întâlnirea de aliniere a domeniului de aplicare, orice schiță de titlu de poveste a utilizatorului poate fi adăugată sub caracteristică. În acest moment, detaliile nu sunt necesare, iar starea poveștii utilizatorului este "Nouă". Puteți vizualiza poveștile fie în vizualizarea lucrări în curs sau panou.

Următoarea figură arată un exemplu de poveste a utilizatorului adăugată la lucrări în curs.

În acest moment, este vital să menținem calitatea organizând munca în funcție de secvența de lucru și aplicație. Această abordare ajută la menținerea elementelor de lucru corelate împreună și le permite experților din fiecare secvență de lucru să dezvolte și să mențină o înțelegere profundă a funcționalității și a utilizării datelor în fiecare aplicație.

Revizuirea experienței

Revizuirile experienței ar trebui să se concentreze pe experiența utilizatorului final și să se asigure că echipa dvs. respectă cele mai bune practici organizaționale. Această consecvență asigură că toate aplicațiile dvs. oferă o experiență de încredere și repetabilă pentru utilizatorii finali și echipele de asistență.

Adăugați detalii la poveste

Adăugarea unei povești tipice a utilizatorului poate include următoarele informații:

1. Titlu: Ca <persona>, pot <do something> astfel încât <impact/priority/value>
2. Descriere: descrierea include (deși nu se limitează la) anumite detalii cheie, cum ar fi:
   • Scurtă descriere a scenariului care rezumă rezultatul dorit
   • Narațiune - descrie acțiunile pe care utilizatorii le vor întreprinde pentru a naviga și a realiza scenariul
   • Narațiune alternativă - descrie alte moduri în care utilizatorii pot obține același rezultat
   • Note de proiectare – înregistrează entitatea, câmpurile, vizualizările, ecranele de machetă și regulile de business asociate cu povestea utilizatorului
   • Roluri de securitate afectate - enumeră toate rolurile de securitate afectate sau care sunt relevante pentru povestea utilizatorului.

După ce adăugați toate aceste detalii, veți schimba starea poveștii utilizatorului în "Pregătită pentru revizuire". În cele mai multe cazuri, echipa de caracteristici și echipa de business (dacă este cazul) examinează poveștile utilizatorilor.

Revizuirea poveștii

Revizuirile poveștii au loc de obicei în cadrul echipei multidisciplinare pentru a se asigura că toate detaliile sunt menționate în poveste și că nu există ambiguitate. După finalizarea tuturor revizuirilor, recomandarea este de a atribui povestea utilizatorului unui membru al echipei. Asigurarea faptului că echipa dvs. rămâne aliniată în timpul procesului de dezvoltare este vitală pentru atingerea obiectivelor generale.

Adăugați activități și cazuri de testare

După revizuirea poveștilor, membrii echipei creează artivități în Azure DevOps. Procesul general pentru adăugarea de activități și cazuri de testare este următorul:

1. Deschideți lista de lucrări în curs sprint. Alternativ, creați un nou sprint.
2. Adăugați elemente de lucru existente la sprint. Dacă ați adăugat deja elemente de lucru care nu apar în sprint, atunci ar trebui să verificați zona și căile de iterație ale acestora. Nu uitați să atribuiți orice activități fără părinte elementelor de lucru relevante.
3. Adăugați activități la lucrările în curs. Dacă nu aveți elemente de lucrări în curs atribuite sprintului dvs., atunci faceți aceasta acum. Setați, de asemenea, datele de începere și de încheiere a sprintului.
4. completați acest formular pentru activități. Ca regulă generală, finalizarea activităților nu ar trebui să dureze mai mult de o zi. Activitățile care sunt mai mari decât acest interval de timp ar trebui defalcate.
5. Urmăriți sau integrați orice activități fără părinte. Puteți urmări activitățile fără părinte la fel ca și alte activități sau le puteți trage la un element de lucrări în curs existent pentru a-i găsi un părinte.

După ce adăugați activități și cazuri de testare, puteți continua să setați capacitatea sprintului.

Pentru mai multe informații despre adăugarea activităților, consultați elementele din Adăugați activități la lucrările în curs pentru a sprijini planificarea sprintului.

Pregătiți soluțiile

Un aspect important al dezvoltarii în comun reușite este un proces structurat de gestionare a versiunilor. Soluțiile sunt mecanismul de implementare a gestionării ciclului de viață al aplicației (ALM); utilizați soluții pentru a distribui componente în medii prin activități de export și import. O componentă reprezintă un artifact utilizat în aplicația dvs. și este ceva ce puteți teoretic particulariza. Orice lucru care poate fi inclus într-o soluție este o componentă, cum ar fi tabele, coloane, aplicații create pe planșă și proiectate pe bază de model, fluxuri Power Automate, roboți de chat, diagrame sau pluginuri.

Implementări

Componentele pot necesita mai multe sprinturi pentru a fi finalizate, în funcție de complexitate și viteza echipei. Componentele ar trebui să fie adăugate la o soluție într-un mediu de dezvoltare pe măsură ce activitățile sunt finalizate. Soluțiile sunt apoi importate într-un mediu de producție după ce sunt testate. Vă recomandăm să mențineți, de asemenea, un mediu de testare pentru a efectua teste de la un cap la altul și pentru a încerca implementarea soluției înainte de a intra în producție.

Medii Power Platform

Mediile sunt un spațiu de stocare, gestionare și partajare a datelor, aplicațiilor și proceselor de business din organizația dvs. Acestea servesc și drept containere pentru a separa aplicații care pot avea roluri diferite, cerințe de securitate sau segmente de public vizate.

Dacă organizația dvs. are o configurație cu mai multe echipe multidisciplinare în care fiecare echipă își dezvoltă propriile soluții, este important să coordonați durata sprinturilor și lansărilor. Sprinturile nu trebuie să aibă o lungime constantă de-a lungul cronologiei unui proiect și pot varia ca durată între echipe, în funcție de preferințele fiecărui grup. Cu toate acestea, cadența de lansare nu poate fi mai mică decât cea mai scurtă durată de sprint din toate echipele.

Control sursă

Luați în considerare adoptarea unui sistem de control al codului sursă precum Azure DevOps. Azure DevOps oferă servicii dezvoltatorilor pentru a sprijini echipele în vederea planificării muncii, colaborării la dezvoltarea codului și creării și implementării aplicațiilor.

Exportați o soluție din mediul dvs. de dezvoltare care conține aplicațiile și particularizările dvs., despachetați soluția și stocați componentele în sistemul dvs. de control sursă.

Subiect complex: recenzii pentru solicitări de tragere (PR)

Ar trebui să creați PR-uri numai pentru poveștile care sunt active și au avut caracteristici revizuite și aprobate. Ar trebui să vă asigurați că versiunea soluției este corectă, urmând instrucțiunile de sprint și dezvoltare stabilite în Implementați practicile Scrum pentru echipa dvs. în Azure Boards. Rezultatele testelor din PR pot fi capturi de ecran sau videoclipuri care descriu funcționalitatea în curs de generare.

Automatizarea procesului de guvernanță a PR-urilor ajută la asigurarea calității codului fără a necesita o revizuire manuală a verificărilor de bază, cum ar fi versiunile de soluție.

Șabloane și standardizare

Șabloanele și standardizarea oferă eficiență, ajutând la promovarea coerenței în cadrul echipei. Toate aspectele operațiunilor echipei— fie că este vorba despre sarcini de integrare, prezentări de revizuire a poveștilor sau șabloane de articole de lucru care ajută la economisirea timpului și oferă îndrumări echipelor atunci când definiți poveștile utilizatorilor, funcțiile, erorile sau sarcinile— beneficiați de standardizare și simplificare.

Implementarea unui model de asistență eficient

Un model de asistență eficient este esențial pentru succesul pe termen lung al unei aplicații după implementarea sa, așa cum s-a subliniat în secțiunea anterioară despre generarea unei matrice de asistență. Erorile și întreruperile sunt inevitabile, așa că este vital ca echipa să aibă o abordare structurată pentru a face față acestor apariții, iar matricea de asistență oferă cadrul necesar.

Crearea acordului privind nivelul serviciului

Un factor cheie în orice model de asistență este definirea Acordului privind nivelul serviciului (SLA). SLA ar trebui să fie un document formal pe care echipa îl întocmește și care conține secțiuni care acoperă următoarele elemente:

• Întreruperi – ce nivel de întrerupere a serviciului este acceptabil, cine să fie informat, ce acțiuni trebuie întreprinse, confirmarea reluării serviciului și acțiuni pentru a preveni repetarea. Orice proceduri de testare automatizate pe care le folosește echipa trebuie să se alinieze cu toleranța așteptată la întrerupere și cu SLA aplicabil.
• Erori – cine poate notifica, atribuirea nivelurilor de severitate, clasificare, acțiuni privind detectarea, cine este responsabil de rezolvare și semnare.
• Escaladări – niveluri de escaladare, repartizarea personalului pe niveluri, responsabilitățile de la fiecare nivel, liste de distribuție pentru fiecare nivel și așa mai departe.

SLA ar trebui să fie stocat în portalul de documentație al echipei și actualizat după cum este necesar.

Livrarea asistenței pentru aplicații

Cea mai bună abordare pentru furnizarea asistenței pentru aplicații specificată în SLA este ca echipa care a creat soluția să fie responsabilă și pentru asistență. Avantajele acestui sistem sunt:

1. Încurajează o dezvoltare de mai bună calitate, deoarece cei care au creat aplicația știu că vor trebui să ofere asistență.
2. Creatorii vor putea găsi și remedia erori mai rapid decât o echipă terță, pur și simplu pentru că își cunosc aplicația mai bine.
3. Delegarea reparării unui software potențial critic pentru misiune unui alt grup poate fi demoralizatoare și consumatoare de timp pentru acel grup. Ca și în alte faze ale creării, dezvoltării și implementării aplicațiilor, echipa multidisciplinară ar trebui să colaboreze cu departamentul IT pentru asistență atunci când este necesar.

Monitorizarea gradului de satisfacție și de utilizare a aplicației

Partea finală a efortului de asistență este monitorizarea și evaluarea gradului de satisfacție și de utilizare a aplicației implementate. Valorile sunt utile aici, împreună cu metode mai tradiționale, cum ar fi sondajele și chestionarele. Pentru mai multe informații despre monitorizarea utilizării aplicației, consultați Admin Analytics pentru Power Apps.

În cele din urmă, în cazul în care clienții nu folosesc o aplicație publicată, atunci acea aplicație nu își îndeplinește scopul. Întâlnirile regulate de revizuire pot verifica aceste valori de satisfacție și de utilizare pentru a crea o buclă de feedback pozitiv care poate modifica sau adăuga povești la lucrările în curs pentru a genera și apoi a implementa o versiune actualizată a aplicației.

Rezumat

Dezvoltarea de instrumente fără cod și cu cod redus, precum Power Apps oferă opțiuni extinse pentru tehnologii sau creatorii de business pentru a crea, dezvolta și implementa aplicații. Această dezvoltare funcționează cel mai bine într-un mediu cu o echipă multidisciplinară, care cuprinde un proprietar de produs, un expert în domeniu, un dezvoltator profesionist și un administrator, această echipă aducând alte resurse după cum este necesar.

Integrarea abordărilor de dezvoltare Agile și Scrum în echipele multidisciplinare are ca rezultat o dezvoltare mai rapidă a aplicațiilor și o probabilitate mai mare de implementare reușită cu un set de caracteristici care face o diferență semnificativă pentru business. Aplicând aceste bune practici, îndrumări și recomandări, echipa dvs. multidisciplinară va putea folosi Power Apps pentru a aborda provocările de transformare digitală ale organizației dvs.