Periodicamente, altri mi chiederanno come faccio a organizzare le varie attività, risorse, risorse e cose correlate durante un progetto. Innanzitutto, ho deciso di mantenere il Pressware piccolo (e questo è per alcuni motivi), quindi mi consente di eseguirlo in modo diverso rispetto a se fosse, ovviamente, più grande.
In secondo luogo, in genere utilizzo una versione molto ridotta di una scheda kanban. Per chi non lo conoscesse, kanban è definito così:
un sistema produttivo giapponese in cui la fornitura dei componenti è regolata attraverso l’utilizzo di una scheda di istruzioni inviata lungo la linea di produzione.
A tal fine, ho pensato di condividere una breve panoramica di come in genere configuro ogni colonna e ogni scheda, nonché gli strumenti che utilizzo per gestire ogni attività.
Kanban nello sviluppo di WordPress
In generale, ogni scheda che ho impostato – e parlerò momentaneamente degli strumenti che utilizzo per questi – include quattro colonne ciascuna delle quali è definita come segue:
- FARE. Questo è essenzialmente l’arretrato di attività che devono essere eseguite per completare il progetto. È un elenco di tutti i requisiti che di solito sono delineati nella dichiarazione di lavoro, ma suddivisi in attività che possono spostarsi attraverso ogni colonna per vedere i progressi compiuti.
- Fare. Quando una carta è in questa colonna, significa che la squadra, qualcun altro o io ci stiamo lavorando. A volte una scheda conterrà più attività secondarie (che di solito sono identificate come caselle di controllo) e le teniamo aggiornate con lo stato dell’attività. Cerco di mantenere ogni carta relativa a un commit nel codice sorgente in modo che se dobbiamo eseguire il rollback di qualcosa, spostiamo nuovamente una carta in una colonna. In alternativa, una volta che commettiamo una modifica, possiamo spostare la carta nella colonna successiva.
- Revisione / In scena. Questa colonna indica che il lavoro è stato eseguito ed è pronto per essere rivisto dall’utente nell’ambiente di staging del sito. In genere, concedo ai clienti l’accesso alla bacheca, in modo che possano fare proprio questo. Cioè, possono vedere quando qualcosa è pronto per la revisione, avere accesso al sito di staging e possono verificare che i requisiti elencati nella dichiarazione di lavoro e sulla scheda siano pronti per l’uso.
- Fatto. Una volta che il cliente ha verificato che il lavoro completato è stato eseguito in modo soddisfacente, la scheda si sposta nella colonna completata, il codice viene unito al ramo principale e quindi il ciclo si ripete. Se, tuttavia, l’attività non viene eseguita, la scheda torna a Fare e torna indietro nella pipeline finché non è pronta per il rilascio.
Ora, quando si tratta di lavorare sui progetti, c’è un altro aspetto che deve essere considerato: le risorse.
Un’unica fonte di verità
Nello specifico, sto parlando di qualsiasi cosa che va da:
- caratteri,
- disegni,
- credenziali per API di terze parti,
- strumenti di terze parti,
- o in generale qualsiasi altra risorsa che potrebbe essere necessaria dall’inizio del progetto o da quando gli sviluppatori del progetto.
Ci sono un paio di modi per gestirlo e cerco di lasciare che la natura delle risorse imponga dove metto le cose. Ad esempio, le risorse di progettazione sono spesso conservate in una cartella Dropbox condivisa o forse in una scheda, se sono piccole (ma di solito non lo sono). Anche in questo caso, posso comunque creare una colonna Risorse ed elencare schede con collegamenti alla cartella Dropbox, ad esempio.
Un esempio molto semplice di utilizzo di Trello.
Se si tratta di credenziali per un’API, posso inserirla in una scheda nella colonna Risorse, ma se è qualcosa di sensibile, posso utilizzare una nota Droplr privata e quindi collegarla all’interno dello strumento di gestione del progetto di mia scelta.
Tuttavia, hai un’idea: la natura della risorsa determina dove è archiviata, ma la scheda kanban vi fa sempre riferimento in qualche modo. Questo è ciò che aiuta a rimanere un’unica fonte di verità per te e tutte le parti coinvolte.
E per gli strumenti?
Penso che molti di noi amino provare la nuova cosa brillante. Per alcuni è quasi un’abitudine:
Viene rilasciato un nuovo strumento di gestione dei progetti? Proviamolo. Per altri, c’è se c’è un metodo collaudato che funziona, allora perché non attenersi ad esso?
Indipendentemente da dove cadi, penso che sia importante trovare ciò che funziona meglio per te e il tuo team e quindi utilizzarlo in modo coerente e prescrittivo che può essere applicato a tutti i progetti.
Per me, tendo a utilizzare i seguenti strumenti:
- Progetti Trello o GitHub. Questo dipende in gran parte dal cliente.
- Dropbox per la condivisione delle risorse.
- Droplr per la protezione delle credenziali.
- Documenti Google per dichiarazioni di lavoro e Termini e condizioni
- Documenti Google per le note spese
- Fattura per fatture.
- Eversign per le firme elettroniche sui documenti di cui sopra.
So che per alcuni dei software di cui sopra, alcuni potrebbero essere preoccupati per la sicurezza, soprattutto perché si riferisce a informazioni finanziarie o sicure.
Foto di John Salvino su Unsplash
Non lo prendo alla leggera. La regola pratica che cerco di seguire è che se è qualcosa che penso debba essere mantenuto completamente sicuro, userò un sistema appropriato per usarlo; altrimenti, se è qualcosa a cui non mi dispiace davvero se qualcuno dovesse accedere, allora per me va bene.
E penso che sia una considerazione importante che dobbiamo fare come propile per fornire un servizio agli altri. In effetti, è probabilmente contenuto per un altro post se non per un intero altro blog. Ma non è questo post, né questo blog, almeno non in questo momento.
Il mio punto?
Infine, assicurati di avere quanto segue:
- un modo per te e il tuo cliente di monitorare lo stato di avanzamento di un progetto attraverso il ciclo di vita dello sviluppo,
- un modo per loro di vedere come stanno andando le cose che non sono apertamente tecniche come il controllo del codice sorgente,
- un modo per condividere e accedere secondo necessità,
- la capacità di comunicare e porre domande secondo necessità.
Sono sicuro che ci sono altre cose degne di nota, ma queste sono la chiave del contenuto di questo post. Quindi l’utilizzo di kanban nello sviluppo di WordPress non è difficile, ma è anche supportato da alcune cose aggiuntive che possono semplificare il processo.
Mantieni un’unica fonte di verità supportata da servizi di terze parti che semplificano la collaborazione.