Sprejem Pro procesov Zdaj, ko je WordPress vse odrasel

Spomnim se, da sem ustanovila svoj prvi WordPress blog. Kar nekaj ur sem sledil vodičem po spletu, da sem naložil WordPress, poskušal ga naložiti še enkrat in nato ugotovil, kako nastaviti bazo podatkov.


Pravkar sem FTP spremenil vsako spremembo vse do strežnika v živo in upal sem, da blog ne bo potemnel, če sem napačno vtipkal vprašalnik.

WordPress je medtem zrasel. Množična medijska podjetja uporabljajo WordPress kot svoj glavni način komunikacije s svetom. Pojdite na Tech Crunch ali New Yorker in si oglejte izvorni html. Ugotovili boste, da je spletno mesto izdelano s pomočjo WordPress-a. Beyonce? Ja. Kopa WordPress.

Obenem ima WordPress ta grozljiv ugled med razvijalci. Stereotip je, da otroci, ki uporabljajo skripte, nalagajo datoteke prek FTP, ne uporabljajo nadzora različic in na splošno opuščajo vsak razumen princip razvoja programske opreme, ki ga pozna človeštvo.

Očitno ni poštena obtožba. WordPress je zrasel. Dobiva polnopravnost REST API to leto. Zdaj lahko s pomočjo ukazne vrstice namestite WordPress in odvisnosti WP-CLI.

Razvijajo se WordPress razvijalci in oblikovalci tem. Roots.io je primer obravnave projektov WordPress kot vseh resnih projektov za razvoj programske opreme. Z nalaganjem FTP z vlečenjem n-drop se ne spopadajo. Namesto tega uporabljajo git za nadzor različic in capistrano za uvajanje.

Joel of Fog Creek Software je slavno pisal o 12 korakov do boljše programske opreme, in ena od teh je bila težava ali sledilnik napak. Prav ima. Težko si je zapomniti vse različne zahteve po funkcijah in napake v vaši glavi. Še težje si je zapomniti vse korake za razmnoževanje hroščev, kaj je uporabnik pričakoval in kaj v resnici imajo.

Tudi na vaši mizi je samo toliko beležk, ki jih lahko objavite. WordPress sam uporablja Trac kot njegov sledilnik izdaje. Sodeloval sem z Redmine, še enim orodjem za sledenje izdaje in odprtokodnim orodjem za upravljanje projektov, saj sem v podjetju Planio, ki ponuja gostovanje Redmine in git gostovanja.

Tipični primer uporabe sledilca težav

Predstavljajte si, da gradite nov vtičnik za WordPress. Na delu imate majhno ekipo – razvijalca ali dva, oblikovalca in poslovnega fanta.

Nisi več ekipa samo ene osebe. Ne delate vsi na enem mestu, saj je delo na daljavo super in severna polobla pozimi ni tako zabavna..

Uporabnik po e-pošti pošlje sporočilo, da vtičnik “ne deluje”. Če imate res srečo, se vam prikaže posnetek zaslona, ​​ki prikazuje sporočilo o napaki »ne deluje«.

E-pošto posredujete okoli. Nekdo pošlje e-poštna sporočila z vprašanjem, kateri brskalnik uporabljajo, in kar naenkrat imate Gmail nit 12 e-poštnih sporočil. Tu je zapletenih nekaj težav, ki jih lahko rešujejo.

Trije kritični deli vsake popravljive napake

Prva je, da dejansko potrebujete tri stvari za vsako poročilo o napaki:

  1. Katere korake je uporabnik storil, kar je povzročilo napako?
  2. Kaj je uporabnik pričakoval, da bo videl?
  3. Kaj je uporabnik dejansko videl?

Morate biti sposobni reproducirati hrošče, ker je res težko popraviti napako, ki je ne vidite v akciji. Drugič, prepričati se morate, da je napaka dejansko napaka ali ali je uporabnik pričakoval, da vaša programska oprema ne zagotavlja.

Tu je še en način:

In osebe, ki poroča o napaki, ne morete odkriti s klasično vrstico: “To ni hrošček. To je funkcija!“Če ne veste, kaj je oseba namesto tega pričakovala.

Uporaba sledilca težav, kot je Redmine pomeni, da imate standardiziran način prejemanja teh informacij.

Obstaja en način, kako lahko zagotovite, da se naloga nikoli ne bo končala: nejasno je predlagal, naj ekipa nekaj stori v zvezi s tem. Če ni dodeljen enemu “lastniku”, tega preprosto ne bomo storili.

Sledilniki izdaje vas prisilijo, da težavo dodelite eni osebi kadar koli, tako da vedno veste, kdo ima trenutno napako ali nalogo. Hkrati se težave pojavljajo skozi delovni tok različnih stanj, kot so “V teku”, “QA / testiranje” ali “Pripravljen za uporabo”.

Večina sledilcev vam bo dala poročila glede na trenutno stanje težave, tako da si lahko ogledate trenutni obseg dela, ki je v teku, in koliko jih še morate storiti. Ustvarjate lahko celo grafikone izgorelosti, ki so popularizirani v agilnih metodologijah.

Tesno vključite Git v delovni potek upravljanja projektov

Kot smo že omenili, bo uporaba gita v vašem razvojnem procesu WordPress olajšala vaše življenje, ko stvari gredo narobe. Git vam daje gumb za navijanje nazaj na kodi in lahko ustvarite več vzporednih različic spletnega mesta.

Vsakič, ko novo kodo »zavežete« v svojem git repozitoriju, ustvarjate naravno točko za razpravo o spremembi zbirke kod. Poleg tega se mi zdijo lažje razpravljati o težavah na podlagi dejanske predane kode, ne pa samo o nejasnih idejah.

Zato zasledujejo sledilci vprašanj, ker je na primer Redmine tesno povezan z git ali svn. Hitro lahko vidite, kdo je storil nasprotovanje in nato razpravljal o njih.

Ustvarite sistem za svoj WordPress razvoj

Sledilnik težav vam bo pomagal doseči več kot samo vas. Prepričani boste, da težave ne zdrsnejo skozi razpoke.

V podjetju Planio večina naših kupcev uporablja naš gostilnik Redmine za sledenje projektom razvoja programske opreme, vključno s projekti WordPress. Spremljajo napake, nove funkcije in šprinte v povezavi z nadzorom različic.

Redmine, tako kot WordPress, je odprtokodni, zato lahko izkoristite to, da niste zaklenjeni v lastniško programsko opremo. Tako kot WordPress, lahko gostujoče storitve oddate nekomu, kot smo mi, v Planio, ali pa ga sami namestite, če želite Redmine.org.

Nazaj k tebi

Torej – kako upravljate s svojim delovnim tokom? Ste poskusili Redmine? Spodaj bi radi slišali vaše misli in komentarje!

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