Les méthodes agiles mettent au placard de nombreuses méthodes de projet dont les défauts (lourdeur, incompréhension des attentes finales, manque de priorités) ont marqué de leur empreinte l\'échec ou le demi-succès des projets. Longtemps associé à cette image, le “Processus Unifié” s\'accorde pourtant avec le manifeste agile et complète les méthodes connues comme Scrum ou XP sur les moyens et gros projets. Cette session vous propose de parcourir d’autres interprétations et applications du “Processus Unifié” à travers ses différentes versions simplifiées et agiles : Agile Unified Process, Open UP et EssUP.

1. ENRICHIR SES MÉTHODES AVEC
DES PROCESSUS UNIFIÉS AGILES
Romain Couturier – Exakis
Email : romainc@exakis.com
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier

2. PRÉSENTATION

3. VOTRE INTERLOCUTEUR
Après des études en Génie Logiciel et une expérience de
développement chez un éditeur, Romain a contribué au
développement d’un département technique notamment
grâce aux méthodes agiles.
Praticien, formateur et coach, il intervient aujourd’hui auprès des
équipes et de ses clients pour le développement, la diffusion et
l’enrichissement des pratiques agiles.
Email : romainc@exakis.com
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier

6. Roman Pichler
Craig Larman
Scott Ambler
Ron Jeffries
Alistair Cockburn
Mike Cohn
Martin Fowler
Ken Schwaber
Jeff Sutherland
…

8. HISTORIQUE
• 3 amigos :
• Grady Booch (OOAD)
• James Rumbaugh
(OMT)
• IvarJacobson (OOSE)
• 1995/1996 : UP & UML
• Enrichir concepts OO
• Harmoniser processus
de développement
• Capitalisation des
connaissances
• 1998 : Apparition de
RUP
• Version commerciale
• Démarche
d’organisation
• Description et
modélisation métier
• Production de livrables
documentaires
• 2003 : Rachat de
Rational par IBM

9. IDÉES REÇUES

10. UP = UN AUTRE NOM POUR … !*&@#!!

11. UP = BIG UP FRONT DESIGN

12. UP = UML

13. UP = CENTRÉ SUR LA DOCUMENTATION

14. Plus prescriptive Plus adaptative
COMPARER POUR COMPRENDRE, PAS
POUR JUGER
Henrik Kniberg / Crisp
XP
(13)
Scrum
(9)
Kanban
(3)
Do Whatever
(0)
RUP
(120+)
• Architecture Reviewer
• Business Designer
• Business-Model Reviewer
• Business-Process Analyst
• Capsule Designer
• Change Control Manager
• Code Reviewer
• Configuration Manager
• Course Developer
• Database Designer
• Deployment Manager
• Design Reviewer
• Designer
• Graphic Artist
• Implementer
• Integrator
• Process Engineer
• Project Manager
• Project Reviewer
• Requirements Reviewer
• Requirements Specifier
• Software Architect
• Stakeholder
• System Administrator
• System Analyst
• Technical Writer
• Test Analyst
• Test Designer
• Test Manager
• Tester
• Tool Specialist
• User-Interface Designer
• Architectural analysis
• Assess Viability of architectural
proof-of-concept
• Capsule design
• Class design
• Construct architectural proof-
of-concept
• Database design
• Describe distribution
• Describe the run-time
architecture
• Design test packages and
classes
• Develop design guidelines
• Develop programming
guidelines
• Identify design elements
• Identify design mechanisms
• Incorporate design elements
• Prioritize use cases
• Review the architecture
• Review the design
• Structure the implementation
model
• Subsystem design
• Use-case analysis
• Use-case design
• Analysis model
• Architectural proof-of-concept
• Bill of materials
• Business architecture document
• Business case
• Business glossary
• Business modeling guidelines
• Business object model
• Business rules
• Business use case
• Whole team
• Coding standard
• TDD
• Collective ownership
• Customer tests
• Pair programming
• Refactoring
• Planning game
• Continuous integration
• Simple design
• Sustainable pace
• Metaphor
• Small releases
• Scrum Master
• Product Owner
• Team
• Sprint planning
meeting
• Daily Scrum
• Sprint review
• Product backlogt
• Sprint backlog
• BUrndown chart
• Visualize the workflow
• Limit WIP
• Measure and optimize lead time
• Business use case realization
• Business use-case model
• Business vision
• Change request
• Configuration audit findings
• Configuration management
plan
• Data model
• Deployment model
• Deployment plan
• Design guidelines
• Design model
• Development case
• Development-organization
assessment
• End-user support mateirla
• Glossary
• Implementation model
• Installation artifacts
• Integration build plan
• Issues list
• Iteration assessment
• Iteration plan
• Manual styleguide
• Programming guidelines
• Quality assurance plan
• Reference architecture
• Release notes
• Requirements attributes
• Requirements
management plan
• Review record
• Risk list
• Risk management plan
• Software architecture
document
• Software development
plan
• Software requirements
specification
• Stakeholder requests
• Status assessment
• Supplementary business
specification
• Supplementary specification
• Target organization assessment
• Test automation architecture
• Test cases
• Test environment configuration
• Test evaluation summary
• Test guidelines
• Test ideas list
• Test interface specification
• Test plan
• Test suite
• Tool guidelines
• Training materials
• Use case model
• Use case package
• Use-case modeling guidelines
• Use-case realization
• Use-case storyboard
• User-interface guidelines
• User-interface prototype
• Vision
• Work order
• Workload analysis model

15. RÉALITÉS

16. UP
Caractéristiques
• Itératif et incrémental
• Focalisé sur les risques
• Centré sur
l'architecture
• Piloté par les cas
d'utilisation
Pratiques
• Eliminer les risques au plus
tôt
• Engager les utilisateurs sur
l'évaluation, feedback, les
besoins
• Architecture cohérente et
fondations
• Qualité continue & test
• Modélisation visuelle
• Gestion du changement
• Gestion de la configuration

18. UP ET LES AUTRES MÉTHODES AGILES
Cycle de vie
projet
(UP)
Gestion de
projet
(Scrum)
Ingénierie
logicielle
(XP)

19. Inception Elaboration Construction & Transition
Equipe initiale
Equipe
architecture
Equipe
prototype
Equipe
management
Equipe
architecture
Equipe
intégration
Equipe
management
Equipe
fonct.1
Equipe
fonct.2
Equipe
fonct.3
Equipe
infrastructure
EVOLUTION DES ÉQUIPES

20. LA BOITE À OUTILS UP

21. VISION PRODUIT
Design-the-box

23. CAPTURE DES EXIGENCES

24. CAS D’UTILISATION & USER STORIES
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/

25. DÉVELOPPER SA TRAÇABILITÉ
Besoins et
objectifs métier
Scénarios de test
métier
Exigences non-
fonctionnelles
Cas d’utilisation
User story
Tâche technique
Anomalie/Bug
Perspective métier
Perspective fonctionnelle
Perspective technique
Exigences non-
fonctionnelles
Tests unitaires
Critères
d’acceptation
Cas de tests

26. DOSSIER D’ARCHITECTURE
• Contraintes
• Vue des cas d’utilisation
• Vue par processus
• Décisions et principes d’architecture
• Vue logique
• Vue interface
• Vue infrastructure
• Vue déploiement
• Vue opérationnelle
• Vue sécurité
• Vue données
• Technologies
• … autres vues

27. AGILE MODELING
• AM est un processus « chaordic » pour la modélisation et la
documentation
• AM est une collection de pratiques basée sur des valeurs et des
principes d’ingénierie logicielle prouvés
• AM est une approche légère pour améliorer les efforts de
modélisation et de documentation d’autres processus logiciels
comme XP et UP
Copyright 2001-2005 Scott W. Ambler
Your Software Process
A Base Software Process
(e.g. XP, RUP, DSDM, FDD, …)
Principles and Practices of
Agile Modeling (AM)
Other Techniques
(e.g. Database refactoring)
Copyright 2001-2005 Scott W. Ambler

28. THE CORE OF AM
YOU NEED TO ADOPT AT LEAST THE CORE
Core Principles
• Assume Simplicity
• Embrace Change
• Enabling the Next Effort is
Your Secondary Goal
• Incremental Change
• Model With a Purpose
• Multiple Models
• Maximize Stakeholder
Investment
• Quality Work
• Rapid Feedback
• Software Is Your Primary Goal
• Travel Light
Core Practices
• Active Stakeholder
Participation
• Apply the Right Artifact(s)
• Collective Ownership
• Create Several Models in
Parallel
• Create Simple Content
• Depict Models Simply
• Display Models Publicly
• Iterate to Another Artifact
• Model in Small Increments
• Model With Others
• Prove it With Code
• Single Source Information
• Use the Simplest Tools
Copyright 2001-2005 Scott W. Ambler

30. AGILE MODELING ILLUSTRÉ
Cycle n: Development
Cycle 2: Development
Cycle 1: Development
Cycle 0: Initial Modeling
Initial Requirements
Modeling
(days)
Initial Architectural
Modeling
(days)
Model Storming
(minutes)
Implementation
(Ideally Test Driven)
(hours)
Reviews
(optional)
All Cycles
(hours)
Copyright 2003-2005
Scott W. Ambler
Documentation agile
Les tests sont les
principaux artefacts
Value
Effort
Ideal Realistic
Copyright 2005 Scott W. Ambler
Just Barely
Good Enough

31. MODÈLE DE COMMUNICATION

32. AGILE UP
H T T P : / / W W W . A M B Y S O F T . C O M / U N I F I E D P R O C E S S / A G I L E U P . H T M L

33. CYCLE DE VIE

34. PHASES ET JALONS

35. LIVRABLES
Obligatoires (et dans l’ordre)
• Système
• Code source
• Tests de régression
• Scripts d’installation
• Documentation système
• Notes de release
• Modèles de spécification
• Modèles de conception
Tous les autres livrables
sont optionnels …

36. ESSENTIAL UP (ESSUP)
H T T P : / / W W W . I V A R J A C O B S O N . C O M / P R O C E S S _ I M P R O V E M E N T _ T E C H
N O L O G Y / E S S E N T I A L _ U N I F I E D _ P R O C E S S _ S O F T W A R E /

37. ORIGINES
EssUP
Software
engineering (UP)
Process maturity
(CMMi, SPICE)
Méthodes agiles
(Scrum, XP)

38. ESSENTIAL PRACTICES

39. ESSENTIAL PRACTICES

41. OPENUP
HTTP://EPF.ECLIPSE.ORG/WIKIS/OPENUP/

42. OPENUP
Un processus itératif de
développement logiciel
minimal, complet et extensible
penUP
Analyst
Stakeholder
Project
Manager
Architect
Developer
Tester
• Collaborer pour aligner les intérêts et
partager la compréhension
• Équilibrer les priorités concurrentes
pour maximiser la valeur des
sponsors
• Focus sur l'architecture pour
minimiser les risques et organiser le
développement
• Évoluer en permanence par
l’amélioration continue

43. CYCLE DE VIE OPENUP

45. CONCLUSION

46. « LA VARIÉTÉ DES MÉTHODES AGILES EST
UNE OPPORTUNITÉ »

47. RÉFÉRENCES
• Présentation de UP : http://www.univ-angers.fr/docs/etudquassi/RUP.pdf
• Portail RUP : http://www.ts.mah.se/RUP/RationalUnifiedProcess/
• Forum IBM (Methods, and Practices: Rational Unified Process, OpenUP, Harmony and other Agile
methods) : http://www.ibm.com/developerworks/forums/forum.jspa?forumID=335
• Scrum & XP from the Trenches : http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
• The Agile Unified Process : http://www.methodsandtools.com/archive/archive.php?id=21
• Alistair Cockburn - Writing Effective use cases : http://www.amazon.fr/Writing-Effective-Cases-
Alistair-Cockburn/dp/0201702258
• A Manager’s Introduction to thee The Rational Unified Process (RUP) :
http://www.ambysoft.com/downloads/managersIntroToRUP.pdf
• Site de Scott Ambler : http://www.ambysoft.com
• Scott Adams : http://www.dilbert.com
• EssUP, the practice centric software development process :
• http://blog.xebia.com/2007/04/26/essup-the-practice-centric-software-development-process/
• Tips for Business Analysts: What are RUP, EUP, UP, OpenUP, EssUp? :
http://www.writingusecases.com/wordpress/index.php/archive/tips-for-business-analysts-what-
are-rup-eup-up-openup-essup/
• The Essential Unified Process: New Life for the Unified Process :
http://www.drdobbs.com/architecture-and-design/196702101
• Eclipse process framework project : www.eclipse.org/epf
• Craig Larman – Applying UML and Patterns
• Simon Brown – Coding the Architecture

48. ENRICHIR SES MÉTHODES AVEC
DES PROCESSUS UNIFIÉS AGILES
Romain Couturier – Exakis
Email : romainc@exakis.com
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier