INFOTEL VOUS REMERCIE POUR VOTRE CANDIDATURE

Un chargé de recrutement prendra contact avec vous prochainement.

LES RECETTES DU COACH AGILE #3

LES RECETTES DU COACH AGILE

Comment et pourquoi visualiser la dette technique ?

C’est une question qui revient très souvent dans les équipes : doit-on estimer et compter la dette technique dans la vélocité ? La réponse n’est pas si simple et en tant que Scrum Master, tous les yeux risquent de se tourner vers vous pour une parole sage.

La dette technique ?

La dette technique représente toutes ces choses que nous n’avons pas voulu, ou pas pu faire.

 

Par exemple, le Product Owner a accepté que des histoires soient considérées comme Done malgré que les critères d’acceptation ne soient pas tous validés, anomalie, ou que tous les critères de la définition du Done ne soient pas cochés, ou bien encore que le code génère un bug mineur.

Une anomalie est créée lorsqu’une fonctionnalité ne correspond pas à ce qui avait été défini par le Product Owner, comme un critère d’acceptation non valide.

Un bug est un problème qui est créé par une modification du code, souvent en dehors de son périmètre – par influence – alors que le code en lui-même, réponds parfaitement à la fonctionnalité et aux critères d’acceptation.

Toutes ces choses devront être faites, un jour. L’équipe gagne donc du temps aujourd’hui, pour le payer plus tard. Vous créez de la dette technique.

Compter la dette technique dans la vélocité

Certaines équipes estiment et tiennent compte de cette dette. Par exemple, si la vélocité moyenne est de 30 points par Sprint et que l’équipe s’accorde sur le fait de résorber l’équivalent de 10 points de dette, alors, ils devront répartir les 20 points restants dans les histoires fonctionnelles.

La bonne et la mauvaise vélocité

Si la vélocité reste constante, la valeur fonctionnelle ajoutée au produit, diminue. Il est donc important de garder un moyen de différencier les deux. Comme le cholestérol, il y a un bon et un mauvais, ici c’est pareil, il faut donc se surveiller. Vous pouvez profiter du BurnUp chart pour faire apparaître la différence entre les deux.

Bien que la vélocité reste constante, la dette technique est visible et apporte de l’information.

Ne pas compter la dette technique dans la vélocité

À l’opposé, il est possible de ne pas comptabiliser la dette technique. L’avantage certain est la mise en lumière rapide et immédiate de son impact, paradoxalement.

1 – Non estimée

Ce cas est plus délicat. Bien que la chute de vélocité soit visible et qu’il est toujours possible d’ajouter une note au BurnUp, le Product Owner ne pourra pas se projeter sur l’impact du remboursement et aura donc des réticences à prioriser dans le flou. Nous voyons ici une chute spectaculaire de la vélocité de l’équipe (pointillés bleus). Presque rien (de valeur pour l’utilisateur) n’a été produit pendant une période – la ligne rouge, plate – mais on ne visualise pas la raison.

2 –Estimée

Il est important de montrer pourquoi la vélocité a chuté. Si vous avez estimé la dette sans la compter, vous pouvez utiliser le type de BurnUp du précédent paragraphe, mais avec cette foisci la ligne de la vélocité. C’est la méthode que je recommande.

Par Robin

banque

Banque

Traitement automatisé des demandes de prêt et simplification du KYC "Know Your Customer".

Fonctionnement

  • Amélioration du KYC et embarquement des clients en vérification automatiquement l'identité des nouveau clients grâce au traitement intelligent des documents d'identité sur le web ou dans une application.
  • Accélération des demandes de prêts et d'hypothèques : traitement et classification automatique des documents entrants, extraction des informations et validation des points de données.
  • Prévention de la fraude et respecte des règles : automatisation des contrôles de conformité réglementaire sur les contrats, les documents financiers et les documents d'identité.
  • Facilitation et simplification de la compréhension des dépenses des consommateurs : classification des transaction bancaires en lisant les données des postes de reçus et de factures.
Brevets

Brevets

Traitement automatisé des documents scientifiques et autres documents liés au dépôt de brevet pour la propriété intellectuelle.

Fonctionnement

  • Reconnaissance et indexation automatique des champs pour une recherche précise parmi les documents relatifs au dépôt de brevet.
  • Uniformisation des documents en lien avec les spécifications qui sont ainsi mis à jour : bibliographie, brevet expiré, brevet renouvelé, etc.
Comptabilité

Comptabilité

Traitement automatisé des reçus, factures et autres documents financiers etc.

Fonctionnement

  • Automatisation des processus comptable : réconciliation des comptes bancaires, déclaration de TVA, saisie des factures fournisseurs.
  • Standardisation et harmonisation des processus comptables de l'entreprise.
  • Sécurisation de la qualité des données en supprimant les erreurs manuelles et en synthétisant les contrôles.
  • Contribution à la réduction des risques de fraude, renforcement de la sécurité des opérations, la pise d'audit et le contrôle interne.
  • Accompagnement dans la conduite du changement et des équipes comptables sur l'appropriation de cette nouvelle solution.