Kopīgot, izmantojot

Ieteikumi programmatūras izstrādes vadības prakses formalizēšanai

Attiecas uz šo Power Platform labi arhitektūras operatīvās izcilības kontrolsaraksta ieteikumu:

OE:03 Formalizējiet programmatūras ideju un plānošanas procesu, pamatojoties uz noteiktajiem nozares un organizāciju standartiem. Izmantojiet kopīgu, prioritāru uzkrājumu un pietiekami detalizētas specifikācijas. Veicināt nepārtrauktus uzlabojumus plānošanas procesā, pamatojoties uz rezultātiem.

Šajā rokasgrāmatā ir aprakstīti ieteikumi darba slodzes izstrādes prakses pārvaldībai saskaņā ar noteiktajiem standartiem. Jūsu komandas spēja ražot augstas kvalitātes programmatūru balstās uz strukturētu, sadarbības pieeju attīstības plānošanai. Darba slodzes komandām ir jāsaprot un skaidri jāpaziņo ieinteresētajām personām par paveikto darbu. Precīzāk, darba slodzes komandām vajadzētu būt skaidram priekšstatam par darbu, kas jāveic izstrādes ciklā, un jānodrošina, ka visas ieinteresētās puses ir saskaņotas ar šī darba "kāpēc". Noteiktie standarti nosaka, kā jāveic izstrādes prakse, un ļauj darba slodzes komandai efektīvi sadarboties, samazinot neskaidrību risku par mērķiem un cerībām.

Galvenās dizaina stratēģijas

Formalizējiet savu darba slodzes izstrādes praksi, lai palīdzētu nodrošināt kopīgu izpratni par mērķiem un cerībām.

Neuztveriet zema koda darba slodzes kā zemas sarežģītības. Jūs joprojām gūsiet labumu no zema koda darba slodzes izstrādes un pārvaldības formalizēšanas. Mācieties no citām programmatūras izstrādes komandām. Ir izveidota lēmumu matrica, kas nosaka formalizācijas līmeni, kas nepieciešams, pamatojoties uz darba slodzes sarežģītību un kritiskumu.

Attīstības plānošanas standarti

Tālāk norādītie standarti var palīdzēt jums izstrādāt visaptverošu attīstības plānošanas stratēģiju.

  • Prioritāšu noteikšana: Darba kārtības un apjoma plānošana ietver izpratni par darba slodzes funkciju patieso ietekmi un vērtību uz uzņēmumu. Tas ietver arī šīs ietekmes novērtēšanu, salīdzinot ar citiem darba pieprasījumiem un jūsu produkta vai programmas vispārējo ceļvedi. Viens no veidiem, kā noteikt darba slodzes prioritātes, ir novērtēt visas darba slodzes biznesa vērtību . Jums var būt arī noderīgi novērtēt atsevišķus darba slodzes līdzekļus biznesa vērtībai.

  • Kategorizācija: izveidojiet procesus, kas nodrošina, ka kritiskajām lietojumprogrammām ir nepieciešamās aizsargmargas to atbalstam. Tajā pašā laikā pārliecinieties, ka produktivitātes scenārijus nepalēnina vai apslāpē pārāk daudz stingru procesu.

  • Sadarbība: ierosināto izmaiņu definēšanas procesam darba slodzē vajadzētu būt kopīgam centienam. Lielākā daļa darba slodzes izmaiņu ietekmē vairākas funkcijas un komponentus, tāpēc pēc iespējas vairāk darba slodzes komandas locekļu iesaistīšana palīdz nodrošināt, ka netiek izlaisti svarīgi apsvērumi un ka ikviens apzinās ietekmi uz savu konkrēto domēnu. Sadarbība arī palīdz skaidri definēt izmaiņu apjomu un to, kā sadalīt nepieciešamos uzdevumus skaidri definētos darba elementos. Lielāka grupa ar zināšanām dažādās jomās spēj sniegt pieredzi pamatotas aplēses par nepieciešamajiem centieniem.

  • Rīki: izmantojiet izveidotus, nozarē pārbaudītus rīkus un procesus, piemēram , Agile, Scrum un Kanban dēļus.

Kompromiss: Agile metodoloģija var kļūt pārāk stingra, ja tā ir pārāk preskriptīva. Cenšieties panākt līdzsvaru starp skaidri definētiem standartiem un inovācijām.

  • Izvietošana: plānojiet izmantot biežus mazus, iteratīvus izvietojumus, nevis lielus, retus izvietojumus.

  • Nosacījumi: standartizējiet pabeigto izstrādes ciklu definīciju, lai palīdzētu nodrošināt, ka atbalsta funkcijas, tostarp testēšana, dokumentācija un pieejamības līdzekļi, tiek veiksmīgi pabeigtas.

  • Komunikācija: definējiet standarta protokolus produktu īpašniekiem un projektu vadītājiem, lai reklamētu gaidāmos laidienus.

  • Lietotāju stāsti: standartizējiet lietotāju stāstu veidni. Labi uzrakstītiem lietotāju stāstiem jāievēro INVEST pieeja:

    • Es neatkarīgs: katram lietotāja stāstam jābūt neatkarīgam no citiem, ļaujot komandai sniegt rezultātus ar nelieliem soļiem.
    • N-apspriežams: Lietotāju stāstiem jābūt apspriežamiem un atvērtiem diskusijām un pārmaiņām.
    • V-Vērtīgs: Lietotāju stāstiem vajadzētu sniegt vērtību klientam.
    • E-Novērtējams: Lietotāju stāstiem jābūt novērtējamiem un skaidri definētiem.
    • S–mazs: lietotāju stāstiem jābūt maziem un koncentrētiem uz vienu funkciju.
    • T-testējams: lietotāju stāstiem jābūt pārbaudāmiem un skaidriem pieņemšanas kritērijiem.

  • Pieņemšanas kritēriji: standartizējiet pieņemšanas kritēriju veidni. Pārliecinieties, ka pieņemšanas kritēriji attiecas tieši uz lietotāja stāstu un tos var nepārprotami pierādīt, izmantojot vienu vai vairākus pieņemšanas testus.

  • Izsekošana: pārliecinieties, ka izstrādes process ir izsekojams. Jums ir skaidri jāizseko ražošanas darba slodzes stāvoklim un saistītajam kodam līdz kvalitātes nodrošināšanas testēšanai, pieņemšanas kritērijiem, lietotāju stāstiem un funkcijām. Detalizēta izsekošana dažos gadījumos var būt arī regulatīvā prasība, piemēram, veselības aprūpe.

  • Pārskatīšana: Regulāri veiciet savas izstrādes prakses iekšējos auditus, izmantojot izstrādes cikla retrospektīvas un pēcnāves pārbaudes. Procesu refleksijai jābūt nevainojamai un jākoncentrējas uz mācīšanos, ko var izmantot kā uzlabojumus. Pārliecinieties, ka komanda pārdomā, cik efektīvi bija lietotāja stāsts un uzdevumi, definējot nepieciešamos uzdevumus un laika aprēķinu precizitāti.

  • Atskaites: standartizējiet atskaites ieinteresētajām personām, kas sniedz noderīgus rādītājus, koncentrējoties uz izmaiņām. Koncentrēšanās uz pārmaiņām ļauj izsekot produkta paātrinājumam un palēninājumam. Noderīgi rādītāji var ietvert izmaiņas:

    • Ikmēneša pieņemšanas pieauguma temps
    • Veiktspēja
    • Apmācības laiks
    • Incidentu biežums

    Pārskatus nevajadzētu izmantot kā rīku, lai novērtētu indivīdu darbu, tāpēc izvairieties no metrikām, piemēram, stāsta punktiem vai koda rindām katram inženierim.

Power Platform Atvieglošana

Lai gan Power Platform nav produktu, kas tieši atvieglotu šo ieteikumu, Microsoft kaudzē varat izmantot citus rīkus. Azure Boards ir tīmekļa pakalpojums, kas ļauj komandām plānot, izsekot un apspriest darbu visā izstrādes procesā.

GitHub projekti ir pielāgojams projektu pārvaldības rīks projektu organizēšanai un integrējas ar jūsu problēmām un vilkšanas pieprasījumiem GitHub.

Nākamās darbības

Darbības izcilības kontrolsaraksts