Le rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile<br />françoisbeauregard<br />pyxi...
Une belle aventurePyxis Technologies (2000 - xxxx)www.pyxis-tech.com<br />Pyxis aide les organisations de développementlog...
Uneautre belle aventureAgile Montréal (2002 - xxxx)www.agilemontreal.ca<br />
Avertissements<br />Quelques diagrammes sont en anglais!<br />J’ai plus de diapos que nécessaire car… je parle beaucoup! A...
Objectifs de la présentation<br />Vous présenter les pratiques Agiles liées à l'analyse d'affaires, en particulier en mati...
Sondage à main levée<br />Utilisez-vous une approche Agile dans votre organisation?<br />
Déroulement<br />État des lieux<br />Agile en quelques mots<br />Modélisation Agile et documentation<br />Initiale<br />Dé...
Des questions<br />Quel est le rôle d’un analyste d’affaires?<br />Quels sont ses objectifs?<br />Comment aide-t-il?<br />...
Nos projets doivent être une réussite<br />Réussite : Le projet se termine dans le respect du délai et du budget. Il compo...
Investissement dans les caractéristiques de valeur <br />Jim Johnson, Standish Group, XP 2002<br />
Qu’est-ce que le développement logiciel?<br />Le développement et la gestion des exigences logicielles se résument essenti...
Développement et gestion des exigences<br />
Cycle en V (cascade)‏<br />
Défis<br />Dans une approche traditionnelle ayant un cycle en V, la définition des exigences se fait dans un document écri...
Défis (suite)<br />Les documents sont multiples.<br />Beaucoup d'effort pour s'assurer que tout est tenu à jour<br />Traça...
Mais alors que doit-on changer? Quelques idées...<br />Avoir une forme contractuelle qui reconnaît qu’il n’est pas optimal...
Manifeste pour le développement Agile de logiciel<br />Nous sommes à découvrir de meilleures manières de développer des lo...
Principes Agiles (un sous-ensemble)<br />La priorité est de satisfaire le client par la livraison rapide et continuede sol...
Qu’est-ce la gestion Agile de projet?<br />“Agile project management is the work of energizing, empowering, and enabling p...
ProcessusAgilestandard<br />Scrum - 3 rôles<br /><ul><li>Propriétaire
ScrumMaster
Équipier</li></ul>L’analyste d’affaires?<br />
équipe pluridisciplinaireautogérée<br />inspection et <br />adaptation<br />incrément prêt pourla production<br />classé p...
Une question commune<br />Quel est la bonne façon de représenter la portée et de permettre d’apporter des changements à la...
Déroulement<br />État des lieus<br />Agile en quelques mots<br />Modélisation Agile et documentation<br />Initiale<br />Dé...
Qu’est-ce que la modélisation Agile?<br />Il s’agit d’un ensemble de pratiques de modélisation fondées sur des valeurs Agi...
Quelques valeurs et principes <br /><ul><li>Communication
Simplicité
Rétroaction
Courage
Humilité</li></ul>Principes de base<br /><ul><li>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</li></ul>Principes supplémentaires<br /><ul><li>Le contenu est plus important que la présentation.
Il faut préconiser les communications ouvertes et honnêtes.</li></li></ul><li>Prenez note<br />Modèle != document<br />Il ...
Quel est la façon la plus efficace de communiquer ?<br />
À quel vitesse l’information se déplace-t-elle ?<br />Configuration traditionnelle<br />Configuration en espace ouvert<br />
La modélisation Agile dans un processus Agile<br />
La modélisationinitiale<br />
Objectifs de la modélisation initiale <br />Comprendre les objectifs du projet<br />Élaborer une stratégie incrémentale ma...
Quels sont les problèmes liés à la phase d’analyse traditionnelle initiale?<br />Connaissance initiale incomplète<br />Man...
Modèles possibles de modélisation des exigences<br />Modélisation des exigences<br />Cartographie des rôles utilisateurs<b...
Comment gérons-nous les exigences dans les projets Agiles?<br /> Carnet du produit <br />
Les détails relatifs aux exigences s’accumulent<br />
Exemple de schéma en format libre<br />
Quand cessons-nous d’ajouter des détails?<br />
Modélisation détaillée<br />
Objectifs de la modélisation détaillée<br />Comprendre les exigences des intervenants<br />Comprendre comment les entités ...
Quels sont les problèmes liés à la phase de conception traditionnelle?<br />Il est impossible de trouver tous les problème...
La réponse? La conception évolutive<br />Il ne s’agit pas de coder et de corriger.<br />Il faut faire place au changement....
La réponse? La conception évolutive<br />Il faut supporter la conception évolutive.<br />Modélisation itérative <br />Prop...
Documentation Agile<br />Le problème fondamental c’est la communication, pas la documentation.<br />Les modèles ne sont pa...
Prochain SlideShare
Chargement dans…5
×

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

4 178 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
4 178
Sur SlideShare
0
Issues des intégrations
0
Intégrations
16
Actions
Partages
0
Téléchargements
66
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. Le rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile<br />françoisbeauregard<br />pyxis-tech.com/francois-beauregard<br />
  2. 2. Une belle aventurePyxis Technologies (2000 - xxxx)www.pyxis-tech.com<br />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.<br />
  3. 3. Uneautre belle aventureAgile Montréal (2002 - xxxx)www.agilemontreal.ca<br />
  4. 4. Avertissements<br />Quelques diagrammes sont en anglais!<br />J’ai plus de diapos que nécessaire car… je parle beaucoup! Aussi …<br />
  5. 5.
  6. 6.
  7. 7. Objectifs de la présentation<br />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<br />Comprendre ce que signifie être Agile pendant la modélisation<br />Comprendre où se situe la modélisation dans un processus Agile<br />Fournir des éléments de réflexion pour la mise en œuvre d'améliorations dans vos projets<br />Soyez sceptique mais ouvert!<br />
  8. 8. Sondage à main levée<br />Utilisez-vous une approche Agile dans votre organisation?<br />
  9. 9. Déroulement<br />État des lieux<br />Agile en quelques mots<br />Modélisation Agile et documentation<br />Initiale<br />Détaillée<br />Quotidienne<br />Conclusion<br />
  10. 10. Des questions<br />Quel est le rôle d’un analyste d’affaires?<br />Quels sont ses objectifs?<br />Comment aide-t-il?<br />Que fait-il au quotidien?<br />
  11. 11.
  12. 12. Nos projets doivent être une réussite<br />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.<br />Défi : Le projet est en retard, il y a dépassement de budget ou il manque certaines fonctions et caractéristiques. <br />Échec : Le projet est annulé avant sa fin ou il est terminé mais ne sera jamais utilisé.<br />Standish Group CHAOS Report, 2003 <br />
  13. 13. Investissement dans les caractéristiques de valeur <br />Jim Johnson, Standish Group, XP 2002<br />
  14. 14. Qu’est-ce que le développement logiciel?<br />Le développement et la gestion des exigences logicielles se résument essentiellement à une problématique de communication.<br />Ceux qui demandent lelogiciel doivent communiqueravec ceux qui le construisent.<br />
  15. 15. Développement et gestion des exigences<br />
  16. 16. Cycle en V (cascade)‏<br />
  17. 17. Défis<br />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.<br />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.<br />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.<br />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é.<br />
  18. 18. Défis (suite)<br />Les documents sont multiples.<br />Beaucoup d'effort pour s'assurer que tout est tenu à jour<br />Traçabilité difficile<br />Il est difficile de tester desdocuments!<br />La gestion des exigences et lagestion de projet sontsouvent mal intégrées. <br />
  19. 19. Mais alors que doit-on changer? Quelques idées...<br />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)<br />Mettre en place des processus qui conservent un niveau de contrôle adéquat mais qui permettent les changements rapides<br />Avoir une forme documentaire simplifiée qui permette l’évolutivité de la documentation<br />Créer une culture de collaboration<br />Mettre en place des outils (p. ex. : wiki) pour soutenir la démarche<br />
  20. 20. Manifeste pour le développement Agile de logiciel<br />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.<br />Par ce travail, nous en sommes venu à valoriser ce qui suit :<br />les individus et les interactions davantage que les processus et les outils<br />les logiciels fonctionnels davantage que la documentation exhaustive<br />la collaboration avec le client davantage que la négociation de contrat<br />l’ouverture au changement davantage que le suivi d’un plan<br />En fait, bien que les éléments de droite soient importants, nous considérons que les éléments de gauche le sont encore plus.<br />
  21. 21. Principes Agiles (un sous-ensemble)<br />La priorité est de satisfaire le client par la livraison rapide et continuede solutions logicielles utiles. <br />Intégrez les changements, même ceux de dernière minute, car ils offriront un avantage compétitif à votre client. <br />Élaborez des projets autour d’individus motivés, fournissez-leur le soutien nécessaire et faites-leur confiance. <br />Les meilleures solutions émergent des équipes auto-organisées. <br />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. <br />Porter une attention continue à l’excellence technique et à un bon design améliore l’Agilité. <br />La simplicité est essentielle.<br />
  22. 22.
  23. 23.
  24. 24. Qu’est-ce la gestion Agile de projet?<br />“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.”<br />- SanjivAugustine<br />
  25. 25. ProcessusAgilestandard<br />Scrum - 3 rôles<br /><ul><li>Propriétaire
  26. 26. ScrumMaster
  27. 27. Équipier</li></ul>L’analyste d’affaires?<br />
  28. 28. équipe pluridisciplinaireautogérée<br />inspection et <br />adaptation<br />incrément prêt pourla production<br />classé par valeur<br />Uneéquipe Scrum = Un système<br />
  29. 29. Une question commune<br />Quel est la bonne façon de représenter la portée et de permettre d’apporter des changements à la définition?<br />Corollaires :<br />Êtes-vous bon actuellement avec cela?<br />Comment les principes et pratiques Agiles peuvent vous aider? <br />Comment pouvez-vous partager cette responsabilité? Est-ce que ça doit être l’affaire de tous?<br />
  30. 30. Déroulement<br />État des lieus<br />Agile en quelques mots<br />Modélisation Agile et documentation<br />Initiale<br />Détaillée<br />Quotidienne<br />Conclusion<br />
  31. 31. Qu’est-ce que la modélisation Agile?<br />Il s’agit d’un ensemble de pratiques de modélisation fondées sur des valeurs Agiles et des principes d’ingénierie logicielle.<br />Il s’agit d’une approche légère permettant d’améliorer les efforts de modélisation et de documentation.<br />
  32. 32. Quelques valeurs et principes <br /><ul><li>Communication
  33. 33. Simplicité
  34. 34. Rétroaction
  35. 35. Courage
  36. 36. Humilité</li></ul>Principes de base<br /><ul><li>Assumer la simplicité
  37. 37. Faire place au changement
  38. 38. Permettre le prochain effort, c’est votre deuxième but
  39. 39. Permettre les modifications incrémentielles
  40. 40. Modéliser avec un but
  41. 41. Avoir des modèles multiples
  42. 42. Maximiser l’engagement des intervenants
  43. 43. Faire du travail de qualité
  44. 44. Avoir une rétroaction rapide
  45. 45. Avoir les logiciels comme principal but
  46. 46. Voyager léger</li></ul>Principes supplémentaires<br /><ul><li>Le contenu est plus important que la présentation.
  47. 47. Il faut préconiser les communications ouvertes et honnêtes.</li></li></ul><li>Prenez note<br />Modèle != document<br />Il y a plus à la modélisation que l’UML.<br />Il faut modéliser avant de coder.<br />Il faut travailler ensemble pour apprendre comment devenir de meilleurs développeurs.<br />
  48. 48. Quel est la façon la plus efficace de communiquer ?<br />
  49. 49. À quel vitesse l’information se déplace-t-elle ?<br />Configuration traditionnelle<br />Configuration en espace ouvert<br />
  50. 50. La modélisation Agile dans un processus Agile<br />
  51. 51. La modélisationinitiale<br />
  52. 52. Objectifs de la modélisation initiale <br />Comprendre les objectifs du projet<br />Élaborer une stratégie incrémentale maximisant l’atteinte des objectifs (ex. : Story Mapping)<br />Explorer le domaine d’affaires <br />Développer un langage commun <br />Définir l’architecture initiale<br />
  53. 53. Quels sont les problèmes liés à la phase d’analyse traditionnelle initiale?<br />Connaissance initiale incomplète<br />Manque de rétroaction des utilisateurs<br />Efforts d’analyse additionnelle sur des fonctionnalités qui sont de faible priorité ou qui apporte peu de valeur<br />Peu de place au changement<br />
  54. 54. Modèles possibles de modélisation des exigences<br />Modélisation des exigences<br />Cartographie des rôles utilisateurs<br />Cas d’utilisation (descriptif)‏<br />Diagramme UML de cas d’utilisation<br />Scénarios utilisateurs (user stories)‏<br />…<br />Modélisation des interfaces utilisateurs<br />Modélisation du domaine<br />
  55. 55. Comment gérons-nous les exigences dans les projets Agiles?<br /> Carnet du produit <br />
  56. 56. Les détails relatifs aux exigences s’accumulent<br />
  57. 57. Exemple de schéma en format libre<br />
  58. 58. Quand cessons-nous d’ajouter des détails?<br />
  59. 59. Modélisation détaillée<br />
  60. 60. Objectifs de la modélisation détaillée<br />Comprendre les exigences des intervenants<br />Comprendre comment les entités d’affaires sont inter reliées <br />Détailler l’enchaînement des processus opérationnels<br />Concevoir une interface utilisateur<br />
  61. 61. Quels sont les problèmes liés à la phase de conception traditionnelle?<br />Il est impossible de trouver tous les problèmes d’avance.<br />Les architectes deviennent des spécialistes et ils ne codent plus.<br />La conception traditionnelle ne fait pas place au changement.<br />Comment communiquez-vous aux programmeurs vos idées relatives à la conception?<br />Comment tenez-vous à jour la documentation relative à la conception?<br />
  62. 62. La réponse? La conception évolutive<br />Il ne s’agit pas de coder et de corriger.<br />Il faut faire place au changement.<br />Elle implique la réversibilité.<br />Elle apprécie la simplicité.<br />Elle a besoin de pratiques d’ingénierie.<br />Tests <br />Réusinage<br />Intégration continue<br />
  63. 63. La réponse? La conception évolutive<br />Il faut supporter la conception évolutive.<br />Modélisation itérative <br />Propriété collective<br />Application de modèles <br />Juste assez bien<br />Devons-nous documenter la conception?<br />
  64. 64. Documentation Agile<br />Le problème fondamental c’est la communication, pas la documentation.<br />Les modèles ne sont pas nécessairement des documents, vice versa.<br />La documentation devrait être ‘légère et efficace’.<br />Il faut mettre la documentation à jour seulement quand c’est nécessaire.<br />Il ne faut jamais oublier que votre principal but, c’est le développement!<br />
  65. 65. Modélisation détaillée des exigences : modèles possibles<br />Modélisation des exigences<br />Cas d’utilisation<br />Scénarios utilisateurs<br />Modélisation des interfaces utilisateurs <br />Modélisation de domaine <br />
  66. 66. Prototype de fidélité de bas niveau :prototypes papier<br />
  67. 67. Modélisation juste à temps<br />
  68. 68. Objectifs de la modélisation juste à temps<br />Faciliter la collaboration par la communication<br />Confirmer les exigences avec des exemples de règles d’affaires<br />Examiner en détail les éléments de conception <br />Avoir une compréhension commune de la conception <br />
  69. 69. Pratiques Agiles de modélisation<br />Il faut savoir quand arrêter la modélisation.<br />Il faut le prouver avec du code.<br />Le code est un modèle.<br />C’est juste assez bien.<br />Il faut modéliser avec les autres.<br />
  70. 70. Modèles possibles de collaboration<br />Collaboration concernant les exigences <br />Détails sur les cartes de scénario (verbalement)‏<br />Tests d’acceptation du client <br />Séance de conception rapide<br />Développement piloté par les test (TDD)‏<br />
  71. 71. Le code est le modèle primaire<br />Le prouver avec du code <br />Vérifier le code avec les tests d’acceptation du client<br />Faire la conception avec les tests unitaires <br />S’assurer que les tests unitaires constituent la documentation principale du code<br />Rester près du code : les concepteurs devraient coder<br />
  72. 72. Spécifications exécutables – Un exemple<br />Le système doit supporter l'addition de deux nombres naturels.<br />Comment tester cela :<br />Tapez 3 dans le champ de saisie.<br />Cliquez sur le bouton +.<br />Tapez 7 dans le champ de saisie.<br />Cliquez sur le bouton =.<br />Vérifiez que le résultat affiché est 10. <br />Est-ce qu'il y a une meilleure façon?<br />
  73. 73. Spécifications exécutables – Un exemple (suite)<br />Le système doit également supporter la division.<br />Est-cequ'il y a unemeilleurefaçon?<br />
  74. 74. Exemple plus significatif<br />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 $.<br />
  75. 75. Réponse<br />
  76. 76. Conclusion<br />Les conceptions Agiles se réalisent de façon émergente, elles ne sont pas définies au départ.<br />L’étape de modélisation initiale est cruciale.<br />Itérez, itérez, itérez...<br />Chaque investissement en documentation devrait être compris et entendu avec le client.<br />Adhérez au principe du juste assez bien<br />
  77. 77. Without the shift in thinking, methodology becomes technique and practice becomes imitation. Peter Block<br />
  78. 78. Merci!<br />Des questions?<br />Pour obtenir les diapos : fbeauregard@pyxis-tech.com<br />
  79. 79. En discuter davantage<br />N’hésitez pas à m’accrocher<br />N’hésitez pas à me contacter - fbeauregard@pyxis-tech.com - <br />Voussouhaitezouvrirune discussion ou faire uneprésentation (celle-làouuneautre) dansvotreorganisation - Avec grand plaisir!<br />

×