La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "SERENA : Processus Agile 23 Novembre 2010 SERENA SOFTWARE INC. 23 nov 2010 Sylvain CAILLIAU."— Transcription de la présentation:

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

2 Agenda Loffre 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. 2

3 Loffre « AGILE » de SERENA 3

4 Développement dApplications Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique 4

5 Le Cycle de vie applicatif VisualiserDefinirConcevoirDévelopperFabriquerTesterDéployer Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique 5

6 La Gestion du Cycle de vie applicatif VisualiserDéfinirConcevoirDévelopperFabriquerTesterDéployer Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique Exécution des projets maîtrisée Processus répétables Artéfacts logiciels gérés 6

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

8 Le cycle de vie applicatif VisualiserDefinirConcevoirDévelopperFabriquerTesterDéployer Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique Exécution des projets maîtrisée Processus répétables Artéfacts logiciels gérés On doit pouvoir faire mieux … 8

9 La méthode traditionnelle… Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique Analyse des Exigences Système Analyse des Exigences Conception Générale Conception Détaillée Code et tests unitaires Intégration et tests dintégration Installation et Déploiement Exploitation et Maintenace 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 9

10 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 LAgilité a émergée dans les environnements où cette approche était impossible ou inappropriée Le changement est encouragé Les processus sont empiriques Emergence de lAgilité 10

11 La Méthode Agile… ! Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes Damélioration Problèmes Défauts Stratégique Tactique 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 dune robustesse et dune dune 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 sexécutant à minima toutes les nuits 11

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

13 Serena Agile On Demand Conçu pour une utilisation dentreprise Dans lesprit « lean » mais pour une utilisation globale Conçu par des experts Support pour le multi-Tout ! Une nouvelle façon de passer à lAgilité 13

14 Jeff McKenna Chief Agile Evangelist Co-créateur de Scrum Paul Dupuy Product Owner Auteur de nombreuses publications sur lAgilité 100% Pure Agile Simple à utiliser Plus de succès Support de multiples méthodes agiles 14

15 Multi-compétente Toutes les fonctions et expertises requises pour réaliser le produit / lapplication 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 lAssistance Maîtrise dOuvrage) Membre de léquipe Développeurs Testeurs Rédacteurs … LEquipe Agile 15

16 Aplanir les obstacles Contrôler le processus Maintenir léquipe en mouvement Sassurer du bon fonctionnement de léquipe Le rôle du Scrum Master16 16

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

18 Chaque élément de la Backlog est affecté dune 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 lissue du Sprint 0, une revue du plan de livraisons est faîte et le premier Sprint est lancé Release Planning - Sprint 0 18

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

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

21 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 Définition et Planning du Sprint 21

22 Backlog et Gestion de la Demande Listes Excel Outil dimport SBM Intégration directe Mise à jour bi-directionnelle 22

23 Le processus complet Customers, Business Owners, Stakeholders Business Analysts, Product Owners Demandes Projet Deploiement 23

24 Intégration SBM / AOD 24

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

26 Une brève description dune activité quil faut réaliser Initialement les Stories définissent des activités qui ont pour but dajouter des fonctionnalités à un produits … mais … Elles peuvent concerner dautres domaines comme lArchitecture, la Conception de Haut Niveau, des Bugs à corriger … voire (dans le cas de XP) des Dettes à payer. Une User Story cest quoi? 26 26

27 Les détails dune Story sont obtenus par conversation / interaction avec le Product Owner Cest forcément bref : le Just enough documentation Les critères dacceptation sont obligatoire pour permettre de confirmer quune Story a été implémentée correctement (ce qui va dans le sens du TDD) Une User Story cest quoi dautre ? 27

28 Lestimation 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) Comment déterminer la taille dune User Story? 28 28

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

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

31 Les User Stories pilotent le développement et les tests Les Développeurs les utilisent pour déterminer ce quil faut construire Les Testeurs pour déterminer ce quil 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) Gérer les activités 31

32 User Stories et Tâches Affiner les User Stories en Tâches Elaboration et estimation des tâches 32

33 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 Cest de là que vient lexpression Scrum (mêlée) Parfois le processus peut être brutal Planification incrémentale 33

34 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 quil a fait depuis le veille, ce quil va faire aujourdhui et précises toutes les difficultés ou blocages quil rencontre Les difficultés ou blocage seront résolus offline (responsabilité du Scrum Master) Tableau Blanc La mêléé quotidienne 34

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

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

37 Collaboration avec nimporte quelle équipe, nimporte où Les post-its ne sont pas extensibles Le tableau virtuel des Cartes Glisser-déposer vos Cartes 37

38 Faites vous assister ! Si vous navez pas dexpérience avec les méthodes Agiles, prenez conseil auprès dun 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 Comment réussir la mise en place dans votre organisation 38

39 Une communauté dexperts en Ligne Produit blogs & forums Meilleures pratiques & trucs et astuces produit 39

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

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

42 Les utilisateurs Un nombre dutilisateurs important Jusquà 150 connexions concurrentes Plusieurs centaines dutilisateurs 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 42

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

44 Solution de GCL en place Serveur Centralisé Pas de réplication Utilisation dOracle Bibliothèques dItem 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 44

45 Configuration côté serveur 45

46 Configuration Library Cache 46

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 47

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 48

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

50 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 days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

51 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:CM That Project had a default named branch: cm1013 Those Sprint Teams have resources for: Development QA Documentation And participation from the Product Owners 51

52 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

53 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) SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

54 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) SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

55 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

56 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

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 57

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 58

59 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

60 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

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

62 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

63 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

64 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) SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

65 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

66 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 SERENA R&D Process days 24 hours Product Backlog As prioritized by Product Owner Sprint Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Scrum Meeting

67 Les « Offres Solutions » de SERENA 67

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

69 Demand Management SERENA SOFTWARE INC. 69 Demand Manager Requirements Management Development Management Release Management App Delivery Lifecycle IT Service 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) 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) SBM, PPM Integrations Help Desk: Remedy, HP Service Center, Serena ITSM KPIs & Reporting Discretionary vs. non-discretionary Average IT cost per customer Investment mix Plan vs. actual costs Resource utilization Demand vs. capacity

70 Requirements Management SERENA SOFTWARE INC. 70 Requirements Manager Development Management Release Management App Delivery Lifecycle IT Service 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) 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) Demand Management SBM, PC, RM Integrations SW Quality: HP QC Modeling: Rhapsody, System Architect Config Mgmt: CM KPIs & Reporting Requirements growth Requirements volatility Requirements acceptance Requirements verified Project complexity

71 Development Management: Enterprise SERENA SOFTWARE INC. 71 Enterprise Developer Release Management App Delivery Lifecycle 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) 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) Demand Management Requirements Management SBM,PPM, Project, Dim CM Integrations SW Quality: HP QC Build: Hudson, Maven Reqmts: RM, Doors, ReqPro KPIs & Reporting Find/fix rate Defects per KLOC Percent successful builds Test coverage Design: RSM Project Mgmt: MS Project IT Service Management

72 Development Management: Agile SERENA SOFTWARE INC. 72 Agile Developer Release Management App Delivery Lifecycle 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) 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) Demand Management Requirements Management SBM, Agile, Project, Dim CM Integrations SW Quality: HP QC Build: Hudson, Maven Reqmts: RM, Doors, ReqPro KPIs & Reporting Find/fix rate Team velocity Defects per KLOC Percent successful builds Test coverage Design: RSM Project Mgmt: MS Project IT Service Management

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

74 Development Management: Embedded SERENA SOFTWARE INC. 74 Embedded Developer Release Management App Delivery Lifecycle IT Service 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) 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) Demand Management Requirements Management SBM, Agile, Project, PC, CM Integrations SW Quality: LDRA, Parasoft Reqmts: Dim RM, DOORS Model: MATLAB, Simulink, Rhapsody KPI s & Reporting Requirements growth Requirements acceptance Requirements volatility Change verified Baseline acceptance Failure discovery rate

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

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


Télécharger ppt "SERENA : Processus Agile 23 Novembre 2010 SERENA SOFTWARE INC. 23 nov 2010 Sylvain CAILLIAU."

Présentations similaires


Annonces Google