sinra

Tous les écrans, avant de vous inscrire.

L'interface réelle de Sinra, capturée dans l'application. Données de démo, écrans non retouchés.

Cycle en cours : dates, progression des statuts et du temps, nombre d'issues, et la liste des issues groupée par statut.
Le cycle dans lequel votre équipe travaille en ce moment : où en sont les dates, où en est le travail, et toutes les issues en dessous.

Suivez le produit, étape par étape.

Le rail ci-dessous reprend le Workflow de la barre latérale de Sinra, de la spec au retour d'expérience. Ce que vous voyez ici est ce que vous avez dès le premier jour.

Specify
Refine
Plan
Build
Verify
Learn
Le Spec Pipeline : les capacités en colonnes selon l'état de rédaction de leur spec.
Où en est chaque spec, en un regard : à rédiger, en cours, en relecture, prête. Glissez une carte pour changer son état.
Deux workflows

La rédaction et le développement avancent en parallèle

Tous les autres outils donnent un seul statut à une issue. Sinra lui en donne deux : où en est la spécification, et où en est le code. Vous construisez les deux listes vous-même.

  • Le produit rédige pendant que les développeurs construisent
  • Aucune issue n'attend sur un statut qui veut dire deux choses à la fois
  • Une spécification peut être terminée bien avant la branche
Statut de rédaction et statut de développement configurés en deux listes distinctes.
Charge

Vous découvrez qu'une personne est surchargée avant le début du cycle

Sinra additionne le temps estimé par personne et par équipe, et le compare à la disponibilité que vous définissez. L'alerte arrive pendant la planification.

  • Disponibilité par personne, par équipe, en pourcentage
  • Estimé confronté à la capacité réelle, par cycle
  • Le dépassement est affiché, pas noyé dans un total
Charge par personne confrontée à la capacité sur un cycle.
Spécification

La rédaction des spécifications a son propre tableau

Les product owners suivent les spécifications comme les développeurs suivent le code : groupées par capacité, filtrées par release.

  • Des colonnes par statut de rédaction
  • Groupées par capacité : une fonctionnalité en retard saute aux yeux
  • Glissez une carte pour changer son statut
Tableau du pipeline de spécifications groupé par capacité.
Qualité

Les tests sont rattachés à ce qu'ils vérifient

Un cas de test pointe vers une capacité et ses critères d'acceptation. Une release ne peut pas se déclarer prête quand ses tests disent le contraire.

  • Des templates de test réutilisables
  • Un testeur nommé, dont la charge est comptée
  • L'acceptation enregistrée au niveau de la release
Un cas de test avec son périmètre, ses étapes, son résultat attendu et son statut d'acceptation.

Et tout le reste.

Tout ce qui suit est livré dans le même compte. Rien ici n'est une option ou un palier payant.

Projets Vue long terme des capacités planifiées
Tous les cycles Passés, en cours et planifiés, dans une seule liste
Édition en masse Changer le statut ou la release sur toute une sélection
Pages Documentation, organisée par catégorie
Templates Pages, issues et tests réutilisables
Recherche globale Shift + F, depuis n'importe où
Labels Sur les issues, les capacités et les tests
Plateformes Là où tourne votre produit
Catégories La structure de la base de connaissances
Équipes et rôles Responsabilité, permissions et disponibilité
Notifications Mentions et assignations
Jetons API Pour vos propres intégrations