SERENA : Processus Agile

1. SERENA : Processus Agile 23 Novembre 2010 Sylvain CAILLIAU 23 nov 2010 SERENA SOFTWARE INC.

2. Agenda • L’offre AGILE de SERENA : baséesur SCRUM • Le processus Agile appliqué par la R&D SERENA • Les “Offres Solutions” de SERENA : “Enterprise Developer Agile” SERENA SOFTWARE INC.

3. L’offre « AGILE » de SERENA

4. Développement d’Applications Demandes de Nouvelles applis Stratégique Demandes D’amélioration Problèmes Défauts Tactique

5. Visualiser Definir Concevoir Développer Déployer Fabriquer Tester Le Cycle de vie applicatif Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Défauts Tactique

6. La Gestion du Cycle de vie applicatif Visualiser Définir Concevoir Développer Déployer Fabriquer Tester Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Défauts Tactique Artéfacts logiciels gérés Processus répétables Exécution des projets maîtrisée

7. Une réalité constatée… Qualité insuffisante Planning non-respecté Visualiser Definir Concevoir Développer Déployer Fabriquer Tester Non conforme au Business Budget Dépassé Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Défauts Tactique Artéfacts logiciels gérés Processus répétables Exécution des projets maîtrisée

8. Le cycle de vie applicatif Visualiser Definir Concevoir Développer Déployer Fabriquer Tester Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées On doit pouvoirfaire mieux … Problèmes Applications corrigées Applications retirées Défauts Tactique Artéfacts logiciels gérés Processus répétables Exécution des projets maîtrisée

9. La méthode traditionnelle… Analysedes ExigencesSystème Demandes de Nouvelles applis Analysedes Exigences Nouvelles applications Stratégique Demandes D’amélioration Conception Générale Applications améliorées ConceptionDétaillée Problèmes Applications corrigées Code et tests unitaires Applications retirées Défauts Le Diagramme en Cascade W.W. Royce, 1970 Tactique Intégration ettests d’intégration • Pilotée par la documentation (la plus détaillée possible) • Tâches enchaînées par des équipes cloisonnées • Résistances aux évolutions des exigences • Plus les modifications sont tardives = Plus le coût est élevé • Planning non maîtrisé, particulièrement en phase de stabilisation Installation et Déploiement Exploitation etMaintenace

10. Emergence de l’Agilité • Le développement logiciel traditionnel assume que les exigences sont connues et finalisées avant que la conception et le codage ne démarrent • Contrôler le changement est désirable • Les processus sont définis et/ou contrôlés Toute résistanceest futile • L’Agilité a émergée dans les environnements où cette approche était impossible ou inappropriée • Le changement est encouragé • Les processus sont empiriques

11. La Méthode Agile… ! Planifier, Faire, Vérifier, Adapter Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Défauts Tactique • Equipes Multi-compétentes qui intègrent le client (ou son “proxy”) le développement, les tests et les autres profils nécessaires • Livraison Incrémentale de fonctionnalités d’une robustesse et d’une d’une qualité de « niveau production » à des intervalles réguliers • Développements dirigés par les tests (TDD) pour mettre la qualité au premier rang des préoccupations • Fabrication, tests et rapports Automatisés s’exécutant à minima toutes les nuits

12. Les méthodes Agiles deviennent stratégiques Compromis !@#$% Multi-Tout ! Equipes Projets Géographies Temps & Argent

13. Support pour le multi-Tout ! Serena Agile On DemandConçu pour une utilisation d’entreprise Une nouvellefaçon de passer à l’Agilité Dans l’esprit « lean » mais pour une utilisation globale Conçu pardes experts

14. 100% Pure Agile Plus desuccès Jeff McKenna Chief Agile Evangelist Co-créateur de Scrum Support demultiplesméthodesagiles Paul Dupuy Product Owner Auteur de nombreuses publications sur l’Agilité Simple à utiliser

15. L’Equipe Agile • Multi-compétente • Toutes les fonctions et expertises requises pour réaliser le produit / l’application sont dans l’équipe • Impliqués de la conception à la livraison • Tous sur un même plan (par de relation hiérarchique dans l’équipe) • Rôles • Scrum Master (autrefois le “Chef de Projet”) • Product Owner (autrefois le “Responsable produit” ou “l’Assistance Maîtrise d’Ouvrage”) • Membre de l’équipe • Développeurs • Testeurs • Rédacteurs • …

16. Le rôle du Scrum Master • Aplanir les obstacles • Contrôler le processus • Maintenir l’équipe en mouvement • S’assurer du “bon fonctionnement” de l’équipe 16

17. Release Planning – “Sprint 0” • Pas de contradiction entre agilité et planification ! • Backlog de haut niveau créée à partir des livrables de conception • Revue et évaluée pour s’assurer qu’elle est réalisable ! • Identification des étapes clés et des engagements business • Quand est-il approprié d’avoir un “Sprint 0” ? • Projet long avec de nombreuses livraisons prévues • D’importantes activités postérieures à la mise en production ont à être plannifiées • Ex: Formation des utilisateurs, Lancement Marketing, …

18. Release Planning - “Sprint 0” • Chaque élément de la Backlog est affecté d’une priorité et la charge de réalisation estimée (en “story points” ) • Estimation “à la louche” (précision de +/- 50% acceptable) • Le plan de charge prévisionnel du projet et développé • La charge est comparée à la capacité en ressources et le “Burdown chart” initial est construit • A l’issue du “Sprint 0”, une revue du plan de livraisons est faîte et le premier Sprint est lancé

19. Conçu pour la gestion multi- équipes et projets Visualisez toutes vos backlogs sur un seul écran! Outils de gestion et de planification puissants Glissez-déposez vos Stories

20. Sprinting 2-5 semaines 2-3 jours (PLANNING) RECAP, DEMO, RETROSPECTIVE, RELEASE, KICK-OFF Planifier Faire Vérifier Adapter

21. Définition et Planning du Sprint • Le Product Owner et les team leads identifient les items du backlog pris en compte pour le sprint • Les items du backlog sont affinés • User Stories • Interaction et écrans • Le contenus des fonctionnalité, les cibles de la release et la capacité de l’équipe sont re-calibrés • Le Sprint est lancé par une réunion de l’équipe pour revoir et discuter les objectifs

22. Backlog et Gestion de la Demande • Listes Excel • Outil d’import • SBM • Intégration directe • Mise à jour bi-directionnelle

23. Le processus complet Customers, Business Owners, Stakeholders Business Analysts, Product Owners ScrumMasters,Team Members Release Managers & IT Ops IT Mgmt & PMO Demandes Deploiement Projet Governance, Compliance, Reporting

24. Intégration SBM / AOD

25. Gestion de la Demande : Types de Demandes • Stratégiques • Nouvelles requêtes projet • Nouvelles Exigences • Tactiques • Défauts (Bugs) • Demandes d’amélioration • Mapping : • Défaut Tâche (Task) • Amélioration Story • Exigences Fonctionnalité (Epic)

26. Une “User Story” c’est quoi? • Une brève description d’une activité qu’il faut réaliser • Initialement les Stories définissent des activités qui ont pour but d’ajouter des fonctionnalités à un produits … mais … • Elles peuvent concerner d’autres domaines comme l’Architecture, la Conception de Haut Niveau, des Bugs à corriger … voire (dans le cas de XP) des “Dettes” à payer. 26

27. Une User Story c’est quoi d’autre ? • Les détails d’une Story sont obtenus par conversation / interaction avec le Product Owner • C’est forcément bref : le “Just enough documentation” • Les critères d’acceptation sont obligatoire pour permettre de confirmer qu’une Story a été implémentée correctement (ce qui va dans le sens du TDD)

28. Comment déterminer la taille d’une “User Story”? • L’estimation est faîtes par les membres de l’équipe • La notion de “Story points” est souvent utilisée (uniquement des valeurs relatives propres à l’équipe) • La suite de Fibonacci utilisée pour discriminer les tailles relative • Utilisation de la technique du “Planning Poker” • Rapide : pas de discussion au delà de 2 minutes • Prise en comptes des différents artefacts : Fenêtre, règles, tables, code (méthodes) 28

29. Sprint Backlog Planning Découpage des User Stories en Tâches Drag & drop depuis le backlog produit vers le sprint

30. Ecrire et évaluer les User Stories Définir les priorités et la valeur business … Estimer le travail et visualiser les résultats aggrégés Définir les critères d’acceptance

31. Gérer les activités • Les User Stories pilotent le développement et les tests • Les Développeurs les utilisent pour déterminer ce qu’il faut construire • Les Testeurs pour déterminer ce qu’il faut tester • Les User Stories peuvent être découpées en tâches • Le reste à faire de chaque tâche est évalué par celui qui réalise la tâche • Avancement, Statuts et Blocages sont discuté dans le meeting quotidien (ie. “daily stand-up scrum”)

32. User Stories et Tâches Affiner les User Stories en Tâches Elaborationet estimationdes tâches

33. Planification incrémentale • Le contenu des fonctionnalité, les objectifs des releases et la capacité de l’équipe sont revus/discutés/débattus en continu • Participants clé : Scrum Master et Product Owner • C’est de là que vient l’expression Scrum (mêlée) • Parfois le processus peut être “brutal”

34. La mêléé quotidienne • Réunion quotidienne de l’équipe : toujours à la même heure et au même endroit • Tout le monde est présent – Developpement, Test, Product Owner • Conduite par le Scrum Master (“Chef de projet”) • <15mins • Chaque membre de l’équipe indique ce qu’il a fait depuis le veille, ce qu’il va faire aujourd’hui et précises toutes les difficultés ou blocages qu’il rencontre • Les difficultés ou blocage seront résolus “offline” (responsabilité du Scrum Master) • Tableau Blanc

35. Mêlée quotidienne virtuelle … Rapide et facile à mettre à jour par les développeurs Burn-down charts et collaboration !

36. Réputés « meilleurs outils » pour les petites équipes…

37. Collaboration avec n’importe quelle équipe, n’importe où Le tableauvirtuel des Cartes Glisser-déposervosCartes Les post-itsne sont pasextensibles

38. Comment réussir la mise en place dans votre organisation • Faites vous assister ! • Si vous n’avez pas d’expérience avec les méthodes Agiles, prenez conseil auprès d’un expert • Commencez “petit” • Commencez par un projet de taille “raisonnable” mais surtout avec des dépendances externes limitée • Tous doivent être impliqués • Du sponsor hiérarchique à tous les membres de l’équipe • Capitalisez sur les succès initiaux • Pour construire la crédibilité de cette nouvelle façon de travailler

39. Une communauté d’experts en Ligne Meilleurespratiques & trucs et astucesproduit Produit blogs & forums

40. Le processus Agile appliqué par la R&D SERENA

41. Contexte Global Equipes réparties Plusieurs centaines d’utilisateurs Processus piloté par SERENA Businness Manager Planification et suivi réalisés via SERENA Agile On Demand Toutes les équipes suivent le processus Agile

42. Les utilisateurs • Un nombre d’utilisateurs important • Jusqu’à 150 connexions concurrentes • Plusieurs centaines d’utilisateurs au total • Un serveur Windows serait insuffisant • Item Library et base Oracle peuvent représenter un gros volume de données : • Jusqu’à 500 giga • Les performances sont essentielles • Un processus structurant (SDLC) piloté par SBM • Certains utilisateurs utilisent seulement Dimensions et AOD • Certains utilisateirs utilisent seulement SBM et AOD • Certains utilisent les 3 • Les Métriques et les indicateurs sont pilotés par SBM et AOD

43. Méthodologie • All using Agile Methodology • SCM rules adjustable per project on the fly • Continuous integration • Extreme programming rules in place

44. Solution de GCL en place • Serveur Centralisé • Pas de réplication • Utilisation d’Oracle • Bibliothèques d’Item et Base de données Oracle sur des disques séparés • Disques rapides • Serveur Dimensions réparti pour partager la charge • Logique applicative et Accès aux fichiers • La fonction « Library Cache » utilisée pour les sites distants (Slow WAN) • Tests réalisé au niveau charge et latence du réseau

45. Configuration côté serveur

46. Configuration Library Cache

47. SBM : interface avec Dimensions et AOD Sync Engine Enhancements, Defects and Internal Tasks One Dimensions Issue Type Process Control for DEV in Dimensions All Other Process Control in SBM Sync from SBM to AOD All planning activities from AOD

48. Autres décisions relatives au paramétragede Dimensions • Simple Item Lifecycle • Process control through issues not items • Three Products • Legacy waterfall • Agile product • Project documentation product • Branching through Projects • Some teams use named branches • Privileges by Design Part • Extensive Use of Roles and Groups to Control Security • Release Engineering Controlled Baselines

49. Dimensions utilisé pour contrôler les développements De Dimensions

50. Daily Scrum Meeting Product Backlog As prioritized by Product Owner 24 hours Backlog tasks expanded by team Potentially Shippable Product Increment 30 days Sprint Backlog SERENA R&D Process • “Epic Themes” are defined for the release at Product Strategy Meetings • Product Owners • Executives • “Epic Themes” are manage as “User Stories” in a “Product Backlog” • Product Backlog in AOD • From the Product Backlog a prioritized “Release Backlog” is created