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

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



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







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







Problèmes

Défauts

Str

atég

iqu

eT

acti

qu

e




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







Problèmes

Défauts

Str

atég

iqu

eT

acti

qu

e




On doit pouvoirOn doit pouvoirfaire mieux …faire mieux …

8

La méthode traditionnelle…La méthode traditionnelle…







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

http://uk.gizmodo.com/borg.jpg

La Méthode Agile… !La Méthode Agile… !







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

http://community.serena.com/hives/2f3dcacea7/summary



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



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


Sprint Backlog



Daily ScrumMeeting

Les « Offres Solutions » de SERENA

67

Solution Capabilities


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


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


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


SW Quality: HP QCModeling: Rhapsody, System ArchitectConfig Mgmt: CM

KPIs & ReportingKPIs & ReportingRequirements growthRequirements volatilityRequirements acceptance

Requirements verifiedProject complexity

Development Management: Enterprise


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


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


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


SW Quality: HP QCBuild: Hudson, MavenReqmts: RM, Doors, ReqPro

KPIs & ReportingKPIs & ReportingFind/fix rateTeam velocityDefects per KLOC


Design: RSMProject Mgmt: MS Project

Development Management: Professional


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


SW Quality: HP QCSCM: SVN, TFS, Perforce

KPIs & ReportingKPIs & ReportingFind/fix rateTeam velocityDefects per KLOC


Project Mgmt: MS Project

Development Management: Embedded


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


SW Quality: LDRA, ParasoftReqmts: Dim RM, DOORSModel: MATLAB, Simulink, Rhapsody

KPIs & ReportingKPIs & ReportingRequirements growthRequirements acceptanceRequirements volatility

Change verifiedBaseline acceptanceFailure discovery rate

Release Management


Release ManagerRelease Manager


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


DevelopDevelopDevelopDevelopChg & Config MgmtWork & Project MgmtQuality Management

DemandDemandDemandDemandPortfolio AnalysisResource MgmtRequirements Mgmt

DeployDeployDeployDeployRelease ControlRelease Vault

OperateOperateOperateOperateIncident ManagementProblem ManagementIT Config ManagementIT Change Management

Documents

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