Hvad er så fantastisk ved agile? En grundlæggende i agile metodik

Agile Definer som Agile Management Systems, som har eksisteret i et stykke tid, men som har vundet valuta i nyere tid. Faktisk indeholder Agile Management konsekvent de Top Project Management Trends i næsten hver IT-projektstyringsblog hvert år.

Anvendelserne af Agile i it-baserede projekter er ubestridt, da de finder anvendelse ikke kun i it-softwareprojekter, men også til produktudvikling og innovation.

Så hvad er så godt ved Agile? Spørg medarbejdere, der er flyttet over fra et traditionelt system til Agile, og de beklager måske de konstante møder og "møder om møder."

Det viser sig, at der er meget mere ved Agile end bare møder og feedback. Det fokuserer på at styrke hold og fjerne sekventielle måder til projektudvikling, så der er mere fleksibilitet og innovation. Mens det betyder møder og leverancer oftere end med traditionelle systemer, betyder det også, at der er en mindre chance for iterationer og ændringer senere tændt i projektcyklussen.

Det udråbes som helbredelse for almindelige problemer, der plager IT-relaterede projekter. Hvad er det nøjagtigt, og hvordan er det bedre end traditionelle systemer?

Behov for smidig metodologi - ledelsespraksis

Enhver, der har arbejdet med smidig metode i softwareudviklingsprojekter, vil have en idé om nogle af de sædvanlige problemer, der opstår under et projekt: ændring i omfang, frister, der synes umulige at overholde, og overarbejdede ressourcer.

Traditionelle agile metoder i projektledelse havde mange ulemper, som de ikke kunne klare med det stadigt skiftende forretningsmiljø, især inden for softwareudvikling, og ovenstående situationer var desværre alt for almindelige. Det betyder ikke, at traditionelle metoder ikke finder anvendelse overalt. De er stadig det bedste valg for projekter, hvor ideen er fuldt ud dannet fra starten.

Agile Management-praksis blev timens behov, fordi de opfyldte følgende behov for et produkt, der blev lanceret i et dynamisk miljø:

  • Behov for hastighed for at nå produktet til markedet
  • Behov for fleksibilitet til at imødekomme flere ændringer i specifikationer
  • Mangler i scenariet "arbejdsdeling"
  • Kundens dilemma
  • Behov for reduktion i omkostninger

Behov for hastighed for at nå produktet til markedet:

Vi lever i et hurtigt tempo, hvor fleksibilitet og hastighed er nøglen til succes.

Teknologi er en af ​​de hurtigst skiftende sektorer i branchen. Der er en nyere idé, produkt eller innovation hvert minut. På dette baggrund mislykkes traditionel projektledelsesmetode. Et sekventielt projekt er nødvendigvis afhængigt af, at de agile metodetrin afsluttes tilfredsstillende i rækkefølge. Tidslinjer i traditionelt administrerede projekter er altid en stridsknog.

Organisationer og hold, der ikke er dynamiske, mister løbet til dem, der morfiserer sig for at passe til det skiftende miljø.

Behov for fleksibilitet til at imødekomme flere ændringer i specifikationer:

Klientens forventninger og krav ændres ofte i løbet af produktudviklingen. Inden Agile Management Systems var mainstream, mislykkedes projekter i IT ofte, fordi det traditionelle projektstyringssystem blev bygget til at "pløje på". Hvis der var ændringer, følte klienter ofte klemme til deres tegnebøger eller tidslinjer. Den traditionelle projektstyringsmodel, tilpasset fra andre brancher, fungerede simpelthen ikke for en dynamisk branche som it.

Arbejdsdeling:

I den traditionelle model er der forskellige faser, der starter med analyse af systemkrav og fører til produktfrigivelse og -vedligeholdelse. Dette resulterer i arbejdsdeling og mærkning af medlemmerne som 'designere', 'programmerere' eller 'testere'. Men i virkeligheden er nutidens ressourcer ekstremt tværfunktionelle, og en så klar sondring af roller er ikke mulig i de fleste projekter.

Kundens dilemma:

I flygtige projekter er kunder ofte ikke helt sikre på, hvad deres slutprodukt med alle specifikationer skal være. Funktionaliteter og krav ændres ofte, når der udføres stykker af arbejdet. Traditionelle modeller som vandfaldsmodellen fremhæver klarhed med hensyn til det endelige produkt, og afvigelser i planer lægger et stort stress på systemet. Dette bringer os til den sidste faktor, der førte til udviklingen af ​​agile systemer.

Behov for reduktion i omkostninger:

Traditionelt frarådes ændringer i kravet, når projektet blev startet. Tværtimod var omkostningerne til enhver yderligere komponent høje, undertiden uoverkommeligt. Det var derfor bydende at medtage alle mulige scenarier i selve planlægningsfasen. Dette betød, at alle scenarier blev overvejet og foreslået en løsning. Men da det næsten er umuligt at vide med sikkerhed, hvilken del af produktet brugeren foretrækker, udviklede hold ofte “oppustede versioner” af et produkt. Dette indeholdt alle mulige scenarier, hvoraf en typisk bruger ikke ville bruge mere end 20%. Dette resulterede i unødvendige omkostninger og udvikling.

Naturligvis betød dette, at alle projekter var globale i deres planlægning.

Og da der opstod et helt nyt, ikke planlagt scenarie, var der alligevel ekstra omkostninger på trods af al planlægning.

En gruppe mennesker mødtes i februar 2001 for at diskutere nøjagtigt dette: behovet for en fleksibel og smidig model for softwareudvikling, der hjalp med at udvikle produkter, der faktisk fungerede for klienten og udvikleren. Det, der resulterede i, var ”Agile Manifesto”, som var fordelene ved agile metodesoftwareudvikling, dvs. et sæt af fire principper, der er så enkle som de er beskrivende. Tolv "Agile-principper", der forklarede, hvordan Agile-systemer rent faktisk ville fungere i et projektmiljø, blev også udviklet.

Gennem dette arbejde er vi kommet til værdi:

  • Personer og interaktioner mellem processer og værktøjer
  • Arbejdssoftware over omfattende dokumentation
  • Kundesamarbejde om kontraktforhandling
  • Svar på ændring efter en plan

Det vil sige, at mens der er værdi i elementerne til højre, værdsætter vi emnerne til venstre mere.

De 12 agile principper

De 12 agile principper er et sæt vejledende koncepter bag Agile-manifestet, der understøtter projekthold i implementeringen af ​​Agile-projekter. De er:

  1. Vores højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software.
  2. At byde ændrede krav velkommen, også i den sene udviklingstrin. Agile metodik processer udnytter ændringer til kundens konkurrencefordel.
  3. Lever arbejdssoftware ofte, fra et par uger til et par måneder, fortrinsvis frem for den kortere tidsskala.
  4. Forretningsfolk og udviklere skal arbejde dagligt sammen i hele projektet.
  5. Byg projekter omkring motiverede individer. Giv dem det miljø og den støtte, de har brug for, og stol på dem for at få arbejdet gjort.
  6. Den mest effektive og effektive metode til formidling af information til og inden for et udviklingshold er samtale til ansigt.
  7. Arbejdssoftware er det primære mål for fremskridt.
  8. Agile metodeprocesser fremmer bæredygtig udvikling. Sponsorer, udviklere og brugere skal kunne opretholde et konstant tempo på ubestemt tid.
  9. Kontinuerlig opmærksomhed på teknisk kvalitet og god design forbedrer smidighed.
  10. Enkelhed - kunsten at maksimere mængden af ​​ikke-udført arbejde - er afgørende.
  11. De bedste arkitekturer, krav og design kommer fra selvorganiserende teams.
  12. Med jævne mellemrum reflekterer teamet over, hvordan man bliver mere effektiv, tunes og justerer derefter dens opførsel i overensstemmelse hermed.

Eksempel på et projekt, der behøver Agile Management

Forestil dig en opstart, der udvikler en mobilapp til en klient. Frysning af hele applikationsdesignet, før udviklingen starter, kan være katastrofalt. Der er også begrænset tid til at gennemføre markedsundersøgelsen, kritisere en detaljeret plan, beslutte de varianter, de vil tilbyde, og derefter udvikle produktet. Udover de enorme omkostninger, der er forbundet med denne tilgang, risikerer de, at et andet firma muligvis udvikler appen, før de gør det.

Agile metodik i projektledelse hjælper med at overvinde disse problemer. Under dette system udvikles appen i trin med klientinteraktion hver dag og leverancer eller projektmilepæle identificeret, for eksempel, for hver uge.

Flere teams arbejder muligvis også på den samme app, så udviklingstiden reduceres drastisk.

Funktionaliteter forbedres med hvert møde, og slutproduktet reflekterer det endelige behov. De lærer trin for trin hvad der fungerer for kunden og improviserer tilbudene, indtil de får det ønskede produkt.

I den traditionelle tilgang til projektstyring skulle man tænke på alle revisioner, inden man frigiver produktet. Dette ville resultere i ubesvarede frister, øget arbejdsmængde og omkostningsinflation. Desuden kan produktet måske have mistet sin relevans på frigivelsestidspunktet.

Hvordan fungerer Agile Management nøjagtigt?

Selvom Agile Management for det meste omtales som et IT-koncept, er dens anvendelser ikke begrænset til IT-branchen. F.eks. Anvendte kæder til beklædningsgenstande Zara principperne i Agile Management til at omdanne sin forretning.

Ved hjælp af Agile-principper producerede Zara produkter i små batches i stedet for at fokusere på stor produktion inden den nye sæson. Virksomheden undgik omkostningerne i forbindelse med høje lagerbeholdninger og uforudsigelige rabat tilbud ved hjælp af denne metode.

Nogle af de vigtigste aspekter ved Agile Project Management er:

  • Agile Project Management følger en fleksibel tilgang.

Agile Management glæder sig over tilføjelser og ændringer gennem produktudviklingen i stedet for at overholde dem til de originale specifikationer.

  • Agile projekter er normalt opdelt i separate dele af arbejdet, med teams, der er involveret i at udvikle en eller flere af disse “bidder” af arbejde.

Så det er muligt at have for eksempel fire teams, der arbejder samtidigt på forskellige dele af et projekt, så projektets tidsplaner forkortes. Hold koordinerer med hinanden og med klienten dagligt for levering.

  • Der er daglige møder om fremskridt eller vejspærringer i projektet med konstant feedback.

Efter at have modtaget feedback fra kunder, integreres ændringerne, og holdene går videre til den næste del. Denne proces leverer fortsat et produkt, der er mere dynamisk og bedre tilpasset kundens behov.

  • Der er større involvering af holdmedlemmerne snarere end en top-down tilgang.

Inden for softwareudviklingslivscyklen er teammedlemmer involveret i alle faser: krav, design, udvikling og smidig metodetest. Da der regelmæssigt er en oversigt over effektivitet, justerer teammedlemmer adfærd og procedurer i overensstemmelse hermed.

  • Profilen til projektlederen i et Agile-projekt vil ændre sig fra en traditionel rolle.

Han / hun bruger ikke længere en masse tid på at planlægge eller overvåge ressourcer, men bruger nu mere tid på at samarbejde med teams og sikre, at det samlede billede altid er i syne. Dette er ikke en let overgang, og ledere, der flytter over til Agile-systemer, skal tilpasse sig hurtigt for at projektet skal få succes.

Et par ord om Scrum:

Scrum er en af ​​de mest populære rammer til implementering af Agile Methodology. Hvad er smidig metodologi? Det foregik i agile og blev foreslået for første gang i 1986 og implementeret i bilindustrien og printerindustrien.

Agile metodologi med skrum er ikke synonyme; der er andre rammer, der kan bruges til at implementere Agile, men Scrum er en af ​​de mest effektive og sandsynligvis den mest populære. Hvad er scrum? Scrum har typisk kun tre roller: Produktejer, Team og Scrum master. Scrum-metodologimasteren er ikke en projektleder. Ansvaret for en traditionel projektlederrolle er opdelt blandt de tre Scrum-projektledelsesroller. Projektet er indbygget i en række iterationer med fast længde kaldet sprints. Succesen med hver agile metodesp sprint medfører en følelse af håndgribelig fremgang og kontinuerlig inspiration. Målet med hver iteration er at fremstille et fungerende produkt, der kan demonstreres for interessenterne. Den agile metodik scrum-master arbejder med produktejer og team for at lette gennemførelsen af ​​mål ved at fjerne vejspærringer. Det agile metodologiudviklingsteam er tværfunktionelt og inkluderer testere, designere og ops ingeniører ud over udviklere.

Traditionel projektstyring: vandfaldet

Et af de mest fremtrædende traditionelle projektstyringssystemer er vandfaldet. Det blev ofte brugt siden 1970'erne. Der er adskillige kendte og vidt implementerede vandfaldsmetoder i IT-projekter. Disse inkluderer PRINCE2, som blev oprettet af den britiske regering til dens offentlige sektor.

Ligesom navnet antyder, er det en sekventiel arbejdsgang. Slutproduktet er fast i starten af ​​projektet. Derefter afsluttes de forskellige faser i arbejdsgangen i rækkefølge (undfangning af indtagelse, analyse, design, konstruktion, test, implementering og vedligeholdelse). Når det forrige trin er afsluttet, går udviklerne videre til det næste trin. Projektplanen skal være idiotsikker; når et trin i sekvensen er afsluttet, kan udviklerne ikke se det samme uden at starte på nytt. Det er en statisk tilgang til smidig metode i projektledelse. Der er ikke plads til ændringer eller fejl, og den agile metodeprojektplan skal følges nøje.

Der kan tegnes en analogi mellem vandfaldshåndtering og maling af et mesterværk. Billedet af det sidste mesterværk er allerede i kunstnerens sind, og han arbejder støt mod det. Hvis slutproduktet af en eller anden grund er anderledes end det, han visualiserede, kan han ikke ændre det let.

Agile eller vandfald?

  • Hvad er smidig? Agile er mere velegnet til små teams, der arbejder på trinvise og evolutionære projekter, hvorimod vandfald er velegnet til store ordninger eller udviklingsprojekter. Vandfaldshåndtering er måske bedre egnet til industrier som byggebranchen. Agile bruges i mere dynamiske projekter som IT-branchen.
  • Agile systemer kræver højt kvalificerede teammedlemmer, der kan håndtere alle faser af projektet. Det kræver et dramatisk skift i rollen som projektleder. Vandfaldsprocessen er struktureret på en mere traditionel måde, er en lineær proces og er måske lettere at forstå for ikke-udviklere og dem, der er nye inden for softwareudvikling.
  • Mange organisationer synes, at vandfaldsmetodikken er trøstende, da det er bedre dokumenteret. Agile er kendt for ikke at understrege omfattende dokumentation. Det er mere afhængigt af mennesker, hvilket kan være ubehageligt i organisationer, hvor slidfrekvensen er høj.
  • Mindre ligetil projekter kræver muligvis ikke en Agile-metodologiramme, og en sekventiel vandfaldsmodel fungerer muligvis lige så godt.

Hvor går alt sammen?

Agile udviklingsmetoder tegner sig for mere end to tredjedele af alle it-projekter i USA, ifølge en undersøgelse af HP i maj 2015.

Men Agile er ikke altid den 'perfekte' løsning. Det er ikke en løsning, der passer til alle, og som et resultat har mange organisationer (24% ifølge HP-undersøgelsen) nu indtaget en hybrid tilgang.

En hybrid af agile og vandfaldsmetoder kunne udnytte fordelene ved begge. Denne hybrid tilgang kunne arbejde på komplicerede projekter med eksterne klienter og store teams. Denne tilgang er blevet beskrevet af Erick Bergmann og Andy Hamilton. Det er et kompromis mellem de to metoder, der gør det muligt for softwareteam at arbejde 'agile', mens hardwareudviklingshold og produktledere bruger den traditionelle metode.

Mark Fromson, en digital konsulent påpeger en anden måde, hvorpå en hybrid kan fungere:

Opdeling af projektet i vandfaldslignende faser for at muliggøre fastbydende kontraktering og defineret omfang inden for en mindre fase, men at holde projektet flydende som helhed.

Uanset hvilken form de kommende teams vil tage, er det klart, at Agile metodologiudvikling er her for at blive. Det har gjort det muligt for fordele, tid og omkostninger sammen med den vigtigste faktor af alt: at give en følelse af tilfredshed og en motiverende atmosfære til de mennesker, der arbejder med disse projekter.

Kilde:

For Agile Manifesto og De 12 Agile Principles- www.agilemanifesto.org

Relaterede kurser: -

Agile projektstyring - Lær agile metodologier

Kategori:

Iværksætterudvikling