Existe um objeto de sprint?

Sim. Um sprint tem um nome, um objetivo, um início e um fim, estando um deles ativo por projeto de cada vez, e tudo o que está fora de um sprint reside no backlog do projeto. Fechar um sprint transfere os itens inacabados para o seguinte ou de volta para o backlog, e regista qual das duas opções fez.

O gate de lançamento bloqueia a transição?

Sim. Uma etapa de aprovação abre a aprovação na entrada e recusa a saída até que uma decisão seja registada.

Uma story pode conter tarefas?

Sim. Um epic contém stories e uma story contém tarefas. Essa hierarquia está integrada nos tipos de itens de trabalho.

O Tasked suporta um subconjunto limitado de consultas compatíveis com JQL sobre campos de tarefas registados. Não se trata do JQL completo do Jira; as vistas guardadas continuam a armazenar árvores de filtros validadas, e a pesquisa em linguagem natural funciona em tarefas, projetos, comentários e ficheiros.

O código pode ser revisto no Tasked?

Um diff ou um patch que alguém carregue pode sê-lo, linha a linha: uma nota é ancorada às linhas em que foi escrita e aparece ao lado delas. Não existe ligação a um alojamento de código, pelo que não há repositório, branch, pull request nem commit.

Equipas de software: bugs, stories e um gate de lançamento

Uma alteração de software no Tasked não é um cartão com uma cor. Os bugs contêm gravidade e passos para reproduzir, as stories contêm critérios de aceitação, os epics contêm stories, e o pacote de software termina numa aprovação de lançamento que o motor não deixará o trabalho sair sem uma decisão registada. A revisão de código pode enviar o item de volta para em progresso com a etiqueta de alterações solicitadas. O QA pode retê-lo até que a verificação de aceitação seja concluída. Nada disto é um plugin.

Atualizado a 16 de setembro de 20266 min de leitura

Os tipos que uma equipa de software realmente preenche

Um bug solicita a gravidade como bloqueador, grave, menor ou cosmético, os passos para reproduzir e onde foi encontrado. Uma story solicita critérios de aceitação e story points. Um epic solicita um objetivo e uma data-alvo. Os campos personalizados estendem qualquer um deles quando a equipa precisa de mais.

A hierarquia é integrada: um epic contém stories, uma story contém tarefas. Isto é mostrado na interface, não sendo deixado como uma convenção de nomenclatura.

Bug: gravidade, passos para reproduzir, encontrado em
Story: critérios de aceitação, story points
Epic: objetivo, data-alvo

Quatro pacotes, um motor

O pacote de software executa a receção, triagem, em progresso, revisão de código, QA e aprovação de lançamento, depois concluído. A receção e a triagem têm, cada uma, uma janela de 24 horas. Em progresso tem 72 horas. A revisão de código é uma etapa de revisão de 24 horas. O QA é trabalho de 48 horas. A aprovação de lançamento é uma etapa de aprovação de 24 horas, pertencente ao produto, com em progresso como a etapa de retrabalho.

O pacote de sprint executa o backlog, selecionado, em progresso, revisão de código, QA e concluído, e um sprint é também um objeto no projeto: um nome, um objetivo, um início e um fim, estando um deles ativo de cada vez. Não existe nenhum gate de aprovação nesse pacote, de propósito: um sprint que fecha em concluído tem um formato diferente de uma alteração que deve ser assinada. O pacote de correção de bugs executa a triagem, reprodução, correção, verificação e lançado. O pacote de lançamento executa o corte, staging, assinatura, produção e notas, com a assinatura como a aprovação.

Transições que recusam

Um cartão não pode sair da receção ou triagem até que a sua lista de verificação esteja concluída. A revisão de código tem um caminho de volta para em progresso com a etiqueta de alterações solicitadas. O QA não pode entrar na aprovação de lançamento até que a verificação de aceitação esteja concluída. A aprovação de lançamento não pode entrar em concluído até que a decisão seja registada. Um pedido de alterações nesse gate devolve o item para em progresso.

Essa é a diferença entre um quadro onde qualquer pessoa pode arrastar um cartão para Concluído e um fluxo de trabalho onde Concluído é permitido.

Lacunas honestas para compradores de software

Quatro das lacunas que esta secção costumava listar estão fechadas. Um sprint é um objeto com um nome, um objetivo, um início e um fim, um ativo por projeto, e um backlog de tudo o que está fora dele; fechar um sprint transfere os itens inacabados para o seguinte ou de volta para o backlog, e regista qual das duas opções fez. As etiquetas residem no item e filtram todas as vistas. O tempo é registado como entradas introduzidas num item no dia em que o trabalho foi realizado, e soma-se a uma semana pessoal e a um total do projeto face às estimativas. Uma ligação entre dois problemas é tipificada: relaciona-se, duplica ou clona, com o bloqueio deixado para a dependência que o fluxo de trabalho já lê.

O que ainda falta é o alojamento de código. Um revisor pode marcar linhas num diff ou num patch que alguém carregue, e a nota aparece ao lado das suas próprias linhas. Não existe aqui um painel de código: nada no Tasked mostra um repositório, um branch, um pull request ou um commit, e o GitHub não está integrado. Um gráfico de Gantt com setas de dependência também não está aqui. O Tasked suporta um subconjunto limitado de consultas compatíveis com JQL sobre campos de tarefas registados. As vistas guardadas continuam a utilizar árvores de filtros validadas, e o produto não implementa a gramática ou funções completas do Jira.

A API pública utiliza chaves com âmbito. Os webhooks vêm com um registo de entrega. O OpenAPI e uma página de programadores descrevem a superfície. Estes estão no plano Business.

Perguntas frequentes

Existe um objeto de sprint?: Sim. Um sprint tem um nome, um objetivo, um início e um fim, estando um deles ativo por projeto de cada vez, e tudo o que está fora de um sprint reside no backlog do projeto. Fechar um sprint transfere os itens inacabados para o seguinte ou de volta para o backlog, e regista qual das duas opções fez.
O gate de lançamento bloqueia a transição?: Sim. Uma etapa de aprovação abre a aprovação na entrada e recusa a saída até que uma decisão seja registada.
Uma story pode conter tarefas?: Sim. Um epic contém stories e uma story contém tarefas. Essa hierarquia está integrada nos tipos de itens de trabalho.
Existe JQL?: O Tasked suporta um subconjunto limitado de consultas compatíveis com JQL sobre campos de tarefas registados. Não se trata do JQL completo do Jira; as vistas guardadas continuam a armazenar árvores de filtros validadas, e a pesquisa em linguagem natural funciona em tarefas, projetos, comentários e ficheiros.
O código pode ser revisto no Tasked?: Um diff ou um patch que alguém carregue pode sê-lo, linha a linha: uma nota é ancorada às linhas em que foi escrita e aparece ao lado delas. Não existe ligação a um alojamento de código, pelo que não há repositório, branch, pull request nem commit.