Avalanche Development Process March 24, 2009 12:55 about 1 year ago
Avalanche er en super progressiv udviklingsmetode som langt overstiger alle forventninger til alle andre metoder som fx vandfaldsmodellen. Når metoden tages i brug vil man straks opleve en voldsomt forbedring i både hastighed og deltagertilfredshed. Projekter der benytter denne metode bliver færdige til tiden. Modellen tilfredsstiller egenskaber som “time to market” og “increase speed development”. Modellen garanterer at forretningen når i mål med deres ønsker før konkurrenterne.
Processen er opbygget omkring en række faser som skal gennemløbes i associativ orden. Det er vigtig at processen overholder alle metodens forpligtelser for at lykkes med størst muligt success. Der er mange positive afledte effekter af denne proces men en specielt sidegevinst er det, at de fastansatte bliver lykkelig for dig.
Projektinitiationfasen
I din rolle som projektleder er det din pligt at af sikre det størst mulige budget, dette er ofte i modsætning til direktionen. Enorme budgetter vil kræve at du er meget kreativ i din problemformulering og virksomhedens fordele skal svagt overdrives fx gennem en “Return On Investment” analyse eller en investeringsprofil der viser et stor afkast.
Avalanche metoden er strømlinet specielt til denne proces ved at springe foranalysen og analysen over ved at gå direkte til sidste del af implementeringen. Allerede på tidspunkt hægtes mange konkurrenter af.
Projektgodkendelsen bliver til en leg fordi du som udgangspunkt er et godt og givende menneske. Du kan trygt tilføje alle data fra dine tidligere projekter da det er meget sjældent at ledelsen gennemlæse alle detaljer. Den øverste ledelse vil herefter godkende dit projekt og forvente alle funktionaliteter med halvdelen af budgettet og halvdelen af den forventede tidsplan beskrevet i din projektplan. Ledelsen gør dette vel vidende at du allerede har taget højde for dette da du skrev projektoplæg.
Kravsindsamlingfasen
Veldefineret kravsspecifikationer til et edb-system er af stor vigtighed, selvom de fleste er fuldstændig ude af stand til at give et fuldstændigt sammenhængende beskrivelse af hvad de har brug for. Dette giver en glimrende mulighed for at oprette nogle forretningsbrugere som kan tage skylden for evt. projekt fiasko.
Lad alle forretningsbrugere definere særlige udtryk og funktioner der kræves for at forretningen kan eksistere. Beskriv i detaljer og tving en eller flere bruger til at underskrive dokumentet. I det uundgåelige tilfælde, at den deraf følgende software ikke opfylder forventningerne vil det være muligt at skyde skylden på brugerne for at undlade at identificere alle krav og krævende ændringer.
Detaljeretplanlægningsfasen
For at lykkes kræver metoden at alting brydes op i det der kunne ligne logiske opgaver. Gør hver opgave omtrent samme længde med en vis tilfældig variation så man kan se at en analyse er blevet udført. Derefter øges eller mindskes opgaverne indtil alle opgaver passer med det skøn der på forhånd er fastsat af øverste ledelse.
Det er essentielt at man ikke involvere udviklere på dette tidpunkt idet de vil forsøge at bruge tidligere erfaring til at afgøre hvor lang tid en opgave kan tage. De vil hurtige tilføje flere opgaver som fx unit test, kode design og tidlig aftesting af sikkerhedsting. Alle disse problemet er blot distraktioner der afholder dem i at udføre deres primære opgaver.
I denne del af planen er diagrammer og excel ark nyttige og kan giver indtryk af et professionelt projektteam. Lad aldrig udviklerne benytte MS projekt eller andre planlægningsværktøjer da det vil betyde at de kan åbne og redigere planen. Som en ekstra sikkerhed kan du beholde projektplanen på din private laptop. På den måde kan du redigere de vigtige dokumenter under offentlig transport.
Udviklingsfasen
Softwareudviklere motiveres udelukkende af en fast deadline. Allerede tidligt i projektet skal der meldes ud at virksomheden står og falder med dette produkt så alle kan forstå vigtigheden af din arbejdesindsats. Alle deltagere skal tilslutte sig til en 18 timers arbejdsdag hele ugen undtagen søndag. Vær meget varsom når du berører folks arbejdstid, husk at din stemme skal vibrerer og du må gerne se nervøs ud. Denne proces skal gentages ca. hver 6 uge for at holde teammoralen i top.
Udviklingsprocessen er en hybrid mellem det bedste af Waterfall og Extreme Programming. Udviklere får at vide hvilke opgaver der skal udføres og de arbejder i en uges blokke baseret på projektplan. Projektdeltagerne arbejder i “sprints” for at de skal føle at de er på forkant i et moderne team. Sørg for at understrege at kvalitet er din højeste prioritet. Efter tidsplanen. Og naturligvis budgettet. Men før deres personlige sundhed.
Udviklere er nørder. Det er denne egenskab der gør at de kan betjene en computere der ellers ville blive doneret til den lokale ungdomsskole. Moderne hurtige computere med store skærme er reserveret til den øverste ledelse, revisorer og enkelte projektledere med særlig status. Udviklere har det bedre når de udfordres i deres computermiljø. Med jævne mellemrum vil en eller flere udviklere fremsætte anmodning om nyt hardware eller software. Det er vigtigt at ikke efterkomme det punkt da det udelukkende er et trick for at forbedre deres status blandt de øvrige udviklere. Husk at penge brugt på udstyr er penge mindre til den firmabetalte IT-konferencen i alperne.
Man kan dog også styre budgettet på andre måder. For eksempel kan man gennemføre pair programmering. Effekten af denne proces er at man kan få plads til dobbelt så mange programmører og samtidig spare på IT-udstyr. Denne tilgang er nok den bedste for at forhindre unødig adgang til internettet.
Endelig kan der spares penge på lokaler, klimaanlæg og belysning. Udviklere trives godt i varme, fugtige, ildelugtende lokaler. En kaffemaskine kan være en god langsigtet investering idet store mængder koffein kan give dine udviklere søvnbesvær hvilket ofte hjælper på produktiviteten.
Afprøvningsfasen
Testfasen er den imaginære tid mellem at få råd til en softwarekatastrofe og en fullboat demo for brugerne, i andre udvikling metoder kaldet Alpha test. Enhver ansvarlig projektleder vil naturligvis tilføje to eller tre uger med prøvning i henhold til afslutningen af projektet, for at vise rettidig omhu.
I mere end et halv år har dine udviklere givet dig daglige opdateringer og i mellemtiden har du overført forventninger til den øverste ledelse. Elementer som sygdom, urimelige krav, nye funktioner, dårlige platforme, og en drift som ikke tager telefonen har præet hverdagen. Det dig som leder der er offer.
Denne proces er meget vigtig i projektforløbet. Det er din opgave at bearbejdes den øverste projektledelse til en tilstand af depression i en sådan grad at de vil blive glade for selv en lille del af det færdige produkt.
Slutfasen
Dette er den vigtigste fase i metoden. Laver du en fejl i denne fase kan det have katastrofale følger som afspejle sig i flere år frem.
Trods de groft urealistisk forventninger til projektet kan du ikke åbent bebrejde brugergrupperne for fiasko. Det kunne fremme den øverste ledelse til at tænke over hvem der har nedsat deres forventninger til projektet.
I denne fase er det vigtigt at huske at kun ca. 50% af al software når frem til kunderne. Hvis du bare kan skaffe 5% af alle krav til et produktionsmiljø er du i top 50% af alle software projekter.
Avalanche processen låner begrebet “release early” fra Extreme Programming. Processen undviger dog fra Extreme Programming er i “release often” fordi der aldrig kommer noget godt ud af aflevere hele tiden og det bliver umuligt af finde ud af hvilken softwareversioner der testes på hvilket kun forvirrer hele processen.
Projektet vil naturligvis blive oversvømmet af defekt rapporter; deraf navnet. På denne måde vil du kunne udnytte dine udviklere mere effektivt idet de både kan nyudvikle og fejlfinde på samme tid. Det er derfor vigtigt at du går videre til “mere udfordrende” projekter der vil kunne nyde godt af dit projekts succes.
Hvis du følger denne proces til bunds vil du være i stand til at levere dine projekter hurtigt og effektivt samt at vedligeholde din ry for at være en vellykket teamplayer. Det vil også bedrage med regelmæssig lønstigninger, set i forhold til de mennesker som skal vedligeholde og udbygge dine projekter på lang sigt.
Et sidste punkt er at understrege at alle processer og metoder virker bedst for store virksomheder men at man bør tænke på at alle processer skal være proprietærer så de aldrig kan genkendes udenfor deres rette omgivelser. Det er vigtigt at man ikke umiddelbart kan blande udviklere mellem virksomheder der arbejder med samme forretningsområde.
I virksomheder med særlige forretningsområder er det endnu vigtigere at omskrive eller indkapsle alle værktøjer og processer. Dette sikre sikkerhed over alle grænser. Derfor er denne processbeskrivelse omskrevet en smule fra den ellers udmærkede original af Peter Harrisson
By Frank Vilhelmsen - 2 tags: agile scrum - 2 comments on Avalanche Development Process - Add comment
Carsten Gehling March 25, 2009 00:39 about 1 year ago
To ord:
STORT GRIN :-)
Jeg må indrømme, at jeg skulle ned i 3-4 afsnit, før jeg var sikker på, at det var gas. Inden da, troede jeg først, at skribenten levede af bullshit-bingo… :-)
Jeppe Cramon March 25, 2009 12:07 about 1 year ago
Det er desværre svært at holde en god udviklings process hemmelig, for det virker som om samtlige større danske software virksomheder har kopieret denne udmærkede og veludtænkte process. Jeg ville ønske jeg har patenteret processen, damn jeg var blevet rig på licens salget :-P