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

Développement d’ApplicationsDéveloppement d’Applications

Demandes deNouvelles applis

DemandesD’amélioration

Problèmes

Défauts

Le Cycle de vie applicatifLe Cycle de vie applicatif

ualiser

cevoir

Dévelo

Nouvelles applications

Applications améliorées

Applications corrigées

Applications retirées

Problèmes

Défauts

La Gestion du Cycle de vie applicatifLa Gestion du Cycle de vie applicatif

ualiser

cevoir

Dévelo

Problèmes

Défauts

Exécution des projets maîtrisée

Processus répétables

Artéfacts logiciels gérés

Une réalité constatée…Une réalité constatée…

ualiser

cevoir

Dévelo

Problèmes

Défauts

Budget DépasséBudget Dépassé

Planning non-respectéPlanning non-respecté

Qualité insuffisanteQualité insuffisante

Non conforme au BusinessNon conforme au Business

Le cycle de vie applicatifLe cycle de vie applicatif

ualiser

cevoir

Dévelo

Problèmes

Défauts

On doit pouvoirOn doit pouvoirfaire mieux …faire mieux …

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

Problèmes

Défauts

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é

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

Problèmes

Défauts

Planifier, Faire, Vérifier, Adapter

Equipes Multi-compétentes qui intègrent le client (ou son “proxy”) le développement, les tests et les autres profils nécessaires

Livraison Incrémentale de fonctionnalités d’une robustesse et d’une d’une qualité de « niveau production » à des intervalles réguliers

Développements dirigés par les tests (TDD) pour mettre la qualité au premier rang des préoccupations

Fabrication, tests et rapports Automatisés s’exécutant à minima toutes les nuits

Argent

Compromis

!@#$%Multi-Tout !Equipes

ProjetsGéographies

Les méthodes Agiles deviennent stratégiques

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 !

nouvelle

façon de

passer à

l’Agilité

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

• 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

• 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

• 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”

• 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”

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

planification

puissants

SprintingSprinting

2-5 semaines

2-3 jours(PLANNING)

RECAP,DEMO,

RETROSPECTIVE,RELEASE,KICK-OFF

Planifier Faire Vérifier AdapterPlanifier Faire Vérifier Adapter

• 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

Backlog et Gestion de la Demande

• Listes Excel• Outil d’import

• SBM• Intégration directe• Mise à jour bi-directionnelle

Le processus complet

Customers, Business Owners,

StakeholdersBusiness Analysts,

Product Owners

Demandes Projet Deploiement

Intégration SBM / AOD

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)

• 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?

• 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 ?

• 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”?

Sprint Backlog Planning

Drag & drop depuis le backlog

produit vers le sprint

Découpage

des User

Stories en

Tâches

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 …

• 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

User Stories et Tâches

Affiner les

Stories

en TâchesElaboration

et estimationdes tâches

• 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

• 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

Mêlée quotidienne virtuelle …

Rapide et

facile à

mettre à

jour par les

développeur

Burn-down charts et

collaboration !

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

Collaboration avec n’importe quelle équipe, n’importe où

Les post-itsne sont pasextensibles

Le tableau

virtuel des

Cartes

Glisser-déposer

vosCartes

• 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

Une communauté d’experts en Ligne

Produit blo

gs & forum

Meilleurespratiques & trucs et astucesproduit

Le processus Agile appliqué par la R&D SERENA

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

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

Méthodologie

• All using Agile Methodology• SCM rules adjustable per project on the fly• Continuous integration• Extreme programming rules in place

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

Configuration côté serveur

Configuration Library Cache

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

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

Dimensions utilisé pour contrôler les

développementsDe Dimensions

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

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

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

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

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

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

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

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

• 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

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

SERENA R&D Process

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

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

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

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

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

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

30 days

Sprint Backlog

Daily ScrumMeeting

Les « Offres Solutions » de SERENA

Solution Capabilities

Lifecycle Process MgmtLifecycle Process MgmtLifecycle Process MgmtLifecycle Process Mgmt

Project Project Collaboration Collaboration (Sharepoint)(Sharepoint)

LifecycleLifecycleDashboardsDashboards

KPIs, Metrics & KPIs, Metrics & ReportingReporting

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 VaultRelease VaultRelease VaultRelease Vault

Release Release AutomationAutomation

Development MgmtDevelopment MgmtDevelopment MgmtDevelopment Mgmt

Issue & Issue & Defect MgmtDefect Mgmt

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

HudsonMaven

MS Project

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)

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)

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)

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)

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)

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)

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)

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

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

Documents

JOUE-LA COMME SERENA

Serena 2 - Les données des réserves naturelles...Masque de saisie pour les protocoles communs La COBS : affichage (RNF) Serena 2 Logiciel de gestion de base de données naturalistes

LA COORDINATION ET LA JUXTAPOSITION Présentée par June NGUYEN, Kelly NGUYEN-JEAN et Serena SAN

SERENA - Porada0... · 2019. 10. 22. · SERENA Design E. Gallina SDA CAR 2019 AVORIO Ivory (RAL 1013) NERO Black (RAL 9005) ARGILLA Argilla (RAL 7006) GRANATA Granata (NCS S4050Y90R)

Copie de Flyer tennis v1tcseynod.com/assets/Flyer tennis.pdfJoueuse : Serena Williams Point fort : coup droit 06 68 14 89 46 associationadhérents sportivejeunes enfants à l ’école

Serena Paie

tt info - serena-anr.cirad.fr

Gruppo di lavoro: Serena, Sveva, Loris,William. diapositive a cura di Serena

CAT Tennis News N.79 · Victoria Azarenka - BLR Doubles Dames / Women’s Doubles : Médaille d’Or / Gold Medal : Serena & Venus Williams - USA ... intéressant sur ce plan

Série “Serena” · Affichage date/heure/nbe de cycles réalisés. Affichage des paramètres de sélection: ... Poids 18 lt > 45 kg - 23 lt > 50 kg Bruit moyenne/max 61/65,5 dB

EDITORIAL - belgodere.fr · Merci à Marie-Ange Albertini, Serena Canioni, Laurent Ceccaldi, Pierre Colombani, Béatrice Habrard, Dominique Spadini, José Aldobrandi, Antoine-Léonard

serena vieux port

Poule 1 (44 kg) Tapis 1 - FFJUDO · CV POULAIN Juliette JC TRELAZEEN CV BILLARD Elsa ASPTT ANGERS 1D CAILLIAU Morgane DOJO DU PORZAY COQUIN Melodie DOJO DES ABERS Cadet F 57 kg Nb

Casa do Choroacervo.casadochoro.com.br/files/uploads/scores/score...Música de Waldemar Henrique Versos de Paulo Waldemar Falcão Quando a lua, tão formosa, tão serena, Banha de

· Tosatto Vincenzi Zanini Angela Dylan Francesco Serena Lorenzo Youssef Riccardo Huimin Michella Yinyu Desy Desiree Annakaterina Lorenzo Jashanpreet Chiara Lorenzo Leonardo Asia

· rossi vittoria chiocci rosanna minciaroni rita lanzilotto chiara sportoletti renata paoletti emanuela marchini serena scorpioni patrizia ... cotalini adanella torzuoli silvia

ART CITY Map - MamboSala, Marco Samorè, Lorenzo Scotto di Luzio, Namsal Siedlecki, Vincenzo Simone, Natalia Trejbalova, Luca Trevisani, Marcella Vanzo, Serena Vestrucci, Italo Zuffi;

EMMA DANTE ERACLE · 2020. 9. 21. · ERACLE di / by Euripide traduzione / translation Giorgio Ieranò regia / directed by Emma Dante con / with Serena Barone (Anfitrione), Naike

La storia illustrata di Montaione · Rino Salvestrini La storia illustrata di Montaione Le fotografie di Villa Serena (1967 - 1985)

Gestion des ressources humaines - serena-info.fr GRH.pdf · Possibilité de mémoriser plusieurs types de plannings (Par exemple, mois en cours de l'équipe xxx, mois prochain des