Dagens programvareteam er i det minste i sine prosesser mer smidige! De er villige til å tenke utenfor angitte parametere for å følge det som fungerer for dem. De er ivrige etter å lære og ta i bruk nye teknikker for prosjektledelse og prosjektprosesser.
En prosjektledelsesmetode kalt Kanban har gjort rundene i programvarebransjen i ganske mange år, og har vunnet valuta de siste fem årene. Sammen med Agile-metodologier har bruk av Kanban-metoden gitt selskapene mye å feire.
Men det er også kritikken om at Kanban ikke er annet enn en glorifisert oppgaveliste. Så hva handler det om? La oss finne det ut.
Hva er Kanban?
Hvis bedriften din er klar til å gå videre enn den tradisjonelle tilnærmingen til prosjektledelse av programvare, er det i dag ingen mangel på prosjektstyringsteknikker.
For det første er det Agile Project Management-systemet, som fokuserer på ikke-lineære, iterative metoder for programvareutvikling. Bruken av smidige metoder er tydelig i Scrum, som fokuserer på en mer fleksibel tilnærming til prosjektledelse.
Agile har også lenker til andre prosjektstyringsrammer som Kanban og Ekstrem programmering. Av disse har Kanban oppnådd mye popularitet. Hvem vil tross alt ikke ha en prosess utviklet av japanerne?
Kanban er et konsept som utviklet seg ved Toyota Manufacturing Plant for å oppnå just-in-time-produksjon (JIT) som reduserer kostnadene og muliggjør mindre ressursutnyttelse. I hjertet følger det "pull" -prinsippet om arbeid, noe som betyr at oppgaver eller produkter må "trekkes" av krav og etterspørsel, og ikke "skyves" ovenfra og ned. Den ble utviklet for å sikre bedre strømpe for bilkomponenter i Toyota-anlegg, basert på etterspørsel. Dette betydde at når etterspørselen økte, ville forespørsler bli fylt ut.
Konseptet ble tilpasset programvarebransjen med noen få endringer av David Anderson, i hans bok fra 2010, Kanban . Siden den gang har den blitt brukt til forskjellige prosjekter med stor suksess. Det kan være til stor hjelp i komplekse prosjekter som har potensial til å lide av overbelastning på den ene siden av utviklingssyklusen.
I utgangspunktet behandler Kanban-systemet programvareprosessen som en rørledning. La oss si at en programvareprosess har tre typer oppgaver: analyse, utvikling, testing og til slutt distribusjon. La oss si at det er tjue oppgaver som må fullføres.
I tilfelle av et tradisjonelt prosjektstyringssystem hvis for eksempel
- Det er 25 historier totalt
- Analytikere klarer fem historier i uken
- Utviklere klarer fem historier i uken
- Testere er begrenset til tre historier i uken
I denne situasjonen hoper det seg ganske enkelt opp testerne. På slutten av uke 1 vil situasjonen være som følger:
- Bare tre historier har gått videre til distribusjon.
- Utviklere og analytikere jobber med tre historier, ettersom testere ikke klarer å ta utviklerenes output og teste det samme.
- Arbeidet blir stablet, slik at utviklere og analytikere og prosjektlederen blir løst.
Nå kan analytikerne og utviklerne bare tulle tommelen! Eller lederen deres kan innse at de er ledige og omfordele dem til et annet prosjekt, der en lignende situasjon kan oppstå. Så det er to prosjekter som nå sitter fast i testfasen!
Problemene i en slik situasjon er ikke vanskelig å se. Hva er poenget med å utvikle ti historier (eller programvarebiter) når de ikke skal testes snart?
Nå videre til Kanban-metoden.
Kanban-metoden er et ekstremt enkelt konsept. Det følger en enkel logikk med å bruke en “pull-metode” for å fjerne flaskehalsene først, og begrense Works in Progress (WIPs) for bedre arbeidsprosesser.
I sin enkleste form hjelper Kanban, bokstavelig talt, “visual board” ved å “trekke” elementer fra en oppgaveliste, i stedet for å jobbe med tidslinjer. Kanban-metoden hjelper til med å identifisere flaskehalser slik at prosessflyten styres bedre.
Et grunnleggende Kanban-styre har en liste over oppgaver som skal gjøres, oppgaver som pågår og utførte oppgaver.
I programvarehåndtering kan imidlertid oppgavene være litt mer komplekse. De fleste Agile-prosjekter har et lignende styre også. I et Kanban-brett er stadiene i utplasseringen tydelig merket, sammen med et nummer for hver kolonne. Dette tallet representerer det maksimale antall oppgaver, eller historier, et bestemt trinn kan håndtere.
Eksempelet vårt på et Kanban-bord ville se noe slikt ut i begynnelsen av den andre uken. Dette betyr at utviklere og analytikere ikke vil jobbe med det optimale antallet historier den uken. Det vil være åpenbart at arbeidet begynner å bli stablet på testerens slutt. Og organisasjoner kan sikre at team jobber sammen for å få testen utført. Alternativt kan de se på andre modeller av prosessflyt slik at dette ikke skjer.
Når prosjekter håndteres gjennom Kanban-systemet, er det mindre rom for arbeid med å bli stablet opp. Historier tas opp i henhold til den maksimale tilgjengelige båndbredden.
I et typisk Kanban-oppsett, vil arbeid bli tatt opp i henhold til den tilgjengelige båndbredden, og arbeid vil bli trukket inn av team, slik at de alltid har maksimal kapasitet. Systemet gir også mulighet for et raskt spor, for oppgaver som haster, slik at de beveger seg gjennom brettet med minst mulig innsats.
Ta en titt på dette Kanban-styret.
Det er tydelig at alle trinnene fungerer med maksimal effektivitet. Og oppgaven som er på "Fast Track" blir også gjort rede for.
Kanban er på ingen måte den eneste metoden som brukes for å øke effektiviteten ved å begrense WIP. Det er andre systemer som oppnår samme resultat - for eksempel CONWIP (Constant Works in Progress) og DBR (Drum-Buffer-Rope) systemer, som først og fremst er ment for industri.
Imidlertid er Kanban det systemet som er best endret for å passe til programvareindustrien.
Hvordan er Kanban forskjellig fra smidige metodologier?
I hjertet er Kanban en metodikk som bruker noen elementer i Agile Project Management. Mange prosjekter i Agile-rammen har røtter i Lean-tilnærminger. Forskjellen mellom Kanban-metodikk og smidig prosjektledelse er ikke så svart-hvitt som talsmennene for de to metodene vil ha oss til å tro. De har mer til felles enn forskjeller.
Agile rammeverk er ikke et absolutt. Spørsmålet er ikke om lag er smidige eller ikke. Lag har ofte smidighet i ulik grad. En av metodene for å ha mer smidighet i programvareutviklingsprosessen er å bruke Kanban.
Noen få forskjeller eksisterer mellom Kanban- og Agile-metodologier. Noen av funksjonene i Kanban-utviklingen, som er litt forskjellige fra Agile, er:
- Tidslinjer er ikke en vesentlig faktor . Dette er et tøft konsept for å pakke hodene våre rundt, da det virker veldig ikke-intuitivt. “Hvordan jobber du uten tidsfrister?” Spør folk ofte. Men hvis hvert medlem av teamet er engasjert på maksimal effektivitet, slutter tiden å være en faktor.
- Historier (oppgaver) er større enn i typiske Agile-systemer. Typisk er lengden og kompleksiteten til historier lengre enn med et typisk Scrum-prosjekt. Siden fokuset ikke er på estimering av tid, men bare på å få prosessen til å gå videre, kan Kanban ha råd til å jobbe med større historier.
- Det er ingen vesentlig endring i eksisterende prosesser. Prinsippene til Kanban for programvareutvikling, som artikulert av grunnleggeren, David Anderson, i sin blogg, inkluderer følgende grunnleggende prinsipper:
-
- Begynn med det du gjør nå
- Bli enige om å satse på trinnvis, evolusjonær endring
- Respekter gjeldende prosess, roller, ansvar og titler
- Hver historie måles i syklustid . Prosjektet evalueres ikke av den tradisjonelle Agile-beregningen av hastighet (antall historier gjennomført i løpet av en gitt tid), men etter syklustid. Dette betyr at Kanban legger vekt på hvor lang tid det tok å fullføre en oppgave. Du kan ofte se en ticker på mange Kanban-brett som nevner hvor mange dager teamet tar å fullføre en historie. Dette estimatet strømmer inn i neste syklus.
Kanban: Et styre, men hva annet?
Så Kanban er et styre som viser oss hvordan historiene er ordnet - er det til og med en så stor sak, spør mange. Det er faktisk mye diskusjon om hva Kanban er og kan gjøre.
Er Kanban bare en metode for å administrere arbeidsflyten? Eller er det noe man kan bruke sammen med Agile-metodologier for maksimal effektivitet? Eller kan det være en helt ny måte å håndtere arbeidsflyt på?
Hvert lag bruker Kanban som de anser for passende, for sin spesielle situasjon. Uansett har Kanban potensial til å fungere som en levemåte for programvareutvikling, hvis den brukes til det optimale nivået.
Enten den brukes til å administrere arbeidsflyt eller som et nytt paradigme i programvareutvikling, er det ikke å benekte at det hjelper med å administrere WIP-er.
For å få Kanban til å fungere best, er det viktig å tenke på det ikke bare som å administrere WIP-er, men som et prosjektstyringsrammeverk. Enkelte grunnleggende retningslinjer vil hjelpe prosessen videre.
- Optimaliser lag slik at ingen lag starter noe de ikke kan fullføre. Dette hjelper prosessen sammen.
- Ikke motstå endringer fra det opprinnelige Kanban-systemet. Hvis prosjektet ditt klarer seg med tidsfrister og tidslinjer, må du integrere det samme som du ville gjort. Dette gir et sunnere og mer robust utviklingsmiljø.
- Ikke kast teamarbeidet. Kanban kan virke som, men er ikke, en modell basert på individer som jobber isolert. Teamarbeid må være en integrert del av Kanban programvareutvikling.
- Tenke utenfor boksen. Tenk på endringer i arbeidsflyten. Mange lag velger nå Test-Driven Development, med Acceptance Test-Driven Development, hvor akseptstestene blir utført først med brukstilfeller, som deretter driver de nødvendige funksjonene og arten av utviklingen.
hybrider
Ettersom flere og flere selskaper bruker prosjektstyringsverktøyene som er best egnet for deres spesielle situasjon, er det ikke overraskende at to av de beste metodene for prosjektledelse: Scrum og Kanban, har blitt integrert til stor suksess.
Hybriden, kalt Scrumban, gjør innpass i mange prosjekter.
Hvis en organisasjon allerede bruker Scrum, men synes det er vanskelig å holde prosjektet sammen, enten med at spurtene ikke fungerer godt, for å teste ikke å være lufttette, kan det være på tide å vurdere Scrumban.
For å forklare det enkelt, involverte Scrumban å ta et forstørrelsesglass til spurtene. Det handler ikke bare om spurtene som en del av prosjektet, det handler om hva som skjer innenfor spurtene. Scrumban hjelper deg med å se på hvordan en historie blir behandlet i en sprint, og det kan utgjøre hele forskjellen.
Scrumban, eller noen av dens varianter, er en minimal endring fra eksisterende praksis. Det fine med å bruke Kanban er at det kan brukes med praktisk talt alle slags prosjektstyringsmodeller: foss, smidig eller noe i mellom.
Komme i gang med Kanban
Det er enkelt å komme i gang med Kanban-systemet. Det er også mulig å implementere Kanban på en minimal måte som en prøve for en bestemt del av et prosjekt.
- Kartlegg programvareutviklingsprosessen. Lag et klart kart over hele prosessen. Hvordan fungerer prosjektet - fra den første prosjekteringen, til utvikling, til testing, til endringer i funksjoner, i virkeligheten?
- Liste ned trinnene der Kanban skal brukes. Bruk trinnene som er helt under din kontroll. Dette omfatter typisk analyse, utvikling, gjennomgang og testing av faser.
- Arbeid med viktige punkter som:
- Grenser for de pågående verkene for hvert trinn.
- Prosesser for fremskyndet / blokkert arbeid
- Back-of-the-konvolutt estimater med hensyn til syklustid
- Hyppigheten av Kanban styre / prosess / estimat gjennomgang
- Kjøp en tavle og en stabel med Post-It-lapper.
- Kom i gang
- Gjennomgå etter behov.
- Gjenta
Så gå foran og kom i gang med Kanban!
Ikke vær redd hvis det ikke viser seg slik du først hadde tenkt. Hele ideen bak Agile metodologier er å imøtekomme endringer i mennesker og prosesser! Gi oss beskjed om dine erfaringer med Kanban-metoden.
Anbefalte artikler
- 6 Best Helpful A Project Management Office (PMO)
- 8 nyttige trinn for å lage sofistikerte historiekart for prosjektet ditt
- De 5 viktige verdiene for ekstrem programmering (kraftig)