Kanbanin käyttäminen WordPress-kehityksessä

Ajoittain toiset kysyvät, kuinka onnistun järjestämään erilaiset tehtävät, varat, resurssit ja niihin liittyvät asiat projektin aikana. Ensinnäkin olen päättänyt pitää Presswaren pienenä (ja tämä johtuu jostain syystä), joten sen avulla voin käyttää sitä eri tavalla kuin jos se olisi tietysti suurempi.

Toiseksi, käytän tyypillisesti kanban-levyn erittäin pienennettyä versiota. Niille, jotka eivät ole tuttuja, kanban määritellään seuraavasti:

japanilainen valmistusjärjestelmä, jossa komponenttien toimitusta säännellään tuotantolinjaa pitkin lähetettävän ohjekortin avulla.

Tätä varten ajattelin jakaa lyhyen yleiskatsauksen siitä, kuinka tyypillisesti määritän kunkin sarakkeen ja jokaisen kortin sekä työkalut, joita käytän kunkin tehtävän hoitamiseen.

Kanban WordPress-kehityksessä

Yleisesti ottaen jokainen perustamani taulu – ja puhun hetkellisesti näissä käyttämistäni työkaluista – sisältää neljä saraketta, joista jokainen on määritelty seuraavasti:

1. TODO. Tämä on pohjimmiltaan ruuhka tehtävistä, jotka on tehtävä projektin loppuun saattamiseksi. Se on luettelo kaikista vaatimuksista, jotka on yleensä kuvattu työselosteessa , mutta jotka on jaettu tehtäviin, joita voidaan liikkua kunkin sarakkeen läpi nähdäkseen edistymisen.
2. Tekee. Kun kortti on tässä sarakkeessa, se tarkoittaa, että tiimi, joku muu tai minä työskentelen sen parissa. Joskus kortti sisältää useita alitehtäviä (jotka yleensä tunnistetaan valintaruuduiksi), ja pidämme ne ajan tasalla tehtävän tilan mukaan. Pyrin pitämään jokaisen sitoumukseen liittyvän kortin lähdekoodissa niin, että jos meidän on palautettava jotain, siirrämme kortin takaisin sarakkeeseen. Vaihtoehtoisesti, kun olemme tehneet muutoksen, voimme siirtää kortin seuraavaan sarakkeeseen.
3. Arvostelu / Lavastus. Tämä sarake tarkoittaa, että työ on tehty ja se on valmis käyttäjän tarkastettavaksi sivuston esitysympäristössä. Yleensä annan asiakkaille pääsyn tauluun, jotta he voivat tehdä juuri sen. Toisin sanoen he näkevät, milloin jokin on valmis tarkistettavaksi, pääsevät esityspaikalle ja voivat varmistaa, että työselosteessa ja kortissa luetellut vaatimukset ovat valmiita.
4. Valmis. Kun asiakas on varmistanut, että tehty työ on tehty hänen tyydyttävästi, kortti siirtyy Valmis-sarakkeeseen, koodi yhdistetään päähaaraan ja sykli toistuu. Jos tehtävää ei kuitenkaan suoriteta, kortti palaa Doing -tilaan ja liikkuu takaisin liukuhihnaa pitkin, kunnes se on valmis vapautettavaksi.

Nyt kun on kyse projektien parissa työskentelystä, on otettava huomioon yksi toinen näkökohta: omaisuus.

Yksi totuuden lähde

Tarkemmin sanottuna puhun kaikesta, joka vaihtelee:

• fontit,
• mallit,
• kolmannen osapuolen sovellusliittymien kirjautumistiedot,
• kolmannen osapuolen työkalut,
• tai yleensä mikä tahansa muu omaisuus, jota saatetaan tarvita projektin alusta alkaen tai siitä lähtien, kun hankkeen kehittäjät ovat toteuttaneet.

On olemassa pari tapaa käsitellä tätä, ja yritän antaa omaisuuden luonteen sanella, mihin sijoitan asioita. Esimerkiksi suunnitteluresurssit säilytetään usein jaetussa Dropbox-kansiossa tai ehkä kortissa, jos ne ovat pieniä (mutta eivät yleensä ole). Silloinkin voin silti luoda Resurssit – sarakkeen ja listata kortteja, joissa on linkkejä esimerkiksi Dropbox-kansioon.

Hyvin yksinkertainen esimerkki Trellon käytöstä.

Jos se on API:n tunnistetiedot, voin sijoittaa sen Resurssit – sarakkeen korttiin, mutta jos se on jotain arkaluonteista, voin käyttää yksityistä Droplr-muistiinpanoa ja sitten linkittää sen valitsemastani projektinhallintatyökalusta.

Saat kuitenkin idean: Omaisuuden luonne määrittää sen, missä se tallennetaan, mutta kanban-levy viittaa siihen aina jollakin tavalla. Tämä auttaa sitä pysymään yhtenä totuuden lähteenä sinulle ja kaikille osapuolille.

Ja työkaluille?

Luulen, että monet meistä rakastavat kokeilla uutta kiiltävää asiaa. Joillekin se on melkein tapana:

Onko uusi projektinhallintatyökalu julkaistu? Kokeillaan. Toisille, jos on olemassa jokin hyväksi havaittu menetelmä, joka toimii, niin miksi et pysyisi siinä?

Riippumatta siitä, missä olet, mielestäni on tärkeää löytää se, mikä toimii parhaiten sinulle ja tiimillesi, ja sitten käyttää niitä johdonmukaisesti ja ohjelmoivalla tavalla, jota voidaan soveltaa kaikissa projekteissa.

Itselläni on tapana käyttää seuraavia työkaluja:

• Trello- tai GitHub-projektit. Tämä riippuu pitkälti asiakkaasta.
• Dropbox omaisuuden jakamiseen.
• Droplr käyttöoikeustietojen turvaamiseen.
• Google-dokumentit työselvityksiä ja käyttöehtoja varten
• Google-dokumentit kuluraporteille
• Lasku laskuista.
• Eversign for eSignatures yllä oleviin asiakirjoihin.

Tiedän, että joidenkin yllä olevien ohjelmistojen kohdalla jotkut saattavat olla huolissaan turvallisuudesta, etenkin kun se liittyy taloudellisiin tai turvallisiin tietoihin.

Kuva: John Salvino Unsplashissa

En ota tätä kevyesti. Nyrkkisääntö, jota yritän noudattaa, on, että jos se on jotain, joka mielestäni on pidettävä täysin turvassa, käytän asianmukaista järjestelmää käyttääkseni sitä; Muuten, jos se on jotain, jota en todellakaan välitä, jos joku pääsisi käsiksi, se on okei minulle.

Ja mielestäni tämä on tärkeä näkökohta, joka meidän on otettava huomioon tarjotaksemme palvelua muille. Itse asiassa se on luultavasti sisältöä toiselle viestille, ellei koko muulle blogille. Mutta se ei ole tämä viesti eikä tämä blogi – ainakaan nyt.

Minun pointtini?

Varmista lopuksi, että sinulla on seuraavat asiat:

• tapa, jolla sinä ja asiakkaasi voit seurata projektin etenemistä kehityksen elinkaaren ajan,
• tapa, jolla he voivat nähdä, miten asiat menevät, jotka eivät ole avoimesti teknisiä, kuten lähteen hallinta,
• tapa jakaa ja käyttää tarvittaessa,
• kyky kommunikoida ja kysyä tarvittaessa.

Olen varma, että on muita huomionarvoisia asioita, mutta nämä ovat avainasemassa tämän viestin sisällössä. Kanbanin käyttäminen WordPress-kehityksessä ei siis ole vaikeaa, mutta sen taustalla on myös muutama lisäasia, jotka voivat helpottaa prosessia.

Pidä yksi totuuden lähde, jota tukevat kolmannen osapuolen palvelut, jotka tekevät yhteistyöstä helppoa.