serena : processus agile 23 novembre 2010 serena software inc. 23 nov 2010 sylvain cailliau
TRANSCRIPT
SERENA : Processus Agile23 Novembre 2010
SERENA SOFTWARE INC.
23nov 2010
Sylvain CAILLIAU
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.2
L’offre « AGILE » deSERENA
3
Développement d’ApplicationsDéveloppement d’Applications
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
4
Le Cycle de vie applicatifLe Cycle de vie applicatif
Vis
ualiser
Defi
nir
Con
cevoir
Dévelo
pp
er
Fab
riq
uer
Teste
r
Dép
loyer
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
5
La Gestion du Cycle de vie applicatifLa Gestion du Cycle de vie applicatif
Vis
ualiser
Défi
nir
Con
cevoir
Dévelo
pp
er
Fab
riq
uer
Teste
r
Dép
loyer
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
Exécution des projets maîtrisée
Processus répétables
Artéfacts logiciels gérés
6
Une réalité constatée…Une réalité constatée…
Vis
ualiser
Defi
nir
Con
cevoir
Dévelo
pp
er
Fab
riq
uer
Teste
r
Dép
loyer
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
Exécution des projets maîtrisée
Processus répétables
Artéfacts logiciels gérés
Budget DépasséBudget Dépassé
Planning non-respectéPlanning non-respecté
Qualité insuffisanteQualité insuffisante
Non conforme au BusinessNon conforme au Business
7
Le cycle de vie applicatifLe cycle de vie applicatif
Vis
ualiser
Defi
nir
Con
cevoir
Dévelo
pp
er
Fab
riq
uer
Teste
r
Dép
loyer
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
Exécution des projets maîtrisée
Processus répétables
Artéfacts logiciels gérés
On doit pouvoirOn doit pouvoirfaire mieux …faire mieux …
8
La méthode traditionnelle…La méthode traditionnelle…
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
Analysedes Exigences
Système
Analysedes Exigences
ConceptionGénérale
ConceptionDétaillée
Code et testsunitaires
Intégration ettests
d’intégration
Installation etDéploiement
Exploitation etMaintenace
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
stabilisation9
• 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
Emergence de l’Agilité
10
La Méthode Agile… !La Méthode Agile… !
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Demandes deNouvelles applis
DemandesD’amélioration
Problèmes
Défauts
Str
atég
iqu
eT
acti
qu
e
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
11
Temps
&
Argent
Compromis
!@#$%Multi-Tout !Equipes
ProjetsGéographies
Les méthodes Agiles deviennent stratégiques
12
Serena Agile On DemandConçu pour une utilisation d’entreprise
Dans l’esprit « lean »
mais pour une
utilisation globale
Conçu par
des experts
Support
pour le
multi-Tout !
Une
nouvelle
façon de
passer à
l’Agilité
13
Jeff McKenna Chief Agile Evangelist Co-créateur de Scrum
Paul Dupuy Product Owner Auteur de nombreuses publications sur l’Agilité
100% Pure Agile
Simple àutiliser
Plus de
succès
Support de
multiples
méthodesagiles
14
• 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• …
L’Equipe Agile
15
• Aplanir les obstacles
• Contrôler le processus
• Maintenir l’équipe en mouvement
• S’assurer du “bon fonctionnement” de l’équipe
Le rôle du Scrum Master
16 16
• 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, …
Release Planning – “Sprint 0”
17
• 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é
Release Planning - “Sprint 0”
18
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
SprintingSprinting
2-5 semaines
2-3 jours(PLANNING)
RECAP,DEMO,
RETROSPECTIVE,RELEASE,KICK-OFF
Planifier Faire Vérifier AdapterPlanifier Faire Vérifier Adapter
20
• 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
Backlog et Gestion de la Demande
• Listes Excel• Outil d’import
• SBM• Intégration directe• Mise à jour bi-directionnelle
22
Le processus complet
Customers, Business Owners,
StakeholdersBusiness Analysts,
Product Owners
Demandes Projet Deploiement
23
Intégration SBM / AOD
24
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)
25
• 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.
Une “User Story” c’est quoi?
26 26
• 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)
Une User Story c’est quoi d’autre ?
27
• 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)
Comment déterminer la taille d’une “User Story”?
28 28
Sprint Backlog Planning
Drag & drop depuis le backlog
produit vers le sprint
Découpage
des User
Stories en
Tâches
29
Ecrire et évaluer les User Stories
Définir les critères
d’acceptance
Estimer le
travail et
visualiser
les résultats
aggrégés
Définir les priorités et la valeur
business …
30
• 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”)
Gérer les activités
31
User Stories et Tâches
Affiner les
User
Stories
en TâchesElaboration
et estimationdes tâches
32
• 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”
Planification incrémentale
33
• 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
La mêléé quotidienne
34
Mêlée quotidienne virtuelle …
Rapide et
facile à
mettre à
jour par les
développeur
s
Burn-down charts et
collaboration !
35
Réputés « meilleurs outils » pour les petites équipes…
36
Collaboration avec n’importe quelle équipe, n’importe où
Les post-itsne sont pasextensibles
Le tableau
virtuel des
Cartes
Glisser-déposer
vosCartes
37
• 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
Comment réussir la mise en place dans votre organisation
38
Une communauté d’experts en Ligne
Produit blo
gs & forum
s
Meilleurespratiques & trucs et astucesproduit
39
Le processus Agile appliqué par la R&D SERENA
40
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
41
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
42
Méthodologie
• All using Agile Methodology• SCM rules adjustable per project on the fly• Continuous integration• Extreme programming rules in place
43
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
44
Configuration côté serveur
45
Configuration Library Cache
46
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
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
48
Dimensions utilisé pour contrôler les
développementsDe Dimensions
49
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
50
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
SERENA R&D Process
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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 10.1.3: 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 Owners51
• 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
52
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
53
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
54
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
55
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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 emailed 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
56
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
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
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
• 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
59
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
Progress
752 762
664619
304264
180104
200
100
200
300
400
500
600
700
800
900
Date
Rem
ain
ing
Eff
ort
in
Ho
urs
SERENA R&D Process
60
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
61
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
62
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
63
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
64
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
65
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
• 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
66
30 days
24 hoursProduct BacklogAs prioritized by Product Owner
Sprint Backlog
Backlog tasksexpandedby team
Potentially ShippableProduct Increment
Daily ScrumMeeting
Les « Offres Solutions » de SERENA
67
Solution Capabilities
SERENA SOFTWARE INC.68
Lifecycle Process MgmtLifecycle Process MgmtLifecycle Process MgmtLifecycle Process Mgmt
Project Project Collaboration Collaboration (Sharepoint)(Sharepoint)
Project Project Collaboration Collaboration (Sharepoint)(Sharepoint)
LifecycleLifecycleDashboardsDashboards
LifecycleLifecycleDashboardsDashboards
KPIs, Metrics & KPIs, Metrics & ReportingReporting
KPIs, Metrics & KPIs, Metrics & ReportingReporting
3P Tool 3P Tool ConnectorsConnectors
3P Tool 3P Tool ConnectorsConnectors
Lifecycle Lifecycle ProcessesProcessesLifecycle Lifecycle
ProcessesProcesses
RUP, AUP, DO178B
Release MgmtRelease MgmtRelease MgmtRelease Mgmt
Release Release Planning Planning & Control& Control
Release Release Planning Planning & Control& Control
Release VaultRelease VaultRelease VaultRelease Vault
Release Release AutomationAutomation
Release Release AutomationAutomation
Development MgmtDevelopment MgmtDevelopment MgmtDevelopment Mgmt
Issue & Issue & Defect MgmtDefect Mgmt
Issue & Issue & Defect MgmtDefect Mgmt
Task & Work Task & Work MgmtMgmt
Task & Work Task & Work MgmtMgmt
SW Change &SW Change &Config MgmtConfig MgmtSW Change &SW Change &Config MgmtConfig Mgmt
Build MgmtBuild MgmtBuild MgmtBuild MgmtAgile & Trad. Agile & Trad. Project MgmtProject MgmtAgile & Trad. Agile & Trad. Project MgmtProject Mgmt
Quality MgmtQuality MgmtQuality MgmtQuality Mgmt
Request MgmtRequest MgmtRequest MgmtRequest Mgmt
Request RoutingRequest RoutingProject Request Project Request
ApprovalApproval
Request RoutingRequest RoutingProject Request Project Request
ApprovalApproval
Portfolio MgmtPortfolio MgmtResource MgmtResource MgmtPortfolio MgmtPortfolio MgmtResource MgmtResource Mgmt
Rqmts CaptureRqmts CaptureRqmts CaptureRqmts Capture
Project MgmtProject MgmtProject MgmtProject Mgmt
Requirements MgmtRequirements MgmtRequirements MgmtRequirements MgmtRqmts Change Rqmts Change ManagementManagement
Rqmts Change Rqmts Change ManagementManagement
Traceability & Traceability & ReportingReporting
Rqmts ReuseRqmts ReuseVariant ManagementVariant Management
Traceability & Traceability & ReportingReporting
Rqmts ReuseRqmts ReuseVariant ManagementVariant ManagementPrototyping & Prototyping &
SimulationSimulationPrototyping & Prototyping &
SimulationSimulation
RSMMatLab
Rhapsody
Modeling
RemedyHP Svc Ctr
Serena ITSM
Svc Desk
DoorsReqPro
Reqmts
HP QCLDRA
Parasoft
Test
HudsonMaven
Build
MS Project
Proj
Demand Management
SERENA SOFTWARE INC.69
Demand ManagerDemand Manager
• 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, PPMSBM, PPM
IntegrationsIntegrations
Help Desk: Remedy, HP Service Center, Serena ITSM
KPIs & ReportingKPIs & ReportingDiscretionary vs. non-discretionaryAverage IT cost per customerInvestment mix
Plan vs. actual costsResource utilizationDemand vs. capacity
Requirements Management
SERENA SOFTWARE INC.70
Requirements ManagerRequirements Manager
• 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)
SBM, PC, RMSBM, PC, RM
IntegrationsIntegrations
SW Quality: HP QCModeling: Rhapsody, System ArchitectConfig Mgmt: CM
KPIs & ReportingKPIs & ReportingRequirements growthRequirements volatilityRequirements acceptance
Requirements verifiedProject complexity
Development Management: Enterprise
SERENA SOFTWARE INC.71
Enterprise DeveloperEnterprise Developer
• 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)
SBM,PPM, SBM,PPM, ProjectProject, Dim CM, Dim CM
IntegrationsIntegrations
SW Quality: HP QCBuild: Hudson, MavenReqmts: RM, Doors, ReqPro
KPIs & ReportingKPIs & ReportingFind/fix rateDefects per KLOC
Percent successful buildsTest coverage
Design: RSMProject Mgmt: MS Project
Development Management: Agile
SERENA SOFTWARE INC.72
Agile DeveloperAgile Developer
• 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)
SBM, Agile, SBM, Agile, ProjectProject, Dim CM, Dim CM
IntegrationsIntegrations
SW Quality: HP QCBuild: Hudson, MavenReqmts: RM, Doors, ReqPro
KPIs & ReportingKPIs & ReportingFind/fix rateTeam velocityDefects per KLOC
Percent successful buildsTest coverage
Design: RSMProject Mgmt: MS Project
Development Management: Professional
SERENA SOFTWARE INC.73
Professional DeveloperProfessional Developer
• 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)
SBM, Agile, PC, PVCS VMSBM, Agile, PC, PVCS VM
IntegrationsIntegrations
SW Quality: HP QCSCM: SVN, TFS, Perforce
KPIs & ReportingKPIs & ReportingFind/fix rateTeam velocityDefects per KLOC
Percent successful buildsTest coverage
Project Mgmt: MS Project
Development Management: Embedded
SERENA SOFTWARE INC.74
Embedded DeveloperEmbedded Developer
• 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)
SBM, Agile, SBM, Agile, ProjectProject, PC, CM, PC, CM
IntegrationsIntegrations
SW Quality: LDRA, ParasoftReqmts: Dim RM, DOORSModel: MATLAB, Simulink, Rhapsody
KPIs & ReportingKPIs & ReportingRequirements growthRequirements acceptanceRequirements volatility
Change verifiedBaseline acceptanceFailure discovery rate
Release Management
SERENA SOFTWARE INC.75
Release ManagerRelease Manager
IntegrationsIntegrations
Help Desk: Remedy, HP Service Desk, Serena ITSMRelease Vault: PVCS VM, SVN, Endevor, Clear case
KPIsKPIs
RFCs implementedRFCs completedRFC cost
RFC time to implementRFC 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)
SBM, CM, ZMF, NolioSBM, CM, ZMF, Nolio
Serena IT Solution Landscape
SERENA SOFTWARE INC.76
DevelopDevelopDevelopDevelopChg & Config MgmtWork & Project MgmtQuality Management
DemandDemandDemandDemandPortfolio AnalysisResource MgmtRequirements Mgmt
DeployDeployDeployDeployRelease ControlRelease Vault
OperateOperateOperateOperateIncident ManagementProblem ManagementIT Config ManagementIT Change Management