SERENA : Processus Agile

Présentation au sujet: "SERENA : Processus Agile"— Transcription de la présentation:

1 SERENA : Processus Agile
Serena Software SERENA : Processus Agile 23 Novembre 2010 Sylvain CAILLIAU 23 nov 2010 SERENA SOFTWARE INC. Copyright © 2010 Serena Software, Inc. 3/26/2017

2 Agenda L’offre AGILE de SERENA : basée sur SCRUM
Serena Software Agenda L’offre AGILE de SERENA : basée sur SCRUM Le processus Agile appliqué par la R&D SERENA Les “Offres Solutions” de SERENA : “Enterprise Developer Agile” SERENA SOFTWARE INC. Copyright © 2010 Serena Software, Inc. 3/26/2017

3 L’offre « AGILE » de SERENA

4 Développement d’Applications
Demandes de Nouvelles applis Stratégique Demandes D’amélioration Problèmes Tactique Défauts Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! 4

5 Le Cycle de vie applicatif
Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Visualiser Definir Concevoir Développer Fabriquer Tester Déployer Applications améliorées Problèmes Applications corrigées Applications retirées Tactique Défauts Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! 5

6 La Gestion du Cycle de vie applicatif
Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Visualiser Définir Concevoir Développer Fabriquer Tester Déployer Applications améliorées Problèmes Applications corrigées Applications retirées Tactique Défauts Artéfacts logiciels gérés Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! Processus répétables Exécution des projets maîtrisée 6

7 Une réalité constatée…
Demandes de Nouvelles applis Qualité insuffisante Nouvelles applications Stratégique Demandes D’amélioration Visualiser Definir Concevoir Développer Fabriquer Tester Déployer Applications améliorées Planning non-respecté Problèmes Applications corrigées Applications retirées Tactique Défauts Non conforme au Business Artéfacts logiciels gérés Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! Processus répétables Budget Dépassé Exécution des projets maîtrisée 7

8 Le cycle de vie applicatif
Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Visualiser Definir Concevoir Développer Fabriquer Tester Déployer Applications améliorées On doit pouvoir faire mieux … Problèmes Applications corrigées Applications retirées Tactique Défauts Artéfacts logiciels gérés Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! Processus répétables Exécution des projets maîtrisée 8

9 La méthode traditionnelle…
Analyse des Exigences Système Analyse des Exigences Conception Générale Conception Détaillée Code et tests unitaires Intégration et tests d’intégration Installation et Déploiement Exploitation et Maintenace Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Tactique Défauts Le Diagramme en Cascade W.W. Royce, 1970 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 Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! 9

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ésistance est 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 10

11 La Méthode Agile… ! Stratégique Tactique
Demandes de Nouvelles applis Nouvelles applications Stratégique Demandes D’amélioration Applications améliorées Problèmes Applications corrigées Applications retirées Tactique Défauts Planifier, Faire, Vérifier, Adapter 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 Application development is all about creating new applications or enhancing or fixing existing apps And we need to do this as efficiently as possible to maximize the value we can return to the business So all this process stuff is just a means to an end, NOT the end in and of itself! 11

12 Les méthodes Agiles deviennent stratégiques
Compromis Multi-Tout ! Equipes Projets Géographies We at Serena have been active in the application development space for over 27 years. For decades we’ve watched, along with our customers, the gradual adoption and growth of Agile software development processes. As we watched Agile move from the early adopter stage, across the adoption chasm into the the early majority we’ve seen it hit a brick wall of problems: Compromise between business needs and developer needs, scaling agile to a multi-everything environment, cost, time and money to adopt and transform to agile. Compromise Organizations adopting Agile have to compromise between Agile tools that give management visibility and control OR Agile tools that support the needs of developers to be creative and effective. Multi-Everything Scaling agile practices to large software development organizations with multiple teams working on multiple projects from multiple locations. Time and Money Adopting and scaling agile can be time consuming, costly and difficult to do without the right tools and know how. Temps & Argent

13 Serena Agile On Demand Conçu pour une utilisation d’entreprise
Dans l’esprit « lean » mais pour une utilisation globale Une nouvelle façon de passer à l’Agilité Support pour le multi-Tout ! So we set out to create a completely new way for companies to become agile and make an agile transformation. We set out to build a tool that could specifically address the needs of the modern enterprise and the VP of application development who wants the benefits of Agile but has a Multi-Everything environment where visibility is king. Tools that developers will love to use, because they love agile. Information that managers need to run the department, information and visibility for planning, budgeting and compliance. Conçu par des experts

14 Support de multiples méthodes agiles
100% Pure Agile Plus de succès Jeff McKenna Chief Agile Evangelist Co-créateur de Scrum Support de multiples méthodes agiles Paul Dupuy Product Owner Auteur de nombreuses publications sur l’Agilité Our tool was built by two of the original founders of Scrum. Our head of development, John Scumniotales was the very first Scrum Master. With that understanding on board we set out to build a tool that any Agilest would love. They’ve built a tool any developer will love, b/c they built a tool that they love. It’s got More Cowbell. More of what an Agile developer would choose to put into a product. We’ve made it support ANY type of Agile your using, even if your using your own flavor. You’ll find more flexibility to manage the way you want to with our product than you will with our competitors. Most importantly we made it easy to use, so it would get used. Most developers only need to use an Agile tool for a few minutes every day. We’ve made it easy for them to go to one screen, update their story points, see the burn-down chart and check the story wall. ‘’ Simple à utiliser

15 L’Equipe Agile Multi-compétente Rôles
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! Glissez-déposez vos Stories Preview customers responded positively to the way we’ve used a tree hierarchy on the left to organize and label products, releases and sprint backlogs. Since most customers are doing a hybrid form of Agile, often running multiple products simultaneously and utilizing multiple teams at once (sometimes across multiple products), they have a clear need to be able to organize and label products to match their practices. A common frustration was voiced with competitive products, Rally and Version One, that they do not have enough customization and what customization they do have in their hierarchy is not easily used or accessed. Flexible Tree Hierarchy Allows you to organize Products, Releases and Sprints to fit how your teams work on them. Organize Projects Your Way If you use something other than Products, Releases and Sprints then…. Project types can be easily customized, renamed and attributed….. Because we think you usually customize Agile to fit your culture. Outils de gestion et de planification puissants

20 Planifier Faire Vérifier Adapter
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 Demandes Projet Deploiement
Customers, Business Owners, Stakeholders IT Mgmt & PMO Business Analysts, Product Owners ScrumMasters, Team Members Release Managers & IT Ops For most Enterprises trying to adopt agile, the situation looks like this. They have lots of demand of all kinds coming in from multiple stakeholders (def, ERs, help requests, requests for new products or projects). They have systems in place to help them capture and manage this demand. They have systems to help them manage and track the revisions they make to their software. They have systems to help them manage and control what gets deployed into production. And they need those systems and processes to meet their Governance and Compliance needs. They need to be able to show that they followed a defined business process for evaluating and approving new project investments or that they met SLAs for responding to customer reported problems or defects. They need know what changes went into what software baselines. And they need to know that the baselines that they deploy into production went the required development & testing processes designed to ensure that what gets deployed doesn’t bring down the entire production env. At the ends of the lifecycle, you do want to CONTROL CHANGE. And these processes and the level of control they provide are necessary. But in the middle of this lifecycle, where the software gets built and tested, there are project teams that must do the work. And if those teams are Agile and they need LESS rigor and more flexible processes. And so this is the tension that exists between the existing ALM processes in the lifecycle that try to control change and the Agile team processes that seek to embrace change, and thus the challenge for organizations trying to go Agile. Demandes Projet Deploiement Governance, Compliance, Reporting 23

24 Intégration SBM / AOD

25 Gestion de la Demande : Types de Demandes
Serena Software 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) Copyright © 2010 Serena Software, Inc. 3/26/2017

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
Drag & drop depuis le backlog produit vers le sprint Découpage des User Stories en Tâches

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

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 Elaboration et estimation des tâches
User Stories et Tâches Affiner les User Stories en Tâches Elaboration et estimation des 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 The daily scrum is the core of collaboration and project status for many teams. On this powerful screen the entire team, regardless of where they are located, can see Burn- down and Burn-up charts to track story completion. Update stories right on the screen with in-line edit and log impediments. Click the Storyboard tab and ….. 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 tableau virtuel des Cartes Les post-its ne sont pas extensibles ….instantly get a Card Wall view of the work. With customizable columns you can organize your work flow as you need it. Expand each Card on the wall to see detailed information. Just drag and drop stories in real time to move them from one state to the next. Just because your team isn’t in one room doesn’t mean you have to give up on group collaboration and achievement as stories are completed. Glisser-déposer vos Cartes

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 38

39 Une communauté d’experts en Ligne
Meilleures pratiques & trucs et astuces produit You can talk directly to and get advice from Serena and Valtech Agile experts. Get your info directly from the source. Provide feature requests and input straight to the team that building the next release. Our development team is putting out a new Agile On Demand release every 2 months. We’re still working, incorporating the best ideas from our user community. Be a part of the change. 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étrage de 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 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting “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

51 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Sprint Teams are defined to work on the User Stories The ones selected for a specific Release Backlog A single DIMENSIONS CM Project is created for the release Dimensions : Project was called DMPROD:CM10.1.3 That Project had a default named branch: cm1013 Those Sprint Teams have resources for: Development QA Documentation And participation from the Product Owners

52 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting At the start of a Sprint each team: Takes the “User stories” to be addressed Breaks them down into tasks Estimates the tasks Creates a “Sprint backlog” These tasks are tracked as “EHN” items in SBM (Serena Business Mashup / TeamTrack) Customer reported issues are also tracked in SBM as items of Type “DEF” Are also part of the “Sprint backlog” The sprint team uses SBM to assign these tasks to team members

53 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting SBM / Dimensions CM integration used to synchronize SBM items into ECR type Requests in Dimensions Once an ENH or DEF has been assigned it appears as an ECR in the Dimensions inbox of the developer CM rules are enabled for the Request and Items Developers performs development in different ways Command line (Download / Upload) Graphical Synchronize tool (Synchronize) Eclipse integration (Synchronize) Project Merge tool (Project vs. Workspace)

54 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting When synchronizing back to the repository Developers first check (using Synchronize tools of the different interface) if there are any conflicts If there are conflicts Developers are merging into their local file system (manually or using the synchronize tools again) Build and Test Then the developers perform the check-in The Check-in are done frequently (most developers do it at least once a day)

55 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Sprint team needs to be able to do internal code changes (such as refactoring) Individual developer create a Request of Type “EC” (Engineering Change) When any Task (EC or ECR) is completed: The request is delegated to a senior developer and actioned to “PEER REVIEW” state When peer review is completed the request is actioned to “ASSIGNED TO QA” The item in SBM is moved to a state where the QA manager is owner of the task

56 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting QA Manager assigns the SBM item to an individual tester Tester becomes owner of the SBM Item Tester is performing the test on an “integration” environment The integration environments are built continually Java code is built using Dimensions integration with Cruise Control every time someone checks-in Unit testing are performed in sequence and test results ed to key developers C/C++ code is built every night (using Dimensions Make) on every platform and unit test (command line and Cass level) are performed A baseline is taken first (latest item revision) then the baseline is built

57 Continuous Integration
Many Ways to Implement in Dimensions Cruise Control Java integration Anthill integration Many Different Build Tools and CI Tools in Serena Deployment Areas Always updated with a check-in Can be examined for change to trigger build Allow the CI build without a get Integrates with just about any tool Easy to setup

58 Testing and Code Coverage
Automated Testing Tests kept in same repository Same or different projects Different access privileges Failed tests fail the baseline Optional check-in of artifacts from build Code Coverage Results from Tests and Code Coverage go into TeamTrack/SBM

59 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting QA staff Develop test specifications / plans as tasks within the sprint Perform testing of features delivered by the sprint team (picking up the nightly build) Doc staff Develop User Guides, Online Help, Release Notes … as tasks within the sprint

60 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Daily stand up meeting (typically in the morning) Each team discuss What have been done the day before What is plan for the day What are the blockers Issues raised can lead to further meetings Working on solving the issues Daily update of the Sprint Backlog (typically end of the day) Burndown chart produced

61 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Multiple Sprint teams work in parallel Scrum of scrums meeting are regularly hold for scrum masters Progress shared with a larger audience

62 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting At the end of a Sprint Sprint review meeting Presentation by the sprint teams of their progress Demonstration of their work Retrospective of the Sprint What worked well What can be improved

63 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting When planned development work have been completed Go to a “Stabilization” phase QA perform regression tests Nightly build continue; QA works on weekly build Defects found are addressed Defects are entered into SBM as DEF type items Report on these defect is run daily to assess if they need to be Deferred Investigated Fixed Returned to QA for more info

64 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting When Defects are assigned to the developer the same process are during development is performed SBM / CM integration is triggered Requests are created in Dimensions When close to the end of a release “Surgical” build with only “approved” changes are done The baseline is “revised” with some specific approved Request (only those additional request will be included in the build)

65 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Toward the end of a release typically the work on the next release is started A separate “Project” for the next release is set up Parallel work for the two releases is managed Local replication is set up so that changes in the “current Release” are automatically included in the “next release” Resolve Merge Conflicts are regularly performed for the “next Release”

66 Potentially Shippable
SERENA R&D Process 30 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting Parallel Development when a Patch is needed A separate project and a named branch is created for the Patch Development will occur in that Project the same way as for a main release Once the Patch has been through QA and released The Patch can be merged into the main release Import request feature is used The changed revision are brought into the main project The conflict are then resolved

67 Les « Offres Solutions » de SERENA

68 Solution Capabilities
Lifecycle Process Mgmt Project Collaboration (Sharepoint) Lifecycle Dashboards KPIs, Metrics & Reporting 3P Tool Connectors Lifecycle Processes RUP, AUP, DO178B Request Mgmt Request Routing Project Request Approval Portfolio Mgmt Resource Mgmt Rqmts Capture Project Mgmt Requirements Mgmt Rqmts Change Management Traceability & Reporting Rqmts Reuse Variant Management Prototyping & Simulation Release Mgmt Release Planning & Control Release Vault Release Automation Development Mgmt Issue & Defect Mgmt Task & Work Mgmt SW Change & Config Mgmt Build Mgmt Agile & Trad. Project Mgmt Quality Mgmt Remedy HP Svc Ctr Serena ITSM Svc Desk Doors ReqPro Reqmts RSM MatLab Rhapsody Modeling MS Project Proj HP QC LDRA Parasoft Test Hudson Maven Build SERENA SOFTWARE INC.

69 App Delivery Lifecycle
Demand Management Demand Manager Requirements Management Development Management Release Management Demand categorization & routing (SBM, 3P) Project request approval (SBM, PPM) Requirements definition (SBM) Portfolio management (PPM) Financial management (PPM) Resource & time management (PPM) App Delivery Lifecycle (SBM) App Delivery Lifecycle IT Service Management KPIs & Reporting Discretionary vs. non-discretionary Average IT cost per customer Investment mix Plan vs. actual costs Resource utilization Demand vs. capacity Integrations Help Desk: Remedy, HP Service Center, Serena ITSM SBM, PPM SERENA SOFTWARE INC.

70 Requirements Management
Demand Management Requirements Manager Development Management Release Management Reqmts change management (SBM, RM, 3P) Publish comment & review (SBM, RM, 3P) Requirements prototyping (PC) Traceability and reporting (RM) Requirements reuse (RM) Variant management (RM) App Delivery Lifecycle (SBM) App Delivery Lifecycle IT Service Management KPIs & Reporting Requirements growth Requirements volatility Requirements acceptance Requirements verified Project complexity Integrations SW Quality: HP QC Modeling: Rhapsody, System Architect Config Mgmt: CM SBM, PC, RM SERENA SOFTWARE INC.

71 Development Management: Enterprise
Demand Management Requirements Management Enterprise Developer Release Management Issue & defect management (SBM) Task management (SBM) Modeling & design (3P) Traditional project management (Project, 3P) Software change & config mgmt (CM) Software quality (SBM, Partner) Build management (CM, 3P) App Delivery Lifecycle IT Service Management KPIs & Reporting Find/fix rate Defects per KLOC Percent successful builds Test coverage Integrations SW Quality: HP QC Build: Hudson, Maven Reqmts: RM, Doors, ReqPro Design: RSM Project Mgmt: MS Project SBM,PPM, Project, Dim CM SERENA SOFTWARE INC.

72 Development Management: Agile
Demand Management Requirements Management Agile Developer Release Management Issue & defect management (SBM) Task management (SBM) Modeling & design (3P) Agile project management (Agile) Software change & config mgmt (CM) Software quality (SBM, Partner) Build management (CM, 3P) App Delivery Lifecycle IT Service Management KPIs & Reporting Find/fix rate Team velocity Defects per KLOC Percent successful builds Test coverage Integrations SW Quality: HP QC Build: Hudson, Maven Reqmts: RM, Doors, ReqPro Design: RSM Project Mgmt: MS Project SBM, Agile, Project, Dim CM SERENA SOFTWARE INC.

73 Development Management: Professional
Demand Management Requirements Management Professional Developer Release Management Issue & defect management (SBM) Task management (SBM) Agile project management (Agile) Software change & config mgmt (PVCS VM) Software quality (SBM, Partner) Build management (3P) App Delivery Lifecycle IT Service Management KPIs & Reporting Find/fix rate Team velocity Defects per KLOC Percent successful builds Test coverage Integrations SW Quality: HP QC SCM: SVN, TFS, Perforce Project Mgmt: MS Project SBM, Agile, PC, PVCS VM SERENA SOFTWARE INC.

74 Development Management: Embedded
Demand Management Requirements Management Embedded Developer Release Management Issue & defect management (SBM) Task management (SBM) Modeling & design (3P) Agile project management (Agile) Traditional project management (Project, 3P) Software change & config mgmt (CM) Software quality (SBM, Partner) Build management (CM, 3P) App Delivery Lifecycle (SBM) App Delivery Lifecycle IT Service Management KPIs & Reporting Requirements growth Requirements acceptance Requirements volatility Change verified Baseline acceptance Failure discovery rate Integrations SW Quality: LDRA, Parasoft Reqmts: Dim RM, DOORS Model: MATLAB, Simulink, Rhapsody SBM, Agile, Project, PC, CM SERENA SOFTWARE INC.

75 App Delivery Lifecycle
Release Management Demand Management Requirements Management Development Management Release Manager Release planning & control (SBM) Release deployment (SBM, CM, ZMF, 3P) Release vault (CM) Release automation (Nolio) App Delivery Lifecycle (SBM) App Delivery Lifecycle IT Service Management KPIs RFCs implemented RFCs completed RFC cost RFC time to implement RFC time to deploy Integrations Help Desk: Remedy, HP Service Desk, Serena ITSM Release Vault: PVCS VM, SVN, Endevor, Clear case SBM, CM, ZMF, Nolio SERENA SOFTWARE INC.

76 Serena IT Solution Landscape
Request Management Service Catalog / Demand Portfolio Analysis Resource Mgmt Requirements Mgmt Develop Chg & Config Mgmt Work & Project Mgmt Quality Management Deploy Release Control Release Vault Release Automation App Delivery Lifecycle Operate Incident Management Problem Management IT Config Management IT Change Management IT Service Lifecycle SERENA SOFTWARE INC.