Améliorez et industrialisez vos feedback produit

Transcription

1 Améliorez et industrialisez vos feedback produit

2 Jean- Philippe Gillibert, architecte logiciel et coach agile chez Introduc)on Retour d expérience sur un projet à la SNCF Méthode originale de traitement des «feedback produits»

3 Les boucles de feedback

4 Une clé de l agilité Les boucles de feedback Présentes dans nombre de pra)ques agiles Feedback techniques (tests automa)sés, intégra)on con)nue ) Feedback produit (daily scrum, sprints )

5 Sommaire Contexte du projet Démos Le système Résultats

6 CONTEXTE DU PROJET

7 Client SNCF Contexte du projet : Généralités Développement d un ou)l de planifica)on Durée : 2 ans Maitrise d ouvrage : 1 personne Maitrise d œuvre : 1 chef de projet, 3 développeurs, 1 testeur MOA et MOE sur des sites distants (Paris, Lyon) Produit livré en 2011

8 Contexte du projet : Focus sur MOA Très disponible, très impliquée Pas mo)vée par la produc)on de spécifica)ons Prête à beaucoup tester, à donner de nombreux retours (Feedback produit) Déplacements rares sur le site de la MOE (1 jour tous les deux mois)

9 Contexte du projet : méthodes de développement Méthode officielle : Processus Unifié (UP), avec itéra)ons de 2 mois UP «agilisé» : 2 prototypes intermédiaires livrés (soit des «sprints» de 3 semaines) Pas Scrum Extreme Programming (XP), tests automa)sés, plateforme d intégra)on con)nue

10 Contexte du projet : Idée directrice Mebre le feedback produit au cœur du développement Etre capable de reproduire à l iden)que et en différé les sessions u)lisateur de la MOA = numériser le feedback produit Architecturer l applica)on dans ce sens Obtenir des boucles de feedback produit courtes

11 DEMOS

12 Démo : Signalement d une anomalie

13 Démo : Signalement d un crash

14 LE SYSTEME

15 Le système : Commandes Encapsula)on des ac)ons u)lisateurs dans des commandes (Design pabern Commandes) Généra)on de code

16 Le système : Scénarios Scénario = enchainement de commandes Scénario = feedback produit «numérisé» Sérialisa)on sous forme de code

17 Le système : Tests fonc)onnels automa)sés Feedback produit encapsulé dans un test automa)sé Issu d une session u)lisateur de l applica)on Poten)ellement neboyé et enrichi par le développeur (asserts )

18 Le système : Tests fonc)onnels automa)sés Vérifié con)nuellement par la plateforme d intégra)on con)nue

19 Le système : Architecture Architecture orientée «Commandes» Objets mé)ers accessibles qu en lecture seule dans les couches supérieures d IHM Toute modifica)on d objet mé)er doit passer par une commande Système «cinéma» (capture, projec)on, pellicules) isolé dans un Framework réu)lisable

20 RESULTATS

21 Résultats : Communica)on / Echanges Boucles de feedback produit souvent courtes voir très courtes Le feedback produit «numérisé» est un support efficace pour les échanges MOA MOE mais aussi : MOE MOE, u)lisateurs MOA Il réduit la distance entre l u)lisateur et le développeur et ainsi tend à produire des logiciels plus proches des besoins u)lisateurs

22 Résultats : Résolu)ons de bugs Gain de temps pour celui qui signale le bug Gain de temps pour celui qui débogue et corrige le bug Pas de temps perdu à échanger sur les moyens de reproduire le bug Les bugs «rares» sont captés, analysés (parfois par segmenta)on) et traités rapidement

23 Résultats : Résolu)ons de bugs Temps global sur le projet passé à corriger les bugs très faible. La plupart des bugs sont corrigés tôt et ne coutent pas cher à résoudre.

24 Résultats : Développement logiciel Léger surcout pour le développement : o un peu plus de classes, d interfaces o s assurer que toute ac)on est rejouable dans un scénario o hors coût créa)on du système Bonnes condi)ons de développement : applica)on stable, peu de bugs, bonne couverture de code des tests (filet de sécurité) Aben)on : les développeurs doivent jouer le jeu

25 Résultats : Développement logiciel Principes de l Extreme programming o puisque les tests sont u)les, ils seront faits systéma)quement avant chaque mise en œuvre o puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la solu)on la plus simple o puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement o o puisque pouvoir enregistrer et rejouer les sessions u3lisateur est u3le, nous rendrons toutes les ac3ons u3lisateur enregistrables et rejouables

26 Résultats : Qualifica)on logicielle Campagnes de tests courtes (beaucoup de tests automa)sés)! Feedback rapide! Testeur plutôt sa)sfait des condi)ons de travail

27 Résultats : Sa)sfac)on MOA et u)lisateurs Souvent étonnés par la réac)vité de la MOE Sen)ment d être écoutés Confiance envers la MOE

28 Résultats : Sa)sfac)on MOA et u)lisateurs Applica)on stable Très peu de bugs (quelques rares anomalies remontées depuis 2 ans) Produit semble en adéqua)on avec les besoins Faibles coûts de maintenance

29 Très adapté pour clients lourds Résultats : Limites du système? Systèmes concurren)els? (Des scénarios globaux du système?) Gros volumes de données? Applica)ons distribuées? Doit être mis en place dès le démarrage du projet

30 Résultats : Agilité Le système à permis d être agile malgré la distance entre les sites L'applica)on est devenue elle- même un support à l agilité dans le projet, en facilitant notamment l aspect collabora)f

31 CONCLUSION

32 Conclusion : Les perspec)ves Système actuellement réu)lisé dans un nouveau projet plus important ( taille * 3) Un support pour l agilité en offshore? o Décalages horaires (scénario = un seul échange) o Barrière de la langue (scénario = «langage produit» commun)

33 Méthode «extrême» Quelle valeur donnez vous à vos feedback produit? Comment les exploitez vous? Pensez «feedback produit» Conclusion

34 QUESTIONS? FEEDBACK? jgillibert@sii.fr Site web : hbp://jeanphilippegillibert.wordpress.com/

35 Merci aux sponsors