Parafrasering av et kjent konsept i prosjektledelse, kan man si, «Planlegging er uunnværlig, men planer er ubrukelige. Derfor inspisere og tilpasse.»
Tradisjonelle planer drives av datoer-mest sannsynlig med en sluttdato som den primære drivkraften. I tradisjonell prosjektledelse samler du kravene fra interessentene dine, bygger omfanget av prosjektet og bryter prosjektet ned til håndterbare deler av arbeidet. Dette skaper i sin tur en arbeidsnedbrytingsstruktur (WBS). Deretter brytes det laveste NIVÅET AV WBS, dvs. arbeidspakker, videre ned i aktiviteter. Aktivitetene knyttes deretter til avhengigheter, og ressurser estimeres og brukes på aktiviteter for å lage en ende-til-ende-tidsplan for prosjektet. Denne planen blir deretter overvåket og kontrollert ved hjelp av en tidsplan forvaltningsplan, som vanligvis er et datterselskap plan av konsolidert prosjektstyringsplan.
men hvor mange ganger skjedde det at det du planla og hva som faktisk skjedde på bakken, matchet? Du vet allerede svaret! Åpningen sitat betyr at planlegging er viktig, men forventer at vi kan følge planen nøyaktig er ikke en klok ting å gjøre. Når det er høye kverner i krav og høy usikkerhet i teknologi eller plattform, Går PMs vanligvis med adaptive (Eller Smidige) livssykluser.
faktisk sier den fjerde verdien I Agile Manifestet: «Å Reagere på endring over å følge en plan.»Agile er endringsdrevet, og mest sannsynlig vil disse endringene bli drevet av kunder. Dette fører til et konsept som kalles Agile Release Planning.
Utgivelsesplanlegging er ulikt tradisjonell planlegging, hvor den komplette planen vurderes på forhånd, utdypes i detalj, og kan kun endres med formelle endringsforespørsler. En utgivelsesplan kan oppdateres mange ganger basert på tilbakemeldinger fra tidligere iterasjoner.
fordi adaptive livssykluser er inkrementelle i naturen, kan organisasjoner slippe på slutten av hver iterasjon. De kan også velge å slippe ut etter noen iterasjoner eller til og med kontinuerlig. Dette krever en langsiktig planlegging, men kan effektivt tilrettelegges ved å benytte utgivelsesplanleggingsteknikken, som nylig ble introdusert i 6. utgave AV Pmbok-Guiden.
For aspiring Project Management Professionals (Pmp) og Sertifiserte Medarbeidere I Project Management (CAPM) , Er Agile Release Planning et nøkkelbegrep å vite. Pmbok Guide 6th edition har introdusert Smidige hensyn for hvert kunnskapsområde. Dette er også nyttig for aspiring Agile Certified Practitioners (ACPs).
når vi kommer inn i dette mer, la oss først se hvordan utgivelsesplanene utvikles på et høyt nivå.
fra Visjon til Veikart For Å Frigjøre Planer
i Agile-prosjekter starter arbeidet med en produktvisjon. Visjonen oversetter deretter til et produkt veikart. Veikartet inneholder funksjonene som skal utvikles over en tidsperiode. Du kan også si at et veikart representerer omfanget av produktet, som leveres i ulike utgivelser. Dette forer til utgivelsesplanene og er vist i figuren nedenfor.
Veikart Og Produkt Backlog
en komponent i sekvensen ovenfor er produktet veikart, og for å forstå produktet veikart, først må vi forstå produktet backlog. I Agile tilnærminger, alle kravene – både prosjektkrav og produktkrav – er en del av produkt backlog (pb). Hvert element i produktbacklog kalles et produktbacklog-element (eller PBI). Annet enn funksjoner (krav), kan et produkt backlog element være en endringsforespørsel, feil, feil, problem, eller til og med bestemt teknisk arbeid.
Som vi vet, i Agile prosjekter, er kravene kontinuerlig utvikling og det er betydelige usikkerheter/risikoer. Som et resultat prioriterer vi Vanligvis PBIs. De prioriterte Pbi-Ene tas fra toppen av ordrereserven og leveres til kunden (e). Høy prioritet elementer forblir på toppen av etterslepet og er finkornet, mens lav prioritet elementer er på bunnen av etterslepet og grovkornet. Prioriteringen av varene i PB bestemmer detaljnivået for varen i produktkøen. Dette er avbildet i figuren nedenfor.
hvis Du bruker Smidige verktøy Som Microsoft Project, kan du raskt utvikle produktreserven. Et eksempel produkt backlog, tegnet MED MS Project, er vist nedenfor.
Her har vi en produkt backlog som viser produkt backlog items (PBIs)av «Opprett en ny bruker», «Logg inn på online trading system, «»Overfør en aksje,» etc. Hvis du vil legge til et annet backlog-element, må du bare klikke på » + «- ikonet for «Ny Oppgave» – kommandoboksen.
elementene på øverste nivå i produktbackloggen kan skrives i brukerhistorier, som estimeres i story points – en relativ enhet-mindre mål.
nå, kommer til produktet veikart, kan du bare si det er et produkt backlog med en tidslinje. Et veikart viser prosjektets planlagte fremtid (dvs. planlagte og / eller foreslåtte produktutgivelser) eller utgivelsestemaer, og viser funksjoner på høyt nivå av produktet. Veikartet forteller hvilke funksjoner eller epics (en episk, ganske enkelt, er en stor brukerhistorie) vil bli levert i hver utgivelse.
Utgivelsesplan
produktkartet driver utgivelsesplanene. En utgivelsesplan gir utgivelsesplanen-hver utgivelse er vanligvis tre til seks måneder. En utgivelse inneholder mange iterasjoner – fra Iterasjon 0 (iterasjon null) Til Iterasjon N. Iterasjon 0 kan brukes til prosjektgodkjenninger, sette opp miljøet for prosjektet, innledende oversikt og designdiskusjoner, etc. Noen Smidige utøvere bruker Iterasjon-H (herding iterasjon), som er den endelige iterasjonen på slutten av utgivelsen for å forberede seg på levering. Denne iterasjonen kan inkludere endelige arbeidselementer som opplærings-og markedsføringsmateriell, endelige utgivelsesnotater, installasjonsveiledninger, system – /brukerveiledninger, etc. Dette er avbildet nedenfor.
som vist har utgivelsesplanen iterasjoner – fra «Iteration-0» til «Iteration – N.» Du kan bestemme deg for å få en utgivelse etter noen iterasjoner og / eller en endelig utgivelse etter den siste iterasjonen.
utgivelsesplanen presenterer et veikart for hvordan teamet har til hensikt å oppnå prosjektvisjonen innenfor rammen av prosjektmål og begrensninger. Det hjelper produkteier og hele teamet bestemme hvor mye må utvikles og hvor lang tid det vil ta før de har en releasable produkt. Det formidler forventninger om hva som sannsynligvis vil bli utviklet og i hvilken tidsramme. Utgivelsesplanen kan også fungere som en veiledningspost som laget kan utvikle seg til. Utgivelsesplanen kan oppdateres på slutten av en iterasjon, og den gjenspeiler dagens forventninger som vil bli inkludert, slik at de kan leveres i etterfølgende iterasjoner.
Release Planning med Product Backlog
for å få en bedre forståelse av release planning, kan du visualisere release planene ved hjelp av product backlog.
vi vet allerede at varene i produktkøen er rangert eller bestilt, basert på deres prioritet. Toppnivåpostene som er finkornet, vil være klare til konsum i neste iterasjon (under umiddelbar neste utgivelse). Den prioriterte backlog, med funksjoner og andre elementer, er vist på venstre side av figuren nedenfor.
 |
 |
INNENFOR MS Project må du bare velge, dra og slippe backlog-elementer og ordne dem etter behov for å prioritere dem. Dette er vist på høyre side av figuren ovenfor. Med tanke på forrige eksempel som viser produktbacklog i MS Project, har vi denne relative rangeringen: Først «Logg inn på online trading system, «neste» Opprett en ny bruker, «deretter» Kjøp en aksje, » etc.
som vist ovenfor har jeg valgt og dratt funksjonselementet «Logg inn på online trading system» og droppet det foran tidligere funksjonselement » Opprett en ny bruker.»Det valgte elementet var litt grått ut da jeg dro og droppet det .
ved hjelp av etterslepet kan du bestemme hvilken av etterslepspostene som skal leveres i de neste utgivelsene. Nedenfor ser vi at elementene i neste utgivelse (Dvs. Utgivelse 1) er mest prioritert. Elementene For Utgivelse 2 kan også prioriteres, men vi ser at elementer for Utgivelse 3 ikke prioriteres da de er lavprioriterte elementer.
du kan visualisere denne utgivelsen planlegging MED MS Project, også. Se på figuren nedenfor. Det Er PBIs vist seg å bli tatt i ulike utgivelser. Husk at en utgivelse inneholder iterasjoner? I vårt tilfelle, for den første utgivelsen, har vi tre iterasjoner, og alle elementer forventes å bli levert i disse iterasjonene. En iterasjon kalles en sprint i Scrum framework, som er et populært rammeverk som brukes Av Agile PMs. For de neste to utgivelsene (Dvs. Utgivelse 2 og Utgivelse 3) har Vi Pbiene, men vi har ennå ikke bestemt oss for iterasjonene (eller sprintene).
Iterasjonsplanlegging
hvis du har fulgt, består utgivelsesplanen av Iterasjon 0 Til Iterasjon N, og vi kan bestemme oss for å slippe på slutten av noen få iterasjoner eller hver iterasjon. Men hva skjer i en iterasjon? Enkelt sagt er omfanget av et sett med funksjoner i iterasjonen bekreftet i begynnelsen av iterasjonen og levert på slutten av iterasjonen.
funksjonene som er bekreftet og tatt for iterasjon er brutt ned til oppgaver (eller aktiviteter) og estimert i timer av gruppemedlemmene. Sekvensen av trinn fra produktkart for å frigjøre plan til iterasjonsplan er vist i diagrammet nedenfor.
Oppsummering av figuren ovenfor, vil disse være hovedpunktene:
- produktets vision drives product roadmap
- product roadmap drives release plans
- en release plan vil ha iterasjoner
- Funksjoner, som er estimert i story points, er utviklet i en iterasjon
- Funksjoner er brutt ned til oppgaver, som er estimert i timer
ved hjelp av ms project 2016 kan du raskt bygge En Utgivelsesplan. Med tanke på vårt tidligere backlog-eksempel har vi tre iterasjoner / sprints for den første utgivelsen (Dvs. Sprint 1, Sprint 2 og Sprint 3). Hver sprint har et sett med funksjoner som skal leveres. Dette er vist i under i «Sprint Planning Board» visning.
Du kan også bore ned for å se hva som skjer på iterasjon / sprintnivå og finne ut hvilke Pbier som blir jobbet på. MS Project viser dette i» Nåværende Sprint Board » – visning. Se figuren nedenfor.
For Sprint 1 har vi tre elementer som skal leveres- «Logg inn på det elektroniske handelssystemet», «Opprett en ny bruker» og » Kjøp en aksje.»Disse går gjennom tre arbeidsflyttilstandene «Neste Opp», «Pågår» og » Ferdig.»Selvfølgelig kan du legge til, fjerne eller tilpasse disse arbeidsflytstatusene etter behov.
Utgivelsesplan Vs. Iterasjonsplan
hvis du tar eksamen, må du også vite forskjellene Mellom Utgivelsesplan og Iterasjonsplan. De er notert i tabellen nedenfor. Vanligvis er iterasjonene timeboxed i to til fire uker. Men i noen tilfeller, FOR EKSEMPEL XP (en Annen Agile framework), kan iterasjoner være en uke lang.
Project Management Body Of Knowledge (Pmbok) Guide, 6. Utgave, Av Project Management Institute (PMI)
Jeg Vil Være EN PMP: Den Enkle og Enkle Måten Å VÆRE EN PMP, 2. utgave, Av Satya Narayan Dash
Jeg Vil Være EN ACP: Den Enkle Og Enkle Måten Å VÆRE EN ACP, Av Satya Narayan Dash
Microsoft Project 2016 Live Lessons, Av Satya Narayan Dash
Agile Practice Guide, Av Project Management Institute (Pmi)