Agile Grenoble 2012 - Qualité: Stop à la procrastination

RAYNET SNC / Agile Grenoble 2012

RAYNET SNC

Qualité: Stop à la procrastinationAgile Grenoble 2012

L. Dupanloup - F. Chaminand


Source: www.larousse.fr

Procrastination Nom féminin

Tendance pathologique à différer, à remettre l’action au lendemain.


Les procrastinateurs

Laurent Dupanloup Product OwnerProject Manager

Fabrice Chaminand ScrumMaster


Phase 1: Procrastination - contexte

Phase 2: Formation

Phase 3: Stratégie

Phase 4: Mise en suspens

Phase 5: Action rattrapage

Phase 6: L’équilibre

Conclusion

Agenda



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 1 : Procrastination - Contexte


Le produit

Suivi de la production et traçabilité dans les ateliers (automotive)

Env. 1000+ instances à travers le monde

Production en 24/24h, 7/7j



Le projet

Démarrage cycle en V

Migration vers l’agilité en cours de projet

Projet en cours, début de mise en production

50 000 lignes de code

Très peu de tests automatisés / code peu testable



Phase1 : Procrastination - Contexte

Situation

Pour le PO : Régression frustration

Pour les développeurs : Refactoring cassant frustration

Pour le client : Avenir très incertain



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 2 : Formation


Phase 2 : Formation

Motivations Prise de conscience sur la nécessité d’implémenter des tests

automatisés Mise en production imminente

Décisions Formation « TDD » sur l’implémentation des tests unitaires Apprentissage : « Comment faire du code testable » Mise en place de quelques tests


Phase 2 : Formation

Activités 2h de workshop par semaine :

pour toute l’équipe développement Binômage

Résultat Le nouveau code est plus testable Beaucoup de temps passé versus couverture de test faible



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 3 : Stratégie



Motivations Budget qualité limité Planning serré Nécessité de cibler les tests -> Dépenser au bon endroit

Décisions Identification des fonctionnalités critiques Choix des fonctionnalités à tester en priorité Analyse des composants logiciels impactés Choix du type de test et estimation des coûts Sélection des composants : Les moins coûteux et gains

importants


Phase 3 : Stratégie Identification des fonctionnalités critiques

use cases

Who What Details WhereWorrying

after Downgraded mode, workaroundOperator To have the list of the POs and next PO notification up to date RM 1h none

Operator To supervise the current operation

Change of batch RM 15mn ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call controls engineer (marking); call CIP for data correction

Change the operation RM 15mn ALT-F4; unplugg the machine; start again the same operation and close it (red cross); call CIP for data correction

Input a comment RM 1d paper

Consult the comments RM 1d paper

Modify the status RM 1d none

Process the HUs (recording, printing,…) RM 1h manual printing; none for creating/modifying Hus; Poogle+…

Manage the Quality controls RM 1h call controls engineer (unblock after first sampling); SAP GUI; manual unblocking in Raypro

Change the HU type RM 2h None today; tomorrow :Poogle+… and manual printing;

View operation details RM 7d Supervision

Print manually the label RM 7d Supervision

Send the setup RM 15mn call controls engineer; tomorrow add capability to edit et re send the parameters in RM

View header information RM 8h paper

View notifications RM 2h paper

View status (current and history) RM 1d none

View graph of productivity RM 7d none

View graph of quality RM 7d none

View defect counters RM 1d PLC

View batch info RM 4h paper; none

View misc info RM 8h none

View components list RM 3d paper

Manivelle To setup the operation for material & WC RS 4h today none; tomorrow add capability to edit et re send the parameters in RM

Manivelle Definition of the material RS 8h if by import, do it manually; if manual, none

CIP To add/modify hardware configuration RS 1d None but a lot of XML export/import functionnalities exists

The boss To obtain productivity information (screen) RS 1d shop floor

The boss To obtain productivity information (reports) RS 3d paper

Manivelle To block/unblock batches/HUs RS/RM 4h CIP

Manivelle To validate the calendar RS 2d none

Manivelle To be informed about the last 24/48h running RS 2d shop floor


Phase 3 : Stratégie Identification des composants impactés


Phase 3 : Stratégie Analyse de testabilité des composants

Block Projet Risques Moyens Coût Rq Action

UI Machine Faible TU très elevéRefactoring a bcp de valeur pour ajouter des fonctionnalités (synchro supervision de l'atelier : story à venir en R4)

WF Entities Machinemoyen (regles metiers, chagt de status)

TU + definition de regles à introduire dans les entités faible

Part 1 : garantir règle métier => regrouper les entités model (packaging, handling unit, operation, workcenter, etc...toutes les WFEntities) concernées par WFModel , défniir leur dépendances pour etablir la sequence dans laquelle elles doivent être sauvegardées. Tester que pour chaque entité commitée, cet ordre de sauvegarde est respecté.Part 2 : garantir unicté de l'instance d'entité manipulée : Gérer un dictionnaire de WFEntity et ne créer une nouvelle instance que si absente du dico. Attention aux perf! gérer la durée de vie des WFentity dans ce dico

Business Services Machine moyen

TU sur workaround + regle sur ajout/modif dans schema (limiter les dependances) + definir des workaround (sur le save, checker les dependances, sauvegarder ce qu'on peut et lever un warning) + regle d'equipe sur le passage obligé par commande pour toute modif de donnees

en l'etat de nos connaissances,coût TU elevé du fait de la dépendance à Nhibernate. UPDATE : on maitrise maintenant la testabilité des services dépendant d'Nhibernate => Cout faible en fait c'est un DAL

Identifier les entités et leurs relations (analyse) => identifier les entites qui ne doivent pas etre transient sur un SaveOrUpdate => TU sur cette méthode avec fake sur entité et repo (transient or not)Si SaveOrUpate failed => remonter l'exception

WF Engine WF Engine élevé (si on y touche) TU => refactoring moyen (à confirmer)

Peu de raisons de toucher au schedulingcode existant Lourd et peu flexibles , peu de classes pour neaucoup de responsabilités => moyens limités, impact fortAxer le test sur CommandeInvoker et pas WFConnectorTester le méchanisme et non les commandesDéfinir ce qu'il faut tester y

WF CommandsWF Communication faible à moyen

Normaliser les commandes + "Boite à tester la norme"

élevé :normalisation lourdebeaucoup de commandes Tester les différentes commandes + la norme

WorkflowsRaypro.Worklow.Specific très élevé

Outil de test des workflows + écriture des cas, normaliser les worklows (idem commandes) + règles d'utilisation des activités élevé

Le workflow en lui-mêmeOutil similaire développé par Thales (Charlotte Gaidon, cf Jérémie Gomez) Définir un backlog pour l'outil de test des workflows

Machine CommandsWFCommunication faible TU faible

Abstract MachineAbstract Machine faible TU

moyen (Construction des devices)

Device (Business)Abstract Machine élévé TI Automatisé élevé

script de contrôle des I/O générés pour un comportement métier donné

Device (Hardware)Abstract Machine + Wrapper faible à moyen TI (drivers simulé, simulateur, ….) (très) élévé

application de TI pour chacun des device independemment les uns des autres



Activités 2h de workshop par semaine

Toute l’équipe projet Planning + implémentation

Résultat Liste de tâches cibles à faire en workshop Format workshop mal adapté à l’implémentation



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 4 : Mise en suspens


Phase 4 : Mise en suspens

Motivations Baisse de capacité non prévue Changements non prévus sur les fonctionnalités Date de livraison figée

Décisions Suppression temporaire des workshops Qualité jusqu’à livraison

Résultat Livraison dans les temps Augmentation de la charge de tests manuels de non régression Besoin de refactoring encore plus pressant



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 5 : Rattrapage



Motivations Livraison effectuée Besoin de rattraper le retard en terme de Qualité Ressources supplémentaires Bugs critiques dans le backlog nécessitant du

refactoring

Décisions Création d’un backlog de story Qualité :

sur les fonctionnalités critiques sur les fonctionnalités récentes (Garantie testables)

Premier sprint avec 50% de story Qualité Story Qualité comptabilisées à 0 point dans le sprint



Activités Intégration des story au storyboard. Code review pour valider les Story Qualité

Résultat Nouveau code testé Mauvaise répartition de l’effort :

Beaucoup de temps passés sur les story Qualité moins critiques

Pas assez de disponibilités des « experts » sur les story qualité critiques

Perturbation sur l’organisation du sprint : Pas de différenciation sur le tableau (User story vs Quality

story) Calcul faussé de la vélocité



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Phase 6 : L’Equilibre


Phase 6 : L’Equilibre

Motivations Bugs critiques dans le backlock nécessitant du refactoring Nécessité de cibler les tests -> Dépenser au bon endroit

Décisions Sélectionner le volume de story qualité en fonction du contenu

du sprint (Disponibilité des « experts ») Avoir un ratio 80/20 Meilleure identification des story qualité au tableau (Post-it vert) Estimer et comptabiliser les story Qualité


Phase6 : L’Equilibre

Activités Implémentation des story en binôme (expert + développeur) Revue de code pour valider la story

Résultat Des composants critiques enfin testés Des bugs critiques enfin résolus A terme, moins de régression sur les fonctionnalités critiques



Phase 2: Formation

Phase 3: Stratégie




Conclusion

Conclusion


Conclusion

Procéder par étapes

Justifier l’effort par du résultat concret

Trouver un équilibre

Rester réaliste

Négocier, collaborer, être ouvert


Questions?

DISCLAIMER“Presentation” means the information and any materials available in this presentation including, without any limitation, pictures, datasheets, product descriptions, etc. “RAYNET SNC” means an independent company of ARaymond Network and the editor of this presentation. This presentation does not constitute an offer or an agreement of any kind. The presentation is provided «as is». RAYNET SNC makes no warranty or representation whatsoever regarding the presentation, its use or its suitability to meet specific needs. RAYNET SNC DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE OF THE presentation. RAYNET SNC is not liable for any incidental, consequential or special damages of any kind due to the use of the presentation. The presentation and/or its contents is copyrighted works of RAYNET SNC and may be also protected by trademark laws, patent laws or other laws. All other copyrights, trademarks or patents not owned by RAYNET SNC are the property of their respective owners. The only use permitted is to consult the presentation. Any rights not expressly granted herein are reserved. Except as expressly specified in these terms, nothing contained herein shall be construed as conferring any license or right of any copyright, trademark, patent, or any proprietary rights. Any unauthorized use of this presentation e may violate rights, and so, RAYNET SNC or any third party concerned may claim any damages or losses suffered.

RAYNET SNC

Agile Grenoble 2012 - Qualité: Stop à la procrastination

Technology

Transcript of Agile Grenoble 2012 - Qualité: Stop à la procrastination