Transcript Une autre belle aventure

Le rôle de l'analyste d'affaires et la place de
la documentation dans un processus Agile
françois beauregard
pyxis-tech.com/francois-beauregard
Une belle aventure
Pyxis Technologies (2000 - xxxx)
www.pyxis-tech.com
Pyxis aide les organisations de développement logiciel à devenir
des endroits où les résultats, la qualité de vie et le plaisir coexistent
de façon durable en étant en premier lieu un exemple de ce qu'elle
propose à ses clients et en accompagnant ceux-ci.
Une autre belle aventure
Agile Montréal (2002 - xxxx)
www.agilemontreal.ca
Avertissements
• Quelques diagrammes sont en anglais!
• J’ai plus de diapos que nécessaire car… je
parle beaucoup! Aussi …
Objectifs de la présentation
• Vous présenter les pratiques Agiles liées à l'analyse d'affaires,
en particulier en matière de développement et de gestion des
exigences
• Comprendre ce que signifie être Agile pendant la
modélisation
• Comprendre où se situe la modélisation dans un processus
Agile
• Fournir des éléments de réflexion pour la mise en œuvre
d'améliorations dans vos projets
Soyez sceptique mais ouvert!
Sondage à main levée
Utilisez-vous une approche Agile dans
votre organisation?
Déroulement
• État des lieux
• Agile en quelques mots
• Modélisation Agile et documentation
– Initiale
– Détaillée
– Quotidienne
• Conclusion
Des questions
•
•
•
•
Quel est le rôle d’un analyste d’affaires?
Quels sont ses objectifs?
Comment aide-t-il?
Que fait-il au quotidien?
Nos projets doivent être une réussite
Réussite : Le projet se termine dans le
respect du délai et du budget. Il comporte
toutes les fonctions et caractéristiques
prévues.
Défi : Le projet est en retard, il y a
dépassement de budget ou il manque
certaines fonctions et caractéristiques.
Échec : Le projet est annulé avant sa fin ou il
est terminé mais ne sera jamais utilisé.
Standish Group CHAOS Report, 2003
Investissement dans les caractéristiques de
valeur
Jim Johnson, Standish Group, XP 2002
Qu’est-ce que le développement logiciel?
• Le développement et la gestion des exigences
logicielles se résument essentiellement à une
problématique de communication.
• Ceux qui demandent le
logiciel doivent communiquer
avec ceux qui le construisent.
Développement et gestion des exigences
Cycle en V (cascade)
Défis
• Dans une approche traditionnelle ayant un cycle en V, la définition des
exigences se fait dans un document écrit en langage naturel par un expert
du domaine.
• Les scénarios permettant de valider le code développé sont écrits dans un
autre document par des experts en assurance qualité, avec un formalisme
spécialisé. De bons experts en assurance qualité doivent avoir une double
compétence et à cause de cela ils sont rares et onéreux.
• Le code de l'application est développé après lecture des exigences
fonctionnelles et validé par la suite par les scénarios de test, le plus
souvent manuellement.
• Les sources d'information et les intervenants sont multiples et soulèvent
la question de la fiabilité de l'interprétation, de la synchronisation de
l'information, de l'efficacité et de l'optimisation du procédé.
Défis (suite)
•
•
•
•
Les documents sont multiples.
Beaucoup d'effort pour s'assurer que tout est tenu à jour
Traçabilité difficile
Il est difficile de tester des
documents!
• La gestion des exigences et la
gestion de projet sont
souvent mal intégrées.
Mais alors que doit-on changer? Quelques
idées...
• Avoir une forme contractuelle qui reconnaît qu’il n’est pas optimal (désiré)
de chercher à connaître précisément l’ensemble des exigences au départ
(ceci est un sujet en soit)
• Mettre en place des processus qui conservent un niveau de contrôle
adéquat mais qui permettent les changements rapides
• Avoir une forme documentaire simplifiée qui permette l’évolutivité de la
documentation
• Créer une culture de collaboration
• Mettre en place des outils (p. ex. : wiki) pour soutenir la démarche
Manifeste pour le développement Agile de
logiciel
• Nous sommes à découvrir de meilleures manières de développer des
logiciels en aidant les autres et en en développant nous-même.
• Par ce travail, nous en sommes venu à valoriser ce qui suit :
–
–
–
–
les individus et les interactions davantage que les processus et les outils
les logiciels fonctionnels davantage que la documentation exhaustive
la collaboration avec le client davantage que la négociation de contrat
l’ouverture au changement davantage que le suivi d’un plan
• En fait, bien que les éléments de droite soient importants, nous
considérons que les éléments de gauche le sont encore plus.
Principes Agiles (un sous-ensemble)
• La priorité est de satisfaire le client par la livraison rapide et continue de
solutions logicielles utiles.
• Intégrez les changements, même ceux de dernière minute, car ils
offriront un avantage compétitif à votre client.
• Élaborez des projets autour d’individus motivés, fournissez-leur le soutien
nécessaire et faites-leur confiance.
• Les meilleures solutions émergent des équipes auto-organisées.
• Régulièrement, l’équipe fait une réflexion sur les façons de devenir plus
efficace, s’ajuste et modifie son comportement en conséquence.
• Porter une attention continue à l’excellence technique et à un bon design
améliore l’Agilité.
• La simplicité est essentielle.
Qu’est-ce la gestion Agile de projet?
“Agile project management is the work of energizing,
empowering, and enabling project teams to rapidly and
reliably deliver business value by engaging customers and
continuously learning and adapting to their changing needs
and environments.”
- Sanjiv Augustine
Processus Agile standard
Scrum - 3 rôles
• Propriétaire
• ScrumMaster
• Équipier
L’analyste d’affaires?
équipe pluridisciplinaire
autogérée
inspection et
adaptation
incrément prêt pour
la production
classé par
valeur
Une équipe Scrum = Un système
Une question commune
• Quel est la bonne façon de représenter la portée et de
permettre d’apporter des changements à la définition?
• Corollaires :
– Êtes-vous bon actuellement avec cela?
– Comment les principes et pratiques Agiles peuvent vous aider?
– Comment pouvez-vous partager cette responsabilité? Est-ce que ça
doit être l’affaire de tous?
Déroulement
• État des lieus
• Agile en quelques mots
• Modélisation Agile et documentation
– Initiale
– Détaillée
– Quotidienne
• Conclusion
Qu’est-ce que la modélisation Agile?
• Il s’agit d’un ensemble de pratiques de modélisation fondées
sur des valeurs Agiles et des principes d’ingénierie logicielle.
• Il s’agit d’une approche légère permettant d’améliorer les
efforts de modélisation et de documentation.
Agile Modeling (AM)
Base Software Process
(XP, UP, DSDM, ...)
Your
Process
Quelques valeurs et principes
Principes de base











Assumer la simplicité
Faire place au changement
Permettre le prochain effort, c’est votre
deuxième but
Permettre les modifications incrémentielles
Modéliser avec un but
Avoir des modèles multiples
Maximiser l’engagement des intervenants
Faire du travail de qualité
Avoir une rétroaction rapide
Avoir les logiciels comme principal but
Voyager léger

Communication

Simplicité

Rétroaction

Courage

Humilité
Principes supplémentaires

Le contenu est plus important que la
présentation.

Il faut préconiser les communications
ouvertes et honnêtes.
Prenez note
•
•
•
•
Modèle != document
Il y a plus à la modélisation que l’UML.
Il faut modéliser avant de coder.
Il faut travailler ensemble pour apprendre comment devenir
de meilleurs développeurs.
Quel est la façon la plus efficace de
communiquer ?
À quel vitesse l’information se déplace-t-elle
?
Configuration traditionnelle
Configuration en espace ouvert
La modélisation Agile dans un processus
Agile
Self Organized Team
Project Vision
(Iteration 0)
Iteration
Planning
Iteration
Initial
Modeling
Detailed
Modeling
Just-In-Time
Modeling
Incremental
Delivery
Product Owner
Time Boxed
Establish
priorities
add
Inspect and
Adapt
Top
Priorities
Iteration Backlog
remove
Features Backlog
La modélisation initiale
Self Organized Team
Product Owner
Project Vision
(Iteration 0)
Iteration
Planning
Iteration
Initial
Modeling
Detailed
Modeling
Just-In-Time
Modeling
Incremental
Delivery
Time Boxed
Establish
priorities
add
Inspect and
Adapt
Top
Priorities
Iteration Backlog
remove
Features Backlog
Objectifs de la modélisation initiale
• Comprendre les objectifs du projet
• Élaborer une stratégie incrémentale maximisant l’atteinte des
objectifs (ex. : Story Mapping)
• Explorer le domaine d’affaires
• Développer un langage commun
• Définir l’architecture initiale
Quels sont les problèmes liés à la phase
d’analyse traditionnelle initiale?
• Connaissance initiale incomplète
• Manque de rétroaction des utilisateurs
• Efforts d’analyse additionnelle sur des fonctionnalités qui sont
de faible priorité ou qui apporte peu de valeur
• Peu de place au changement
Modèles possibles de modélisation des
exigences
• Modélisation des exigences
–
–
–
–
–
Cartographie des rôles utilisateurs
Cas d’utilisation (descriptif)
Diagramme UML de cas d’utilisation
Scénarios utilisateurs (user stories)
…
• Modélisation des interfaces utilisateurs
• Modélisation du domaine
Comment gérons-nous les exigences dans
les projets Agiles?
Carnet du produit
{
High
Priority
Each iteration implement the highestpriority requirements
Each new requirement is
prioritized and added to
the stack
Requirements may be
reprioritized at any time
Requirements may be
removed at any time
Low
Priority
Requirements
Les détails relatifs aux exigences
s’accumulent
Exemple de schéma en format libre
Quand cessons-nous d’ajouter des détails?
Modélisation détaillée
Self Organized Team
Project Vision
(Iteration 0)
Iteration
Planning
Initial
Modeling
Detailed
Modeling
Product Owner
Iteration
Just-In-Time
Modeling
Incremental
Delivery
Time Boxed
Establish
priorities
add
Top
Priorities
Iteration Backlog
remove
Features Backlog
Inspect and
Adapt
Objectifs de la modélisation détaillée
•
•
•
•
Comprendre les exigences des intervenants
Comprendre comment les entités d’affaires sont inter reliées
Détailler l’enchaînement des processus opérationnels
Concevoir une interface utilisateur
Quels sont les problèmes liés à la phase de
conception traditionnelle?
• Il est impossible de trouver tous les problèmes d’avance.
• Les architectes deviennent des spécialistes et ils ne codent
plus.
• La conception traditionnelle ne fait pas place au changement.
• Comment communiquez-vous aux programmeurs vos idées
relatives à la conception?
• Comment tenez-vous à jour la documentation relative à la
conception?
La réponse? La conception évolutive
•
•
•
•
•
Il ne s’agit pas de coder et de corriger.
Il faut faire place au changement.
Elle implique la réversibilité.
Elle apprécie la simplicité.
Elle a besoin de pratiques d’ingénierie.
– Tests
– Réusinage
– Intégration continue
La réponse? La conception évolutive
• Il faut supporter la conception évolutive.
–
–
–
–
Modélisation itérative
Propriété collective
Application de modèles
Juste assez bien
• Devons-nous documenter la conception?
Documentation Agile
• Le problème fondamental c’est la communication, pas la
documentation.
• Les modèles ne sont pas nécessairement des documents, vice
versa.
• La documentation devrait être ‘légère et efficace’.
• Il faut mettre la documentation à jour seulement quand c’est
nécessaire.
• Il ne faut jamais oublier que votre principal but, c’est le
développement!
Modélisation détaillée des exigences :
modèles possibles
• Modélisation des exigences
– Cas d’utilisation
– Scénarios utilisateurs
• Modélisation des interfaces utilisateurs
• Modélisation de domaine
Prototype de fidélité de bas niveau :
prototypes papier
Modélisation juste à temps
Self Organized Team
Project Vision
(Iteration 0)
Iteration
Planning
Initial
Modeling
Detailed
Modeling
Product Owner
Iteration
Just-In-Time
Modeling
Time Boxed
Establish
priorities
add
Top
Priorities
Iteration Backlog
remove
Features Backlog
Inspect and
Adapt
Incremental
Delivery
Objectifs de la modélisation juste à temps
•
•
•
•
Faciliter la collaboration par la communication
Confirmer les exigences avec des exemples de règles d’affaires
Examiner en détail les éléments de conception
Avoir une compréhension commune de la conception
Pratiques Agiles de modélisation
•
•
•
•
•
Il faut savoir quand arrêter la modélisation.
Il faut le prouver avec du code.
Le code est un modèle.
C’est juste assez bien.
Il faut modéliser avec les autres.
Modèles possibles de collaboration
• Collaboration concernant les exigences
– Détails sur les cartes de scénario (verbalement)
– Tests d’acceptation du client
• Séance de conception rapide
• Développement piloté par les test (TDD)
Le code est le modèle primaire
•
•
•
•
Le prouver avec du code
Vérifier le code avec les tests d’acceptation du client
Faire la conception avec les tests unitaires
S’assurer que les tests unitaires constituent la documentation
principale du code
• Rester près du code : les concepteurs devraient coder
Spécifications exécutables – Un exemple
• Le système doit supporter l'addition de deux nombres naturels.
• Comment tester cela :
–
–
–
–
–
Tapez 3 dans le champ de saisie.
Cliquez sur le bouton +.
Tapez 7 dans le champ de saisie.
Cliquez sur le bouton =.
Vérifiez que le résultat affiché est 10.
• Est-ce qu'il y a une meilleure façon?
Règle pour la calculatrice
Opérande 1 Opérande 2 Total?
7
3
10
-3
7
4
6
0
6
-5
3
-2
Spécifications exécutables – Un exemple
(suite)
• Le système doit également supporter la division.
• Est-ce qu'il y a une meilleure façon?
Règle pour la calculatrice
Opérande 1 Opérande 2 Total? Quotient?
7
3
10
2.33
-3
7
4
-0.43
6
0
6
Erreur
-5
3
-2
-1.67
0
5
5
0
Exemple plus significatif
• Un crédit allant jusqu'à 1000 $ est accordé à un client qui fait
affaire avec nous depuis plus de 12 mois s'il a été un bon
payeur durant cette période et s'il a un solde à payer inférieur
à 6000 $.
Réponse
Règle pour la vérification du crédit
Mois Fiable
Solde Crédit accordé? Limite de crédit?
14 Oui
5000 $ Oui
1000 $
0 Oui
0 $ Non
0$
24 Non
0 $ Non
0$
18 Oui
6000 $ Non
0$
12 Oui
5500 $ Non
0$
Conclusion
• Les conceptions Agiles se réalisent de façon émergente, elles
ne sont pas définies au départ.
• L’étape de modélisation initiale est cruciale.
• Itérez, itérez, itérez...
• Chaque investissement en documentation devrait être
compris et entendu avec le client.
• Adhérez au principe du juste assez bien
Without the shift in thinking,
methodology becomes technique and
practice becomes imitation. Peter
Block
Merci!
Des questions?
Pour obtenir les diapos : [email protected]
En discuter davantage
• N’hésitez pas à m’accrocher
• N’hésitez pas à me contacter - [email protected] • Vous souhaitez ouvrir une discussion ou faire une présentation
(celle-là ou une autre) dans votre organisation - Avec grand
plaisir!