Sākums
» Tips
»
Bezmaksas projekta statusa pārskata prezentācijas veidne Agile komandām: Ko iekļaut?
Bezmaksas projekta statusa pārskata prezentācijas veidne Agile komandām: Ko iekļaut?
Agile komandas var radīt daudz darbības datu, tomēr ieinteresētās puses joprojām var palikt ar pamatjautājumiem: Vai mēs esam pareizajā kursā? Kas mainījās? Kas ir apdraudēts? Kāds lēmums ir nepieciešams no manis? Noderīgai projekta statusa pārskata prezentācijai ir jāatbild uz šiem jautājumiem ātri, nepārvēršot to par otro darbu sarakstu, komandas pasākumu aizstājēju vai vanitātes rādītāju kolekciju.
Šī lapa piedāvā bezmaksas, gatavu projekta statusa pārskata prezentācijas veidni Agile komandām. Jūs varat izveidot slaidu struktūru PowerPoint vai citā prezentācijas rīkā un pielāgot to savam produktam, projektam, ziņošanas ritmam un auditorijai. Mērķis nav likt visām komandām ziņot vienādi. Mērķis ir sniegt jums vieglu struktūru, kas padara progresu, nenoteiktību un lēmumus redzamus.
Kādu lēmumu šim statusa pārskatam jāpalīdz pieņemt?
Sāciet šeit, pirms izvēlaties krāsas, diagrammas vai slaidu izkārtojumus. Statusa prezentācija ir noderīga, kad tā palīdz ieinteresētajai pusei pieņemt lēmumu, apstiprināt, novērst šķērsli, mainīt prioritāti, pieņemt prognozi vai saprast būtiskas izmaiņas. Ja auditorija var izlasīt prezentāciju, bet joprojām nevar pateikt, kam nepieciešama uzmanība, pārskats, visticamāk, ir pārāk aprakstošs un nepietiekami orientēts uz lēmumiem.
Agile komandai visnoderīgākie jautājumi parasti ir:
Vai mēs gūstam nozīmīgu progresu virzībā uz pašreizējo produkta vai projekta mērķi?
Kāds rezultāts vai pieaugums tika pabeigts kopš iepriekšējā atjauninājuma?
Kas mainījies darbības jomā, laika grafikā, riskos vai pieņēmumos?
Kas ir bloķēts un kas var palīdzēt novērst šo šķērsli?
Uz ko komanda koncentrēsies tālāk?
Kāds lēmums vai ieinteresētās puses rīcība ir nepieciešama tagad?
Oficiālajā Scrum rokasgrāmatā tiek uzsvērta caurspīdība, pārbaude un adaptācija. Tajā arī teikts, ka progress virzībā uz saskaņotajiem mērķiem ir bieži jāpārbauda, lai varētu konstatēt nevēlamas novirzes vai problēmas. Tas padara kodolīgu statusa prezentāciju visvērtīgāko, kad tā uzlabo redzamību un atbalsta reālu adaptāciju, nevis vienkārši dokumentē, ka darbs tika veikts. Skatiet oficiālo Scrum rokasgrāmatu.
Kādi slidi ietilpst bezmaksas Agile projekta statusa pārskata veidnē?
Spēcīga noklusējuma opcija ir septiņi galvenie slidi ar neobligātu metrikas pielikumu. Mazākas komandas var apvienot vairākus no šiem trim vai četros slaidos. Lielākās programmās var pievienot detaļas, taču galvenajai prezentācijai jāpaliek viegli pārskatāmai.
Slaida
Ko parādīt
Jautājums, uz ko tas atbild
1. Vāks un ziņošanas periods
Projekta vai produkta nosaukums, komanda, ziņošanas periods, atbildīgais
Kādu atjauninājumu es skatos?
2. Izpildu statuss
Kopējais statuss, pašreizējais mērķis, galvenās izmaiņas, galvenais risks, nepieciešamais lēmums
Kas tagad ir vissvarīgākais?
3. Sprinta vai iterācijas progress
Sprinta mērķis, pabeigtais darbs, darbs procesā, nozīmīga tendence
Nākamā fokusa zona, atbildīgais, termiņš, skaidri lēmumu pieprasījumi
Kas notiks pēc šī atjauninājuma?
Neobligāts pielikums
Atbalstošās tendences un operatīvās metrikas
Kādi pierādījumi atbalsta kopsavilkumu?
AI ģenerēta ilustrācija ar izdomātiem parauga datiem, kas parāda vienu iespējamo Agile projekta statusa pārskata slaidu. Tas nav reāla projekta vai izmērīta rezultāta ekrānuzņēmums.
Kāda informācija jāiekļauj izpildu statusa slaidā?
Atbildiet uz galvenajiem jautājumiem, pirms rādāt detaļas. Praktisks izpildu statusa slaidā var ietilpt pieci punkti: pašreizējais mērķis, kopējais statuss, viens vai divi pierādījumu punkti, galvenais risks un nepieciešamais lēmums vai rīcība. Auditorijai nevajadzētu interpretēt sešas diagrammas, lai atklātu secinājumu.
Ja izmantojat sarkanu/dzeltenu/zaļu statusu, definējiet noteikumus. Piemēram, zaļš var nozīmēt, ka pašreizējais mērķis ir sasniedzams esošajā prognozē un neviena neatrisināta problēma neprasa eskalāciju; dzeltens var nozīmēt, ka mērķis joprojām ir sasniedzams, bet būtisks risks vai atkarība prasa aktīvu pārvaldību; sarkans var nozīmēt, ka pašreizējā prognoze vai mērķis vairs nav ticams bez izmaiņām. Tie ir piemēri, nevis universāli Agile standarti. Jūsu organizācijai jāizvēlas definīcijas, kas ir konsekventas un redzamas.
Nemainiet statusa krāsu tikai tāpēc, ka tuvojas sapulce. Ticamam statusa indikatoram jāatspoguļo pierādījumi un zināmā nenoteiktība, nevis prezentācijas spiediens.
Kādas Agile metrikas ir noderīgas statusa prezentācijā?
Izmantojiet metrikas, kas šai auditorijai izskaidro progresu vai risku. Tendences un konteksts parasti ir svarīgāki par vienu skaitli. Atkarībā no darba, noderīgi pierādījumi var ietvert pabeigtos rezultātus, cikla vai izpildes laika tendences, caurlaidspēju, izsprukušos defektus, pakalpojuma uzticamību, prognozes pārliecību, klientu atsauksmes vai progresu virzībā uz produkta mērķi.
Burndown, burnup, kumulatīvās plūsmas un līdzīgas prakses var būt noderīgi prognozēšanas palīglīdzekļi, taču Scrum rokasgrāmata skaidri norāda, ka šādas prakses neatceļ empirismu. Tajā arī brīdina, ka sarežģītā vidē nākotne ir pēc būtības nenoteikta. Tas ir labs iemesls prognozes apzīmēt kā prognozes un parādīt pieņēmumus, nevis prezentēt diagrammu kā noteiktību.
Vai ātrumu (velocity) jāiekļauj slaidā?
Tikai tad, kad tas palīdz paredzētajai auditorijai saprast komandas pašu plānošanas kontekstu. Scrum rokasgrāmata neparedz ātrumu kā obligātu Scrum metriku. Ja to iekļaujat, paskaidrojiet, ko tas nozīmē konkrētajai komandai, un izvairieties no tā izmantošanas kā starpkomandu produktivitātes rangam. Skaitlis bez konteksta var veicināt nepareizu lēmumu.
Vai prezentācijai jāaizstāj Sprinta pārskats (Sprint Review)?
Nē. Scrum metodoloģijā Sprinta pārskats ir darba sesija, kurā Scrum komanda un ieinteresētās puses pārbauda sprinta rezultātu un apspriež progresu virzībā uz produkta mērķi. Scrum rokasgrāmata īpaši norāda, ka Sprinta pārskats nedrīkst būt ierobežots tikai ar prezentāciju. Statusa prezentācija var atbalstīt sarunu, sniegt kodolīgu iepriekšēju izlasīšanu vai apkopot informāciju cilvēkiem, kuri nevar apmeklēt, taču tai nevajadzētu pārvērst pārskatu par vienvirziena ziņošanu.
Līdz 2026. gada septembrim oficiālā Scrum Guides vietne joprojām norāda 2020. gada novembra Scrum rokasgrāmatu kā pašreizējo oficiālo versiju. Pašreizējo versiju varat pārbaudīt oficiālajā Scrum rokasgrāmatas lejupielādes lapā.
Cik daudz detaļu jāiekļauj dažādām auditorijām?
Izstrādājiet galveno prezentāciju cilvēkiem, kuriem ir jāpieņem vai jāietekmē lēmumi. Izpildu direktoriem parasti ir nepieciešams pašreizējais mērķis, biznesa ietekme, prognoze, būtiski riski un lēmumu pieprasījumi. Produktu un piegādes vadītājiem bieži ir nepieciešams tas pats kopsavilkums, kā arī atskaites punktu un atkarību detaļas. Komandai var būt nepieciešami dziļāki operatīvie dati, taču šī informācija var atrasties darbu sarakstā, panelī, problēmu izsekošanas sistēmā vai pielikumā, nevis izpildu slaidos.
Vienkāršs tests ir noņemt jebkuru elementu, kas nemaina izpratni vai rīcību. Ja slaidā ir divdesmit darba vienības, bet auditorijai tikai jāzina, ka viena ārēja atkarība apdraud atskaites punktu, kopsavilkumā norādiet atkarību un saistiet to ar detalizētu izsekošanas sistēmu, nevis reproducējiet darbu sarakstu.
Kā jāprezentē riski un šķēršļi?
Nepalieciet pie problēmu saraksta. Katram būtiskajam elementam jāparāda, kāpēc tas ir svarīgs, kas tiek darīts, kas ir atbildīgs par nākamo darbību un vai ir nepieciešama ieinteresētās puses palīdzība. Kompaktai riska rindai var izmantot šādu struktūru:
Risks vai šķērslis: apraksts vienkāršā valodā.
Ietekme: mērķa, darbības jomas, klienta, kvalitātes, izmaksu vai laika sekas.
Atbilde: mazināšana vai nākamais eksperiments.
Atbildīgais: persona, kas atbildīga par turpmāko darbību.
Nepieciešamais lēmums: apstiprinājums, eskalācija, prioritātes maiņa vai nav.
Atšķiriet šķērsli, kas jau kavē progresu, no riska, kas var rasties. Šī atšķirība padara eskalāciju skaidrāku un novērš situāciju, kurā katrs jautājums izskatās vienlīdz steidzams.
Cik bieži jāatjaunina Agile statusa prezentācija?
Izmantojiet ritmu, kas atbilst ieinteresēto pušu lēmumiem un komandas piegādes ritmam. Iknedēļas atjauninājums var būt jēdzīgs ātri mainīgām iniciatīvām ar ārējām atkarībām. Ar sprintu saistīts atjauninājums var būt pietiekams, ja sprints jau nodrošina pareizo pārbaudes ritmu. Mēneša prezentācija var derēt vecākajai pārvaldībai, ja būtiski lēmumi tiek pieņemti retāk.
Scrum rokasgrāmata nosaka, ka sprinti ir fiksēta garuma notikumi, kas ilgst ne vairāk kā vienu mēnesi, un ka regulāri Scrum notikumi rada iespējas pārbaudei un adaptācijai. Tas nenozīmē, ka katrai Scrum komandai ir nepieciešama atsevišķa iknedēļas statusa prezentācija. Izvairieties no ziņošanas darba radīšanas, kas dublē informāciju, kas jau ir redzama un saprotama citur.
Kas padara šo prezentāciju par atkārtoti lietojamu veidni, nevis vienreizēju prezentāciju?
Saglabājiet struktūru stabilu un saturu aizvietojamu. Izmantojiet konsekventus vietturus ziņošanas periodam, pašreizējam mērķim, statusa kopsavilkumam, risku tabulai, atskaites punktu prognozei un lēmumu pieprasījumiem. Pastāvīgus vizuālos noteikumus, piemēram, logotipa novietojumu, tipogrāfiju, kājeni un standarta izkārtojumus, ievietojiet prezentācijas veidnē, nevis būvējiet tos katru ciklu no jauna.
Ja strādājat ar PowerPoint tīmekļa versijā, Microsoft norāda, ka varat izveidot prezentācijas no veidnēm, taču tās pašreizējā veidņu izveides atbalsta lapa norāda, ka atkārtoti lietojama PowerPoint veidnes faila izveide prasa darbvirsmas versiju. Šis ierobežojums ir svarīgs, ja jūsu mērķis ir īsta .potx veidne, nevis prezentācija, ko manuāli dublējat.
Ko mainīt pirms veidnes prezentēšanas?
Aizstājiet vispārīgās etiķetes ar valodu, ko jūsu ieinteresētās puses faktiski lieto. Padariet pašreizējo mērķi skaidru. Noņemiet neizmantotās metrikas. Definējiet statusa krāsas. Pārbaudiet datumus un atbildīgos. Pēc tam padariet lēmumu pieprasījumus konkrētus: tā vietā, lai rakstītu “Nepieciešams atbalsts”, rakstiet, kāds lēmums ir nepieciešams, kurš to pieņems un līdz kad.
Tāpat atšķiriet faktus no prognozēm. “Trīs funkcijas atbilda Definition of Done” ir apgalvojums par pabeigtu darbu, ja jūsu komanda to ir pārbaudījusi. “Izlaišana paredzēta nākamajā mēnesī” ir prognoze, un tai jāiekļauj attiecīgie pieņēmumi vai pārliecība. Šo kategoriju atšķiršana palīdz lasītājiem saprast, kas ir zināms, un kas var mainīties.
Kā saprast, vai statusa pārskats darbojas?
Pēc atjauninājuma pārbaudiet rezultātu, nevis slaidu izskatu. Noderīgam pārskatam ir jāļauj lasītājam atbildēt uz jautājumiem par pašreizējo mērķi, svarīgāko progresu, galveno risku, īstermiņa prognozi un nākamo lēmumu, neprasa atsevišķu skaidrojumu.
Vai auditorija var identificēt vienu vai divus jautājumus, kam nepieciešama uzmanība?
Vai viņi redz, kas mainījies kopš iepriekšējā atjauninājuma?
Vai pabeigtie rezultāti ir atdalīti no prognozēm?
Vai riski ir saistīti ar atbildīgajiem un atbildēm?
Vai lēmumu pieprasījumi ir skaidri?
Vai prezentācija izvairās no detalizētu darbu saraksta datu dublēšanas, kas pieder citur?
Vai tā atbalsta pārbaudi un adaptāciju, nevis pārvērš Agile notikumus par statusa teātri?
Ja atbilde uz vairākiem no šiem jautājumiem ir “nē”, vienkāršojiet prezentāciju, pirms pievienojat vairāk diagrammu. Labākā projekta statusa pārskata prezentācijas veidne nav tā, kurā ir visvairāk slaidu. Tā ir tā, kas rada pietiekamu caurspīdību, lai pareizie cilvēki saprastu situāciju un pieņemtu nākamo noderīgo lēmumu.