Disclaimer

Histoire que l’on parle bien de la même chose. Ce que j’appellerai bug est bien un bug. C’est à dire que ce n’est pas une incompréhension entre MOA et MOE, ni un must have, ni un nice to have, ni une demande d’amélioration. Un bug est un dysfonctionnement, ou une anomalie directement liée au code en place.

Un bug (de l’anglais bug, « insecte ») ou bogue est, en informatique, un défaut de logique dans un programme informatique qui provoque un calcul ou un traitement incorrect à l’origine de dysfonctionnements et de pannes.

La gravité du dysfonctionnement peut aller de bénigne (défauts d’affichage mineurs) à majeure (explosion du vol 501 de la fusée Ariane 5). On ne qualifie de bug qu’un problème confirmé du logiciel lui-même, le fait technique ou anomalie logicielle désignant plus largement tout comportement inattendu, soupçonné d’être une déficience.

Les bugs résultent d’erreurs de programmation. L’erreur peut résider dans un logiciel applicatif, dans les logiciels tiers utilisés par ce logiciel applicatif, voire dans le micrologiciel d’un composant matériel comme ce fut le cas du bug de la division du Pentium. Un patch (francisé enrustine) est un morceau de logiciel destiné à corriger un ou plusieurs bugs.

Le terme bug est un terme familier et usuel. Dans le monde professionnel, avec des variantes selon la culture de l’entreprise, on préfère utiliser des termes comme fait technique, défaut (software defect), non-conformité, etc. http://fr.wikipedia.org/wiki/Bug_informatique

Quelle importance accorder à un bug?

En fonction de l’état d’avancement du projet et suivant les méthodes de développement (waterfall, V, agile, etc) on est régulièrement confronté à des remontés de bugs. soit pendant la période de recette, soit les bugs relevés par l’équipe de testeur sur le sprint précédent, voir encore si l’application ou le site est en production, une remonté de bug par un utilisateur ou un client.

Ces flux de bugs sont assez perturbants puisqu’on ne sait pas quand est ce qu’ils vont arriver! Et le plus souvent on est en train de travailler sur autre chose…La première chose à ne pas faire est de vouloir le traiter immédiatement. Il faut au moins finir la tache sur laquelle nous étions en train de travailler. Imaginez le temps nécessaire au double switch tache -> bug, bug -> tache…

Une fois que la tâche en cours a été fini, on peut enfin se plonger à fond dans ce putain de bug :p Et la première chose à faire est d’évaluer le temps qu’il vous faudra pour le fixer.  Si vous jugez que c’est un bug majeur il vaut mieux ne pas le résoudre dans l’immediat et le planifier. Peut être qu’en terme de priorité il passera devant tout le reste mais la question mérite d’être posée. Ensuite, le bug peut être long à corriger. Un bug important mais long, ca arrive…Là aussi, on va le planifier. Autrement dit, seuls les bugs dont le temps de corrections est relativement court (disons de l’ordre de l’heure) devraient être fixés immédiatement.

Pour gagner un peu plus en productivité et ne pas en oublier je vous conseille de vous réunir avec votre équipe pour définir un process (bouh c’est maaal) pour la gestion des bugs. Où sont -ils collectés, utilise t-on un outils de bug tracking pour suivre l’état des bugs, une personne est elle chargé de les collecter, bref autant de questions qu’il vaut mieux se poser avant pour ne pas qu’elle viennent vous polluer l’esprit au moment où les bugs surgiront…

Un jour mon père m’a dit : « la NASA envoi ses navettes dans l’espace avec un dictionnaire de correctifs de bugs (comment réagir face à tel ou tel bug), et quand on connait le prix du kilo envoyé dans l’espace… ». A méditer.

Comment traiter le bug?

Maintenant qu’on sait quoi faire face à ce bug (à traiter immédiatement, ou plannifier), les ennuis commencent! Là aussi on peut être confronté à plusieurs ca…ou plutôt devrais je dire plusieurs « cas de conscience ». Parce qu’on est bien d’accord, dans l’idéal, ou l’absolu, un bug : ca se fix! Mais parfois, suivant le projet, le client, les coûts de corrections , les délais, on peut être amener à emprunter un autre chemin…Au lieu de fixer ce vilain truc, on va le cacher. Plutôt que d’apporter des modifications importantes au code, on va faire en sorte que ce bug ne soit pas produisible. Un auto haking en règle.

Je n’ai pas de réponse universelle à ce sujet. Mais personnellement je ferais dans presque 100% des cas l’effort de corriger le bug. Même si je dois tout casser. Une seule raison :

• cacher plutôt que fixer obligera à construire le reste sur une partie de code bancale (la fameuse dette technique). On pourrait comparer ces zones d’ombres du code aux actifs pourri que les états rachètent aux banques : un jour ca vous pète à la gueule.  On ne sait pas quand, ni même si ca arrivera. Mais le jour où cela arrivera, vous pouvez être sur d’une chose : cela coutera beaucoup, beaucoup plus cher de réparer les dégats que si le bug avait été fixé sur le moment…

Mais ça c’est uniquement mon avis Il arrive parfois qu’après discutions, j’ai fais le choix de cacher le bug (pas souvent cependant ). En effet, un délai hyper serré à tenir (une mise en prod’, typiquement) et le choix de coeur passe à l’as (ohoh joli). Après la release il sera temps de le fixer correctement (ou pas…toujours plus vite, plus vite…).

En fait, au fond je pense que la réponse à cette question est étroitement liée à d’autre pratique (agile?) telle que le courage (ne pas hésiter à casser du code) et le refactoring permanent. Bref j’ai un peu du mal à trouver des arguments pour le « cachage » de bug hormis celui des délais…

Je suis donc tout ouïe pour connaitre vos avis sur la question!

• [agilité scrum] difficulté de mise en place des méthodes agiles
• [ecole] à coté de la plaque?
• [stage] la course est lancée
• [new] bonne année et actualités du blog
• [sport management] Des similitudes : la taille (1/3)
• [VACANCES] pas longues mais quand même!
• [auto-promo] application facebook : le quizz du vin
• [gestion] liste d’outils de gestion de projet by smashing mag
• MrBoo voit juste! Mais les autres…
• [MySQL] Certifications en vue

Alors on attaque le discours avec les indicateurs agiles, le bien être de l’équipe, l’augmentation en compétences (dans le cas d’XP), le processus itératif qui permet d’être réactif, etc etc…

Après ces quelques dizaines heures de discussions, il se peut que vous ayez convaincus et que l’agilité prenne un peu de place dans votre quotidien. La première épreuve est passée, bravo!

Alors là on se frotte à un des débats récurrents : que veux dire « épreuve passée » (ou encore « story finie », « done », etc etc). Soit les gens que vous avez essayé de convaincre, voir de persuader (oui les managers ont des sentiments!!), s’impliquent totalement dans l’acquisition et la mise en place de ses nouvelles méthodes. Auquel cas l’épreuve est vraiment passée et les éventuelles difficultés qui arriveront ensuite seront assumées et partagées par l’ensemble des collaborateurs. Soit (ah enfin, le deuxième cas..celui qui pue), vos collaborateurs vous ont écoutés, ont été séduits et vous ont laissés « carte blanche ». Et là ça pue. Sur le moment non. Une grande satisfaction vous envahit, « oui j’ai réussi, j’ai évangélisé!! ». Hélas. Ce n’est que le début d’un long parcours pas nécessairement voué à la réussite.

Les premières semaines, les premiers sprints, dans l’enthousiasme général tout se passe bien. Normalement le burnup ne ressemble a rien mais il y a des prémices d’indicateurs, l’équipe est sur – éxitée (travail en binôme, objectif clair, court et atteignable, livraison régulière avec démo,etc…). Tout est beau dans le meilleur des mondes.

Puis premier accro. Un peu de retard sur un sprint (comme si c’était nouveau dans le monde de l’informatique ). Un scrum master qui découvre, un product owner absent, des binômes qui ne tournent pas assez, (on peut tout imaginer pour finir cette ligne). A un moment ça chie. Et là….malheur!!

Tout est remis en cause. « L’agilité ça ne marche pas! » « Avant ça fonctionnait! » « Quand est-ce que ca marchera? En plus tu ne sais pas? ». Ah….le « quand »! C’est la qu’intervient la citation qui m’a donnée envi d’écrire ce billet :

Beaucoup de gens souhaitent appuyer sur un bouton et magiquement devenir agile. Ils désirent bénéficier de tous les avantages sans avoir à fournir le gigantesque effort qui accompagne la transformation réelle de l’organisation. Les gens pensent que parce qu’ils lisent juste un livre … ou ont pris quelques jours de formation … qu’ils peuvent s’attendre à une productivité instantanée. Ils ne réalisent pas que les méthodes agiles vous montrent uniquement vos problèmes… c’est encore à vous de les régler…

No comment.

Je vous conseille la suite du billet : La stabilité d’abord…La vitesse ensuite!

Alors à votre avis, peut on mettre en place une méthode agile sans une implication forte du top management?

• [sport management] Des similitudes : la taille (1/3)
• [developpement] Traitement des bugs
• [ecole] à coté de la plaque?
• MrBoo voit juste! Mais les autres…
• [blog] 6 mois plus tard, j’en suis où?
• [stage] la course est lancée
• [coup de gueule] Problème dans l’enseignement supérieur en france? ou pas…
• [sport management] Des similitudes : les objectifs (2/3)
• [agile scrum xp]Agile tour toulouse : j’y étais!!
• [gestion de projet] problematique du devisage : l’estimation

Tout d’abord un petit mot sur l’accueil : parfait. (J’avais dit un mot ) Plus sérieusement, nous étions reçus à l’IUT informatique de Blagnac. Bâtiment splendide, deux amphi super confortables. Entre chaque atelier, café, thé, chocolat chaud, jus d’orange et eau à volonté ainsi que viennoiseries le matin et pâtisseries l’après-midi. Un petit tour au RU le midi (là aussi, bien mangé) Bref, que du bonheur. Ceci dit, je n’ai pas fait que manger :p

Au programme :

• atelier : modélisation agile
• conférence : gouvernance agile
• retour d’expérience : scrum sur un projet critique
• conférence : estimations, mesures et indicateurs agiles
• retour d’expérience : les tests dans un projet agile
• retour d’expérience : forfait scrum en équipe distribuée.

Modélisation agile (ou « agile modeling »)

Peut être la déception de la journée, je m’attendais à de nouvelles manières de modélisation de projets informatique. En fait ce fût surtout une présentation d’UML (voir même un cours condensé). Or, on peut avoir deux points de vue vis à vis d’UML. Le premier qui consiste à le mettre en opposition à Merise. On note alors que hormis les diagrammes qui ne sont plus les mêmes, UML est itératif. Le seul lien avec l’agilité (et scrum en particulier)? Je le pense. Parce que même si UML est itératif, il reste ni plus ni moins qu’un paquet de document à rédiger et maintenir. Certes cela fait intervenir la valeur « courage » de l’eXtreme Programming (et il en faut pour maintenir tout les diagrammes ). Mais cela va à l’encontre du principe « individus et interactions plutôt que processus et outils ». Et, vous l’aurez compris, ma pensée penche plutôt de ce coté ci. Attention à ne pas trop dévier le sens de la valeur « courage »…

Gouvernance agile

Première conférence de la journée. A priori plutôt destinée au top management des entreprises. Cependant, de bonnes clés pour la mise en place d’un contexte agile avec une impulsion venant « d’en bas » (bottom-up). De manière générale, la gouvernance agile c’est d’appliquer les valeurs du manifeste agile non seulement à l’équipe mais à toute l’entreprise. Par exemple, de la même manière que dans un projet, le client et l’équipe doivent travailler dans le même sens puisque l’objectif est le même. Le management et l’équipe doivent lier un vrai partenariat puisqu’ils ont un objectif commun : créer de la valeur ajoutée. Une bonne partie de la conférence sur cette question « d’alignement entre les services ». Puis sur les intérêts commun à être agile :

• retours sur investissement au plus tôt (livraisons rapides et régulières)
• investissements au plus tard (ne faire que ce qui est strictement nécessaire)
• application évolutive (qualité du code, test unitaires,…)
• création de valeur ajoutée
• indicateurs de performance
• …

Scrum sur un projet critique

Peut être les points de la journée les plus intéressants : les retours d’expériences. On peut mesurer à quel point on est dans le coup (ou pas…) par rapport à des entreprise qui utilisent depuis peu l’agilité. La criticité du projet se situait à plusieurs points :

• équipe distribuée (Paris / Toulouse)
• projet sensible (gestion d’assurance vie)
• utilisation de prestas pas forcement familiarisés à l’agilité

Le fait que l’équipe soit distribuée n’a pas posé beaucoup de problème. L’utilisation de quelques outils remplaçant le fait d’être dans le même bureau (même si…) :

• skype pour la communication orale (réunion toussa) et les daily scrum
• rally pour la gestion de projet scrum
• svn pour gérer les versions
• basecamp, google docs, wiki pour la communication de l’équipe

Deux extraits interessants :

Le client est intégré dans le dispositif

• participation aux démos, à la rédaction des US
• redéfinition périmètre et/ou fonctionnalités en permanence
• intégration systématique des remarques issues de la démo (sprint suivant)
• intégration exceptionnelle de certaines demandes critiques (en cours de sprint – modification du backlog à chaud)
• insertion des defects issus de la recette directement dans l’outil Rally

Conclusion

• MOE (équipe de réalisation)
  • implication dans toutes les phases du dév et responsabilité
  • charge soutenue et durable
  • justesse et robustesse du projet
• MOA (client)
  • collaboration étroite et efficace
  • respect des attentes fonctionnelles et des délais

Autrement dit : un succès basé sur l’application des méthodes agiles grâce à une relation de confiance entre client et prestataire.

Estimations, mesures et indicateurs agiles

Conférence réalisée par Claude Aubry (un des gourous toulousain de l’agilité, amateur de rugby en plus! bon ok c’est presque un pléonasme..), juste après manger : grosse perf’ pour tenir un auditoire en éveil! Ce que j’en retiens, c’est principalement l’utilité de…l’utilité. Quand on utilise scrum on se penche plutôt sur les indicateurs tels que la vélocité, les points de story (un peu liés les deux quand même),.. voir même, au delà des indicateurs, sur les rituels et le vocabulaire lié à la méthode (scrum, release, features, daily scum/meeting (ou encore stand up), user story, backlog, burn up/down, point, planning poker, revue de sprint, sprint, rétrospective de sprint,etc…). Alors qu’on passe presque à coté de l’essentiel (sans l’oublié pour autant, puisqu’il y a toujours « priorisation » des stories) : l’utilité (je préfère utilité à valeur ajouté, ca fait moins business, plus centré sur l’utilisateur).

Donc, plus qu’une simple priorisation, on parle vraiment d’un pilotage par l’utilité. Avec, au moment des planification, un « utility poker » (similaire au planning poker, les rôles nécessaires étant différent même si le plus, le mieux) qui vise à ordonnancer features par utilité relative.

Ensuite, il devient facile d’identifier les priorités en plaçant les features sur un graphique (taille en abscisse, utilité en ordonné). Deux cas triviaux :

• à utilités égales, la feature la plus petite sera la plus prio.
• à tailles égales, la feature la plus utile sera la plus prio.

Bref, l’impression d’avoir franchi un cap en ce début d’aprem, merci

Les tests dans un projet agile

Dans l’agilité plus qu’ailleurs, on porte de l’importance à la qualité de ce que l’on produit (attention! je n’ai pas dit que les autres n’y font pas attention ). La raison principale est que pour pouvoir répondre rapidement au changement (d’une itération à l’autre) et pour limiter les docs il faut avoir un code super méga hyper ultra-maintenable. Et là, ben il n’y a pas 15 façon d’y parvenir, il faut automatiser les tests. C’est ce que nous a expliqué Arielle Ruellé durant ce retour d’expérience. Elle différencie 2 types de test :

• les tests unitaires, ceux réalisés par les développeurs (voir le TDD)
• les tests d’acceptations.

Sa prez’ s’étendait plus longuement sur les tests d’acceptations. On pourrait aussi les appeler tests fonctionnels. Ce sont ceux qui vont être rédigé avec le product owner (a minima) au moment de la constitution du backlog (bien sûr on peut en rajouter a posteriori). Apparait alors un nouveau rôle, ou une nouvelle fonction dans l’équipe : le ou les testeur(s). Ils vont être charger de réaliser ces tests fonctionnels (la recette?) et de les automatiser (imaginez un peu apres 4/5 itérations…). Les testeurs font donc partis intégrante de l’équipe, avec tout ce que cela importe…communication!

Après, je ne sais pas si c’est appliquable dans toutes les structures…imaginons une équipe de 3 dev, un testeur à temps plein représente 25% du coût de l’équipe. Difficile à faire passer dans le cadre d’une petite structure et encore plus pour un produit en propre. Même si je pense qu’il vaut mieux en faire un peu moins mais mieux…on en revient à l’utilité Peut être un début d’équation? Qualité + Utilité = Victoire (pas encore trouvé mieux pour le « Victoire » :p) Efficacité (merci Chris ).

Forfait scrum en équipe distribuée

Nicolas nous a présenté comment sur un projet en scrum, ils ont pu mettre en place un fonctionnement au forfait (c’était la conclusion de mon rapport de stage, dommage il est classé top secret ). Petite mise en situation : équipe sur deux sites, l’une agile l’autre non mais ouverte et motivée. Beaucoup d’échange et de confiance puisque le principe était le suivant :

• un contrat basé sur 3 itérations
• facturation à la fin de chaque itération
• contrat résiliable à la fin de chaque itération.

Cela peu paraître « fou » à première vue. Cependant, j’y trouve plusieurs intérêts :

• on se rapproche du « win fast, fail fast »
• le client sait pourquoi il paie
• cela ne coute pas plus cher à l’entreprise (dans le cas d’une sous estimation initiale)
• cela ne coute pas plus cher au client (dans le cas d’une sur-estimation initiale)
• cela pousse vers l’excellence : si on veut que le client continue il faut être bon, le meilleur.

Voilà, plus qu’un pari, c’est une question d’alignement : le client et le prestataire unis par les liens sacrés de la réussite (huhu facile celle là).

Claude en parle très bien ici : retour sur un projet au forfait en scrum.

Pour conclure

Une très bonne expérience à renouveler.

Rassuré sur mon « niveau » en agilité.

De nouvelles clés pour continuer à « évangéliser » .

Et vous, agile? pas agile?

PS : les prez’ dispo sont ici : sigmaT

• [agilité scrum] difficulté de mise en place des méthodes agiles
• [gestion de projet] problematique du devisage : l’estimation
• [developpement] Traitement des bugs

Du coup je me remet doucement sur d’autres projets, en plus de mon travail (j’ai été embauché suite à mon stage ). Donc je ressort e-caveavin des cartons et je vais essayer de faire les choses dans l’ordre. Afin de faire un produit maintenable avec une base solide je vais procéder par étapes.

La première sera de faire une backlog du produit. Autrement dit une liste d’actions que pourront faire les utilisateurs (au sens large, donc visiteurs, inscrits, administrateur, etc).

De cette liste je pourrai lister toutes les données que je souhaite gérer. Cela correspondra à tous les attributs de mes objets ou encore aux champs des tables de ma base de données.

Ensuite, une fois que j’aurais cette liste « d’information à gérer » je regarderai quelles vont être les intéractions entre ces données, comment les regrouper en entité logique et comment ces entités vont pouvoir s’imbriquer.

Et enfin je construirai l’architecture du site, ou le « comment les utilisateurs vont pouvoir intéragir avec ses données ». Sans aller jusqu’à une charte graphique pour le moment, mais voir de plus près quelles seront les vues à mettre en place, les liens, la navigation, les formulaires etc etc.

Voilà comment je compte m’y prendre, sans parler de méthode d’analyse comme merise ou UML puisque je n’en utiliserai pas

Et vous vous fonctionnez comment?

• [auto-promo] application facebook : le quizz du vin
• [gestion de projet] TimmyOnTime : gérer votre temps avec votre messagerie instantanée
• [developpement] Traitement des bugs
• [new] bonne année et actualités du blog
• [sport management] Des similitudes : les objectifs (2/3)
• [sport management] Des similitudes : la taille (1/3)
• [VACANCES] pas longues mais quand même!
• [agilité scrum] difficulté de mise en place des méthodes agiles
• [sport management] gestion de la pression en equipe
• [gestion] liste d’outils de gestion de projet by smashing mag

Dans le contexte dans lequel je me trouve les contraintes sont les suivantes :

• analyse et temps de devisage très court (coût supporté par l’entreprise et non pas par le client…)
• date de livraison fixe
• périmetre du projet fixe (ce qui a été devisé doit être livré à la bonne date )

Ce qui en découle est que les devis étant fait rapidement, ils sont souvent approximatifs et bien en deça des temps réels. L’entreprise a donc un surcout relativement important a supporter. D’autre part les dates de mise en production deviennent très dures à respecter.

Dans le livre « agile estimation and planning » de mike cohn (un des gourous des methodes agiles) j’ai trouvé un bon exemple qui stigmatise ce problème.

Si je vous demande d’estimer le temsp que vous mettrez pour lire un livre, a première vu vous serez juste me dire si c’est un roman, un essai, une nouvelle ce qui vous donnera un ordre d’idée approximatif. Puis vous regarderez le nombre de pages. Ce qui vous permettra d’affiner votre estimation.

A ce moment il fait une très net difference entre l’estimation de l’étendue du projet (le livre pour l’exemple) et l’estimation du temps necessaire pour le réaliser. L’estimation du temsp necessaire à sa lecture prend en compte d’autre paramètres tels que la taille des caractères, le nombre de lignes, la taille des marges, la facilité que vous aurez à lire ce livre là, etc etc.

Entre en jeu une deuxième donnée. Vous commencez à lire le livre et vous constatez que vous mettez un certaain temsp a lire 1 page. Disons 2 minutes. Dès lors vous êtes capable de donner une estimation beaucoup plus précise du temps necessaire pour achever sa lecture en multipliant votre vitesse par le nombre de pages!

Autrement dit, évaluer le temps necessaire à réaliser un projet sans le connaitre est mission impossible.

Plusieurs cas peuvent alors se présenter. On vous donne une date limite pour le lire. Vous lisez jusqu’a cette date et vous le rendez en ayant lu les 3/4. L’équivalent dans une entreprise serez une deadline fixe et la livraison d’un produit fonctionnel ne contenant pas toutes les fonctionnalités. L’autre option est qu’on vous dise, termine le livre et rends le moi quand tu l’auras fini. Vous avancez une date approximative que vous tenterez de respecter. Besoin de parallele? LE client veut son produit entierement fini pour cela il est souple sur la date de livraison dans la limite du raisonnable.

Quelles conclusions tirer? Je pense que dans tout les cas il est nécessaire d’avoir une variable. Soit la date de livraison, soit le nombre de fonctionnalité. Si toutes les données sont fixe l’estimation est vouée à l’echec. Les methodes agiles permettent de s’adapter dans tout les cas (les itérations permettent de livrer un produit utilisable à chaque fois et donnent la vélocité qui permet d’estimer le nombre d’iterations restantes pour boucler le projet). Au contraire l’utilisation de méthode traditionnelles (bien rigide comme peut l’etre merise) nous donne une foultitude (dédicasse à mr goumi) d’exemple de retard de livraison (même dans les plus grande entreprise) et de surcout phénoménaux…

Et vous ca se passe comment? quelles sont vos solutions?

Et puis allé je vais poser la question à babozor (allez voir son blog, plein de truc intéressant sur les méthodes de travail dans le monde du web et puis son désormais célèbre screencast : la grotte du barbu ). Donc si tu as l’occaz de faire un billet avec ton point de vue, je suis preneur

• [agilité scrum] difficulté de mise en place des méthodes agiles
• [agile scrum xp]Agile tour toulouse : j’y étais!!
• [developpement] Traitement des bugs