Transcript Agile Process

SERENA : Processus Agile
23 Novembre 2010
23
Sylvain CAILLIAU
nov 2010
SERENA SOFTWARE INC.
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”
2
SERENA SOFTWARE INC.
L’offre « AGILE » de
SERENA
3
Stratégique
Développement d’Applications
Demandes de
Nouvelles applis
Demandes
D’amélioration
Tactique
Problèmes
Défauts
4
Stratégique
Le Cycle de vie applicatif
Demandes de
Nouvelles applis
Tactique
Défauts
5
Déployer
Tester
Fabriquer
Développer
Concevoir
Definir
Problèmes
Visualiser
Demandes
D’amélioration
Nouvelles applications
Applications améliorées
Applications corrigées
Applications retirées
Stratégique
La Gestion du Cycle de vie applicatif
Demandes de
Nouvelles applis
Tactique
Déployer
Tester
Fabriquer
Développer
Concevoir
Définir
Problèmes
Visualiser
Demandes
D’amélioration
Nouvelles applications
Applications corrigées
Applications retirées
Défauts
Artéfacts logiciels gérés
Processus répétables
Exécution des projets maîtrisée
6
Applications améliorées
Stratégique
Une réalité constatée…
Demandes de
Nouvelles applis
Tactique
Déployer
Tester
Fabriquer
Développer
Concevoir
Definir
Problèmes
Qualité insuffisante
Visualiser
Demandes
D’amélioration
Nouvelles applications
Applications améliorées
Planning non-respecté
Applications corrigées
Applications retirées
Défauts
Non conforme au Business
Artéfacts logiciels gérés
Processus répétables
Budget Dépassé
Exécution des projets maîtrisée
7
Stratégique
Le cycle de vie applicatif
Demandes de
Nouvelles applis
Déployer
Tester
Fabriquer
Développer
Concevoir
Definir
Visualiser
Demandes
D’amélioration
Nouvelles applications
Applications améliorées
On doit pouvoir
faire mieux …
Tactique
Problèmes
Applications retirées
Défauts
Artéfacts logiciels gérés
Processus répétables
Exécution des projets maîtrisée
8
Applications corrigées
Stratégique
La méthode traditionnelle…
Demandes de
Nouvelles applis
Demandes
D’amélioration
Analyse
des Exigences
Système
Analyse
des Exigences
Nouvelles applications
Conception
Générale
Conception
Détaillée
Applications améliorées
Code et tests
unitaires
Tactique
Problèmes
Applications corrigées
Intégration et
tests
d’intégration
Installation et
Déploiement
Défauts
•
•
•
•
•
9
Le Diagramme en Cascade
W.W. Royce, 1970
Exploitation et
Maintenace
Applications retirées
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
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
Toute résistance
est futile
• Contrôler le changement est désirable
• Les processus sont définis et/ou contrôlés
 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
Stratégique
La Méthode Agile… !
Tactique
Demandes de
Nouvelles applis
Nouvelles applications
Demandes
D’amélioration
Applications améliorées
Problèmes
Applications corrigées
Défauts
Applications retirées
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
Les méthodes
Agiles deviennent stratégiques
12
Serena Agile On Demand
Conçu pour une utilisation d’entreprise
13
100% Pure Agile
Jeff McKenna
Chief Agile Evangelist
Co-créateur de Scrum
Paul Dupuy
Product Owner
Auteur de nombreuses publications
sur l’Agilité
14
L’Equipe Agile
• Multi-compétente
• Toutes les fonctions et expertises requises pour réaliser le produit /
l’application sont dans l’équipe
• Impliqués de la conception à la livraison
• Tous sur un même plan (par de relation hiérarchique dans l’équipe)
• Rôles
• Scrum Master (autrefois le “Chef de Projet”)
• Product Owner (autrefois le “Responsable produit” ou “l’Assistance Maîtrise
d’Ouvrage”)
• Membre de l’équipe
•
•
•
•
15
Développeurs
Testeurs
Rédacteurs
…
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
1
6
16
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, …
17
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é
18
Conçu pour la gestion multi- équipes et
projets
19
Sprinting
2-5 semaines
2-3 jours
(PLANNING)
RECAP,
DEMO,
RETROSPECTIVE,
RELEASE,
KICK-OFF
Planifier Faire Vérifier Adapter
20
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
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,
Stakeholders
Demandes
Business Analysts,
Product Owners
Projet
Governance, Compliance, Reporting
23
Deploiement
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
• Amélioration
• Exigences
25
Tâche (Task)
Story
Fonctionnalité (Epic)
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.
2
6
26
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)
27
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)
2
8
28
Sprint Backlog Planning
29
Ecrire et évaluer les User Stories
30
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”)
31
User Stories et Tâches
32
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”
33
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
34
Mêlée quotidienne virtuelle …
35
Réputés « meilleurs outils » pour les
petites équipes…
36
Collaboration avec
n’importe quelle équipe, n’importe où
37
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
Une communauté d’experts en Ligne
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
•
•
•
•
42
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
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é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
Dimensions utilisé pour contrôler
les développements
De Dimensions
49
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Sprint Backlog
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
• “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
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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 Owners
51
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Sprint Backlog
52
Daily Scrum
Meeting
24 hours
Backlog tasks
expanded
by team
30 days
Potentially Shippable
Product Increment
• 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
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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
•
•
•
•
53
Command line (Download / Upload)
Graphical Synchronize tool (Synchronize)
Eclipse integration (Synchronize)
Project Merge tool (Project vs. Workspace)
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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)
54
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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
55
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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
56
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
•
•
•
•
•
57
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
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
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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
59
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
24 hours
Backlog tasks
expanded
by team
Potentially Shippable
Product Increment
30 days
Sprint Backlog
• Daily stand up meeting (typically in the morning)
• Each team discuss
• Working on solving the issues
600
500
400
300
200
100
0
752
762
664
619
304
264
180
104
20
3/
2
5/ 00
5/ 2
2
5/ 002
7/
2
5/ 00
9/ 2
5/ 200
11 2
5 / /2 0
13 02
/
5/ 200
15 2
/
5/ 200
17 2
5 / /2 0
19 02
/
5/ 200
21 2
5 / /2 0
23 02
/
5/ 200
25 2
/
5/ 20
27 02
/
5/ 200
29 2
5 / /2 0
31 02
/2
00
2
meetings
900
800
700
5/
• Issues raised can lead to further
Remaining Effort in Hours
• What have been done the day before
• What is plan for the day
• What are the blockers
Progress
Date
• Daily update of the Sprint Backlog (typically end of the day)
• Burndown chart produced
60
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• Multiple Sprint teams work in parallel
• Scrum of scrums meeting are regularly hold for scrum masters
• Progress shared with a larger audience
61
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Sprint Backlog
• 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
62
Potentially Shippable
Product Increment
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• When planned development work have been completed
• Go to a “Stabilization” phase
•
•
•
•
•
63
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
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
24 hours
Backlog tasks
expanded
by team
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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)
64
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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”
65
SERENA R&D
Process
Product Backlog
As prioritized by
Product Owner
Daily Scrum
Meeting
Backlog tasks
expanded
by team
24 hours
30 days
Potentially Shippable
Product Increment
Sprint Backlog
• 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
66
Les « Offres Solutions » de
SERENA
67
Solution Capabilities
Lifecycle Process Mgmt
Project
Collaboration
(Sharepoint)
Lifecycle
Dashboards
Lifecycle
Processes
KPIs, Metrics &
Reporting
3P Tool
Connectors
RUP, AUP, DO178B
Request Mgmt
Request Routing
Project Request
Approval
Requirements Mgmt
Rqmts Change
Management
Traceability & Reporting
Rqmts Reuse
Variant Management
Prototyping &
Simulation
Portfolio Mgmt
Resource Mgmt
Development Mgmt
Project Mgmt
Issue & Defect
Mgmt
SW Change &
Config Mgmt
Remedy
HP Svc Ctr
Serena ITSM
68
Release Planning
& Control
Release Vault
Quality Mgmt
Rqmts Capture
Svc Desk
Release Mgmt
Release
Automation
Task & Work
Mgmt
Agile & Trad.
Project Mgmt
Build Mgmt
Reqmts
Modeling
Doors
ReqPro
HP QC
RSM
MS Project
LDRA
MatLab
SERENA SOFTWARE INC.Parasoft
Rhapsody
Proj
Test
Build
Hudson
Maven
Demand Management
Discretionary vs. non-discretionary Plan vs. actual costs
Resource utilization
Average IT cost per customer
Demand vs. capacity
Investment mix
Integrations
Help Desk: Remedy, HP Service Center, Serena ITSM
SBM, PPM
IT Service Management
69
SERENA SOFTWARE INC.
Release Management
KPIs & Reporting
Development 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)
Requirements Management
App Delivery
Lifecycle
Demand Manager
Requirements 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
IT Service Management
70
SERENA SOFTWARE INC.
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)
Development Management
Demand Management
App Delivery
Lifecycle
Requirements Manager
Development Management: Enterprise
• 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)
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
IT Service Management
71
SERENA SOFTWARE INC.
Release Management
Requirements Management
Demand Management
App Delivery
Lifecycle
Enterprise Developer
Development Management: Agile
• 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)
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
IT Service Management
72
SERENA SOFTWARE INC.
Release Management
Requirements Management
Demand Management
App Delivery
Lifecycle
Agile Developer
Development Management:
Professional
• Issue & defect management (SBM)
• Task management (SBM)
• Agile project management (Agile)
• Software change & config mgmt (PVCS VM)
• Software quality (SBM, Partner)
• Build management (3P)
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
IT Service Management
73
SERENA SOFTWARE INC.
Release Management
Requirements Management
Demand Management
App Delivery
Lifecycle
Professional Developer
Development Management: Embedded
• 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)
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
IT Service Management
74
SERENA SOFTWARE INC.
Release Management
Requirements Management
Demand Management
App Delivery
Lifecycle
Embedded Developer
Release Management
Development Management
Requirements Management
Demand Management
App Delivery
Lifecycle
Release Manager
•
•
•
•
•
Release planning & control (SBM)
Release deployment (SBM, CM, ZMF, 3P)
Release vault (CM)
Release automation (Nolio)
App Delivery Lifecycle (SBM)
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
IT Service Management
75
SERENA SOFTWARE INC.
76
Demand
Develop
Portfolio Analysis
Resource Mgmt
Requirements Mgmt
Chg & Config Mgmt
Work & Project Mgmt
Quality Management
Operate
Incident Management
Problem Management
IT Config Management
IT Change Management
SERENA SOFTWARE INC.
Deploy
Release Control
Release Vault
Release Automation
Service Catalog /
Request Management
IT Service
Lifecycle
App Delivery
Lifecycle
Serena IT Solution Landscape