Kuni viimase aastani põhines üks viise, kuidas ma verstaposte määrasin, suurel määral vaatenurgast, kuidas mina või mu meeskond ja mina pidime projektiga töötama.
Selle lähenemisviisiga on aga probleem: neil meist, kes püüavad klientide tagasisidet kogu arendusprotsessi kaasata, ei ole nii lihtne mõista meie kasutatavat kõnepruuki ja lasta neil sellest siiski aru saada.
Selleks olen hakanud WordPressi projekti verstapostide ulatust veidi erinevalt hindama, et need oleksid veidi kliendisõbralikumad, kuid samas oleks siiski mõtet, kuidas arendajate meeskond saab teha seda, mis on vajalik asjade funktsionaalsuse tagamiseks.
WordPressi projekti verstapostid
Mõelge korraks sellele, millal te viimati vastutasite kohandatud pistikprogrammi loomise või kohandatud funktsioonide integreerimise eest WordPressi projekti. Võib-olla sisaldas see midagi sellist:
- Importige andmed WordPressi andmebaasi,
- Muutke teave WordPressi haldusalas vaadatavaks ja redigeeritavaks,
- Kuvage teave esiotsas ja viisil, mida saab sortida näiteks veeru väärtuste järgi,
- Andmeid saab uuendada mõne muu impordi kaudu või hallata haldusalast,
- Ja võib-olla mõned muud seotud funktsioonid.
Kui soovite selle jagada arendaja kõneks, räägite palju teatud asjadest, mis puudutavad importimist, andmete sõelumist, andmete terviklikkust ja nii edasi. Ja kõik see on 100% õige ja kõik see peaks olema arendaja vaatevinklist.
Kuid kui kasutate projektihaldustarkvara (mille oleme viimasel ajal Asana puhul leppinud ), ei aita seda tüüpi verstapostid kasutajate projekti kaasamisel.
- Kuidas nad peaksid impordiprotsessi üksikasjadest midagi teadma?
- Kuidas nad peaksid mõistma millegi sorteeritava tegemise tehnilisi aspekte?
- Kas on võimalik neile lihtsalt kirjeldada algoritmi, mis on isegi oluline?
Ma ütleks ei. Niisiis, kuidas saaksime WordPressi projekti verstapostid juurdepääsetavamaks muuta? Ma ei tea, kas mu vastus on kindel, kuid see on midagi, mida oleme proovinud ja mis tundub suhteliselt hästi toimivat, kuid see on lihtne:
- Kliendid mõtlevad sageli oma projektidele seoses lehtedega (või millegagi seotud),
- Kuna meie arendajatena saame selles kontekstis töötada, saame määratleda avalikkusele suunatud projekti, et jaotada ülesanded lehekülgede kaupa.
Seega muutuvad WordPressi projekti verstapostid rohkem ülesannete kohta leheküljepõhiselt ja ülejäänud ülesanded "üldisemas" verstapostis.
Sõna tehniliste aspektide kohta
Kõik ülalmainitu toimib hästi, kui klient on projekti teatud osadega seotud, kuid see jätab siiski küsimuse: "Mida me teeme tehnilisemate aspektidega?"
Ja see võib olla kõike alates sellest, kuidas kavatsete korraldada oma liideseid, klasse, meetodeid ja nii edasi, kuni selleni, kuidas kavatsete teatud algoritmi rakendada. Sellest hoolimata on mõte selles, et tuleb läbi viia sügavam tehniline arutelu. Mida me siis nendega teeme, kui arutame WordPressi projekti verstaposte?
Valikuid on mitu:
- Seadistage eraldi verstapost, ülesannete rühm, projektid, arutelu, mis iganes teie süsteem võimaldab, ja hoidke seda enda ja meeskonna vahel.
- Kasutage GitHubi probleeme, GitHubi projekte, wikit, Trellot või mõnda muud süsteemi,
- Hoidke teavet teises rakenduses, mis on saadaval kõigile arendajatele, kuid on kliendist eraldatud.
Muidugi, see tekitab natuke rohkem üldkulusid, kuid olen avastanud, et mida rohkem teavet olete oma projekti osades levitanud, seda edukam projekt võib olla.
Kui teave on välja jäetud, hajutatud, jagamata või üksikasjalik, muutub seda raskemaks hallata, mida projekt edasi läheb, eriti tulevaste iteratsioonide ajal.
Põhimõte on see, et minu arvates on oluline jagada WordPressi projekti verstapostid osadeks, kus klient saab hõlpsasti aru, mis tööd tehakse ja et teil ja teie meeskonnal on võimalus tehtut hallata.
See, kuidas te seda teete, on ilmselgelt teie enda otsustada, kuid ma olen leidnud, et see on seadistamiseks kuluvat aega väärt.