enrichir ses méthodes avec des processus unifiés agiles
DESCRIPTION
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.TRANSCRIPT
ENRICHIR SES MÉTHODES AVEC
DES PROCESSUS UNIFIÉS AGILES
Romain Couturier – Exakis
Email : [email protected]
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier
PRÉSENTATION
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 : [email protected]
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier
Roman Pichler
Craig Larman
Scott Ambler
Ron Jeffries
Alistair Cockburn
Mike Cohn
Martin Fowler
Ken Schwaber
Jeff Sutherland
…
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
IDÉES REÇUES
UP = UN AUTRE NOM POUR … !*&@#!!
UP = BIG UP FRONT DESIGN
UP = UML
UP = CENTRÉ SUR LA DOCUMENTATION
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
RÉALITÉS
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
UP ET LES AUTRES MÉTHODES AGILES
Cycle de vie projet
(UP)
Gestion de projet
(Scrum)
Ingénierie logicielle
(XP)
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
LA BOITE À OUTILS UP
VISION PRODUIT
Design-the-box
CAPTURE DES EXIGENCES
CAS D’UTILISATION & USER STORIES
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/
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
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
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
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
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
Modeling
Testing Programming
Refactoring
Documentation agile
Les tests sont les
principaux artefacts
Value
Effort
Ideal Realistic
Copyright 2005 Scott W. Ambler
Just Barely
Good Enough
MODÈLE DE COMMUNICATION
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
CYCLE DE VIE
PHASES ET JALONS
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 …
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 /
ORIGINES
EssUP
Software engineering (UP)
Process maturity (CMMi, SPICE)
Méthodes agiles (Scrum, XP)
ESSENTIAL PRACTICES
ESSENTIAL PRACTICES
OPENUP
HTTP ://EPF .ECL IPSE .ORG/WIK IS/OPENUP/
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
CYCLE DE VIE OPENUP
CONCLUSION
« LA VARIÉTÉ DES MÉTHODES AGILES EST
UNE OPPORTUNITÉ »
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
ENRICHIR SES MÉTHODES AVEC
DES PROCESSUS UNIFIÉS AGILES
Romain Couturier – Exakis
Email : [email protected]
Twitter : @romaincouturier
LinkedIn : http://fr.linkedin.com/in/romaincouturier