Team software: bug, story e un gate di rilascio
Una modifica software in Tasked non è una semplice scheda colorata. I bug indicano la gravità e i passaggi per riprodurli, le story contengono i criteri di accettazione, le epic contengono le story e il pacchetto software termina con un'approvazione di rilascio senza la quale il sistema non consentirà al lavoro di procedere. La code review può rimandare l'elemento allo stato in corso con l'etichetta modifiche richieste. Il QA può bloccarlo finché non viene eseguita la verifica di accettazione. E niente di tutto questo richiede un plugin.
I tipi di elementi che un team software compila davvero
Un bug richiede la gravità (bloccante, grave, minore o cosmetico), i passaggi per riprodurlo e dove è stato riscontrato. Una story richiede i criteri di accettazione e gli story point. Un'epic richiede un obiettivo e una data target. I campi personalizzati estendono ciascuno di essi quando il team ha bisogno di altro.
La gerarchia è integrata: un'epic contiene story, una story contiene task. Questo viene mostrato chiaramente nell'interfaccia, senza lasciarlo a una semplice convenzione di denominazione.
- Bug: gravità, passaggi per riprodurlo, riscontrato in
- Story: criteri di accettazione, story point
- Epic: obiettivo, data target
Quattro pacchetti, un solo motore
Il pacchetto software gestisce intake, triage, in corso, code review, QA e approvazione di rilascio, per poi passare a completato. Intake e triage hanno ciascuno una finestra di 24 ore. Lo stato in corso prevede 72 ore. La code review è una fase di review di 24 ore. Il QA è un lavoro di 48 ore. L'approvazione di rilascio è una fase di approvazione di 24 ore, di proprietà del product, con lo stato in corso come fase di correzione.
Il pacchetto sprint gestisce backlog, selezionati, in corso, code review, QA e completato; inoltre, lo sprint è un oggetto all'interno del progetto: ha un nome, un obiettivo, un inizio e una fine, con uno solo attivo alla volta. In questo pacchetto non c'è un gate di approvazione, ed è intenzionale: uno sprint che si chiude in completato ha una forma diversa rispetto a una modifica che deve essere approvata formalmente. Il pacchetto bugfix gestisce triage, riproduzione, correzione, verifica e rilasciato. Il pacchetto di rilascio gestisce cut, staging, approvazione finale, produzione e note, con l'approvazione finale come approvazione.
Transizioni che si rifiutano
Una scheda non può lasciare le fasi di intake o triage finché la sua checklist non è completata. La code review prevede un percorso di ritorno allo stato in corso con l'etichetta modifiche richieste. Il QA non può passare all'approvazione di rilascio finché non viene eseguita la verifica di accettazione. L'approvazione di rilascio non può passare a completato finché non viene registrata la decisione. Una richiesta di modifiche in quel gate rimanda l'elemento allo stato in corso.
Questa è la differenza tra una board in cui chiunque può trascinare una scheda in Completato e un workflow in cui lo stato Completato deve essere autorizzato.
Lacune oneste per chi acquista software
Quattro delle lacune precedentemente elencate in questa sezione sono state colmate. Lo sprint è un oggetto con un nome, un obiettivo, un inizio e una fine, uno solo attivo per progetto, e un backlog con tutto ciò che ne è fuori; la chiusura di uno sprint sposta gli elementi non completati a quello successivo o li rimanda nel backlog, registrando quale delle due azioni è stata eseguita. Le etichette sono associate all'elemento e filtrano ogni visualizzazione. Il tempo viene registrato come voci inserite per un elemento nel giorno in cui il lavoro è stato svolto, e si somma al totale della settimana personale e del progetto rispetto alle stime. Il collegamento tra due elementi è tipizzato: correlato, duplicato o clone, lasciando il blocco alla dipendenza che il workflow già rileva.
Ciò che manca ancora è l'hosting del codice. Un revisore può contrassegnare le righe in un diff o in una patch caricata da qualcuno, e la nota compare accanto alle righe corrispondenti. Non è presente un pannello del codice: nulla in Tasked mostra un repository, un branch, una pull request o un commit, e GitHub non è integrato. Non è presente nemmeno un diagramma di Gantt con frecce di dipendenza. Tasked supporta un sottoinsieme limitato di query compatibili con JQL sui campi dei task registrati. Le visualizzazioni salvate continuano a utilizzare alberi di filtri convalidati e il prodotto non implementa la sintassi o le funzioni complete di Jira.
L'API pubblica utilizza chiavi con ambito definito. I webhook includono un registro di consegna. OpenAPI e una pagina per gli sviluppatori descrivono l'interfaccia. Queste funzionalità sono disponibili nel piano Business.
Domande frequenti
- Esiste un oggetto sprint?
- Sì. Uno sprint ha un nome, un obiettivo, un inizio e una fine, con uno solo attivo alla volta per progetto, e tutto ciò che si trova al di fuori dello sprint risiede nel backlog del progetto. La chiusura di uno sprint sposta gli elementi non completati a quello successivo o li rimanda nel backlog, registrando quale delle due azioni è stata eseguita.
- Il gate di rilascio blocca la transizione?
- Sì. Una fase di approvazione avvia l'approvazione al momento dell'accesso e rifiuta l'uscita finché non viene registrata una decisione.
- Una story può contenere dei task?
- Sì. Un'epic contiene story e una story contiene task. Questa gerarchia è integrata nei tipi di elementi di lavoro.
- È disponibile il JQL?
- Tasked supporta un sottoinsieme limitato di query compatibili con JQL sui campi dei task registrati. Non si tratta del JQL completo di Jira; le visualizzazioni salvate memorizzano comunque alberi di filtri convalidati e la ricerca in linguaggio naturale funziona su task, progetti, commenti e file.
- È possibile fare la code review in Tasked?
- Sì, riga per riga, per un diff o una patch caricata da qualcuno: la nota viene ancorata alle righe su cui è stata scritta e compare accanto ad esse. Non c'è alcun collegamento a un hosting di codice, quindi nessun repository, branch, pull request o commit.