Your SlideShare is downloading. ×
Le rôle de l'analyste d'affaires et la place de la documentation dans un processus agile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Le rôle de l'analyste d'affaires et la place de la documentation dans un processus agile

3,274
views

Published on

françois parle du rôle de l’analyste d’affaires et de la place de la documentation dans un processus Agile. Dans cette session, les valeurs, ainsi que les principes et pratiques d’une approche de …

françois parle du rôle de l’analyste d’affaires et de la place de la documentation dans un processus Agile. Dans cette session, les valeurs, ainsi que les principes et pratiques d’une approche de développement Agile sont clairement présentés à travers de multiples exemples concrets.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,274
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
42
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Le rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile
    françoisbeauregard
    pyxis-tech.com/francois-beauregard
  • 2. Une belle aventurePyxis Technologies (2000 - xxxx)www.pyxis-tech.com
    Pyxis aide les organisations de développementlogicielàdevenir des endroitsoù les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de cequ'elle propose àses clients et en accompagnantceux-ci.
  • 3. Uneautre belle aventureAgile Montréal (2002 - xxxx)www.agilemontreal.ca
  • 4. Avertissements
    Quelques diagrammes sont en anglais!
    J’ai plus de diapos que nécessaire car… je parle beaucoup! Aussi …
  • 5.
  • 6.
  • 7. 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!
  • 8. Sondage à main levée
    Utilisez-vous une approche Agile dans votre organisation?
  • 9. Déroulement
    État des lieux
    Agile en quelques mots
    Modélisation Agile et documentation
    Initiale
    Détaillée
    Quotidienne
    Conclusion
  • 10. 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?
  • 11.
  • 12. 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
  • 13. Investissement dans les caractéristiques de valeur
    Jim Johnson, Standish Group, XP 2002
  • 14. 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 lelogiciel doivent communiqueravec ceux qui le construisent.
  • 15. Développement et gestion des exigences
  • 16. Cycle en V (cascade)‏
  • 17. 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é.
  • 18. 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 desdocuments!
    La gestion des exigences et lagestion de projet sontsouvent mal intégrées.
  • 19. 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
  • 20. 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.
  • 21. Principes Agiles (un sous-ensemble)
    La priorité est de satisfaire le client par la livraison rapide et continuede 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.
  • 22.
  • 23.
  • 24. 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.”
    - SanjivAugustine
  • 25. ProcessusAgilestandard
    Scrum - 3 rôles
    L’analyste d’affaires?
  • 28. équipe pluridisciplinaireautogérée
    inspection et
    adaptation
    incrément prêt pourla production
    classé par valeur
    Uneéquipe Scrum = Un système
  • 29. 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?
  • 30. Déroulement
    État des lieus
    Agile en quelques mots
    Modélisation Agile et documentation
    Initiale
    Détaillée
    Quotidienne
    Conclusion
  • 31. 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.
  • 32. Quelques valeurs et principes
    Principes de base
    • Assumer la simplicité
    • 37. Faire place au changement
    • 38. Permettre le prochain effort, c’est votre deuxième but
    • 39. Permettre les modifications incrémentielles
    • 40. Modéliser avec un but
    • 41. Avoir des modèles multiples
    • 42. Maximiser l’engagement des intervenants
    • 43. Faire du travail de qualité
    • 44. Avoir une rétroaction rapide
    • 45. Avoir les logiciels comme principal but
    • 46. Voyager léger
    Principes supplémentaires
    • Le contenu est plus important que la présentation.
    • 47. 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.
  • 48. Quel est la façon la plus efficace de communiquer ?
  • 49. À quel vitesse l’information se déplace-t-elle ?
    Configuration traditionnelle
    Configuration en espace ouvert
  • 50. La modélisation Agile dans un processus Agile
  • 51. La modélisationinitiale
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. Comment gérons-nous les exigences dans les projets Agiles?
    Carnet du produit
  • 56. Les détails relatifs aux exigences s’accumulent
  • 57. Exemple de schéma en format libre
  • 58. Quand cessons-nous d’ajouter des détails?
  • 59. Modélisation détaillée
  • 60. 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
  • 61. 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?
  • 62. 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
  • 63. 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?
  • 64. 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!
  • 65. 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
  • 66. Prototype de fidélité de bas niveau :prototypes papier
  • 67. Modélisation juste à temps
  • 68. 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
  • 69. 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.
  • 70. 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)‏
  • 71. 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
  • 72. 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?
  • 73. Spécifications exécutables – Un exemple (suite)
    Le système doit également supporter la division.
    Est-cequ'il y a unemeilleurefaçon?
  • 74. 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 $.
  • 75. Réponse
  • 76. 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
  • 77. Without the shift in thinking, methodology becomes technique and practice becomes imitation. Peter Block
  • 78. Merci!
    Des questions?
    Pour obtenir les diapos : fbeauregard@pyxis-tech.com
  • 79. En discuter davantage
    N’hésitez pas à m’accrocher
    N’hésitez pas à me contacter - fbeauregard@pyxis-tech.com -
    Voussouhaitezouvrirune discussion ou faire uneprésentation (celle-làouuneautre) dansvotreorganisation - Avec grand plaisir!