Noter: Projekt styring

Noter fra undervisning og forberedelse til Projekt styring. Noter taget på MMD. Undervisning afholdt af Karen Malene.

Forberedelsesmaterialet

Til forberedelsens skulle der læses:

  • The Scrum Guide – https://www.scrumguides.org/scrum-guide.html.
  • Web Project Management af Ashley Friedlin – s. xiii-xvii, 3-11, 31, 35-47.
  • Digital Media Management af Loise Harder Fischer & Marie Oosterbaan – s. 30-40.

Projektstyring

Projekttrekanten

Projekttrekanten består af 3 emnegrupper, som består af henholdsvis:

  • Tid & dealines.
  • Mål, indhold & scope.
  • Ressourcer, økonomi & omkostninger.

Alle grupper er afhængige af hinanden. Påvirkes en af grupperne påvirkes de andre. Tilsammen definerer de et projekts kvalitet.

Teamarbejde

I et godt teamarbejde er der:

  • God kommunikation.
  • Forståelse for individers kompetencer.
  • Forventningsafstemninger.
  • Komplimentære eller mindst kompatible evne sæt.
  • Respekt eller tillid.
  • Tilsvarende evne-niveauer i tildelte arbejdsopgaver.
  • Godt eller rimeligt socialt forhold i gruppen.
  • Projektstyring.
  • En eller få har overblik.

Konflikter

Konflikttrappen

Et værktøj til at forstå konflikter. Værktøjet bruges oftest til at løse konflikter.

Konflikttrappen.
At gøre det bedre:
7. Flyt dig fra konflikten,
6. Kontakt ledelsen og få hjælp til at løse konflikten,
5. Kontakt DJ og få professionel konfliktmægling,
4. Indrag en tillidsvagt og få hjælp til dialog,
3. Tag kontakt og forsøg at få talt sammen,
2. Hvad mon hans/hendes behov er?
1. Hvad er vi egentlig uenige om?
At gøre det værre:
1. Vi er uenige - vi vil ikke det samme,
2. Personificering - vi giver hinanden skylden,
3. Inddragelse af andre - kolleger bliver parter i konflikten
4. Samtale opgives - vi taler om - ikke med hinanden,
5. Fjendebilleder - vi synes begge den anden er et dårligt menneske,
6. Åben fjendtlighed - vi skader hinanden,
7. Polarisering - det er dig eller den anden.
https://journalistforbundet.dk/konflikttrappen

På trappen kan man aflæse hvordan konflikter kan blive værre, og hvad der kan gøres for at gøre det bedre. Graden for konflikt er visualiseret med trappetrin og farver.

Projektleder/Projektmanager

Kendetegn for en god projektleder:

  • Har overblik.
  • Er objektiv/demokratisk.
  • Motiverer.
  • Sætter realistiske mål.
  • Agere anerkende.
  • Kan facilitere.
  • Er ikke konfliktsky.
  • Er tålmodig.
  • Har erfaring/kendskab eller mulighed for at forstå projektets rammer.
  • Kan udvise empati.

Udviklingsmetoder

En udviklingsmetode kan defineres som en sammensætning af retningslinjer og anbefalinger for arbejdet til udførelsen af digitale produkter.

Overordnet set kan man opdele udviklingsmetoderne som værende fixed eller agil.

De mest populære metoder igennem tiden (pradigmerne) er følgende:

  • Fixed:
    • Vandfaldsmetoden.
    • Prototyping.
    • Udforskende programmering/udvikling.
  • Agile metoder:
    • Scrum.
    • Design thinking (dækkes ikke i dette materiale).

Vandfaldsmodellen

En lineær og fastopdelt udviklingsproces. Der er fokus på løbende godkendelser og dokumentation. Der forudsættes et specifikt udgangspunkt i metoden.

I vandfaldsmodellen er der lille risikovillighed. Der er faste faser der er dokumenteret og godkendt.

I modellen anvendes der flere faser/trin. Hver fase bør være nemme at differentiere imellem. Resultaterne fra fase er med til at definere krav. Kravene kan være til selve produktet, designet eller tests.

Faserne består af analyse, design, programmering og vedligeholdelse.

I analysefasen fastsættes krav og definitioner. I designfasen defineres system designet. I programmeringsfasen udvikles der implementeringer og modultester, og derefter integration og systemtest. I vedligeholdelsesfasen sørges der for drift og vedligeholdelse.

Godkendelsesprocessen

Faserne dokumenteres og godkendes af udviklere og kunde. Efter godkendelse fortsættes til næste fase.

Godkendelsesprocessen kendes også som sign-off.

Prototyping

Prototyping består af iterative (gentagende) udvikling. Der udarbejdes skitser forberedes og afprøves. Formålet er at kunne få brugere og kunder til at opstille krav. Kravene er med til at danne grundlaget for en udviklingsproces.

Metoden er god til at finde præcise krav, men forudsætter at man ikke kender meget til slutproduktet. Det er en god idé at skifte en metode efter at prototyping faserne er overstået.

I prototyping er der moderat risikovillighed. Man starter med en hvis mængde usikkerhed. I enhver efterfølgende iration bliver det mere sikkert.

I prototyping arbejder man efter faser. Design, programmering, analyse og design analyse.

I designfasen opstilles overordnede specifikationer. I programmeringsfasen bygges prototypen. I analysefasen evalueres prototypen. Hvis evalueringen fejler, går man tilbage til programmeringsfasen. Hvis evalueringen lykkedes, specificeret produktet. I design analysefasen designes og implementeres produkter. Derefter valideres produktet. Fasen kan herefter gentages.

Udforskende udvikling

Udforskende udvikling består af at afprøve løsninger og dele af løsninger på brugere indtil der gives accept.

I metoden udvikles der fra starten et udkast. Brugeren afprøver det og giver feedback. Denne feedback bruges til videreudvikling, hvorefter brugeren igen prøver det. Denne fremgang fortsætter indtil brugeren ikke længere stiller nye krav.

Det kan være fordelagtigt at anvende metoden når slutresultatet er diffus og usikker.

Der er stor risikovillighed, da man skal præcisere hvad man vil meget nøjagtigt.

I Udforskende udvikling arbejder man efter faser. Analyse & Design, Programmering & Design, og Analyse & Vedligeholdelse.

I analyse- og designfasen udvikles overordnede specifikationer. I Programmerings- og designfasen bygges en prototype. I Analyse- og Vedligeholdelsesfasen afprøves prototypen. Efter faserne kan brugeren give accept. Gives accept ikke genstarter faserne sig fra Programmering og Design. Gives accept afleveres produktet.

Agile metoder

De agile metoder er kendetegnet ved at være hurtige og effektiv håndtering af skiftende forudsætninger.

Der anvendes korte iterationer. Iterationerne indeholder alle udviklingsfaser. Udviklingsfaserne består af planlægning, kravspecifikation, design, programmering, test og accepttest af fungerende produkt. Iterationerne varer normalt 1-4 uger.

Der arbejde i små teams bestående af 5-9 personer. En person er en repræsentant udvalgt af kunden.

Dokumentation er normalt ikke et stort fokus. Dokumentation prioriteres på samme niveau som produktet. Kunden eller repræsentanten kan derfor vælge i hvilken grad fremdrift og dokumentation skal varetages.

Der er en lav mængde risikovillighed. Kunden definerer arbejdet. og deadlines sættes på baggrund af opgaver.

SCRUM

Scrum er et framework for udvikling, leverancer og vedligeholdelse af komplekse produkter. Scrum er praktisk til iterative processer der ofte ændrer sig og er komplekse.

Scrum er let forståeligt, nemt at forstå og svær at mestre.

Scrum kan bruges til bl.a.

  • Research og identifikation af markeder, teknologi og produkt egenskaber.
  • Udvikling af produkter og produktforbedringer.
  • Løbende udgivelser.
  • Udvikling og vedligeholdelse af Cloud og andre operative miljøer.
  • Vedligeholdelse og fornyelse af produkter.

Scrum består af Scrum teams (små teams) og deres toller, events, artefakter og regler.

Scrum Teams

Scrum teams består af en Product owner, udviklingsteam og Scrum Master. Enkelte medlemmer er fleksible og tilpasningsvenlige. Scrum teams organiserer sig selv og er tværfaglige.

Product ownerens ansvar er at makisimere resultaterne fra udviklingsholdet. Kun Product owner er ansvarlig for Product Backlog. De kan dog uddelegere skrivearbejdet til udviklingsteamet. Deres ansvar ikluderr at formidle elementerne deri. Organisere indholdet for bedst muligt at kunne opnå mål og mission. Optimering værdi fra udviklingsteamets arbejdsindsats. Sørge for at den er synlig og transparent for alle. Sørge for at den viser hvad der skal ske som det næste. Sørge for at udviklingsteamet forstår emnerne.

Udviklingsteamet består ideelt set af professionelle. I slutningen af ethvert sprint leverer udviklingteamet et brugbart produkt. Der er ingen roller. Teamet styrer sig selv. Medlemmer er multifunktionelle. Teams bør være små med 3-9 medlemmer.

Scrum master er ansvarlig for at formidle Scrum teori, praksis, regler og værdier. Scrum master er ansvarlig for at hjælpe eksterne med hvem fra teamet der kan være behjælpelig for dem. Scrum master servicerer Product owner ved at sikre mål, sætte scope, finde teknikker til at håndtere Product backlog emner, forså planlægning for produktet, sikre at Product owner effektivt kan håndtere Product backlog, forstå og praktisere agilt, facilitere Scrum. Scrum Master servicerer udviklingsteamet ved at undervise i hvordan man er selvstændig og tværfaglig, hjælpe til med udvikling af høj kvalitet, fjerne hindringer, facilitering af events, undervise udviklingsteamet i organisatoriske miljøer hvor Scrum ikke nødvendigvis er fuldstændig implementeret. Scrum Master servicerer Organisationen ved at lede og undervise organisationen om brugen af Scrum, planlægge Scrum implementationer i organisationen, hjælpe medarbejdere og interessenter forstå Scrum, skabe forandring og samarbejde med andre Scrum Mastere.

Scrum Events

Alle events i Scrum er tidsbaseret. Fastsatte varigheder bliver ikke ændret.

Sprint er udtrykket for leverance af funktionelt produkt i et inkrement. Når et sprint er afstluttet starter et nyt. Imens et sprint er i gang ændres målet, målsætninger og scopet sig ikke. Imellem sprints kan scope blive uddybet eller genforhandlet. Sprint varer ikke mere end 1 måned. Hvert sprint har en målsætning. Kun Product owner kan aflyse sprint.

Scrum møder er 15 minutter lange møder imellem udviklingsteamet. Under sprint afholdes Scrum møder dagligt. Til disse møder planlægges de næste 24 timers arbejde. Til møderne briefer medlemmer hinanden med hvad de har gjort for at nå mål i sprint, hvad de vil gøre i dag og om der er noget der forhindrer eller forventes at forhindre dem snart.

Sprint review er en gennemgang af hvad der blevet lavet efter et sprint med Scrum teamet og interessenter og planlægning til næste sprint.

Sprint Retrospective er en gennemgang af sprintets krav, typisk efter sprint review, af Scrum teamet.

Scrum artefakter

Scrum artefakter er med til at skabe transparens.

Product backlog er en liste af alt der skal bruges i produktet. Det den eneste resource for krav til ændringer. Product backlog ejes af Product owner. Det er normalt at alle eller mange i teamet arbejder deri.

Sprint Backlog er en samling af product backlogs og en plan for leverancer og opnå målsætninger. Sprint backlog kan med fordel oprettes på trello.

Web project management

Web project manager

I store projekter kan det være svært for udviklere at få et overblik. Derfor kan det være nødvendigt at have en dedikeret projektleder til denne opgave. En sådan projektleder bliver her refereret til som Web project manager.

Projektledelsesprincipper

Omkostninger (Cost) bestående af penge, medarbejder tid og ressourcer brugt på projektet.

Tid (Time) i form af den totale tid brugt på projektet.

Kvalitet (Qualitity) i form af udfyldte succeskriterier. Succeskriterierne kan være bl.a. være defineret som at opnå fastsatte mål eller specifikationer, kommerciel succes, innovation eller en kombination af de nævnte.

Hvis en omkostninger, tid eller kvalitet bliver påvirket, så påvirker det også de andre.

Udvikling af flere løsninger | Parallel development on web projects

For at følge med kravene for webudvikling er det ikke unormalt for en Web project manager at styre flere projekter på en gang.

For at starte på en ny opgave skal en gammel opgave være færdig. Det er projektlederens ansvar at kunne nedbryde opgaver således at man kan arbejde parallelt på flere opgaver.

Egenskaber for en Web project manager

Det er vigtigt at en Web project manager er god til at facilitere processer. De skal kunne forstå udviklere og kunder.

Projektlederen vil komme til at arbejde meget med designere, programmører og klienter. Hver af dem arbejder generelt set i forskellige fagtærmer. En god projektleder vil kunne forstå sproget de bruger, og formidle budskaberne derfra til de øvrige partier.

Roller for en Web project manager

En Web project manager skal have forståelse for industrien og virksomhedens. De skal forstå discipliner i virksomheden og evner. Yderligere skal de også vide hvordan de forbinder faktorerne til web og hvordan web kan bidrage til projektet.

En Web project manager skal kunne kommunikere. De skal kunne agere som bindeled mellem ledelse, eksterne interessenter, specialister og kontraktholdere. De skal kunne briefe status for projektet til klienter. I statusopdateringer skal de kunne formidle forulemninger, løsninger til disse, andre faktorer i projektet og risikovurderinger. De skal kunne styre og sætte deadlines og milepæle for udviklingen og klienten. De skal kunne anmelde projektet og vurdere resultater, og beskrive hvad der kan gøres bedre.

En Web project manager skal kunne dokumentere. De skal kunne udvikle kravspecifikationer, der tager hensyn til klient og teamet. De skal kunne give input for at støtte fremgang til dokumentation og arbejde. De skal kunne dokumentere projektets fremgang, herunder samtaler, rapporter alle dokumentversioner og sikre sign-offs. De skal arkivere projektet, dets dokumentation, dets aktiver, indhold og kunne returnere materialet til klient og øvrige interessenter.

En Web project manager skal kunne yde kvalitetskontrol. De skal kunne sikre at produktet bliver testet og accepteret før udgivelse. De skal sikre at løsningen overholder specifikationerne der er blevet aftalt.

En Web project manager skal bidrage til udvikling. De skal sikre et miljø, hvori de selv og deres team medlemmer kan udvikle deres evner. De skal søge efter nye muligheder, forbedre metoder og styre teamets viden og ekspertise.

Metoder for web projekter

Fordele ved at anvende metoder:

  • Man har en checkliste.
  • Man kan fokusere som team.
  • Man kan redegøre for udgifter.
  • Ansvar kan fordeles.
  • Den kan give komparative fordele.
  • Den gør facilitering nemmere.
  • Den er med til at vedligeholde professionelle standarder
  • Kontrollering er nemmere.
  • Den er med til at gøre det nemmere for nye teammedlemmer at komme ind i processen.
  • Den bidrager til at reducere spildtid.
  • Den giver et bedre grundlag for planlægning, beregning af ressourcer og budgettering.
  • Den kan facilitere projektets kommunikation og aflevering/overleveringer.

Metoder

Ethvert projekt bør have sin egen metode. Metoder bør tilpases projekter og ikke omvendt.

The Project Road Map

Et projekt består af 8 stadier.

  1. Produkt forståelse
  2. Definition af løsning
  3. Projekt specifikation
  4. Indhold
  5. Design og konstruktion
  6. Test, lancering og handover
  7. Vedligeholdelse
  8. Review og evaluering

Der er 4 overordnede faser. Stadie 1-3 tilhører preproduktionsfasen, også kendt som Discovery. Stadie 4-6 tilhører produktionsfasen. Stadie 7 tilhører vedligeholdelsesfasen. Stadie 8 tilhører evalueringsfasen.

Fordele ved planlægning:

  • Planlægning øger produktionshastigheden.
  • Planlægning øger kvalitet.
  • Planlægning sparer penge.
  • Planlægning bidrager til langsigtede gevinster.