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

Transcription

1 Le rôle de l'analyste d'affaires et la place de la documentation dans un processus Agile François Beauregard 2008 Pyxis Technologies. Tous droits réservés. All Rights Reserved.

2 Avertissement Quelques diagrammes sont en anglais! J ai plus de diapos que nécessaire car je parle beaucoup!

3 Par où commencer?

4 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!

5 Sondage à main levée Utilisez vous une approche Agile dans votre organisation?

6 Déroulement État des lieus Agile en quelques mots Modélisation Agile et documentation Initiale Détaillée Quotidienne Quelques mots à propos d une transition vers une approche Agile Conclusion

7 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?

8 État des lieus Bref historique et quelques anecdotes

9 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.

10 Développement et gestion des exigences Source : Karl E. Wiegers

11 Une découverte? Ces élément sont nécessaires peu importe l approche, n est-ce pas? Mais alors que doit-on changer? Pourquoi changer?

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 Feature Usage within deployed applications Never 45.00% Always 7.00% Rarely 19.00% Often 13.00% Sometimes 16.00% Jim Johnson, Standish Group, XP 2002

14 Cycle en V (cascade)

15 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é.

16 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.

17 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

18 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.

19 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.

20 Modèle en cascade vs. Agile : le paradigme Waterfall Agile PM responsibilities Team responsibilities The plan creates The vision creates feature estimates cost/schedule estimates Constraints Features Cost Schedule Value/visiondriven Plandriven Estimates Cost Key performance indicator (KPI) Schedule Budget and time Features Supported functionalities

21 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

22 Processus Agile standard Scrum -3 rôles Propriétaire ScrumMaster Équipier L analyste d affaire?

23 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? Questions corollaires : Êtes-vous bon actuellement avec cela? Comment les principes et pratiques Agile peuvent vous aider? Comment pouvez-vous partager cette responsabilité? Est-ce que ça doit être l affaire de tous?

24 Déroulement État des lieus Agile en quelques mots Modélisation Agile et documentation Initiale Détaillée Quotidienne Quelques mots à propos d une transition vers une approche Agile Conclusion

25 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

26 Quelques valeurs et principes Principes de base Communication Simplicité Rétroaction Courage Humilité 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 Les logiciels sont votre principal but Voyager léger Principes supplémentaires Le contenu est plus important que la présentation Il faut préconiser les communications ouvertes et honnêtes

27 Prenez note Modèle!= document Il y a plus à la modélisation que l UML La modélisation n a pas à être dysfonctionnelle (peu importe ce que pense les bureaucrates) Il faut modéliser avant de coder Il faut travailler ensemble pour apprendre comment devenir de meilleurs développeurs

28 Quel est la façon la plus efficace de communiquer?

29 À quel vitesse l information se déplace-t-elle? Configuration traditionnelle Configuration en espace ouvert

30 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 Product Ow ner Inspect and Adapt Incremental Delivery Time Boxed Establish priorities add Top Priorities Iteration Backlog remove Features Backlog

31 La modélisation initiale Self Organized Team Product Owner Project Vision (Iteration 0) Iteration Planning Iteration Initial Modeling Detailed Modeling Just-In-Time Modeling Inspect and Adapt Incremental Delivery Time Boxed Establish priorities add Top Priorities Iteration Backlog remove Features Backlog

32 Objectifs initiaux de modélisation Déterminer la portée du projet Définir l architecture initiale Établir la liste des exigences Explorer les domaines d affaires Développeur un langage commun

33 Quels sont les problèmes liés à la phase d analyse traditionnelle initiale? La connaissance initiale est incomplète Manque de feedback des utilisateurs Efforts d analyse additionnelle sur des fonctionnalités qui sont de basse priorité ou qui apporte peu de valeur Ne laisse pas facilement place au changement

34 Modèles possibles de modélisation des exigences Modélisation des exigences Cartographie des rôles utilisateur Cas d utilisation (Descriptif) Diagramme UML de cas d utilisation Scénarios utilisateur (User Stories) Modélisation des interfaces utilisateurs Modélisation du domaine

35 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

36 Les détails relatifs aux exigences s accumulent

37 Exemple de schéma de déroulement :Main Menu use Enrollment Requester use Transcript Requester :Enroll in Seminar use Transcript Requester :Obtain Transcript use Professor Information Requester use Prerequisite Details Requester :Professor Information use Seminar Information Requester :Transcript :Seminar Information

38 Prototype essentiel d interface utilisateur

39 Exemple de schéma de format libre

40 Quand cessons-nous d ajouter des détails?

41 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 Inspect and Adapt Incremental Delivery Time Boxed Establish priorities add Top Priorities Iteration Backlog remove Features Backlog

42 Objectifs de la modélisation détaillée Comprendre les exigences des intervenants Comprendre comment les entités d affaires sont interreliées Détailler l enchaînement des processus opérationnels Concevoir une interface utilisateur

43 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?

44 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

45 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?

46 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!

47 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

48 Prototype de fidélité de bas niveau : prototypes papier

49 Modélisation juste à temps Self Organized Team Project Vision (Iteration ٠) Iteration Planning Initial Modeling Detailed Modeling Product Owner Iteration Just-In-Time Modeling Inspect and Adapt Incremental Delivery Time Boxed Establish priorities add Top Priorities Iteration Backlog remove Features Backlog

50 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

51 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. Modélisez avec les autres.

52 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)

53 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

54 Spécifications exécutables Un exemple Le système doit supporter l'addition Est-ce qu'il y a une meilleure façon? 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. Règle pour la calculatrice Opérande ١ Opérande ٢ Total? ٧ ٣ ١٠-٣ ٧ ٤ ٦ ٠ ٦-٥ ٣-٢

55 Spécifications exécutables Un exemple (suite) Le système doit également supporter Est-ce qu'il y a une meilleure façon? la division. Règle pour la calculatrice Opérande ١ Opérande ٢ Total? Quotient? ٧ ٣ ١٠ ٢.٣٣-٣ ٧ ٤-٠.٤٣ ٦ ٠ ٦ Erreur -٥ ٣-٢ -١.٦٧ ٠ ٥ ٥ ٠

56 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 $.

57 Réponse Règle pour la vérification du crédit Mois Fiable Solde Crédit accordé? Limite de crédit? ١٤ Oui ٥٠٠٠ $ Oui ١٠٠٠ $ ٠ Oui ٠ $ Non ٠$ ٢٤ Non ٠ $ Non ٠$ ١٨ Oui ٦٠٠٠ $ Non ٠$ ١٢ Oui ٥٥٠٠ $ Non ٠$

58 Transition vers un processus Agile Il s agit d un sujet pouvant faire l objet d une présentation. La transition se fait progressivement (sans heurt ou non). Chaque mise en œuvre Agile est unique et adaptée aux particularités et à la réalité de l organisation cible Intégrez des pratiques d ingénierie graduellement. Créer un environnement collaboratif. Soyez sincère et transparent. Autonomisez les équipes.

59 Courage et persévérance

60 Conclusion Les conceptions Agile 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

61 Références importantes Scott W. Ambler Méthodologiste, auteur, conseiller

62 Autres références Merci! Des questions? Pour obtenir les diapos : fbeauregard@pyxis-tech.com

63 Besoin d un coup de main? Centre de développement Développement sur mesure Gestion du changement et formation Architecture et conception Transition Agile Méthodes de test Scrum Évaluation et gestion de projet Modélisation Agile Tests (stratégie, tests fonctionnels, TDD, etc.) Accompagnement Agile Services-conseils en développement Développeurs chevronnés Accompagnement technologique (Java,.NET, Ruby) concertée de spécifications exécutables et de Exploration de solutions d'amélioration tests de réception de scénarios exécutables. De plus, il offre de grandes capacités de traçabilité Sélection et configuration d'outils Gestion de projet, évaluation de mandat Audit et recommandations Rétrospective GreenPepper simplifie grandement la création des exigences.