Sistema di ticketing / Fase di sviluppo

Il cambiamento nel modo di pensare è meno lontano dal "tracciamento dei bug e dalla raccolta di idee di miglioramento per le versioni successive" per rendersi conto che la versione in cui stiamo attualmente lavorando era "una versione successiva" a un certo punto.

Siamo arrivati a renderci conto che, per il futuro controllo e manutenzione e per la nostra sanità mentale, "tutto inizia con un biglietto". Requisiti per la versione attuale, bug che sono stati trovati prima, cambiamenti che realizziamo devono essere fatti per pianificare una crescita futura - tutto. Quindi, la prima cosa che fa uno sviluppatore o un progettista, prima di aprire una finestra dell'editor, è assicurarsi che esista un ticket che descriva perché il cambiamento deve essere fatto. Potrebbe essere un puntatore a un documento formale richiesto (dall'azienda o cliente con approvazioni e tutto quel jazz) o solo poche note che normalmente andrebbero perse in un corridoio o in una conversazione via email ("hey, penso che dovremmo fare X a causa di Y "). Poi un po 'di che il cambiamento deve essere aggiunto, che poi inizia a diventare codice.

Questo facilita anche la comunicazione dandoti la possibilità di dire "Sto lavorando sulla funzionalità 12345 oggi" piuttosto che "sai, quella cosa in cui cambio la pagina A in modo che non faccia le cose cattive. "

Una volta che hai ottenuto compiti in un sistema di ticketing di qualche tipo, allora puoi anche applicare il Kanban, lo Scrum o altra metodologia per stabilire le priorità e assegnare tali compiti, in realtà facendo le cose.

Non sono d'accordo sui sistemi di ticketing, possono essere molto utili per le attività. Un buon sistema di ticketing consentirà richieste di funzionalità, bug, categorie di miglioramento. Di cui puoi facilmente tenere traccia, prima del lancio, basta aggiungere un ticket invece di un client / utente. Detto ciò, trac fa bene a questo e offre le "pietre miliari" che dovrebbero essere considerate obiettivi a lungo termine da raggiungere e biglietti a breve termine.

Sono d'accordo che può essere difficile tradurre l'idea generale di un progetto che stai ancora pianificando nei termini di un tracker di problemi. Questo compito può essere reso più semplice dalla comprensione che un "Piano per un progetto" è la stessa cosa di "Una specifica approssimativa per un progetto", che a sua volta è la stessa cosa di "Una raccolta di funzionalità".

Quindi, inizia con le funzionalità che desideri implementare. Puoi inoltre collegare più problemi a ciascuna di queste funzioni, in quanto sai quali modifiche devi apportare per supportare tali funzioni.

Ecco come mi piace avvicinarmi a questo. Una volta che sono arrivato al punto che si , voglio davvero iniziare il progetto, la mia prima azione sarà quella di posizionare il "elevator pitch" come primo ticket nel issue tracker. Di ':

1: A website that makes straighter bacon!

E quasi subito, posso vedere che ho bisogno di alcune cose basilari per iniziare da capo

2: Create a django project (is depended on by 1:)

3: Create some database models for bacon (is depended on by 1:)

4: Design An HTTP method for cooking food. (Is depended on by 1:)

E lavoro con focus laserlike per implementare tutte le funzionalità di cui ho bisogno per creare un progetto che faccia effettivamente quello che dice quel primo biglietto. Essere in grado di chiudere quel primo biglietto e vedere quanto ancora devo andare prima di poter chiudere quel biglietto, è una cosa molto utile e motivante.

Il Kanban è un approccio eccellente in quanto aiuta a tracciare l'arretrato e a mantenere il lavoro scorrevole la strada da percorrere, senza sovraccaricare gli sviluppatori in qualsiasi momento del ciclo. Ogni storia utente ha una serie di attività che possono mostrare lo stato fino al completamento mentre è in fase di sviluppo e le regole aziendali possono far rispettare quante storie possono essere presenti in ogni fase del processo.

Guarda Agile Zen per una buona implementazione di questo concetto come applicazione web.