5 beste smidige prosjektstyringsverktøy og -teknikker

Det var tydelig i de tidlige dagene av IT-utviklingen at det var vanskelig og repeterende å jobbe med store prosjekter uten en dedikert prosjektstyringsmodell.

Mange organisasjoner utviklet sine opprinnelige implementeringer som førte til opprettelsen og tilpasningen av tradisjonelle modeller som Foss, Spiral, Iterativ, V-formet, etc.

Men de møtte alle behovene til tidlige utviklingsprosjekter. Men med utviklingen av datateknologi, dot-com-boomen og den økende etterspørselen etter programvare, slet disse modellene med å tilpasse seg det skiftende miljøet både under og etter produktets utviklingslivssyklus.

Følgelig fikk mange organisasjoner redusert holdbarhet på produktene og klarte ikke å møte kundenes krav før levering.

Og så skjedde det noe revolusjonerende – The Agile manifesto.

Manifestet bidrar til å adressere prosjektledelsesproblematikken basert på kjerneprinsippene.

I dag kan bedrifter bruke ulike varianter av smidige modeller levert av en rekke verktøy støttet av disse prinsippene.

For det første anbefaler vi at du går gjennom de 12 kjerneprinsippene bak det smidige manifestet. Og så skal vi utforske de fem beste smidige verktøyene og metodene som ofte brukes av organisasjoner.

1. Klikk opp: Nytt favorittverktøy for prosjektstyring og produktivitet

ClickUp er en skybasert prosjektledelse app laget for alle typer og størrelser av virksomheter. Den tilbyr alle verktøy og funksjoner for å administrere prosjekter for kunder, tildele oppgaver og samarbeide med teamet på en synlig måte.

Med ClickUp blir det enklere og mer fleksibelt å jobbe med smidige metoder. Takket være dens høye tilpasningsmuligheter og brukervennlighet!

Det kan være et nytt verktøy for prosjektledere, men er ganske intuitivt med design og funksjonalitet. Du kan gjøre alle typer justeringer av arbeidsområdet med de tilgjengelige temaene, fargene og dra og slipp-funksjonene med noen få klikk.

Hovedformålet er å øke de ansattes produktivitet til en viss grad. Enten du er en liten bedrift eller et fremvoksende merke, Klikk opp kan leve opp til dine forventninger.

Funksjoner

• Tilpassbarheten lar smidige utviklingsteam lage Scrum/Kanban-dashboard og bruke dem til å administrere sprints, feilsporing og se fremdriften til produktet.
• Med arbeidsflytautomatisering lar den utviklere automatisere sprintsystemet, redusere hverdagslige oppgaver og effektivt allokere ressurser.
• Enkelt for utviklere å integrere med verktøy som Github og Bitbucket samt synkronisere med kommunikasjonsappene som Zoom, Slack, etc.
• ClickUp tilbyr et bredt spekter av funksjoner som bare er tilgjengelige i betalte planer eller andre verktøy. Derfor reduserer det avhengighetene av bruk av tillegg eller annet programvare for oppgavehåndtering.

Prising:

2. Motion: AI-drevne oppgaver, prosjekter og møter automatisering

Motion er den AI-drevne produktivitetsappen som forvandler hvordan team jobber. Den effektiviserer oppgave- og prosjektstyring gjennom intelligent automatisering.

Med Motions fleksibilitet er det en absolutt lek å omfavne enhver smidig metodikk.

Det svært tilpassbare, visuelt drevne grensesnittet tilpasser seg prosessen din, ikke omvendt.

Du kan lage det perfekte arbeidsområdet med tilpassede temaer, fargeskjemaer og intuitiv dra-og-slipp-enkelhet for å få alle brukere i gang på kort tid.

Men Motion er ikke bare pen å se på – den er bygd for å øke produktiviteten for team av alle størrelser.

Funksjoner

• AI-drevet oppgaveplanlegging prioriterer arbeid basert på haster, tidsfrister, arbeidsbelastninger og avhengigheter for optimal planlegging.
• Sofistikerte prosjektstyringsverktøy visualiserer oppgaver, milepæler og ressursallokering for å holde initiativene på rett spor.
• Forutsigbar deadline-sporing varsler teamene proaktivt om utsatte forfallsdatoer uker eller måneder i forveien.
• Samlet kalendersynkronisering konsoliderer alle arbeids- og personlige tidsplaner i én delbar teamkalender.
• Kraftig arbeidsbelastningsanalyse gir innsyn i gjeldende og anslåtte teambåndbredder for å forhindre overengasjement.
• Innebygd møteplanlegging finner og bestiller optimale møtetider basert på deltakernes tilgjengelighet.

Prising:

3. Jira: Det mest populære smidige verktøyet blant prosjektledere

Atlassians Jira er utvilsomt en av de mest brukte prosjektstyringsprogramvarene i IT-bransjen. De siste to tiårene har Jira vært toppprioritet for problemsporingsløsninger.

Og med bruken av smidige metoder, har Jira utvidet funksjonaliteten utover utviklingsteam som HR-drift, markedsføring, lovlighet, salgOsv

HR-ledere kan bruk Jira å forbedre sine interne arbeidsflyter og lette ansettelsesprosessen. Salgspersonell kan holde oversikt over kundens reise og bringe effektive salgsstrategier. Markedsføringsteam kan bruke det til å bygge bro over gapet mellom teamene, identifisere høyverdiprosjekter og jobbe sammenhengende.

Funksjoner

• Jiras kjernekomponenter er feilsporing og problemhåndtering som hjelper utviklere med å finne feilene og adressere dem deretter.
• Smidig rapportering hjelper til med å få sanntidsinnsikt om et teams ytelse ved hjelp av sprintrapporter, nedbrenningsdiagrammer, versjonsrapporter, kumulative flytdiagrammer, etc.
• Intuitiv dra og slipp-funksjon for å omorganisere komponentene på backlog, for eksempel feil, brukerhistorier, etc.
• Rik integreringsfunksjon for å øke programvarens funksjonalitet med tilgjengeligheten av over 3000 tredjepartsapper.

Prising:

4. Teamwork: Beste smidige programvare for enkeltpersoner eller små team

Teamwork var tidligere kjent som Digital Crew som var en tilpasset webutvikling og intranetttjenesteleverandør. Men med fremveksten av teamsamarbeidssystemer i markedet, utvidet det seg til smidig utvikling. Og helt fra begynnelsen fokuserte det på å tilby tilpasningsdyktige prosjektstyringsløsninger, spesielt for små grupper.

Nøkkeltilbudene inkluderer innebygd meldingstjenester, versjonskontroll, fildeling, tidsregistrering, oppgaveadministrasjon og prosjektbudsjettering. Den har også kapasitetsstyring som holder styr på ressursene som kreves for å imøtekomme forretningsbehovene på en kostnadseffektiv måte.

Teamworks intuitive brukergrensesnitt gjør det godt for små bedrifter akkurat som hvordan Jiras brukergrensesnitt passer godt for store bedrifter.

Med Kanban-styret kan team planlegge og bygge produkter uten å tvinge en prosess på noen. Snarere hjelper det deg med å lage flere tavler i prosjektet for forskjellige team, slik at du kan spore arbeidsflyten i hvert team.

Den beste delen er fugleperspektivet som effektivt hjelper deg å bruke et tidsregistreringssystem for å se hvor mye tid teammedlemmer brukte på prosjektet.

Teamwork er utvilsomt det beste rimelige smidige verktøyet, spesielt for et veldig lite team og selv om du er frilanser.

Funksjoner

• Teamworks dashbord utforming er kortfattet og mye mindre forvirrende. Den bruker enkle terminologier for hver funksjon.
• Et rent brukergrensesnitt som muliggjør kortere veier for handlinger rundt oppgaver.
• Du kan ha alle oppgavene og underoppgavene dine i én enkelt prosjektvisning der du enkelt kan dra og slippe elementer og skjule de som ikke betyr noe.
• Ocuco timeregistrering funksjonen hjelper det lille teamet til å håndtere et stort antall prosjekter.
• Utløsere lar deg automatisere arbeidsflyten, for eksempel ved å tildele oppgaver til hver utvikler eller generere underoppgaver når hovedoppgaven er fullført.

Prising:

5. Varsel: Beste AI-drevne automatiseringsfunksjon for smidige prosjekter

Forecast er nok et smidig prosjektstyringsverktøy som er spesielt bygget for å automatisere og forenkle monotone oppgaver. Drevet av naturlig bygd AI, kan Forecast automatisere prosjektplanlegging og planlegging og spare tid på repeterende manuelle oppgaver.

Skaperne gjorde dette mulig ved å trene programvaren med 50,000 XNUMX prosjekter som lar verktøyet lage estimater og foreslå antall timer det bør ta for lignende oppgaver. Det er enkelt for administratorer å angi tillatelsesnivåer for forskjellige teammedlemmer og organisere etterslepet med oppgaver.

Samlet sett er Forecast en ny versjon av smidig prosjektledelse og et anbefalt verktøy for ledere som ønsker det få gjort mer på kortere tid.

Funksjoner

• Forecasts business intelligence-funksjon bruker maskinlæring og hevdes å være 94 % nøyaktig når det kommer til oppgaveprediksjon og fullføringstid.
• Administratorer kan angi tillatelsesnivåer for hvert medlem av teamet, enten de er utviklere, samarbeidspartnere eller interessenter.
• Smidige team kan velge mellom Scrum-, Kanban-brett eller ekstreme programmeringsmetoder som kommer med fleksible dra-og-slipp-funksjoner.
• Dens opprinnelige sanntidsrapporteringsfunksjon og automatiserte læringsalgoritme jobber hånd i hånd for å gi nødvendig statistikk som hjelper til med å finne ut av problemene.

Prising:

Agile prosjektledelsesteknikker du bør kjenne til

Agil prosjektledelse er basert på flere iterative og inkrementelle tilnærminger. I motsetning til fossefall/tradisjonell metode, følger smidig ikke en lineær bane og kan tilpasses enhver situasjon. Se for deg to forskjellige spill – bueskyting og fotball.

Bueskyting er et lineært spill med et forhåndsdefinert mål, mens fotball er dynamisk som tilpasser seg situasjoner mens spilleren fortsetter mot målet (bortsett fra straffesparket).

Selv om smidig er dynamisk i naturen, er det ingen måte for ledere å ta i bruk denne teknikken. La oss finne ut bransjens beste smidige prosjektledelsesteknikker én etter én:

1. Kanban: En allsidig smidig metodikk

Kanban er et av de populære smidige rammeverkene i IT-bransjen. Selv om denne teknikken ble introdusert i 2004 av David J. Anderson spesielt for IT og utvikling, ble den opprinnelig laget av den japanske bilingeniøren Taiichi Ohno.

Tilbake på begynnelsen av 1940-tallet kom Ohno opp med Just-in-time (JIT)-prinsippet for å øke bilproduksjonsprosessen. Han brukte papirkort til å plassere i kolonnene for å planlegge og spore arbeidsflyten. Med denne teknikken fant han en merkbar endring i å administrere aksjene og møte produksjonskravene. Og så navnet fikk popularitet som betyr et "skilt" på japansk.

Det er ikke noe forskjell på IT og utvikling. I Kanban-systemet kan du vise elementene som kort i kolonnen fra Ny til Fullført. Du kan tildele oppgaver fra etterslepet, holde oversikt over fremdriften og opprettholde en jevn arbeidsflyt.

For å sikre at hver oppgave blir fullført i tide, setter systemet begrensninger på rekkefølgen for å legge til et antall elementer. Disse kalles Work in Progress (WIP) grenser.

Hver gang du prøver å pålegge oppgaver utover grensene, setter systemet avbrudd slik at du kan fullføre de gjenværende oppgavene og deretter legge til elementer fra etterslepet. WIP-grenser sparer også tid ved å unngå for mange oppgavebytte og fokusere på høyprioriterte oppgaver.

Kanban-brett er et flott sted å samarbeide. Den visuelle presentasjonen av arbeidsflyten lar team jobbe sammen med smidige prinsipper og hjelpe dem til å føle seg engasjerte, informerte og ansvarlige.

Kanban fungerer også bra med Scrum. På den ene siden lar Kanban teamet holde seg på sporet med den daglige arbeidsflyten med minst mulig overhead og blokkeringsproblemer. På den andre hjelper Scrum med sprints, administrere tilbakemeldinger, kontinuerlig flyttilnærming og minimere kaoset.

Samlet sett er Kanban-metoden ikke begrenset til en enkelt type industri og kan også brukes sammen med andre smidige teknikker.

2. Scrum: Den beste teknikken for produktutvikling

I 1993 introduserte Jeff Sutherland, John Scumniotales og Jeff McKenna offisielt Scrum-metoden hos et programvareutviklingsfirma. Men ideen bak Scrum var inspirert av en artikkel publisert i 1986 av Hirotaka Takeuchi og Ikujiro Nonaka.

Artikkelen gjorde en interessant analogi av produktutvikling med spillet Rugby som fokuserer på korte pasninger og en fartsfylt tilnærming for bedre ytelse.

I dagens konkurranseutsatte marked er Scrum en mye brukt smidig metodikk ved siden av Kanban.

I kjernen handler Scrum om sprints. Det ligner på kortpasningstilnærmingen i rugby. Ledere kan bruke teknikken til å dele opp en større oppgave i små deler som hjelper teamene til å jobbe med hver oppgave innen en kort tidsramme. Å strukturere produktet i spurter hjelper dem å fullføre oppgaven og unngå unødvendig forvirring eller forsinkelse.

Så hvordan fungerer Scrum egentlig?

For det første oppretter lederen en produktbacklog (ved hjelp av kundens ideer) i form av det prioriterte antall oppgaver. Og elementene i oppgaven kalles brukerhistorier. Lagene lager sprinten som går mellom én til fire uker. Så deler de opp brukerhistoriene i små seksjoner og trekker brukerhistoriene med høyere prioritet fra backlog til spurtene.

Gjennom hele produktets livssyklus gjennomfører team sprintplanlegging der de har kort kommunikasjon og finner ut av flaskehalsene som hindrer dem i å nå sprintmålene.

Når alle spurtene er fullført, inviteres klienten til sprintgjennomgangen hvor teamene får tilbakemelding som deretter legges til produktbacklogen som en ny brukerhistorie.

Lagene gjennomfører deretter sprintretrospektiver der de diskuterer hva som gikk bra og ikke.

Nå velger de neste prioritet fra etterslepet for neste sprintsyklus, mens de tar hensyn til tidligere tilbakemeldinger og fokuserer på forbedret produktutvikling.

Videre lager teamet en "Definition of Ready" som i utgangspunktet er en sjekkliste som hjelper dem med å definere om en brukerhistorie er klar til å jobbes med i en sprint eller ikke.

Og så lager de en "Definition of Done" som skal brukes på slutten av sprintsyklusen.

Dette kan hjelpe dem til å ha en felles forståelse av hva som trengs for at arbeidet skal fullføres.

Med Scrum opplevde mange organisasjoner fordeler som høyere produktivitet, bedre teamdynamikk, raskere innovasjon, bedre produktkvalitet, raskere tid til markedet, og til slutt trygghet for alle som er tilknyttet produktet.

3. Krystallmetodikk: Et fleksibelt og brukersentrisk smidig rammeverk

Ikke alle Agile-rammeverk er ment å være strengt utformet for å følge en viss trinn-for-trinn-prosess. Krystallmetodikk er et slikt rammeverk som fremmer en adaptiv arbeidstilnærming, mindre dokumentasjon eller rapportering, og fokuserer mer på mennesker og samarbeid.

Krystallmetoden er ideen til den amerikanske dataforskeren Alister Cockburn som utviklet dette rammeverket for IBM i 1991. Og ideen bak metodikken er å ha et trygt og menneskesentrisk arbeidsøkosystem som kan endres for å passe teamets spesifikke behov.

Derfor introduserte han et fleksibelt sett med regler for å kategorisere oppgavene i henhold til risikoen for menneskeliv. Hver oppgavekategori er delt inn i fargegrupper (krystallfamilie) slik at kompleksiteten i produktutviklingen kan kontrolleres med teamvekst.

I hver krystallfamilie er hovedfokuset på teamstørrelsen, deretter oppgavens kritikkverdighet, og til slutt prioriteringen av utviklingssyklusen. Etter hvert som teamstørrelsen vokser, endres retningslinjene og praksisene tilsvarende. Og det samme gjør intensiteten i arbeidet, teamkommunikasjon og oppdateringer.

La oss nå få vite om hver kategori av krystallfamilien og deres utviklingstilnærminger:

1. Krystallklar

• Den er designet for lag på 6 personer eller færre.
• Denne gruppen er den letteste formen for krystallprosessen.
• Den brukes i små prosjekter med ikke-forhandlingspris.
• Lag trenger ikke å produsere mange artefakter eller stole sterkt på prosessene.
• Krever litt dokumentasjon.
• Fokus er mer på prosjektsikkerhet.

2. Krystallgul 

• Den består av små mellomlag på 7-20 personer.
• Her er det definert en tydelig eierkodeks som betyr at de som eier koden er de eneste som gjør endringer.
• Tilbakemelding er samlet inn fra direkte kommunikasjon med reelle brukere.
• Oppdragserklæringer er godt definert og verifisert med kundene.
• Automatisert testing gjennomføres og forbedringsplaner settes.

3. Krystalloransje 

• Det er for prosjekter på mellomnivå med team på 20-50 personer.
• Her forventes prosjekter å vare i 1-2 år.
• På grunn av størrelsen blir teamene delt opp i funksjonelle ferdighetsgrupper.
• Utgivelsen kreves hver 3.-4. måned, kjent som inkrement.

OBS: Det er en egen versjon av Crystal orange for nettbaserte kunder kjent som "Orange-web". Den fokuserer på den kontinuerlig utviklende koden som brukes av allmennheten og tar sikte på minst mulig defekter. Selv om den grunnleggende ideologien forblir likegyldig fra krystalloransje.

4. Krystallrød

• Det er for mellomstore til store prosjekter med en teamstørrelse på 40-80 personer.
• Team deles opp eller dannes ettersom arbeidet krever og følger en mer tradisjonell programvareutviklingsprosess.

5. Krystall rødbrun 

• Den ligner på den krystallrøde, men laget for en lagstørrelse på 80-200 personer.
• Den brukes kun til store prosjekter.
• Metoder er designet i henhold til behovene til programvare og bruker tradisjonelle utviklingsmetoder.

6. Diamant og safir

De brukes kun til store prosjekter med høy kritikalitet som innebærer potensiell risiko for menneskeliv (i tung verkstedindustri).

4. Ekstrem programmering: Pålitelig teknikk for å håndtere kritiske situasjoner

Kort sagt betyr ekstrem programmering (XP) å håndtere komplekse problemer med ekstrem arbeidsflythastighet. Men det er også underliggende risikoer. Så hvorfor stoler selskaper på en slik metodikk?

Før vi forstår prosessen, la oss lære om formålet.

XP-metoden ble utviklet av den amerikanske programvareingeniøren Kent Beck i 1996. Han er ikke bare skaperen av XP-metoden, men også en den opprinnelige underskriveren av Agile-manifestet.

I løpet av sine dager som ingeniør ønsket han å løse noen av feilene på grunn av den tradisjonelle/fossefallstilnærmingen til prosjektledelse. Han ønsket å forkorte tilbakemeldingssløyfene, bringe fleksibilitet og tilpasningsevne til arbeidstilnærmingen, involvere alle deltakere under ett tak og ta hensyn til menneskenes menneskelighet.

Også det faktum at 1990-tallet så gjennombruddet til internett og troverdigheten til objektorienterte programmeringsspråk (C++, Java, Python) fremfor prosedyreprogrammeringsspråk (C, FORTRAN, BASIC) utløste ideen om en kortere utviklingslivssyklus og var ofte uforenlige med de tradisjonelle metodene.

Følgelig påvirket dette selskapene sterkt til å ta i bruk raskere utviklingsteknikker for å holde seg på nivå med konkurrentene.

XPs tilnærming er ganske flytende. Du kan ikke forutsi prosjektkravene helt fra begynnelsen. I stedet har XP et fleksibelt økosystem der du kan gjøre endringer etter hvert som prosjektet går videre på utviklingssporet.

Men XP-metoden kan ikke alltid brukes på alle andre agile-baserte prosjekter. Metoden er helt fokusert på de dynamiske kravene til kundene – spesielt for å møte raskt skiftende behov og redusere kritiske risikoer.

Totalt sett har XP en rekord for å forbedre prosjektets effektivitet ettersom det presser grensene for utviklingslivssyklusen og øker intensiteten i bransjens beste praksis.

Derfor vurderer prosjektledere noen viktige fremgangsmåter mens de bruker XP-metodikk:

• Ombordstigning 2-12 personer: Mindre team betyr mindre tid til idédugnad og kommunikasjon.
• Intern arbeidsstyrke: Teamet bør være tilgjengelig på stedet da XP kanskje ikke er egnet for eksternt arbeid.
• Sette tilpasningsdyktige, men strenge tidsbegrensninger: Uten noen tidsfrister kan utviklingen gå langsommere eller mindre effektiv.
• Arbeide med kritiske situasjoner eller prosjekter med strengere tidsfrister: Risiko kan reduseres ved å involvere alle deltakerne og få hyppige tilbakemeldinger.

Ved ekstrem programmering fungerer tilbakemelding på ulike nivåer. Husk at planlegging er en midlertidig enhet, og du må gjenskape dem så ofte du mottar ny kundeinnsikt.

Her kan du se at det er forskjellige nivåer av tilbakemeldingssløyfer i et prosjekts utviklingslivssyklus, og hver av dem endres på en bestemt tidsperiode. Og hvert nivå definerer kjerneprinsippet for XP-metodikk.

Utgivelsesplan:

Ikke bygg opp hauger med uutgitte koder som ellers kan kreve for mye regresjon og integrering. Slipp i stedet verdi til kundene og få tilbakemelding så ofte og så tidlig som mulig.

Iterasjonsplan:

Identifiser problemene fortsett å redusere ineffektiviteten ved å refaktorisere koden og opprettholde standardene.

Godkjennelsestest:

Før teamet koder noe, lag automatisert klientgodkjenning og enhetstester. Skriv så nok kode, kjør den og refaktorer så lenge den viser en feil. Derfor, før du gjør krav på et vellykket prosjekt, fortsett å teste det ferdige produktet ditt.

Standup møter:

Prøv å bruke analogier mens du forklarer prosjektmålene (si, denne utviklingsprosessen er som et spill) som lett kan relateres til alles erfaring og forståelse. Slike møter kan stimulere teamene til produktive diskusjoner.

Parforhandling:

Ethvert medlem av teamet kan være åpne for å fikle med andres kode ved å ta ansvar, eierskap og ansvarlighet i betraktning. Begge utviklerne blir trygge på hverandres ferdigheter, noe som forbedrer kvaliteten på koden.

Enhetstest:

Flere tester betyr flere sjanser til å identifisere eventuelle problemer. Enhetstester utføres i kortere iterative sykluser for å sikre at delen av appene oppfyller designkravene.

Parprogrammering:

Det er en praksis der to personer, en med en strategisk og en annen med en taktisk tankegang, jobber sammen. En er navigatøren og en annen er driveren for å sikre at kvaliteten på utviklingsstandardene er godt vedlikeholdt og lett å forstå av alle deltakere.

Kode:

Koding er ikke bare en måte å skape løsninger på, men også for å diskutere problemer. Ved å følge kodestandardene er enkle navnekonvensjoner, samarbeid og konsistens måtene å opprettholde utviklingseffektiviteten på.

5. DSDM-metodikk: Best for dynamisk og fartsfylt prosjektutvikling

Som navnet sier, er DSDM en dynamisk tilnærming til prosjektlevering innen programvareutvikling. Denne metoden er en utviklet versjon av Rapid Application Development (RAD) som kom rundt 1994.

RAD-metoden var i utgangspunktet basert på iterasjoner og tilbakemeldinger fra brukere, men hadde en rigid struktur. Også på grunn av fremskritt innen datateknologi der GUI erstattet gamle grønne skjermer, trengte RAD forbedringer for å passe utviklingspraksisen.

Utviklingsmetodene var fri form der en uavhengig arbeidsstil utelukket risikoen for ressursutarming.

Men starten av DSDMs første versjon muliggjorde rask prototyping, iterative tiltak og bedre kommunikasjon. Det tar tid og budsjett i betraktning i løpet av utviklingens livssyklus.

Senere i 2007 ble den nyere versjonen omdøpt til "Atern" av en fugl (Arctic Tern) kjent for sin svært samarbeidende natur og langdistansefly. Men metaforen ble holdt tilbake da folk følte den forvirrende.

Men de store fremskrittene innen DSDM kom på midten av 2010-tallet da den DSDM-baserte programvaren var i stand til å operere sammen med andre smidige rammeverk.

Og med en rekke ytterligere utgivelser, er DSDM nå i stand til å brukes utover programvarespesifikke virksomheter. I dag omfavner mange ikke-IT-prosjekter smidige metoder, og DSDM er ikke noe slikt unntak.

Men hva gjør det annerledes?

DSDM-metoden fungerer etter filosofien til Pareto-prinsippet eller 80-20-regelen, dvs. å oppnå 80 % av utviklingslivssyklusen på 20 % av tiden.

Det er en leverandøruavhengig teknikk som forstår årsaken til at mange prosjekter ender opp uten suksess – på grunn av folks problemer snarere enn strategien eller bruken av teknologi.

Og også tre kjerneteknikker som legger grunnlaget for DSDM-prosessen. De er som følger:

• MOSKVA: Et akronym eller en teknikk for å prioritere prosjektkrav. Den utvides som – Må ha, Bør ha, Kunne ha og Vil ikke ha.
• Timeboksing: En systematisk tilnærming for å bruke din tilgjengelige tid og dele opp oppgaven i mindre deler for å unngå stresset i den siste timen. Også hvis det er knapphet på tid og budsjett, avvises kravene med minst prioritet.
• Produktivt verksted: Å gjennomføre emnemessige og kortere idédugnadsøkter for en bedre forståelse av målene, risikoene, kunnskapsdelingen og samarbeidet.

Siste ord

Alt i alt gir de smidige prosjektstyringsverktøyene nevnt ovenfor unike måter å implementere ulike smidige metoder på.

Selv om det smidige manifestet ble introdusert i 2001, bidro det virkelig til å sette sammen all adaptiv utviklingspraksis (lansert tidlig eller senere) og verktøy som skisserte den overordnede filosofien bak.

Organisasjoner skapte sine egne prosesser som adresserte og aksepterte endringer i stedet for å prøve å undertrykke dem ved å lage modeller som var interaktive, inkrementelle, kommunikasjonsdrevne og kundesentriske.

Mens de identifiserte mange likheter mellom relaterte iterative ideologier som dukket opp for å møte moderne programvareutfordringer, satte mange grupper av programvareutviklere seg for å lage forskjellige rammer som endret kurs i prosjektledelse.