Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve

331 vues

Publié le

Atelier présenté lors de la préconférence BAFS 2015 le 29 juin 2015 à Genève.
Essayer quelques outils du monde Agile pour aider le BA à identifier la valeur et aider à définir le périmètre minimum pour la livrer rapidement, de manière itérative et incrémentale.

Publié dans : Données & analyses
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
331
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
15
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Ça ne signifie pas que les items du côté droit ne sont pas importants.
    Lorsqu’il est possible de faire des choix, l’approche Agile favorise toujours les items du côté gauche
    Sous-jacents aux 4 valeurs, il y a 12 principes – une feuille contenant les valeurs et principes est distribuée aux participants
    Le questionnaire utilisé au début de la formation était directement en lien avec ces 4 valeurs de l’Agilité
    Utiliser une approche Agile signifie que l’on aligne nos pratiques, nos processus et notre mode de fonctionnement sur les valeurs du côté gauche

    Jeu Débattons
    Séparez la salle à deux
    Pour chacune des valeurs :
    Ceux à ma gauche sont fervents de la valeur de gauche.
    Ceux à ma droite sont fervents de la valeur de droite.
    Pas le droit d’insulter ou de porter des coups ou de lancer des objectifs.
    Go.

    Take time to review the 3 parts
    No silver bullet (part 1)
    Practice (part 1)
    Discuss the balance
    Review the 13 Principles (not shown here)


    Faire de l’Agile vs « Être Agile »

    La complexité et le changement ne cesseront de croître
    On se concentre donc sur la planification plutôt que sur le plan.
    La planification nécessite un niveau de précision croissant. (Rolling wave planning)
    On cherche l’équilibre entre anticipation et émergence
    On intègre l’apprentissage obtenue par nos cycles de rétroactions (approche empirique)
    Rétroaction quotidienne
    Rétroaction mensuelle

    Key Message : Agile challenges the Project Manager’s assumptions about certainty

    http://technorati.com/tag/rolling-wave-planning



    Le vrai défi : Adopter une attitude Agile plus qu’un processus de développement Agile
    Collaboration et entraide
    Transparence et humilité
    Recherche constante de l’amélioration continu
    Engagement et responsabilisation
    Simplicité : Juste assez , Juste à temps

    Nous visons la création de véritable équipe hautement performante

    « It’s always a people problem »
  • Atelier :
    Séparez la salle 4 groupes
    Sur l’aspect de l’architecture, la modélisation et l’analyse discuter comment répondre au principe que je vous ai assigné. Identifier 1 à 3 exemples concrets. (5 minutes)
    Synthèse de chacun (8 minutes)
  • 6
  • Pourquoi l’architecture est nécessaire : la complexité de nos systèmes.

    Si le client trouve cela simple, en général il va développer ses spécifications dans Access ou Excel. A partir du moment que cela devient complexe, il fait affaire aux équipes de développement.
  • Présentation des différents patterns de démarrage que je connais.
  • Les processus sont une autre moyen de se concentrer sur la valeur d’affaire
  • Dans le meilleur des cas vous pouvez travailler à une story sans voir les autres histoires.
  • Agile BA - catalyseur, createur de valeur - BAFS 29 juin 2015 Geneve

    1. 1. Agile BA - catalyseur, créateur de valeur Christian Lapointe Tremeur Balbous BAFS15 29 juin 2015
    2. 2. Qui sommes nous? • Christian Lapointe – clapointe@pyxis-tech.com – @chrlapointe • Tremeur Balbous – tbalbous@pyxis-tech.com – @agilegardener
    3. 3. Agenda • Introduction • Pilotage par la valeur • Impact mapping • Story mapping • User Stories • Conclusion
    4. 4. Les individus et leurs interactions Une solution fonctionnelle La collaboration avec le client La réponse au changement les processus et les outils. une documentation exhaustive. la négociation d’un contrat. le suivi d’un plan. sont plus importants que est plus importante que est plus importante que est plus importante qu’ Qu’est-ce que l’Agilité? manifeste Agile – 4 valeurs Dans le contexte de votre travail, qu’est-ce que cela signifie?
    5. 5. Satisfaire le client en premier Accepter les demandes de changement Livrer fréquemment dans les plus courts délais Soutenir la collaboration avec le client et les équipiers Soutenir les équipes et leur faire confiance Favoriser les conversations en face à face Mesurer l’avancement par des logiciels fonctionnels Favoriser un rythme soutenable Soutenir l’excellence technique Maximiser par la simplicité Former des équipes auto- organisées S’améliorer continuellement Qu’est-ce que l’Agilité? manifeste Agile – 12 principes Quels défis ces principes posent-ils sur votre rôle?
    6. 6. Qu’est-ce que l’Agilité? Scrum : un cadre de travail Idée des clients, de l’équipe, des gestionnaires et de la direction
    7. 7. • Déterminer la valeur; • Cartographier la chaîne de valeur; • Mesurer la cadence (flux); • Éliminer le gaspillage; • Établir un flux tiré; • Assurer l’amélioration continue. • Quelques techniques Lean : – Outils visuels d’aide à la prise de décisions (Kanban); – Stop the line; – Single digit set-up; – Kaizen-A3; – Pratiques « à l’épreuve des erreurs ». Qu’est-ce que l’Agilité? Agile Lean
    8. 8. Qu’est-ce que l’Agilité? L’Empirisme Inspection Adaptation Transparence
    9. 9. ARCHITECTURE AGILE RAPPEL : FACTEURS DE COMPLEXITÉ Loin d’une certitudePrès d’une certitude Technologies Loind’unaccordPrèsd’unaccord Spécifications Compliqué Compliqué Simple Chaos La plupart du temps, vous êtes ici. Source : Stacey RD. Strategic management and organisational dynamics : the challenge of complexity. 3rd ed. Harlow : Prentice Hall, 2002 Domaine d’affaires Technologie La complexité
    10. 10. En cascade (waterfall) L'information initiale est supposée fiable et le risque est dans la réalisation des activités (ex. : efficacité). Un diagramme de Gantt est utilisé pour tracer le chemin critique des activités. Agile L'information initiale est considérée insuffisante, et le risque est dans la livraison d'un produit à forte valeur ajoutée. Le chemin critique est construit avec des biens livrables (ex. : story mapping) et l'avancement se mesure à partir d’incréments pertinents (ex. : terminés). Choisir une stratégie
    11. 11. Pilotage par la valeur
    12. 12. Deux approches Source : « Choisir l’Agilité » de Mathieu Boisvert et Sylvie Trudel
    13. 13. Un modèle de financement Agile Itération 3 Itération 1 Itération 2 • L’équipe est réduite, semblable au modèle traditionnel, mais avec l’ajout de quelques développeurs principaux. • L’analyse est faite dans l’ordre de la valeur d’affaires et du risque (style Agile et Lean Startup). • En plus des documents, les incréments valident les plus grandes hypothèses. • L’investissement est une dépense. Itération 4 Itération 5 Itération 8 Itération 6 Itération 7 Itération 9 Itération 10 Itération … • Changement dans la composition de l’équipe : plus de développeurs, moins d’analystes; • Continuité; pas de transfert de projet; • Carnet de produit, définition de « terminé », outil de suivi et incrément de base déjà en place : pas seulement un document d’analyse; • Transfert des coûts d’avant-projet au budget du projet de développement. LE BUT EST DE RÉDUIRE LE RISQUE ET ESTIMER LES PARAMÈTRES DU PROJET LE BUT EST DE LIVRER AVEC UNE PLUS GRANDE VÉLOCITÉ ProjetAvant-projet
    14. 14. • Les besoins d’affaires alimentent le carnet de produit et fixent son ordonnancement. • Chaque itération met en œuvre les besoins prioritaires. • Chaque nouvel item est inséré dans la liste selon sa priorité. • Il est possible de changer l’ordre des items qu’on n’a pas commencés. • Les items non commencés peuvent être supprimés en tout temps. Les carnets de produit et d’itération Carnet d’itération Carnet de produit ExplorationPotentielRéalisable Une stratégie est requise afin de gérer et de planifier les spécifications d’architecture.
    15. 15. Source : Estimating and Planning de Mike Cohn Stratégie pour atténuer les risques : Grande valeur et coûts élevés Stratégie de capitalisation : Grande valeur et coûts faibles pour augmenter rapidement la valeur du produit Faible Forte Faible ÉlevéRisque Valeur d’affaires 2 1 3 1 2 3 Rédaction et entretien du carnet de produit Quadrants de Mike Cohn Planification commune de la valeur d’affaires et du risque Technique Ordonner les éléments selon la stratégie
    16. 16. Évaluation des risques et de la valeur d’affaire Probabilité très faible (1) Probabilité faible (2) Probabilité modérée (3) Probabilité élevée (4) Probabilité très élevée (5) Impact T. faible (1) (1) * (1) (2) * (1) (3) * (1) (4) * (1) (5) * (1) Impact faible (2) (1) * (2) (2) * (2) (3) * (2) (4) * (2) (5) * (2) Impact modéré (3) (1) * (3) (2) * (3) (3) * (3) (4) * (3) (5) * (3) Impact élevé (4) (1) * (4) (2) * (4) (3) * (4) (4) * (4) (5) * (4) Impact très élevé (5) (1) * (5) (2) * (5) (3) * (5) (4) * (5) (5) * (5) Impacts Probabilités Faible Forte Faible Élevé Risque Valeur d’affaires 2 1 3 1 2 3
    17. 17. La réalité • On fait du Water-Scrum-Fall • Une fois le projet lancé, les hypothèses ne sont pas vérifiées ni challengées • Les Product Owners, chefs de projet Agile ou autres, ne sont pas en mesure de le faire
    18. 18. Relation avec le Product Owner Il est responsable du succès du produit. Il a une vision globale du produit. Il agit comme un entrepreneur. Il se soucie des utilisateurs. L’équipe veut le satisfaire. Il est responsable du carnet de produit (priorité). Vous avez besoin de lui. Ajustez votre langage pour qu’il soit compris par tous. Il a besoin de vous. > Définir les besoins > Détailler certains items > Prévoir les incertitudes > Prendre les bonnes décisions > Comprendre l’impact > Avoir le besoin > Ordonner > Élaborer la vision > Obtenir de la rétroaction Product Owner
    19. 19. 4 questions simples • Pourquoi? • Qui? • Comment? • Qu’est-ce que?
    20. 20. Pourquoi? • L’objectif que nous voulons atteindre • Aide les équipes à – Aligner leurs activités – Identifier les vrais requis – Designer de meilleures solutions
    21. 21. Pourquoi? • Le problème, pas la solution • SMART – Specific, Measurable, Action-oriented, Realistic, Timely • Exemples – Augmenter le taux de conversion des utilisateurs par 20% dans 3 mois – Diminuer les coûts d’opération par utilisateur de 100 CHF d’ici la fin de l’année
    22. 22. Qui? • Qui peut produire l’effet désiré? • Qui peut l’empêcher, le bloquer? • Qui sont les consommateurs de notre produit? • Qui sera impacté? • Ce sont nos acteurs
    23. 23. Qui? • Acteurs principaux • Acteurs secondaires • Acteurs hors-scènes • Soyez spécifique – Eviter les termes tel « utilisateur » – Individus spécifiques – Persona – Rôle ou poste – Groupe ou département
    24. 24. Qui? • Exemples – Paul Hudon du département de marketting – Moins de 18 ans avec un téléphone portable – Inspecteurs de l’état de Vaud
    25. 25. Comment? • Comment le comportement de l’acteur doit changer? • Comment l’acteur peut nous aider? • Comment peut-il nous nuire/bloquer? • Ce sont les impacts que nous voulons créer – Ce ne sont pas des fonctionnalités du produit
    26. 26. Comment? • Idéalement, montrer le changement – Non pas « vendre des billets » – Mais plutôt « vendre des billets 5 fois plus rapidement » • Exemples – Inviter plus d’amis – Acheter des billets sans appeler le service des ventes
    27. 27. Qu’est-ce que? • Que peut-on faire, en tant qu’organisation ou équipe de déploiement, pour supporter les impacts requis? • Ce sont nos livrables – liés à de la valeur d’affaire
    28. 28. Qu’est-ce que? • A faire en mode itératif (PDCA) • Ce sont seulement des options • A briser plus tard (plus de niveau, user stories) • Tout n’est pas du logiciel • Exemples – Billetterie en ligne – Mutualisant plusieurs commandes
    29. 29. Atelier Impact Mapping • Jeux en ligne • Nous voulons 1 million de joueurs supplémentaires
    30. 30. Ensuite • Prioriser vos items – Par votes, achat … – Trouver vos KPI • Vérifier vos hypothèses – Sur les 2 niveaux • Rincer et répéter
    31. 31. Impact mapping • Outil de planification stratégique • Aide à prévenir le « scope creep » • Limite le gaspillage en s’assurant de livrer un produit qui répond aux attentes d’affaires
    32. 32. Story Mapping 33
    33. 33. Story Mapping de Jeff Patton • Objectif : Extraire les processus fonctionnel d’un cahier des charges. • Exercice en 3 étapes: • Classement par ordre chronologique • Classement selon la criticité • Identification des couloirs fonctionnels • En prime, si les acteurs sont identifiés, permet de tracer le diagramme de séquence.
    34. 34. 1 - Classement par ordre chronologique Logiquement, à quel moment cette fonctionnalité est-elle utile ? Logiquement, à quel moment cette fonctionnalité est-elle utile ?
    35. 35. 2 - Classement selon la criticité Fréquence: jour, semaine, mois, année? Importance: haute, moyenne basse?
    36. 36. Indice de criticité Fréquence •Jour •Semaine •Mois •Année Importance • Haute • Moyenne • Basse E – Consulter les postes par région / ville S B E – Créer une offre d’emploi M H
    37. 37. 3 - Identification des couloirs fonctionnels Tiré du livre « Choisir l’Agilité » de Mathieu Boisvert et Sylvie Trudel
    38. 38. Planification incrémentale Tiré du livre « Choisir l’Agilité » de Mathieu Boisvert et Sylvie Trudel
    39. 39. User stories
    40. 40. Description 41 • Une story est une courte description d’un besoin du point de vue de l’utilisateur • Une story met l’accent sur le Qui, Quoi et le Pourquoi, jamais sur le comment • La valeur, les risques et les coûts varient d’une spécification à l’autre • Elles sont compréhensibles que ce soit par le Product Owner ou l'équipe de développement • Leurs tailles permet la planification
    41. 41. Les avantages recherchés • Mettre l’emphase sur la communication et la compréhension au lieu d’une documentation • Avoir une compréhension commune entre les utilisateurs, le responsable de produit et l'équipe de développement • Avoir un accord de l’équipe pour réaliser la story • Reporter les décisions et les détails au moment opportun • Supporter les opportunités • Favoriser le développement itératif
    42. 42. Les 3 « C » (Ron Jeffries) • Une section qui contient: – La description • Qui - rôle de l’utilisateur • Quoi - fonctionnalité • Pourquoi - raison – La priorité – La valeur affaires – La catégorisation (tags, thèmes, regroupement) – L’effort Carte Conversation Confirmation En tant que candidat, je veux rechercher les offres d’emploi correspondant à des arguments afin de me permettre d'accéder à la description de l’offre et ultimement poser ma candidature. http://xprogramming.com/articles/expcardconversationconfirmation/
    43. 43. Les 3 « C » (Ron Jeffries) • Une section qui contient de l’information complémentaire de la story. • Privilégier la collaboration et la communication au lieu d’une documentation non nécessaire. Carte Conversation Confirmation Les besoins d'affaires suivants s'appliquent à cette story: • Arguments : compétence, région, domaine d'activité, langue • Si aucun argument saisi dans la recherche = aucun résultat • Besoin d'une pagination sur la liste des résultats de recherche • Possibilité de trier les résultats par colonne dans le tableau des résultats En tant que candidat, je veux rechercher les offres d’emploi correspondant à des arguments afin de me permettre d'accéder à la description de l’offre et ultimement poser ma candidature. http://xprogramming.com/articles/expcardconversationconfirmation/
    44. 44. Les 3 « C » (Ron Jeffries) • Une section qui contient la condition de succès pour confirmer que la story est complétée comme prévu. Carte Conversation Confirmation Condition de succès : • Je constate que tous les critères sont vides à l'entrée de la fonction. • Je saisis des critères puis je déclenche la recherche et je constate le résultat. • Je vide les critères puis je déclenche la recherche et je constate le résultat vide. • J'effectue un tri à même les colonnes du tableau des résultats et constate le classement des résultats. Les besoins d'affaires suivants s'appliquent à cette story: • Arguments : compétence, région, domaine d'activité, langue • Si aucun argument saisi dans la recherche = aucun résultat • Besoin d'une pagination sur la liste des résultats de recherche • Possibilité de trier les résultats par colonne dans le tableau des résultats En tant que candidat, je veux rechercher les offres d’emploi correspondant à des arguments afin de me permettre d'accéder à la description de l’offre et ultimement poser ma candidature. http://xprogramming.com/articles/expcardconversationconfirmation/
    45. 45. INVEST (Bill Wake) – Indépendant – Négociable – Valeur d'affaires ajoutée – Estimable – Grosseur appropriée (Sized right) – Testable http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
    46. 46. 47 Questions pour vous aider Qu’est-ce que l’équipe a besoin de savoir? Qu’est-ce que l’utilisateur voit durant chacune des étapes? Quelles sont mes assomptions sur l’implémentation de la story ? Qu’est-ce qui peut ne pas fonctionner?
    47. 47. Gherkin pour vous aider • L’intention de la BDD (behavior driven development) est de spécifier, sous la perspective des utilisateurs, le comportement du produit de façon concise, claire et exécutable Scénario : Retirer avec succès un montant d'un compte valide Étant donné que le compte bancaire de Robert est valide Et le compte bancaire de Robert contient 300.00$ Et Robert a ouvert une transaction avec le bon NIP Quand Robert retire 100.00$ Alors la machine donne 100.00$ à Robert Et le compte bancaire de l'usager est de 200.00$ Scénario : Erreur lorsque l'usager essaie de retirer un montant supérieur au fond du compte Étant donné que le compte bancaire de Robert est valide Et le compte bancaire de Robert contient 300.00$ Et Robert a ouvert une transaction avec le bon NIP Quand Robert retire 350.00$ Alors la machine retourne à l'écran l'erreur "fond insuffisant" à Robert Et le compte bancaire de l'usager est de 300.00$
    48. 48. Les pièges Cela sent bon lorsque • CCC • INVEST • Maximum de 6 minutes pour expliquer la story • Les gens comprennent en lisant le story Cela sent mauvais lorsque • Rôles non existants dans l’organisation • Pas assez détaillé / Trop détaillé • Interdépendance entre les stories • Trop de stories • Trop fignolé, peaufiné • Montre le comment et la solution • Introduire des détails d'interface utilisateur trop tôt • Penser trop d'avance • L'utilisateur a de la difficulté à établir des priorités
    49. 49. 50 Définition de prêt • Écrite sous forme narrative ("En tant que ...") • Comprise par l’équipe et les parties-prenantes • D'une granularité qui n'excède pas 25% de la capacité de l‘équipe projet par itération • Tous les pré-requis sont résolus • La portée est définie par les « Conditions de succès »
    50. 50. Atelier 51 Titre : En tant que « acteur » je veux une « fonctionnalité » afin que « besoin d’affaires » Écrire des stories sur le site de recherche d’emploi selon le gabarit de droite. Gardez en tête les qualités des stories : 3 « C » INVEST Servez-vous des axes de découpage si la condition de succès devient trop complexe : par données, par priorité, par opérations et par considération transversale. Description : attributs, règles d’affaire, prototype d’écran, diagramme, etc… Condition de succès: Des tests fonctionnels qui définissent la portée de la story Gabarit de story Exercice – Rédaction de stories 20 min
    51. 51. 52 Conclusion • On veut limiter le travail de spécifier des stories qui risquent de changer dans le temps. • Éclatez vos épics: pendant la rédaction des stories, il se peut qu’on découvre différentes priorités. Diviser la spécification et prioriser le résultat. • Rédigez des stories ‘fermées’ • N'incluez pas les spécifications techniques : l’équipe de projet est responsable de décrire le « comment ». • Écrivez chaque cas pour un seul utilisateur : souvent une même fonctionnalité n’est pas spécifiée de la même manière selon l’utilisateur. • Découpez vos stories
    52. 52. Questions
    53. 53. Campus Agile • pyxis-tech.com/fr/campus-agile-europe • Formation Professional Scrum Product Owner – 29-30 octobre 2015 à Lausanne – 7-8 décembre 2015 à Genève
    54. 54. Références

    ×