Share
Con uno strumento potente come Pivotal Tracker, a volte può essere difficile capire come usarlo a tuo vantaggio. E anche se non pretendiamo di avere tutte le risposte, il tempo che abbiamo trascorso nel profondo e sporco con Tracker ci ha dato un buon punto di osservazione da cui trarre le migliori pratiche da quelle ... meno belle.
Ecco, quindi, sono quelle che consideriamo alcune pratiche guida per ottenere il massimo dal frutto del Tracker e per il successo Agile in generale.
La lingua è fluida e soggetta a interpretazione, quindi cerca di non utilizzare una storia di Tracker come supporto per una conversazione. Prendi in considerazione la possibilità di realizzare una procedura di progettazione di una storia o di un progetto con il supporto e i tester, in modo che possano aiutare con diverse prospettive sull'utilizzo e le richieste dei clienti.
I commenti della tua storia si accumulano? Fai in modo che le persone si uniscano brevemente per esaminare i problemi, quindi aggiorna la storia con i punti chiave. Discutere di persona in prima persona può ridurre al minimo le incomprensioni che possono facilmente diventare distrazioni o perdite di tempo.
Ogni volta che è possibile, i clienti e gli sviluppatori devono scrivere storie insieme perché una storia è sia un valore aziendale del cliente che un risultato da sviluppatore. In questo modo, gli interessi e i punti di vista di tutti possono essere condivisi e allineati.
Conduci una riunione di pianificazione dell'iterazione settimanale in modo che il team possa esaminare e valutare le storie future. Sviluppa stime come gruppo, in modo che tutti possano essere ascoltati. Per rendere il processo più leggero, puoi giocare a un gioco di stima. Non suggeriamo Settlers of Catan per questo. Invece, prova qualcosa di più simile a Rock, Paper, Scissors.
Per stimare una determinata storia, chiedi a ciascun membro del team di scartare le dita, in linea con la scala di stima che hai scelto, per indicare il loro suggerimento per la complessità della storia. Tutti stimavano lo stesso? Grande! In caso contrario, iniziare una discussione e stimare la storia insieme.
Creare storie che siano incrementali e focalizzate sulla prospettiva dell'utente. Quindi, se hai bisogno di riparare un muro di mattoni, prova a concentrarti sull'interazione dell'utente con un aspetto specifico del muro, non sull'intero muro stesso. La trama, "Il muro dovrebbe essere in buone condizioni", sarebbe più utile in quanto "il passante non dovrebbe vedere crepe visibili nel muro".
Allo stesso tempo, alcune storie saranno più grandiose o più complicate nonostante le migliori intenzioni. Dovresti comunque cercare di minimizzarlo e riservare la pratica solo a storie di portata non chiara o enorme, e poi scomporle. Altrimenti, una stima di 8 (basata sulla scala di Fibonacci) è un grido di aiuto.
Come sviluppatore, dovresti chiedere chiarimenti e cercare giunture in cui la storia può essere suddivisa in più storie.
Dirigere la nave e contemporaneamente riparare una perdita è una sfida, per non dire altro. A tal fine, dovresti avere un Czar Tracker, che non dovrebbe essere codificato nel progetto che possiedono. Possedere un progetto è una grande responsabilità, ma fa una grande differenza.
Mentre è vero che chiunque può creare storie e metterle nell'Icebox, solo il cliente (o un PM che agisce per conto del cliente) dovrebbe dare la priorità a loro.
In qualità di proprietario dell'azienda, parte del processo decisionale del cliente è decidere quali funzionalità hanno la priorità rispetto ad altre. In altre parole, il cliente dovrebbe fare le scelte difficili.
Trasformare le faccende in feature le ridefinisce come elementi di valore diretto e verificabile sia per l'utente finale che per gli obiettivi del progetto. Questo potrebbe semplicemente essere una questione di riformulare la storia, o di argomentare più strenuamente per il suo valore aziendale.
Non riavviare mai una storia accettata; invece, crea una nuova storia o bug. È più pulito, puoi mantenere le nuove informazioni più mirate e non toglie nulla al lavoro già svolto. Puoi sempre incollare l'URL alla storia originale per il contesto.
Rifiutare una storia con tatto e chiarezza può essere una sfida, ma ci sono alcune strategie per farlo andare più facilmente.
Se non ti trovi a bordo con una determinata funzione o storia, aggiungi il tuo commento con "reject:": è più facile scansionare e capire quale commento è correlato al rifiuto.
Dopotutto, potrebbe esserci di più qui di quanto non sembri. Ancora una volta, parla. Rivalutare ciò che manca e creare una nuova storia; non limitarti a rifiutarlo senza conoscere tutti i dettagli.
Posizione, posizione, posizione: è di fondamentale importanza. Sposta una storia rifiutata nella parte superiore del gruppo attivo nell'iterazione corrente. Quando gli sviluppatori cercano di vedere la prossima storia su cui lavorare, vedranno la storia rifiutata come la prossima a raccogliere.
Anche se non esiste un modo verificabile in maniera universale per utilizzare Pivotal Tracker per lo sviluppo Agile, e sebbene possa supportare una varietà di approcci, il tempo e l'esperienza ci hanno dimostrato che alcune pratiche hanno più senso.
Se avete domande o feedback per noi, ci piacerebbe sapere da voi! Per ulteriori informazioni, visitare il nostro sito Web o contattarci all'indirizzo [email protected].
Accentsconagua