![Encadrement (3e niveau)
•
Soutien au développement
–
–
–
–
•
Prodiguer la formation continue sur les nouvelles pratiques
Coacher sur les pratiques agiles
Gérer le processus organisationnel
Obtenir des ressources [matérielles] aux équipes
Gestion des individus: rôles et responsabilités
–
–
–
Identifier et résoudre les dysfonctionnements des équipes
Revoir les descriptions de postes, et peut-être les échelles
de rémunération associées
Impliquer les pairs dans le processus de GRH](https://image.slidesharecdn.com/strudel-isaca-20120412-v02-131129072354-phpapp01/85/L-adoption-de-l-agilite-les-impacts-sur-l-organisation-19-320.jpg)
Téléchargé parISACA Chapitre de Québec
L'adoption de l'agilité: les impacts sur l'organisation
Le document traite de l'adoption de l'agilité dans les organisations, en expliquant ses impacts au-delà des projets, notamment en matière de culture, de gouvernance et de gestion du changement. Il détaille les valeurs, principes et méthodes agiles, ainsi que les défis liés à leur mise en œuvre et les meilleures pratiques pour assurer la qualité et l'efficacité des processus. En conclusion, une transition vers l'agilité nécessite un accompagnement pour minimiser les risques et améliorer les pratiques organisationnelles.
Contenu connexe
![[SEN#7] Le classement des Entreprises de Service du Numérique (ex-SSII) qui r...](https://cdn.slidesharecdn.com/ss_thumbnails/top100sen7esn-v1-170320094858-thumbnail.jpg?width=640&height=640&fit=bounds)
Similaire à L'adoption de l'agilité: les impacts sur l'organisation
L'adoption de l'agilité: les impacts sur l'organisation
- 1. L’adoption de l’agilité: Impactssur l’organisation • • ISACA - Québec 12 avril 2012
- 2. Qui suis-je? • Sylvie Trudel – CoachAgile – Chargé de cours Université de Sherbrooke – Doctorat de l’ETS – Co-auteur d’un livre avec Mathieu Boivert
- 3. Agenda • • Introduction à l’agilité Impactsde l’agilité au-delà des projets – – – – – – • • Activité limitrophes Encadrement Coûts Gouvernance Culture organisationnelle Gestion du changement Pratiques liées à l’ACQ dans les projets agiles Discussion et conclusion
- 4. • Valeurs, principes etméthodes Introduction à l’agilité
- 5. Qu’est-ce que l’Agilité? L’agilitéest une philosophie de travail basée sur 4 valeurs et 12 principes Les méthodes et approches qui sont dites « agiles » sont cohérentes avec ces valeurs et ces principes
- 6. Les 4 valeursde l’agilité L’agilité valorise: 1. Les individus et les interactions 2. Les logiciels fonctionnels 3. La collaboration avec le client 4. La réponse au changement davantage que: les processus et les outils une documentation exhaustive la négociation de contrat le suivi d'un plan Utiles, nécessaires, mais moins importants que
- 7. Les 12 principesde l’agilité 1. 2. 3. 4. 5. 6. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles 7. 8. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte Les experts métier et les développeurs doivent collaborer quotidiennement au projet Bâtissez le projet autour de personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail La méthode la plus efficace pour transmettre l'information est une conversation en face à face 9. 10. 11. 12. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet Les processus agiles promeuvent un rythme de développement durable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens
- 8. Méthodes agiles • Scrum – – – • Extreme Programming(XP) – – • Méthode inspirée du domaine manufacturier • • • engagement des équipes de développement collaboration avec les clients plus grande valeur ajoutée possible • • • • Qualité du code Souplesse du code Amélioration continue Élimination du gaspillage AgileUP – • Méthode agile la plus technique Pratiques rigoureuses d’ingénierie logicielle Lean / Kanban – • Méthode agile la plus adoptée Gestion de projet et gestion des exigences Peu restrictive mais demande de la rigueur Adaptation de RUP, la plus prescriptive des méthodes agiles Crystal – Une famille de méthodes adaptées au contexte de l’organisation et à l’envergure des projets
- 9. L’approche Scrum: unsurvol ScrumMaster Équipe Scrum Utilisateurs Product Owner Vision
- 10. Pourquoi l’agilité? • • • • • • • • Pour satisfairerapidement le client avec des solutions logicielles utiles Pour faire face à la complexité en générant rapidement de la connaissance Pour que la qualité soit prise en compte dès le début du projet Pour rendre visible les inefficacités Pour éviter les longues périodes de stabilisation en fin de projet Pour maximiser la collaboration entre tous les intervenants Pour augmenter la motivation et l’engagement des individus Pour avoir du plaisir au travail
- 11. Cartographie des pratiquesagiles Source: Blogue Développement Agile, Le guide des pratiques Agile, Mercredi 7 mars 2012, http://developpementagile.com/posts/2012/march/le-guide-des-pratiques-agile
- 12. • Ce qui n’estpas couvert directement par les méthodes agiles Impacts de l’Agilité au-delà des projets
- 13. Culture Gouvernance Soutien au développement Architecture Projets Infrastructure technologique Gestionde projets Déploiement Gestion des individus Impacts de l’Agilité au-delà des projets
- 14. $ (1 à 4mois) (2 à 8 mois) (6 à 36 mois) (Durée de vie utile) $ (2 à 8 mois) La cible Transition agile Le point de départ Cycle de vie des projets (1er niveau) (2 à 4 semaines) (de 2 jours à 4 semaines) $ (5 à 10 jours) (2 à 4 semaines) (1/2 journée) (<= 1 journée)
- 15. Quels sont leséléments différents? • Méthodologie traditionnelle – – – – Améliorations ponctuelles, parfois rares Documentation lourde, dogmatique, peu gérée Bilans de projet comptables Cycle de développement souvent en cascades Architecture Analyse Design Program. Test • Méthodologie Agile (Scrum, TDD et/ou XP) – – – – Améliorations mensuelles Documentation réfléchie, améliorée et gérée Rétrospectives régulières Cycle de développement itératif et incrémental
- 16. Pratiques non couvertesde l’Agilité À peu près tout ce qui contient ou sous-entend le mot « organisationnel » à Typiquement en dehors de la portée des méthodes agiles • • • • Processus organisationnel Gouvernance Assurance qualité sur des activités organisationnelles (ex. bureau de projet) Gestion des individus Parce que les méthodes agiles sont peu prescriptives, une organisation a toute la latitude pour entourer et soutenir ses équipes
- 17. Pratiques limitrophes (2eniveau) • Gestion de projet: reddition de compte – • Architecture: de linéaire à incrémentale – • Adopter une approche et une façon différente de découper un projet, tant organique que fonctionnel Déploiements: plus fréquents, à la fin de chaque itération – • Tenir compte des mesures de progression basées sur du logiciel fonctionnel Rendre le processus de déploiement plus efficient Infrastructure technologique: juste à temps – Obtenir les différents environnements dès le début
- 18. État d’avancement: leSunset Graph Projection optimiste : 69 pts avec une vélocité estimée à 13 pts/itération 70 Cône d’incertitude 60 Points 50 Catégories du carnet de commandes: Projection pessimiste : 51 pts avec une vélocité estimée à 7pts/itération Obligatoire 40 Important Facultatif 13 30 7 20 10 Catégories des livraisons : Obligatoire Actuel: 30 pts réalisés 10 Important Facultatif 0 1 2 3 4 Itérations 5 6 7
- 19. Encadrement (3e niveau) • Soutienau développement – – – – • Prodiguer la formation continue sur les nouvelles pratiques Coacher sur les pratiques agiles Gérer le processus organisationnel Obtenir des ressources [matérielles] aux équipes Gestion des individus: rôles et responsabilités – – – Identifier et résoudre les dysfonctionnements des équipes Revoir les descriptions de postes, et peut-être les échelles de rémunération associées Impliquer les pairs dans le processus de GRH
- 20. Performance attendue d’unetransition agile: impact sur les coûts unitaires Effort Processus traditionnel non amélioré Processus en transition Processus agile Taille (PFC) Amélioration anticipée de 20% à 30% sur les 1ers projets Amélioration potentielle de 50% + en ± 3 ans
- 21. Gouvernance (4e niveau) • • Alignementstratégique: ROI plus rapide Répercussions sur les objets de gouvernance opé Risqu rat es i on ne l s • Gérer cet enjeu tant du côté affaires que du côté TI Transformation du rôle de gestionnaire – • et ôles ités R f il Af onsab resp Confo TI rmité Ge Ge st cha stion pr ion oj n g e du et de me s nt Positionnement de l’imputabilité des affaires – • s ire a Ils ne gèrent plus les mêmes éléments avec les mêmes paramètres Structures organisationnelle et de gouvernance – Revoir les matrices RACI é it r cu Sé
- 22. Processus Possibilités • Toute transformation impliquela perte des acquis … pour en gagner d’autres! – Gérer le changement est essentiel Impersonnel Certaines cultures se prêtent mieux que d’autres à l’Agilité Actualité et réalité Contenu • Personnel La culture (5e niveau)
- 23. La gestion duchangement – Ingrédients menant au succès 1- Pression pour changer 2-Vision 3-Capacité à changer 4-Actions 5-Résultats Compétences Motivation Ressources Plan d’action Changement Compétences Vision Motivation Ressources Plan d’action Confusion Motivation Ressources Plan d’action Anxiété Ressources Plan d’action Changement graduel Plan d’action Frustration Vision Vision Compétences Vision Compétences Motivation Vision Compétences Motivation Ressources Faux départs Source: adapté de Dolores Ambrose, 1987. Personal Communication. Ce modèle provient originalement de « The Enterprise Corporation », une firme de consultants qui a cessé d’exister.
- 24. • Les activités menantà la qualité Pratiques liées à l’ACQ dans les projets agiles
- 25. Principes et orientationsde qualité 1. 2. 3. 4. La qualité est l'affaire de tous rôles et responsabilités Chaque pratique et livrables du processus doit être conforme avec ses critères de qualité, soit ses objectifs à atteindre pratiques agiles d’inspection pratique du carnet de produit «Qualité» de nos applications et de nos processus en tant que critère non négociable définition de terminé L’équipe applique les principes d’amélioration continue Rétrospectives
- 26. 1. Rôles etresponsabilités imputable d’un carnet de qualité, du ROI et de l’acceptation du produit responsable des estimations, de prendre des engagements et de livrer des résultats surveille l’application du processus agile
- 27. 2a. Pratiques agilesd’inspection Mêlée quotidienne pour assurer le bon déroulement de l’itération Rétrospective pour vérifier et améliorer le processus de l’équipe Tests automatisés pour valider la qualité du produit à chaque mouvement de code Revue d’itération pour valider le dernier incrément de logiciel Pratiques adaptées au cycle de Verification, Validation, Revue, et Audit
- 28. 2b. Pratique ducarnet de produit Chaque itération met en œuvre les exigences prioritaires Chaque nouvelle exigence est insérée dans la liste selon sa priorité Il est possible en tout temps de changer l’ordre de priorité des exigences Les exigences peuvent être supprimées en tout temps
- 29. Le carnet deproduit (suite) • • Chaque item est un « contrat » entre l’équipe et le client Chaque item est un projet en soit: • • • • • Requiert toutes les disciplines, de l’analyse jusqu’au tests Définit un test d’acceptation Répond à la définition de terminé Adapté aux tests automatisés: unitaires et fonctionnels, parfois intégrés Ne peut pas être partiellement livré qualité « production »
- 30. La User Storyou scénario utilisateur • Comprend 3 éléments: 1. Un besoin d’affaires en 3 parties a. b. c. 2. Une description •. 3. En tant que <rôle> Je veux <besoin/fonctionnalité/feature> Afin de <bénéfices attendus> Toute l’information jugée utile et nécessaire pour développer et maintenir le besoin/fonctionnalité Des conditions de succès •. Ce qui sera démontré lors de la revue de sprint et qui aura été préalablement testé
- 31. 3. Définition determiné • • • • Entente sur les pratiques de qualité entre le client et l’équipe La définition de « terminé » devrait s'étendre à toutes les activités nécessaires à la livraison en production Le travail qui n'est pas couvert pas la définition de «terminé» (travail « non terminé ») doit être identifié et porté au carnet de produit Tout élément qui ne respecte pas la définition de «terminé» n'est pas présenté à la revue d’itération
- 32. Définition de terminé(exemple) Période Définition de terminé Story • • • • • • • • Devis fonctionnel rédigé Code intégré au gestionnaire de code source Intégration continue réussie Tests unitaires écrits et réussis à 100% Remodelage effectué Code revu par un pair Respect des normes IUG Aucun avertissement lors de la compilation Itération • • Mêmes éléments que pour la story, plus: Bilan d’itération publié sur le Wiki Livraison • • Déployé sur l'espace de pré-production Répond au plan de Tests de stabilisation (à préciser) Procédure de déploiement fonctionnelle et documentée Guide utilisateur rédigé au niveau du dernier incrément • • Phase • Déployé sur l'espace de production Équivalente au plan qualité logiciel (SQAP) en grande partie!
- 33. Un produit de qualitéproduction … … à chaque itération!
- 34.
- 35. 4. Rétrospective • • • • La rétrospectivefait suite à la revue d’itération Permet à l'équipe de prendre du recul sur l'itération terminée et le processus de travail L'équipe s'auto-évalue sur ce qui a bien fonctionné, ce qu'on doit faire autrement, et les axes d'amélioration L’équipe définit des actions pour s'améliorer dès la prochaine itération
- 36. • Défis et enjeuxd’une organisation vers l’Agilité Discussion et Conclusion
- 37. Discussion • à Défis et enjeuxliés au non-respect des meilleures pratiques au regard de la qualité et des risques, quels sont-ils? Similaires, peu importe que l’équipe soit agile ou pas: • • • Processus non suivi AQ déficiente Pratiques bâclées de contrôle de la qualité (vérification) Pas la bonne personne dans des rôles clés
- 38. Points à surveillerpour un auditeur • Respect de la définition de terminé – • Reddition de compte – • Les résultats sont-ils conformes avec la réalité? Comment s’en est-on assuré? Prise en charge des risques par le PO – – – • Y a-t-il accumulation d’une dette technique? De quelle valeur? Est-ce la bonne personne, avec les bonnes connaissances du domaine d’affaires? Le contenu et l’ordonnancement du carnet de produit opérationnalisent la gestion des risques La conformité et la sécurité ont-elles été prises en charge? Gestion de la transition à l’Agilité – Le changement est-il soutenu adéquatement?
- 39. Conclusion • • • Le principe directeurAgile est de livrer le bon produit fonctionnel, de qualité production, en ligne avec les objectifs d’affaires et de continuité Les pratiques agiles offrent de multiples points d’inspection pour combler les besoins liés à la gouvernance (gestion de risques) et à l’amélioration continue Une transition agile nécessite presque toujours de l’accompagnement pour réduire les risques liés aux changements et tendre vers de meilleures pratiques, tant dans les projets de développement qu’au niveau de la gouvernance
- 40.