Vedta pro-arbeidsflyter nå som WordPress alt er oppvokst

Jeg husker at jeg startet min første WordPress-blogg. Jeg brukte timer på å følge guider på nettet for å laste ned WordPress, prøver å laste den opp igjen og deretter finne ut hvordan jeg skulle sette opp en database.


Jeg bare FTP’ed hver endring helt opp til live-serveren, og håpet bloggen ikke ble mørk hvis jeg feil tastet inn et spørsmålstegn.

WordPress har vokst opp i mellomtiden. Massive medieselskaper bruker WordPress som sin viktigste måte å kommunisere med verden på. Gå til Tech Crunch eller New Yorker og se kilden html. Du finner ut at nettstedet er bygget ved hjelp av WordPress. Beyonce? Jepp. Hun digger WordPress.

På samme tid har WordPress dette forferdelige omdømmet blant utviklere. Stereotypen er av skriptkiddies som laster opp filer via FTP, ikke ved å bruke versjonskontroll og generelt forlate alle fornuftige prinsipper for programvareutvikling kjent for menneskeheten..

Det er klart det ikke er noen rettferdig beskyldning. WordPress har vokst opp. Det blir en fullverdig REST API i år. Du kan nå installere WordPress og avhengigheter fra kommandolinjen ved å bruke WP-CLI.

WordPress-utviklere og temadesignere vokser opp. Roots.io er et eksempel på å behandle WordPress-prosjekter som et seriøst programvareutviklingsprosjekt. De ikke roter seg med dra-n-slipp FTP-opplasting. I stedet bruker de git for versjonskontroll og capistrano for distribusjoner.

Joel av Fog Creek Software skrev kjent om 12 trinn for å bedre programvare, og en av disse var et problem eller en bug tracker. Han har rett. Det er vanskelig å huske alle de forskjellige funksjonsforespørslene og feilene i hodet ditt. Det er enda vanskeligere å huske alle trinnene for å reprodusere feil, hva brukeren forventet og hva de faktisk fikk.

Det er bare så mange post-it-lapper du kan også på skrivebordet ditt. WordPress bruker selv Trac som sin tracker. Jeg har jobbet med Redmine, et annet åpen kildekode-tracker og prosjektstyringsverktøy, fordi jeg er hos Planio, som tilbyr vertskap for Redmine og git-hosting.

Den typiske brukssaken til en problemsporing

Så tenk deg at du bygger en ny plugin for WordPress. Du har et lite team på jobben – en utvikler eller to, en designer og en forretningskar.

Du er ikke lenger et lag med bare én person. Dere jobber ikke alle på ett sted, for fjernarbeid er kjempebra, og den nordlige halvkule er ikke så morsom om vinteren.

En bruker sender inn en e-post med beskjed om at pluginen “ikke fungerer”. Hvis du er virkelig heldig, får du et skjermbilde som viser en feilmelding om “fungerer ikke”.

Du videresender e-posten rundt. Noen e-poster tilbake med et spørsmål om hvilken nettleser de brukte, og plutselig har du en Gmail-tråd på 12 e-poster. Det er noen problemer pakket inn her, og utstedelsessporere hjelper deg å løse disse problemene.

De tre kritiske brikkene til hvert feste

Den første er at du faktisk trenger tre ting for hver feilrapport:

  1. Hvilke trinn tok brukeren som resulterte i feilen?
  2. Hva forventet brukeren å se?
  3. Hva så brukeren faktisk?

Du må kunne reprodusere feilen, fordi det er veldig vanskelig å fikse en feil du ikke kan se i handling. For det andre må du sørge for at feilen faktisk er en feil, eller om brukeren forventet noe programvaren din ikke gir.

Her er en annen måte å si det på:

Og du kan ikke avverge personen som rapporterer feilen med den klassiske linjen: “Det er ikke en feil. Det er en funksjon!”Hvis du ikke vet hva personen forventet i stedet.

Ved hjelp av en issue tracker som Redmine betyr at du har en standardisert måte å motta denne informasjonen på.

Det er en måte du kan sørge for at en oppgave aldri blir gjort: antydet vagt at teamet skulle gjøre noe med det. Med mindre det er tilordnet en “eier”, blir det bare ikke gjort.

Utstedingssporere tvinger deg til å tildele et problem til, vel, en person til enhver tid, slik at du alltid vet hvem som for øyeblikket eier en feil eller oppgave. Samtidig går problemene gjennom en arbeidsflyt med forskjellige statuser, for eksempel “Pågår”, “QA / Testing” eller “Ready for Deployment”.

De fleste trackere vil gi deg rapporter basert på gjeldende status for et problem, slik at du kan se det gjeldende volumet pågår og hvor mye som gjenstår. Du kan til og med lage nedbrent diagrammer, som er popularisert i smidige metoder.

Integrer Git tett i arbeidsflyten for prosjektledelse

Som vi nevnte ovenfor, vil bruk av git i din WordPress utviklingsprosess gjøre livet ditt mye enklere når ting går galt. Git gir deg en spole tilbake-knappen på koden din, og du kan opprette flere, parallelle versjoner av nettstedet ditt.

Hver gang du “begår” ny kode til git-lageret ditt, oppretter du et naturlig poeng for å diskutere endringen av kodebasen. I tillegg synes jeg det er lettere å diskutere problemer basert på faktiske engasjerte koder i stedet for bare vage ideer.

Det er her problemsporere skinner, fordi Redmine, for eksempel, er tett integrert med git eller svn. Du kan raskt se hvem som begikk hva mot saker og deretter diskutere disse spørsmålene.

Lag et system for din WordPress-utvikling

En tracker vil hjelpe deg med å skalere utover bare deg selv. Du vil være sikker på at problemene ikke glir gjennom sprekkene.

Hos Planio bruker flertallet av kundene våre vert Redmine for å spore programvareutviklingsprosjekter, inkludert WordPress-prosjekter. De sporer feil, nye funksjoner og spurter i forbindelse med versjonskontroll.

Redmine er, i likhet med WordPress, åpen kildekode, så du får fordelen av å ikke være låst i proprietær programvare. Og som WordPress, kan du outsource hosting til noen som oss på Planio, eller du kan installere det selv hvis du foretrekker det Redmine.org.

Over til deg

Så – hvordan skal du administrere arbeidsflytene dine? Har du prøvd Redmine? Vi vil gjerne høre tankene og kommentarene dine nedenfor!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map