Hva er så flott med smidig? En grunning på smidig metodikk
Agile Definer som Agile Management Systems som har eksistert en stund, men som har fått valuta i nyere tid. Faktisk har Agile Management konsekvent funksjoner på topp prosjektledelse-trender for nesten hver eneste IT-prosjektledelsesblogg hvert år.
Bruken av Agile i IT-baserte prosjekter er ubestridt, da den finner bruk ikke bare i IT-programvareprosjekter, men også i produktutvikling og innovasjon.
Så hva er så flott med Agile? Be ansatte som har flyttet over fra et tradisjonelt system til Agile, og de kan beklage de stadige møtene og "møter om møter."
Det viser seg at det er mye mer med Agile enn bare møter og tilbakemeldinger. Den fokuserer på å styrke team og fjerne sekvensielle måter for prosjektutvikling, slik at det er mer fleksibilitet og innovasjon. Selv om det betyr møter og leveranser oftere enn med tradisjonelle systemer, betyr det også at det er mindre sjanse for iterasjoner og endringer senere videre i prosjektsyklusen.
Det blir utpekt som kur for alle vanlige problemer som plager IT-relaterte prosjekter. Hva er det egentlig, og hvordan er det bedre enn tradisjonelle systemer?
Need for Agile Methodology - Management practices
Alle som har jobbet med smidig metodikk i programvareutviklingsprosjekter vil ha en ide om noen av de vanlige problemene som dukker opp i løpet av et prosjekt: endring i omfang, frister som virker umulige å oppfylle og overarbeidede ressurser.
Tradisjonelle smidige metoder i prosjektledelse hadde mange ulemper som de ikke klarte å takle det stadig skiftende virksomhetsmiljøet, spesielt i programvareutvikling, og situasjonene ovenfor var dessverre altfor vanlige. Dette er ikke å si at tradisjonelle metoder ikke er anvendelige noe sted. De er fremdeles det beste alternativet for prosjekter der ideen er fullstendig fra starten.
Agile Management-praksis ble timens behov fordi de tilfredsstilte følgende behov til et produkt som ble lansert i et dynamisk miljø:
- Behov for hastighet for å nå produktet til markedet
- Behov for fleksibilitet for å imøtekomme flere endringer i spesifikasjoner
- Mangler i scenariet "arbeidsdeling"
- Kundens dilemma
- Behov for reduksjon i kostnader
Behov for hastighet for å nå produktet til markedet:
Vi lever i et fartsfylt miljø der fleksibilitet og hastighet er nøkkelen til suksess.
Teknologi er en av sektorene som er raskt i endring. Det er en nyere ide, produkt eller innovasjon hvert minutt. I dette bakgrunnen mislykkes tradisjonell prosjektledelse. Et sekvensielt prosjekt er nødvendigvis avhengig av at de smidige metodologitrinnene er fullført tilfredsstillende i orden. Tidslinjer i tradisjonelt administrerte prosjekter er alltid et stridsben.
Organisasjoner og lag som ikke er dynamiske, vil miste løpet til de som morfiserer seg for å passe til det skiftende miljøet.
Behov for fleksibilitet for å imøtekomme flere endringer i spesifikasjoner:
Kundens forventninger og krav endres ofte i løpet av produktutviklingen. Før Agile Management Systems var mainstream, mislyktes prosjekter i IT ofte fordi det tradisjonelle prosjektstyringssystemet ble bygget for å "pløye på". Hvis det var noen endringer, følte klienter ofte klemme til lommebøkene eller tidslinjene. Den tradisjonelle prosjektstyringsmodellen, tilpasset fra andre bransjer, fungerte rett og slett ikke for en dynamisk industri som IT.
Arbeidsdeling:
I den tradisjonelle modellen er det distinkte faser, starter med analyse av systemkrav og fører frem til produktutgivelse og vedlikehold. Dette resulterer i arbeidsdeling og merking av medlemmene som 'designere', 'programmerere' eller 'testere'. Men i virkeligheten er dagens ressurser ekstremt tverrfunksjonell, og en så tydelig rolleforskjell er ikke mulig i de fleste prosjekter.
Kundens dilemma:
I flyktige prosjekter er kunder ofte ikke helt sikre på hva sluttproduktet deres, med alle spesifikasjonene, må være. Funksjonaliteter og krav endres ofte etter hvert som deler av arbeidet blir gjort. Tradisjonelle modeller som Waterfall-modellen understreker klarhet med hensyn til sluttproduktet, og avvik i planer legger et stort stress på systemet. Dette bringer oss til den siste faktoren som førte til utviklingen av smidige systemer.
Behov for reduksjon i kostnader:
Tradisjonelt ble endringer i krav når som helst etter at prosjektet startet, frarådet. Snarere, kostnadene for en tilleggskomponent var høye, noen ganger uoverkommelig. Det var derfor viktig å inkludere alle mulige scenarier i selve planleggingsfasen. Dette medførte at alle scenarier ble vurdert og foreslått en løsning. Men siden det er nesten umulig å vite med sikkerhet hvilken del av produktet brukeren vil foretrekke, utviklet team ofte “oppblåst versjoner” av et produkt. Dette inneholdt alle mulige scenarier, hvor en typisk bruker ikke ville bruke mer enn 20%. Dette resulterte i unødvendige kostnader og utvikling.
Unødvendig å si betydde dette at alle prosjekter var globale i planleggingen.
Og da et helt nytt uplanlagt scenario dukket opp, var det uansett ekstra kostnader til tross for all planlegging.
En gruppe mennesker møttes i februar 2001 for å diskutere nøyaktig dette: behovet for en fleksibel og smidig modell for programvareutvikling som hjalp til med å utvikle produkter som faktisk fungerte for klienten og utvikleren. Det som resulterte var "Agile Manifesto" som var fordelene med programvareutvikling for smidig metodikk, dvs. et sett med fire prinsipper som er like enkle som de er beskrivende. Tolv “smidige prinsipper” som forklarte hvordan agile systemer faktisk ville fungere i et prosjektmiljø, ble også utviklet.
Gjennom dette arbeidet har vi kommet til verdi:
- Enkeltpersoner og interaksjoner over prosesser og verktøy
- Arbeidsprogramvare over omfattende dokumentasjon
- Kundesamarbeid over kontraktsforhandlinger
- Reagerer på endring etter å ha fulgt en plan
Det vil si at mens det er verdi i varene til høyre, verdsetter vi varene til venstre mer.
De 12 smidige prinsippene
De 12 Agile-prinsippene er et sett med veiledende konsepter bak Agile Manifesto som støtter prosjektgrupper i implementering av Agile Projects. De er:
- Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlig og kontinuerlig levering av verdifull programvare.
- Innbydende endrede krav velkommen, også i sen utvikling. Agile metodikk behandler selesendring for kundens konkurransefortrinn.
- Lever arbeidsprogramvare ofte, fra et par uker til et par måneder, fortrinnsvis til den kortere tidsskalaen.
- Forretningsfolk og utviklere må jobbe sammen hver dag gjennom prosjektet.
- Bygg prosjekter rundt motiverte individer. Gi dem miljøet og støtten de trenger, og stol på dem for å få jobben gjort.
- Den mest effektive og effektive metoden for å formidle informasjon til og i et utviklingsteam er samtale ansikt til ansikt.
- Arbeidsprogramvare er det primære målet på fremgang.
- Agile metodeprosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne holde et konstant tempo på ubestemt tid.
- Kontinuerlig oppmerksomhet på teknisk dyktighet og god design forbedrer smidigheten.
- Enkelhet - kunsten å maksimere mengden arbeid som ikke er utført - er avgjørende.
- De beste arkitekturene, kravene og designene kommer fra selvorganiserende team.
- Med jevne mellomrom reflekterer teamet om hvordan man kan bli mer effektiv, og deretter innstiller og justerer oppførselen deretter.
Eksempel på et prosjekt som trenger Agile Management
Se for deg en oppstart som utvikler en mobilapp for en klient. Det kan være katastrofalt å fryse ned hele applikasjonsdesignet før utviklingen starter. Det er også begrenset tid å gjennomføre markedsundersøkelsen, kritisere en detaljert plan, bestemme seg for variantene de ønsker å tilby og deretter utvikle produktet. I tillegg til de enorme kostnadene som er involvert i denne tilnærmingen, risikerer de at et annet selskap kan utvikle appen før de gjør det.
Agile metodikk i prosjektledelse er med på å løse disse problemene. Under dette systemet utvikles appen i trinn, med klientinteraksjon hver dag og leveranser eller prosjekt milepæler identifisert, for eksempel, for hver uke.
Flere lag kan også jobbe med den samme appen, slik at utviklingstiden reduseres drastisk.
Funksjonaliteter foredles med hvert møte, og sluttproduktet gjenspeiler det endelige behovet. De lærer trinn for trinn hva som fungerer for kunden og improviserer tilbudene til de får ønsket produkt.
I den tradisjonelle tilnærmingen til prosjektledelse skulle man tenke på alle revisjonene før man slipper produktet. Dette vil føre til tapte frister, økt arbeidsmengde og prisvekst. Videre kan produktet ha mistet sin relevans på utgivelsestidspunktet.
Hvordan fungerer Agile Management?
Selv om Agile Management for det meste omtales som et IT-konsept, er bruken ikke begrenset til IT-bransjen. For eksempel brukte kjede-apparelforhandleren Zara prinsippene fra Agile Management for å transformere virksomheten.
Ved å bruke Agile-prinsipper produserte Zara produkter i små partier i stedet for å fokusere på stor produksjon før den nye sesongen. Selskapet unngikk kostnadene knyttet til høye varebeholdninger og uforutsigbare rabatttilbud med denne metoden.
Noen av de viktigste aspektene ved Agile prosjektledelse er:
- Agile prosjektledelse følger en fleksibel tilnærming.
Agile Management ønsker velkommen tillegg og endringer gjennom produktutviklingen i stedet for å samsvare med originale spesifikasjoner.
- Agile prosjekter er vanligvis delt inn i separate arbeidsbiter, med team som er involvert i å utvikle en eller flere av disse “biter” av arbeid.
Så det er mulig å ha for eksempel fire team som jobber samtidig på forskjellige deler av et prosjekt, slik at prosjektets tidslinjer blir forkortet. Lag koordinerer med hverandre og med klienten på daglig basis for leveranser.
- Det er daglige møter om fremdriften eller veisperringene i prosjektet med konstant tilbakemelding.
Etter å ha mottatt tilbakemelding fra kunder, blir endringene integrert og teamene går videre til neste del. Denne prosessen fortsetter å levere et produkt som er mer dynamisk og bedre tilpasset kundens behov.
- Det er større involvering av teammedlemmene i stedet for en ovenfra og ned-tilnærming.
I programvarenes livssyklus er teammedlemmer involvert i alle stadier: krav, design, utvikling og smidig metodetesting. Siden det regelmessig er oversikt over oppgaveeffektivitet, justerer teammedlemmene atferd og prosedyrer deretter.
- Profilen til prosjektlederen i et Agile-prosjekt vil endre seg fra en tradisjonell rolle.
Han / hun bruker ikke lenger mye tid på å planlegge eller overvåke ressurser, men bruker nå mer tid på å samarbeide med team, og sikre at helhetsbildet alltid er i sikte. Dette er ingen enkel overgang, og ledere som flytter over til Agile-systemer må tilpasse seg raskt for at prosjektet skal lykkes.
Noen få ord om Scrum:
Scrum er et av de mest populære rammene for implementering av Agile Methodology. Hva er smidig metodikk? Det er tidligere Agile, og ble foreslått for første gang i 1986, og implementert i bil- og skriverindustrien.
Agile metodikk med skrum er ikke synonymt; det er andre rammer som kan brukes til å implementere Agile, men Scrum er en av de mest effektive og sannsynligvis den mest populære. Hva er skrum? Vanligvis har Scrum bare tre roller: Produktseier, Team og Scrum-master. Scrum-metodologimesteren er ikke prosjektleder. Ansvaret for en tradisjonell prosjektlederrolle er delt opp mellom de tre Scrum-prosjektlederrollene. Prosjektet er bygd inn i en serie med faste lengder iterasjoner kalt sprints. Suksessen til hver agile metodespurt gir en følelse av håndgripelig fremgang og kontinuerlig inspirasjon. Målet med hver iterasjon er å produsere et fungerende produkt som kan demonstreres for interessentene. Den smidige metodologien skrummesteren jobber med produktseieren og teamet for å lette gjennomføringen av mål ved å fjerne veisperringer. Det smidige metodutviklingsgruppen er tverrfunksjonell og inkluderer testere, designere og ops ingeniører i tillegg til utviklere.
Tradisjonell prosjektledelse: Fossen
Et av de mest fremtredende tradisjonelle prosjektstyringssystemene er Fossen. Det ble ofte brukt siden 1970-tallet. Det er flere kjente og vidt implementerte fossefallmetodologier i IT-prosjekter. Disse inkluderer PRINCE2 som ble opprettet av den britiske regjeringen for sin offentlige sektor.
På samme måte som navnet antyder, er det en sekvensiell arbeidsflyt. Sluttproduktet er fast i begynnelsen av prosjektet. Deretter fullføres de forskjellige stadiene i arbeidsflyten i rekkefølge (unnfangelse initiering, analyse, design, konstruksjon, testing, implementering og vedlikehold). Når forrige trinn er fullført, går utviklerne videre til neste trinn. Prosjektplanen skal være tålsikker; Når et trinn i sekvensen er fullført, kan ikke utviklerne se det samme uten å starte på nytt. Det er en statisk tilnærming til smidig metodikk i prosjektledelse. Det er ikke rom for endringer eller feil, og prosjektplanen for smidig metodikk må følges nøye.
Det kan trekkes en analogi mellom Waterfall Management og å male et mesterverk. Bildet av det endelige mesterverket er allerede i kunstnerens sinn, og han jobber stadig mot det. Hvis sluttproduktet av en eller annen grunn er forskjellig fra det han visualiserte, kan han ikke endre det lett.
Smidig eller foss?
- Hva er smidig? Agile er mer egnet for små team som jobber med inkrementelle og evolusjonsprosjekter, mens Foss er egnet for store ordninger eller utviklingsprosjekter. Fosseforvaltning er kanskje bedre egnet for bransjer som byggebransjen. Agile brukes i mer dynamiske prosjekter som IT-bransjen.
- Agile systemer krever svært dyktige teammedlemmer som kan håndtere alle faser av prosjektet. Det krever et dramatisk skifte i rollen som prosjektleder. Fosseprosessen er strukturert på en mer tradisjonell måte, er en lineær, og er kanskje lettere å forstå for ikke-utviklere og de som er nye innen programvareutvikling.
- Mange organisasjoner synes metoden for fossefall trøstende siden den er bedre dokumentert. Agile er kjent for ikke å vektlegge omfattende dokumentasjon. Det er mer avhengig av mennesker, noe som kan være ubehagelig i organisasjoner der utslagsfrekvensen er høy.
- Mindre enkle prosjekter krever kanskje ikke et smidig metodisk rammeverk og en sekvensiell fossefallmodell kan fungere like bra.
Hvor går alt?
Agile utviklingsmetodikk står for mer enn to tredjedeler av alle IT-prosjekter i USA, ifølge en undersøkelse av HP i mai 2015.
Men Agile er ikke alltid den 'perfekte' løsningen. Det er ikke en 'one-fit-all'-løsning, og som et resultat har mange organisasjoner (24% ifølge HP-undersøkelsen) nå tatt i bruk en hybrid tilnærming.
En hybrid av agile og fossefallsmetoder kan utnytte fordelene ved begge. Denne hybridtilnærmingen kan fungere for kompliserte prosjekter med eksterne kunder og store team. Denne tilnærmingen er blitt beskrevet av Erick Bergmann og Andy Hamilton. Det er et kompromiss mellom de to metodene, slik at programvareteam kan jobbe 'smidige' mens maskinvareutviklingsteam og produktledere bruker den tradisjonelle metoden.
Mark Fromson, en digital konsulent påpeker en annen måte en hybrid kan fungere på:
Å dele opp prosjektet i fossenlignende faser for å gi mulighet for fast anbudskontrakt og definert omfang i en mindre fase, men holde prosjektet flytende som en helhet.
Uansett hvilken form fremtidige team vil ta, er det tydelig at Agile metodikkutvikling er her for å bli. Det har gitt muligheter for fleksibilitet, tid og kostnad, sammen med den viktigste faktoren av alt: å gi en følelse av tilfredshet og en motiverende atmosfære til menneskene som jobber med disse prosjektene.
Kilde:
For Agile Manifesto og De 12 Agile Principles- www.agilemanifesto.org
Relaterte kurs: -
Agile prosjektledelse - Lær smidige metodologier