Agile Grenoble 2012 - Qualité: Stop à la procrastination

RAYNET SNC / Agile Grenoble 2012

Qualité: Stop à la procrastination
Agile Grenoble 2012
L. Dupanloup - F. Chaminand

RAYNET SNC

Procrastination
Nom féminin

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

Source: www.larousse.fr


Les procrastinateurs

Fabrice Chaminand
ScrumMaster

Laurent Dupanloup
Product Owner
Project Manager


Agenda

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


Phase 1 : Procrastination - Contexte


Phase 2: Formation

Phase 3: Stratégie




Conclusion



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 2: Formation

Phase 3: Stratégie




Conclusion


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 3 : Stratégie


Phase 2: Formation

Phase 3: Stratégie




Conclusion



 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


Identification des fonctionnalités critiques
use cases
Worrying
Who What Details Where after Downgraded mode, workaround
Operator 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


Identification des composants impactés


Analyse de testabilité des composants
Block Projet Risques Moyens Coût Rq Action
Refactoring a bcp de valeur pour ajouter des
UI Machine Faible TU très elevé fonctionnalités (synchro supervision de l'atelier :
story à venir en R4)

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
moyen (regles metiers, chagt TU + definition de regles à introduire dans de WFEntity et ne créer une nouvelle instance que si absente du dico. Attention
WF Entities Machine de status) les entités faible aux perf! gérer la durée de vie des WFentity dans ce dico

en l'etat de nos
connaissances,coût TU
elevé du fait de la
TU sur workaround + regle sur ajout/modif dépendance à
dans schema (limiter les dependances) + Nhibernate. UPDATE :
definir des workaround (sur le save, on maitrise maintenant
checker les dependances, sauvegarder ce la testabilité des Identifier les entités et leurs relations (analyse) => identifier les entites qui ne
qu'on peut et lever un warning) + regle services dépendant doivent pas etre transient sur un SaveOrUpdate => TU sur cette méthode avec
d'equipe sur le passage obligé par d'Nhibernate => Cout fake sur entité et repo (transient or not)
Business Services Machine moyen commande pour toute modif de donnees faible en fait c'est un DAL Si SaveOrUpate failed => remonter l'exception

Peu de raisons de toucher au scheduling
code existant Lourd et peu flexibles , peu de
classes pour neaucoup de responsabilités =>
moyens limités, impact fort
Axer le test sur CommandeInvoker et pas
WFConnector
Tester le méchanisme et non les commandes
WF Engine WF Engine élevé (si on y touche) TU => refactoring moyen (à confirmer) Définir ce qu'il faut tester y
élevé :
WF normalisation lourde
Communicatio Normaliser les commandes + "Boite à beaucoup de
WF Commands n faible à moyen tester la norme" commandes Tester les différentes commandes + la norme
Outil de test des workflows + écriture des
cas, normaliser les worklows (idem Le workflow en lui-même
Raypro.Worklo commandes) + règles d'utilisation des Outil similaire développé par Thales (Charlotte
Workflows w.Specific très élevé activités élevé Gaidon, cf Jérémie Gomez) Définir un backlog pour l'outil de test des workflows
WFCommunica
Machine Commands tion faible TU faible
Abstract moyen (Construction
Abstract Machine Machine faible TU des devices)
Abstract script de contrôle des I/O générés pour un
Device (Business) Machine élévé TI Automatisé élevé comportement métier donné
Abstract
Machine + application de TI pour chacun des device
Device (Hardware) Wrapper faible à moyen TI (drivers simulé, simulateur, ….) (très) élévé 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 4 : Mise en suspens


Phase 2: Formation

Phase 3: Stratégie




Conclusion


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 5 : Rattrapage


Phase 2: Formation

Phase 3: Stratégie




Conclusion



 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 6 : L’Equilibre


Phase 2: Formation

Phase 3: Stratégie




Conclusion


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


Conclusion


Phase 2: Formation

Phase 3: Stratégie




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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (10)

Similaire à Agile Grenoble 2012 - Qualité: Stop à la procrastination

Similaire à Agile Grenoble 2012 - Qualité: Stop à la procrastination (20)

Agile Grenoble 2012 - Qualité: Stop à la procrastination