Index
Documentation Générale Qualité
Documentation Classes Metier
Documentation Liste Qualité Code Review
Documentation Liste Qualité Guideline Development
Documentation Bugs Defaults
Documentation Tests Unitaires
Documentation i18n
Documentation SQL Indexation
Documentation Timeframe

TIME FRAME

Outil et point de repère pour les développeurs et le chef de projets

Introduction        2

Gestion du temps comme un outil        2

Une nomenclature des descriptions dans Toggle plus précise et exploitable        2

Introduction

Les Time Frame permettent d’utiliser la notion de temps comme un outil et un point de repère des difficultés en cours de développement (et pas après), afin d’être réactifs et sereins sur des projets de tailles variables.

Nous allons aussi renforcer la chaîne de conception du chef de projet jusqu’au développeur en améliorant la méthode et les feedbacks.

Un chef de projet avec un background de dev nous rejoint le 1er octobre. Il va venir progressivement développer ce poste et nous aider à améliorer et fluidifier notre organisation et nos process.

Gestion du temps comme un outil

Nous avons introduit un timeframe théorique pour chaque nouveau projet en introduisant une notion de temps approximative ensemble. Le but est d’avoir un point de repère temporel qui va déclencher une réaction du développeur lui-même ou du chef de projet (demande aide/assistance, réévaluation du ticket, analyse du pb rencontré) et ainsi encourager la réflexion créative et pousser les équipes à trouver la bonne solution, sans attendre la fin du projet.

Pour cela chacun aura une visibilité sur un timeframe dans les titres des tickets sous la forme [TFx].

Attention, le but n’est pas de fixer des contraintes de temps théoriques qui seront de toute façon imparfaites, encore moins de vous pousser à négliger le codage pour aller plus vite et rentrer dans le timeframe à la dernière minute.

Le timeframe est un outil, un point de repère pour vous aider à réagir pendant le développement. Pour un timeframe de 4 heures si vous êtes à 6 heures 30 et que vous ne voyez pas le bout de la tâche en cours, que vous avez l’impression de « galérer », c'est surement qu'il vous manque une information ou que le ticket est mal rédigé, il faut revenir vers l’équipe. Appeler le "reporter" du projet et s'il n'est pas dispo, m'appeler moi. Vous pouvez aussi poser la question aux collègues autour de vous en leur demandant leur avis (mais pas très longtemps, 1/2 heure max), si cela n'avance toujours pas, nous appeler.

Les titres des tickets dans Jira font maintenant référence au « TimeFrame » sous la forme « Titre du ticket [TF3] » pour 3 heures environ. Ce temps est une estimation, ce n’est pas une contrainte ferme mais un indicateur. Par exemple, dès la prise en charge des projets vous devrez vérifier les time frames. Premier feedback, si le chef de projet estime qu’il faut environ 2 heures et que vous en analysant vous pensez qu’il en faut 8, c’est le signe qu’il faut en discuter, soit le ticket est mal rédigé, soit on est passé à côté de quelque chose. La notion de TF va permettre d’augmenter les interactions positives avant et pendant le développement puis d’éviter les interprétations qui sont sources d’erreurs.

Une nomenclature des descriptions dans Toggle plus précise et exploitable

Description = CODEPROJET ou EPIC s’il y en a un - Ticket père - Ticket fils - titre du ticket ou détail explicite si pas assez explicite. Se demander à chaque fois, quelles précisions on ajouterait pour permettre à soi-même de pouvoir analyser plus tard le dérouler et la répartition du développement.

exemple : STATUSINSCRIPTION - HTK1483 - HTK-1476 - #2 gestion champ obligatoire pour créer la fiche consultant depuis la liste des inscriptions.

S'assurer que l'on change bien le Toggle quand on change de projet ou qu’on aide un collègue sur un autre projet, systématiquement et en utilisant la nomenclature ci-dessus.