Læringsplan 6

Så har jeg læst 3. Del i bogen, omhandlende aftaler. Her har der været en del ting, jeg har bidt mærke i og kan relaterer til, både på tidligere semestre, men også i det arbejde jeg har lavet hos Pentia. Man er som projektleder aftaleskaber og bestyrer. Det betyder blandt andet, ansvar for kravspecifikationen, der fortæller hvad projektet skal levere til omverdenen. Ligeledes skal man udfærdige en projektplan, der viser hvad omverden stiller til rådighed af ressourcer, samt en forventning om projektets forløb.

Krav:
Det var interessant læsning, da vi tidligere på uddannelsen har arbejdet med krav, både indhentningen men også FURPS/MOSCOW, for at give os noget at arbejde ud fra. Men hvad er krav og hvad bruger vi dem til? 

Bogens forfatter definere at krav er; ” Eksternt observerbare egenskaber ved et projekts resultat”. Et eksempel er ved udviklingen af en bil. Her kan et krav være et bestemt benzinforbrug, men ikke antal ventiler i motoren (det er en teknisk løsning). Krav er en slags detaljering af projektets mål og når kravene er opfyldt er projektet færdigt. Vi bruger krav til flere ting, det er f.eks. at undgå konflikter mellem brugere og udviklere. Projektets resultat, måles op i mod de krav der stilles (kvalitetssikring/styring). Når vi finder krav er det vigtigt at, afdække behov og muligheder, forhandle med alle parter og beskrive dem herefter. Krav skal være målbare og kunne reguleres ved fejl eller ændringer, til vilkår i projekt.

Den gode kravspecifikation, er en omstændig proces og skal være:

• Struktureret – Aftaler og forhold, skal kunne ses og findes
• Udtømmende – Hvad skal med og ikke med?
• Detaljeret – De skal ikke kunne misforstås og der må gerne være sporbarhed til, hvorfor et krav eksistere.
• Stilfuld – Krav er fagprosa, så overblik og forståelighed skal fremmes.

Plan:
En projektplan fortæller “hvem gør hvad, hvordan og hvornår”. Da et projekt er en midlertidig organisation, kan planen være med til at sikre sammenhæng og et gennemført forløb. Planen er en uddybelse af projektmodellen og skal være kommunikerbar, målbar og reviderbar. Derfor bør man også bygge planen op omkring faselinjer og faser. De imødegår bedre ændringer, kontra den traditionelle netværksplan, med mange aktiviteter og afhængigheder (Perth eks.).

Der findes 2 slags planer:

• Ekstern projektplan – Kigger på hele projektet, overordnede faser, strategi mv.
• Intern projektplan – Dykker ned i faser, detaljere i timer og sprints, laver Gannh/Perth.

Den gode plan er velstruktureret, da det skal være nemt at finde aftaler. Planen kan sættes op på mange måder, men det er vigtigt at kunne få et overblik over projektets helhed og eksistensberettigelse (alla businesscase).  Derudover skal faser og faselinjer (faseskift) kunne ses som en slags SCRUM sprint-planning, samt diverse bilag som kravspecifikation og andet. Faselinjer er netop vigtige, da de gør projektet synlig, når et skift mellem faser (begivenhed eller resultat) markeres. De er også med til at gøre det sværere, at slække på krav, da et delresultat ofte vurderes efter specifikke kriterier og procedure. En fase ligger mellem skiftende og er en afgrænset periode i projektets forløb, med bestemte aktiviteter (design etc.).

Planlægning af planen er svær, den foregår i den indledende fase og skal være både realiserbar og retfærdig. En god indgangsvinkel er, først at få styr på faselinjer, bemand herefter centrale aktiviteter, i det forskellige faser. Planlægning revideres ved hvert faseskift.

Estimering:
Estimering er en forudsigelse af, forbrug af person ressourcer og et nøgletal i et projekt. Denne ressource er den absolut vigtigste i et udviklingsprojekt, som har indflydelse på både omkostninger og varighed. Det gode estimat er ikke nødvendigvis “rigtigt”, da verden ikke er kendt på forhånd. Det gode estimat er “rimeligt” og bør give en realistisk plan. Generelt skal de:

• Bygge på en sund faglig vurdering, som erfaring eller erfaringstal (branche normer)
• Der skal være synlig argumentation bag, så andre forstå dem.
• De skal være lette at revidere, uden planen vælter. (Brug regneark, til løbende opsamling)
• Invitere til erfaringsopsamling. Det styrker vores næste projekt, så lav skabeloner og struktur hertil.

Estimering er behæftet med stor usikkerhed, det bør omverdenen forstå og acceptere, da de samtidig har ret til et tidlig estimat. Dog præciseret de undervejs i projektet, når risici reduceres. Estimering er meget forskellig i projekter af forskellig karakter, i byggeprojekter er projekteringen oftest færdig inden udbud og usikkerhederne er mindre. Ved IT udviklingsprojekter estimeres der både før, analyse og design og er i sin natur langt mere usikre. Hvorfor så overhovedet estimere med den usikkerhed? Dette er for at sikre projektets sundhed, aftaler og ressourcer skal hænge sammen.

Når man skal lave estimering, kan man læne sig op af nogle kerne- og hjælpe teknikker. Der to kerneteknikker, den ene kaldes analogi. Det er den bedste og mest valide og går i sin enkelthed ud på, at sammenligne med lignende projekter. Den anden er faktor-vurdering, her bruger man af branchen nogle velkendte formler (bygget på normtal), der kan udregne estimater for diverse aktiviteter. Det kan være antal linjer med kode, udviklernes erfaring mv. De ene af de to hjælpe teknikker er usikkerhedsoverslag, som kigger på forskelle mellem tidligere projekters estimering og faktuelle forbrug. Teknikken inddrager også vurderinger fra fagpersoner og sammenligner dem på tværs. Den sidste hjælpeteknik er nedbrydning og sammensmeltning, som forsøger at nedbryde usikkerhed ved at nedbryde projektdele. Det vigtigste er at blande og krydstjekke teknikker.

Det sidste som er værd at tage med er, at estimering indgår i forhandling. En projektleder fungerer som købmand og skal i den grad undgå “dårlige handler”. Både under- og overordnede forsøger at få reserver, så man skal finde et rimeligt niveau. Hvis nogen så påtager sig en usikkerhed (rekvirent eller udvikler), skal denne også have en præmie i form af reserver. Et projekt kan opdeles, således rekvirenten kun forpligtiger sig, en fase ad gangen. Der kan også være en politisk vinkel. man kan gå efter det størst mulige budget, der er det bedste for projektlederen. Eller det mindst acceptable budget (hvis man bare vil have opgaven). En projektleder kan kommunikere estimater forskelligt, dermed kan ressourcer skjules for udviklere eller rekvirent (hvis projektleder vil have reserver). 

Evaluering

Denne del af bogen har helt klart været udbytterig. Jeg har fået en dybere indsigt i krav, således jeg ikke bare kan lave dem og anvende dem som udvikler, men jeg forstår deres eksistens berettigelse og hvordan de kan bruges på tværs i projektet. Afsnittet med planer har givet mig forståelse for faser og faselinjer, jeg brugt i forskellige systemudviklingsmetoder, men ikke tillagt den nødvendige værdi. jeg vil helt klart gøre mere ud af markeringen af en “milestone” i vores projekt. Dette vil både kunne give teamet et boost og forøge produktiviteten, men også flytte fokus og få afslutte opgaver og i gang sat nye, da jeg mærker at folk har en tendens til at arbejde i cirkler.

Afsnittet om estimering har dog været det vigtigste. Teorien dækker bredt og giver god forståelse for både vigtigheden af, men også udfordringen med at lave estimater. Jeg kan drage direkte paralleller mellem læsestoffet og de øvelser og artefakter jeg af Pentia bliver bedt om at lave. Blandt andet 3-punkts estimering, inddragelse af udviklere til estimering af usecases mv. Jeg har også arbejdet med at kigge på tidligere projekter, samt normtal for appudvikling. Jeg har sågar afprøvet den politiske del, da jeg opererer med forskellige estimater eksternt og internt i projektet. 

• https://www.saxo.com/dk/strategisk-projektledelse_andreas-munk-madsen_hardback_9788791649080