Share
Mens Scrums primære mål er organisering og prosjektledelse, Lene seg handler mer om å optimalisere prosesser for å raskt produsere kvalitetsprodukter. Det kan være ditt første skritt mot å vedta agile prinsipper, eller det kan være noe teamet ditt utvikler seg til når Scrum ikke er nok. Jeg inviterer deg til å lese mitt lags historie, og hvordan vi utviklet seg fra Scrum til en mer Lean-ish utviklingsprosess.
Lean er et sett med prinsipper definert av den japanske bilindustrien i 1980-årene. Toyota kvalitetsingeniør, John Krafcik, utpekte begrepet mens man observerte prosessene og verktøyene som pleide å eliminere avfall i massebilproduksjon. Det var ikke før 2003 at Mary og Tom Poppendieck introduserte Lean som en programvareutviklingsprosess i sin bok, Lean Software Development: En Agile Toolkit.
Mens Scrum er et sett av regler og roller, er Lean et sett med prinsipper og konsepter med en håndfull verktøy. Begge anses Agile teknikker, og de deler den samme ideologien om å levere raskt, samtidig som feil og feil reduseres. Jeg legger alltid vekt på Agiles tilpasningsevne, men kan ikke ignorere det faktum at Scrum presenterer seg som et obligatorisk sett med regler. Faktisk ville Scrums religiøse fans rope blasfemi for ikke å følge Scrums regler til brevet.
Mager, derimot, er mer åpen; dets tilhengere presenterer prosessen som et sett med svært tilpasningsdyktige anbefalinger.
Det oppfordrer laget eller firmaet til å ta avgjørelser, og det tilpasser seg avgjørelsene og hver dag overrasker at teamet ditt og firmaet står overfor.
Som teamet mitt modnet og utnyttet Scrum, følte vi at noen aspekter av det holdt oss tilbake. Vi ble et ganske disiplinert og homogent team. Noen møter var ikke egnede for oss lenger, og vi begynte å innse at daglige møter ikke var effektive. Vi lærte at problemer skulle løses raskere, og vi følte behovet for å unngå disse prosedyrene som holdt oss tilbake.
Vi flyttet videre.
Lean avslører to hovedkonsepter, men kjerneidéene er: eliminere avfall og forbedre arbeidsflyten.
Hvis noe kommer til å bryte, vil det gå på fredag.
Alt som står i veien for produksjonen er avfall. Dette inkluderer tapt tid, gjenværende materialer og en ubrukt arbeidsstyrke. Defekter i sluttproduktet er avfall; det går tid for å fikse dem, kaster bort penger for å erstatte dem, og kaster bort ressurser for å finne andre løsninger.
Konseptet med avfall oversetter pent til programvareutviklingsverdenen. Avfall kan beskrives ved sentleveranser, feil og programmerere som ikke har noe å gjøre (ikke forveksle dette med "programmører skal programmere åtte timer om dagen uten pause og youtube").
Toyotas Lean konsept konsentrerer seg om produksjonsflyten. I et produksjonsanlegg er strømmen en kjede av prosedyrer som forvandler råvarene til sine sluttprodukter. Disse prosedyrene kan være svært forskjellige fra hverandre og ta forskjellige beløp for å fullføre, men de kan hver forbedres for å gjøre dem mer effektive. Det er en konstant kamp å finne og forbedre flaskehalser i prosessen.
En ideell flyt er en der hvert trinn tar samme tid og krefter for å produsere samme mengde produkter.
Dette betyr ikke at hver prosess burde koste like mye penger, men hver prosess burde kunne fullføres med samme mengde letthet.
Ironisk nok var Scrum verktøyet som til slutt førte oss til å innse avfallet i prosjektet vårt. Mens vi fulgte på rent Scrum i noen områder av vår produksjon, begynte vi å identifisere feil og / eller forsinkelser som vi lett kunne unngå ved å ta en annen tilnærming.
Vi visste lite om Lean på det tidspunktet. Vi leser noen artikler om emnet, men vi gjorde det gale og ignorert dem, fordi vi var så fokuserte på vår Scrum-prosess. Vi var nesten overbevist om at Scrum var Holy Grail, men vår "Scrum machine gun" begynte å misfire. Vi trengte å åpne våre sinn.
For programvareutvikling ble Leans prinsipper tilpasset inn i de følgende syv.
Forandringen fra Scrum til Lean var faktisk frigjørende.
I programvareutvikling kan du finne og eliminere avfall ved å gjenkjenne de tingene som må forbedres. I en pragmatisk forstand er alt som ikke er en direkte verdi for kunden sløsing. Å gi noen få eksempler: Avfall er en feil, en kommentar i koden, en ubrukt (eller sjelden brukt funksjon), lag som venter på andre lag, tar et personlig anrop ... du får ideen. Alt som holder deg, teamet ditt, eller produktets tilbake er bortkastet, og du bør ta de nødvendige tiltakene for å fjerne det.
Jeg husker at en av våre problemer var det vanlige behovet for å reagere raskere enn to sprint. Utvikling i sprints og respekt for Scrums regler forbyder deg fra å endre historiene som er tildelt den nåværende sprinten. Et team trenger å tilpasse seg når en bruker finner en feil og trenger en løsning, eller når den viktigste kunden ønsker en funksjon som enkelt kan fylles ut på to dager. Scrum er bare ikke fleksibel nok i disse tilfellene.
Sett høy verdi på utdanning.
Du har avfall, og du vil naturligvis ha mindre avfall i fremtiden. Men hvorfor er det avfall? Det kommer mer enn sannsynlig fra et medarbeider som ikke helt vet hvordan man skal nærme seg et bestemt problem. Det er helt greit; ingen vet alt. Sett høy verdi på utdanning.
Identifiser de områdene som trenger mest mulig forbedring (kunnskapsbestemt) og begynne å trene. Jo mer du og teamet ditt vet, desto lettere er det å redusere avfall.
For eksempel kan læringstestdrevet utvikling (TDD) redusere antall feil i koden din. Hvis du har problemer med å integrere ulike lagsmoduler, kan du kanskje lære hva Kontinuerlig integrering betyr og implementerer en passende løsning.
Du kan også lære av tilbakemeldinger fra brukerne; Dette lar deg lære hvordan brukere bruker produktet. En ofte brukt funksjon kan bare være tilgjengelig ved å navigere gjennom fem menyer. Det er et tegn på avfall! Du kan i utgangspunktet klandre slik avfall på programmerere og designere (og du kan være riktig), men brukerne pleier å bruke programvaren din på måter du aldri tenkte på. Læring fra brukerne bidrar til å eliminere denne typen avfall. Det hjelper deg også med å eliminere feil eller ufullstendige krav. Tilbakemeldinger fra brukere kan kjøre et produkt på stier du aldri ville ha vurdert.
På et tidspunkt identifiserte teamet mitt at enkelte moduler kunne ha vært bedre skrevet hvis vi hadde kjent mer om domenet i begynnelsen. Selvfølgelig er det ingen måte å skru tilbake tid, og omskriving av en stor del av koden er ikke praktisk. Vi bestemte oss for å investere tid for å lære om domenet når det gjaldt en mer komplisert funksjon. Dette kan kreve noen timer eller uker, avhengig av problemets kompleksitet.
Hver beslutning har en kostnad. Det kan ikke være umiddelbar og materiell, men kostnaden er der. Utsettelsesbeslutninger hjelper deg fullt ut for å forberede deg på problemene du må møte. Sannsynligvis er det vanligste eksempelet på forsinket beslutning med databasedesign.
Beslutninger behøver ikke å være tekniske i naturen; kommunisere med kunder hjelper deg med å ta beslutninger som påvirker måten du nærmer deg produktets funksjoner.
Men brukerne vet ikke alltid hva de vil. Ved å utsette funksjonen avgjørelser til brukerne faktisk trenger funksjonen, vil du ha mer informasjon om problemet og kan gi den nødvendige funksjonaliteten.
Velg Agile-metoden som fungerer best for deg og ditt lag.
For fjorten år siden, laget laget en beslutning om å lagre programmets konfigurasjon i en MySQL database. De tok denne beslutningen i begynnelsen av prosjektet, og nå har dagens team (teamet mitt) en vanskelig byrde å bære. Heldigvis er dette produktet ikke lenger i aktiv utvikling, men vi må fortsatt opprettholde det fra tid til annen. Det som burde være en enkel oppgave, blir en monumentalt stor.
På den lyse siden lærte vi fra forgjengernes feil. Vi tar programmering, arkitektoniske og prosjektbeslutninger så sent som mulig. Faktisk lærte vi denne vanskelige leksjonen før vi vedtok Lean. Skriv åpen og koblet kode, og skriv et design som er utholdenhet - og konfigurasjons-agnostisk. Det er absolutt vanskeligere å gjøre, men til slutt sparer du mye tid i fremtiden.
For en tid siden la vi en funksjon til vårt produkt som komprimerer data på disken. Vi visste at det ville være nyttig, og ønsket å legge det til vårt produkt så raskt som mulig. Vi startet med enkel funksjonalitet, unngår avgjørelser angående valg og konfigurasjon til en senere tid. Brukerne begynte å gi tilbakemelding etter noen måneder, og vi tok den informasjonen for å ta våre beslutninger om funksjonens alternativer og konfigurasjon. Vi endret funksjonen på mindre enn en dag, og ikke en enkelt bruker har klaget eller bedt om mer funksjonalitet. Det var en enkel modifikasjon å gjøre; Vi skrev koden og visste at vi ville gjøre en endring i fremtiden.
Vi lever i en stadig skiftende verden. Programmene vi skriver i dag er for datamaskiner som vil bli foreldet om to år. Moores lov er fortsatt gyldig, og det vil fortsette å være så.
Leveringshastigheten er alt i denne raske verden.
Å levere et produkt om tre år setter deg bak pakken, så det er veldig viktig å gi verdier til kundene dine så snart som mulig. Historien viste at et ufullstendig produkt med en akseptabel mengde feil er bedre enn ingenting. I tillegg har du uvurderlig tilbakemelding fra brukerne.
Vårt firma hadde en drøm: lever etter hver sprint. Det er selvfølgelig upraktisk i de fleste tilfeller. Brukerne våre ønsker ikke et oppdatert produkt hver uke eller måned. Så, mens vi streber etter å frigjøre hver versjon av koden, gjør vi det ikke. Vi lærte det "rask" er hva brukeren oppfatter - ikke hva vi fysisk kan gjøre. I vårt produkts bransje betyr rask med regelmessige oppdateringer hvert par måneder og kritiske feilrettinger innen dager. Slik oppfatter brukerne "rask"; Andre typer produkter og næringer har forskjellige definisjoner av "rask".
Programmerer pleide å være ressurser innkapslet i skap, stille utføre sine oppgaver for deres firma. Dette var det fremtredende bildet av en programmerer i slutten av 1990-tallet, men det er absolutt ikke lenger tilfelle.
Historien demonstrerte at denne tilnærmingen og tradisjonell vannfallsprosjektledelse ikke er egnet for programvare.
Det var så ille på et tidspunkt at bare rundt 5% av alle programvareprosjektene faktisk ble levert. Millioner dollar-bedrifter og -produkter sviktet 95% av tiden, noe som førte til store tap.
Lean identifiserte at umotiverte programmerere forårsaket dette avfallet. Men hvorfor mangel på motivasjon? Vel, programmører og utviklingsgrupper ble ikke lyttet til. Selskapet satte opp oppgaver og mikromanaged de ansatte som bare ble sett på som ressurser som produserte kildekoden.
Lean oppfordrer ledere til å lytte til programmører, og det oppfordrer programmører til å lære sine ledere prosessen med programvareproduksjon. Det oppfordrer også programmerere til å arbeide direkte med kunder og brukere. Dette betyr ikke at utviklerne gjør alt, men det gir dem muligheten til å infallce produksjonens utvikling. Overraskende, har den følelsen av, "Du vet den flotte funksjonen brukerne elsker? Det var min ide!"er en stor motivasjonsfaktor.
Men ikke tro at dette bare virker for store lag; vårt lag er lite. Vårt firma har bare en håndfull utviklere, så vi har alltid vært nær våre brukere. Det forholdet har gitt oss mulighet til å påvirke vårt produkt utover hva våre ledere kanskje har opprinnelig tenkt.
Alt som står i veien for produksjonen er avfall.
Integritet handler om robustheten av produktet ditt, og det er hvordan kundene ser produktet ditt som helhet. Integritet handler om UI-enhetlighet, pålitelighet og sikkerhet, og brukeren føler seg trygg med produktet. Integritet er det komplette bildet brukeren oppretter for produktet ditt. For eksempel innebærer UI-integritet utseendet mellom sider, skjermbilder, moduler eller til og med mellom brukergrensesnittet til systemet ditt og selskapets nettsted.
Men integritet kan også observeres og praktiseres på kildekodenivå. Integritet kan bety at moduler, klasser og andre brikker er skrevet på lignende måte. Du bruker de samme prinsippene, mønstrene og teknikkene i hele koden din - selv mellom forskjellige lag. Integritet betyr at du ofte må reflektere koden din. Det er kontinuerlig og uendelig arbeid, og du bør streve for, men aldri nå det.
Opprettholde integritet i kildekoden er en vanskelig oppgave. Vi innså at det å finne duplikat kode er det vanskeligste å gjøre, og ved duplisering betyr jeg ikke et par linjer med duplikatkode i samme metode eller klasse.
Det er ikke engang å søke i forskjellige moduler for nøyaktig samme kode; Det handler om å finne disse delene av felles logikk, utvinne dem i sine egne klasser, og bruke dem på flere steder.
Å finne logisk duplisering er svært vanskelig og krever intim kjennskap til kildekoden.
Jeg har vært på samme prosjekt i mer enn et år, og jeg er fortsatt overrasket når jeg finner duplikatkode. Men det er en god ting; vi nådde et punkt når vi faktisk ser disse tingene og tar handling på dem. Siden vi begynte aktivt å fjerne duplikat logikk på høyt nivå, økte vår kodekvalitet. Vi er ett skritt nærmere å oppnå integritet.
Brukerne vet ikke alltid hva de vil.
Når du lager din søknad, må du tenke på tredjepartskomponentene du stoler på for å utvikle produktet, samt de andre tredjepartene produktet kommuniserer med. Din søknad må integreres med utformingen av en enhet eller operativsystemet på en stasjonær PC. Er det ikke enklere å bruke en app som integreres med smarttelefonens varslingssystem, og brukergrensesnittet gjenspeiler OS-brukergrensesnittet?
Ja, det er ikke så lett å se det hele. Du må løsne deg selv fra de små detaljene og se på produktet ditt langt unna. En av de minneverdige øyeblikkene i produktets utvikling var da vi innså at vi må stole på hva andre programmerere produserer i andre prosjekter. Vi innså at kjernen til systemet, programmert av andre, er en av disse tredjepartskomponenter som vi stoler på.
På et tidspunkt endret den tredjepartskomponenten. Vi kunne nettopp ha brukt band-aids til vår søknad, eller vi kunne ha tatt den enkle ruten og skylden de programmører som skrev den komponenten. I stedet tok vi problemet ved hornene og løst problemet i tredjepartskjernen. Å se hele og jobbe med det kan være rotete, men det kan gjøre forskjellen mellom et produkt og et godt produkt.
Det er flere verktøy og teknikker for å gjøre Lean arbeid. Jeg foretrekker Kanban, et styrebasert verktøy som ligner på Scrums planleggingsbrett. Tenk deg et kanbanbrett som en dobbeltratt.
Til venstre er den endeløse listen over historier vi må adressere. Alle ferdige historier hoper seg opp til høyre, og lederen eller produktets eier bestemmer når du skal publisere en ny utgave, basert på denne listen.
I midten er vår effektive Kanban-prosess. Produktet skal være i en stabil og utløserklar tilstand når vi fullfører en historie. Dette betyr ikke nødvendigvis at en funksjon er utført; Produktet kan ha noen delvis implementerte funksjoner. Men produktets stabilitet, sikkerhet og robusthet skal være produksjonskvalitet.
Vi gjorde det ganske bra med vår nåværende sprint. Det var en vanlig mandag, en rolig dag med liten spenning, men vi begynte å se noen problemer ved onsdag. Det er ok, det skjer hele tiden. Å overvinne disse vanskelighetene krever imidlertid litt ekstra tid. Vår produkteier har avtalt med oss for å fortsette å jobbe med dagens funksjon og utvide dagens sprint om tre eller fire ekstra dager.
Fredag kom med en overraskelse. Du vet regelen: Hvis noe kommer til å bryte, vil det gå på fredag. En viktig og potensiell kunde krevde en viss funksjon før man signerte en kontrakt med selskapet. Vi måtte reagere (og raskt!). En ny utgave var obligatorisk ... Men vent! Vi er midt i en sprint. Produktet skal være utløserklar ved slutten av sprinten. Hva skal vi gjøre? Scrum vil si å gjøre den nye funksjonen i neste sprint, men vi er allerede sent med dagens sprint! Det var øyeblikket da vi begynte å innse at vi må tenke mindre enn en individuell sprint. Vi må være i stand til å tilpasse seg raskere, og vi må slippe ut tidligere hvis det er nødvendig.
Et Kanban-kort ser ganske ut som et Scrum-planbrett, men med noen tilføyelser for å bedre imøtekomme Lean-prosessen.
Første kolonne til venstre er full backlog: alt vi trenger å gjøre på et tidspunkt. Langst til høyre har du den andre trakten, som inneholder alle ferdige (men ikke utgitte) historier.
I midten er vår prosess. Disse kolonnene kan variere avhengig av hvert lag og prosess. Det anbefales vanligvis å ha minst en kolonne for de neste oppgavene, og en annen kolonne for historiene som er i utvikling. Ovennevnte bilde viser flere flere kolonner for å presentere utviklingsprosessen bedre.
De Å gjøre kolonne viser oppgaver som vi må fullføre. Da har vi Design, hvor utviklere jobber med å designe dagens historier. Den fjerde kolonnen er Utvikling, den faktiske kodingen. Endelig, den testing kolonne viser oppgaver som venter på gjennomgang av en annen lagkamerat.
Ingen vet alt.
Hvis du sammenligner dette Kanbanbordet med et scrum planleggingsbrett, vil du umiddelbart legge merke til de åpenbare forskjellene. Først har hver kolonne et tall som representerer det maksimale antall historier som er tillatt å oppholde seg i den kolonnen. Vi har fire å gjøre, fire i design, tre i utvikling og to i testing. Bakloggen og gjennomførte oppgaver har ingen slik grense.
Hver kolonnes verdi må defineres av teamet. I bildet ovenfor har jeg tildelt vilkårlig tall til kolonnene; Tallene dine kan variere betydelig. Tallene er heller ikke endelige. Tilpass tallene når du identifiserer og fjern flaskehalser.
En av de mest fantastiske egenskapene til Kanban og Lean er viktigheten av samarbeid og innsatsfordeling. Som du ser på brettet, inneholder hver kolonne i prosessen våre kort med folk på dem. Det er åtte utviklere på eksempelbordet - ganske stort lag! Styret presenterer alltid den nåværende statusen til hvem som gjør det til enhver tid.
Ifølge vårt styre er det tre personer som jobber med design, to par som jobber med utvikling og en utviklerstesting. Historier går videre til neste kolonne, og arbeidet i den nåværende kolonnen er fullført, og avhengig av hvilken type utvikling og organisering teamet har, kan den samme utvikleren fortsette å jobbe i samme historie som den beveger seg gjennom prosessen.
La oss anta at vi har spesialiserte mennesker. Så de tre designernes primære funksjon er design, de fire utviklerne skriver kode, og den ensomme testeren tester primært produktet / funksjonen. Hvis en designer fullfører en historie, går historien til utvikling, og en annen historie fra oppgavelisten blir trukket inn i design.
Dette er en vanlig prosess. En historie ble flyttet fra design til utvikling, og nå er utviklingen på sine høyeste historier. Men hva om en annen designer fullfører en annen historie? Det gir utviklerlaget fire historier - en uønsket situasjon.
Lean ønsker å unngå overbelastning. Det er forbudt å flytte en historie til neste kolonne hvis den overskrider kolonnens maksimum. I dette tilfellet må ressursene omfordeles; designeren som har fullført oppgaven må velge hva de skal gjøre neste gang. Hans første alternativ er å trekke en annen oppgave fra kolonnen, men han kan ikke gjøre det fordi han må passere sin nylig ferdige oppgave til utviklingslaget (som han ikke kan gjøre). Hans eneste andre mulighet er å begynne å jobbe med en utviklingshistorie. Han er kanskje ikke den beste utvikleren, men hans innsats vil bidra til å opprettholde prosessflyten.
Hvis testeren fullfører den siste historien i sin kolonne, kan han hjelpe designeren med sin utviklingsoppgave.
Dette er flott! Teamet kan omorganisere på fluen! Ser du bortkastet? Ser du en flaskehals i strømmen? Ta øyeblikkelig tiltak!
Når en historie i utviklingskolonnen er fullført, går testeren tilbake til testing, designeren for å designe, og utviklerne tar opp historien som designeren og testeren jobbet med. Men vær oppmerksom på at du ikke trenger å følge det nøyaktige reseptet. utvikleren kunne begynne å designe som designer og tester ferdig med å utvikle sin historie. Det er opp til deg!
Vårt styre er nå tilbake til normal.
Det er forbudt å flytte en historie til neste kolonne hvis den overskrider kolonnens maksimum.
Jeg så på nostalgi som vår scrum master fjernet vårt styre. Stykke for stykke, rev han ned vår elskede brett, som da ble et fjell av krøllet papir.
En annen kollega kom inn i rommet, noen få store ark med friskt hvitt papir i hendene. Vårt styre var i ferd med å bli gjenfødt til noe annet, noe bedre egnet for våre behov. Etter at papirarkene var på veggen, startet vi et ad hoc-møte for å definere kolonnene vi trengte å definere vår prosess. Vi debatterte da mengden historier som burde være i hver kolonne. Etter at alt var forsiktig malt og arrangert på veggen, opplevde vi den merkelige følelsen ... tristhet for den gamle, men lykke til den nye.
Vi gjorde noe som mange folk ringer til, Scrum-Ban. Vi holdt noen scrum konsepter, for eksempel skrummester og produkt eier roller, og vi estimerer og evaluerer fortsatt historiene. Men vi fokuserer nå på Lean og Kanban, bevarer strømning, og oppdager og fikser avfall og flaskehalser.
Forandringen fra Scrum til Lean var faktisk frigjørende. Teammedlemmer ble mye mer vennlige med hverandre, og vi forsto at vi burde tilby hjelp så snart det ikke er noe i vår kolonne. Denne følelsen av at utviklere saken fikk oss til å tenke på prosjektet som helhet; Vi bryr meg mer om prosjektet enn vi noensinne har hatt før.
Lean ble ikke alltid vurdert Agile. Selv i dag, nekter noen agilister å anerkjenne det som en agil metodikk. Men flere og flere godtar programmerere Lean som en av de ultimate Agile-metodene.
Som en av mine vise kolleger påpekte, lar Lean og Kanban deg selv følge denne metoden. Så, hvis du er en ensom utvikler og trenger verktøy for å gjøre livet enklere, kan du prøve noen gratis Kanban-verktøy.
AgileZen-nettstedet tilbyr en gratis konto, slik at du sporer et enkelt prosjekt.
Jeg fant det å være et av de beste gratis online Kanban verktøyene; Jeg bruker det til og med hver dag for å spore og planlegge fremdriften av artiklene og kursene som jeg gir for Tuts +. Selvfølgelig kan du alltid oppgradere din AgileZen-konto, hvis du trenger å spore flere prosjekter.
I denne artikkelen har vi gjennomgått Lean og Kanban som en utvikling av Scrum. Betyr dette at Lean er bedre enn Scrum? Absolutt ikke! Det avhenger av prosjektene og menneskene du jobber med. Som alltid, velg Agile-metoden som fungerer best for deg og ditt team.
Accentsconagua