parafrasera ett välkänt koncept i projektledning, man kan säga, ” planering är oumbärlig, men planer är värdelösa. Därför inspektera och anpassa.”
traditionella planer drivs av datum – troligen med ett slutdatum som den primära drivfaktorn. I traditionell Projektledning samlar du kraven från dina intressenter, bygger projektets omfattning och bryter ner projektet till hanterbara arbeten. Detta skapar i sin tur en Work breakdown structure (WBS). Därefter sönderdelas den lägsta nivån av WBS, dvs arbetspaket, ytterligare i aktiviteter. Aktiviteterna kopplas sedan till beroenden, och resurser uppskattas och tillämpas på aktiviteter för att skapa ett end-to-end-schema för projektet. Detta schema övervakas och kontrolleras sedan med hjälp av en schemahanteringsplan, som vanligtvis är en dotterplan för den konsoliderade projekthanteringsplanen.
men hur många gånger hände det att det du planerade och vad som faktiskt hände på marken matchade? Du vet redan svaret! Öppningscitatet betyder att planering är nödvändig, men att förvänta sig att vi kan följa planen exakt är inte en klok sak att göra. När det finns höga kannor i krav och hög osäkerhet i teknik eller plattform, går PMs vanligtvis med adaptiva (eller smidiga) livscykler.
faktum är att det fjärde värdet i Agile Manifesto säger: ”svara på förändring över att följa en plan.”Agile är förändringsdriven, och troligtvis kommer dessa förändringar att drivas av kunder. Detta leder till ett koncept som kallas Agile Release Planning.
Release planning är till skillnad från traditionell planering, där den fullständiga planen betraktas på förhand, utarbetas i detalj och endast kan ändras med formella ändringsförfrågningar. En release plan kan uppdateras många gånger baserat på feedback från tidigare iterationer.
eftersom adaptiva livscykler är inkrementella kan organisationer släppa i slutet av varje iteration. De kan också välja att släppa efter några iterationer eller till och med kontinuerligt. Detta kräver en långsiktig planering, men kan effektivt underlättas genom att använda släppplaneringstekniken, som nyligen introducerades i den 6: e upplagan av PMBOK Guide.
för blivande Projektledningspersonal (PMP) och certifierade medarbetare i Projektledning (CAPM) är Agile Release Planning ett nyckelbegrepp att veta. PMBOK Guide 6th edition har infört smidiga överväganden för varje kunskapsområde. Detta är också användbart för aspirerande Agile Certified Practitioners (ACPs).
när vi kommer in i detta mer, låt oss först se hur utgivningsplanerna utvecklas på en hög nivå.
från Vision till färdplan för att släppa planer
i agila projekt börjar arbetet med en produktvision. Visionen översätts sedan till en produktplan. Färdplanen innehåller de funktioner som ska utvecklas under en tidsperiod. Du kan också säga att en färdplan representerar produktens omfattning, som levereras i olika utgåvor. Detta leder till utgivningsplanerna och visas i figuren nedan.
färdplan och produktbacklog
en komponent i ovanstående sekvens är produktplan, och för att förstå produktens färdplan måste vi först förstå produktbacklog. I agila tillvägagångssätt är alla krav – både projektkrav och produktkrav – en del av produktbackloggen (PB). Varje artikel i produktbackloggen kallas en produktbacklog-artikel (eller PBI). Annat än funktioner (krav) kan en produktbacklog vara en ändringsförfrågan, defekt, bugg, problem eller till och med specifikt Tekniskt arbete.
som vi vet, i agila projekt utvecklas kraven kontinuerligt och det finns betydande osäkerheter/risker. Som ett resultat prioriterar vi vanligtvis PBIs. De prioriterade PBI: erna tas från toppen av eftersläpningen och levereras till kunden / kunderna. Högprioriterade poster kvar på toppen av eftersläpningen och är finkornig, medan lågprioriterade poster är på botten av eftersläpningen och grovkornig. Prioriteringen av artiklarna i PB bestämmer detaljnivån för det objektet i produktbackloggen. Detta visas i nedanstående figur.
om du använder smidiga verktyg som Microsoft Project kan du snabbt utveckla produktbackloggen. Ett exempel på produktbacklog, ritad med MS Project, visas nedan.
Här har vi en produktbacklog som visar produktbackloggen (PBIs) av ”skapa en ny användare”, ”logga in på online-handelssystemet”, ”överför ett lager” etc. Om du vill lägga till något annat backlog-objekt måste du bara klicka på ” + ” – ikonen för ”ny uppgift” – kommandofältet.
toppnivåobjekten i produktbackloggen kan skrivas i användarhistorier, som uppskattas i berättelsepunkter-ett relativt enhetsfritt mått.
nu, när du kommer till produktplanen, kan du helt enkelt säga att det är en produktbacklog med en tidslinje. En färdplan visar projektets planerade framtid (dvs. planerade och/eller föreslagna produktutgåvor) eller släppteman, som visar produktens funktioner på hög nivå. Färdplanen berättar vilka funktioner eller epics (en episk, helt enkelt, är en stor användarhistoria) kommer att levereras i varje utgåva.
utgivningsplan
produktens färdplan Driver utgivningsplanerna. En release-plan ger release-schemat-varje release är vanligtvis tre till sex månader. En utgåva innehåller många iterationer-från Iteration 0 (iteration zero) till Iteration N. Iteration 0 kan användas för projektgodkännanden, inställning av miljön för projektet, inledande översikt och designdiskussioner etc. Vissa Agila utövare använder Iteration-H (härdande iteration), som är den slutliga iterationen i slutet av utgåvan för att förbereda sig för leverans. Denna iteration kan innehålla slutliga arbetsobjekt som utbildnings-och marknadsföringsmaterial, slutliga versionsanteckningar, installationsguider, system/användarguider etc. Detta visas nedan.
som visat har släppplanen iterationer – från” iteration-0 ”till” Iteration-N. ” Du kan bestämma dig för att få en release efter några iterationer och/eller en slutlig release efter den sista iterationen.
utgivningsplanen presenterar en färdplan för hur teamet avser att uppnå projektvisionen inom ramen för projektmål och begränsningar. Det hjälper produktägaren och hela teamet att bestämma hur mycket som måste utvecklas och hur lång tid det tar innan de har en släppbar produkt. Det förmedlar förväntningar om vad som sannolikt kommer att utvecklas och inom vilken tidsram. Utgivningsplanen kan också fungera som en vägstolpe mot vilken laget kan utvecklas. Utgivningsplanen kan uppdateras i slutet av en iteration, och den återspeglar de nuvarande förväntningarna som kommer att inkluderas, så att de kan levereras i efterföljande iterationer.
Utgivningsplanering med produktbacklog
för att få en bättre förståelse för utgivningsplanering kan du visualisera utgivningsplanerna med hjälp av produktbacklog.
vi vet redan att artiklarna i produktbackloggen rankas eller beställs, baserat på deras prioritet. Toppnivåobjekten som är finkorniga kommer att vara klara för konsumtion i nästa iteration (under omedelbar nästa utgåva). Den prioriterade eftersläpningen, med funktioner och andra objekt, visas på vänster sida av figuren nedan.
 |
 |
inom MS Project måste du helt enkelt välja, dra och släppa eftersläpningsobjekt och ordna dem enligt ditt behov av att prioritera dem. Detta visas på höger sida av figuren ovan. Med tanke på tidigare exempel som visar produktbacklog inom MS Project har vi denna relativa ranking: först ”logga in på online-handelssystemet”, nästa ”skapa en ny användare”, sedan ”Köp ett lager” etc.
som visas ovan har jag valt och dragit funktionsobjektet ”logga in i online-handelssystemet” och släppte det före tidigare funktionsobjekt ”skapa en ny användare.”Det valda objektet var något grått när jag drog och släppte det.
med hjälp av eftersläpningen kan du bestämma vilken av eftersläpningsobjekten som ska levereras i nästa utgåva. Nedan ser vi att objekten i nästa utgåva (dvs. Release 1) oftast prioriteras. Objekten för Release 2 kan prioriteras också, men vi ser att objekt för Release 3 inte prioriteras eftersom de är lågprioriterade objekt.
du kan visualisera denna release planering med MS Project, också. Titta på figuren nedan. Det finns PBIs visat sig tas i olika utgåvor. Kom ihåg en release innehåller iterationer? I vårt fall, för den första utgåvan, har vi tre iterationer, och alla artiklar förväntas levereras i dessa iterationer. En iteration kallas en sprint i Scrum framework, vilket är ett populärt ramverk som används av Agile PMs. För de kommande två utgåvorna (dvs Release 2 och Release 3) har vi PBIs, men vi har ännu inte bestämt oss för iterationerna (eller sprints).
Iteration planering
om du har följt, release planen består av Iteration 0 till Iteration N och vi kan besluta att släppa i slutet av varje några iterationer eller varje iteration. Men vad händer inom en iteration? Enkelt uttryckt bekräftas utrymmet för en uppsättning funktioner inom iterationen i början av iterationen och levereras i slutet av iterationen.
de funktioner som bekräftas och tas för iterationen är uppdelade på uppgifter (eller aktiviteter) och beräknas i timmar av teammedlemmarna. Sekvensen av steg från produkt färdplan för att släppa plan till iteration planen visas i diagrammet nedan.
Sammanfattningsvis ovanstående figur kommer dessa att vara de viktigaste punkterna:
- produktens vision Driver produkt färdplan
- produkt färdplan driver release planer
- en release plan kommer att ha iterationer
- funktioner, som uppskattas i story punkter, utvecklas i en iteration
- funktioner är uppdelade i uppgifter, som beräknas i timmar
med MS Project 2016 kan du snabbt bygga en release-plan. Med tanke på vårt tidigare backlog-exempel har vi tre iterationer / sprints för den första utgåvan (dvs. Sprint 1, Sprint 2 och Sprint 3). Varje sprint har en uppsättning funktioner som ska levereras. Detta visas i nedanstående i vyn ”Sprint Planning Board”.
du kan också borra ner för att se vad som händer på iteration/sprint nivå och ta reda på vilka PBIs som arbetas på. MS Project visar detta i” nuvarande Sprint Board ” vy. Se figuren nedan.
för Sprint 1 har vi tre artiklar som ska levereras – ”logga in på online-handelssystemet”, ”skapa en ny användare” och ”köp ett lager.”Dessa passerar genom tre arbetsflödestillstånd för ”nästa upp”, ”pågår” och ” gjort.”Naturligtvis kan du lägga till, ta bort eller anpassa dessa arbetsflödestillstånd enligt ditt behov.
Release Plan Vs. Iteration Plan
om du tar provet måste du också veta skillnaderna mellan Release Plan och Iteration Plan. De noteras i tabellen nedan. Vanligtvis är iterationerna timeboxed i två till fyra veckor. Men i vissa fall, till exempel XP (en annan smidig ram), kan iterationer vara en vecka långa.
Project Management Body of Knowledge (PMBOK) Guide, 6: e upplagan, av Project Management Institute (PMI)
Jag vill vara en PMP: det enkla och enkla sättet att vara en PMP, 2: a upplagan, av Satya Narayan Dash
Jag vill vara en ACP: det enkla och enkla sättet att vara en ACP, av Satya Narayan Dash
Microsoft Project 2016 Live Lessons, av Satya Narayan Dash
Agile Practice Guide, av Project Management Institute (PMI)