Agile, ou pas Agile, telle est la question.

Agile ou pas, telle est la question.

Publié le en Transformation numérique du gouvernement

La fortune scandaleuse des processus en cascade dans l'administration publique

"Si c'est plus noble pour l'esprit de souffrir
La fronde et les flèches d'une fortune démesurée,
Ou de prendre les armes face à une mer d'ennuis,
Et en s'opposant à leur fin ?". - Hamlet de William Shakespeare
De nombreuses initiatives gouvernementales en matière de technologies de l'information fonctionnent comme des tragédies grecques: tous les efforts déployés pour réduire les risques d'un projet aboutissent à une augmentation des risques. De plus, les taux d'échec élevés, en particulier lorsqu'il s'agit de l'adaptation des logiciels de planification des ressources de l'entreprise (ERP), développés à l'origine pour le secteur privé, dans les administrations publiques.
L'informatique gouvernementale a également des accents de tragédie shakespearienne. Les gouvernements et les partenaires donateurs imposent souvent des "meilleures pratiques" de gestion de projet à des fournisseurs comme FreeBalance. L'une de ces "meilleures pratiques" est l'imposition de la gestion de projets de type "chute d'eau que présuppose que les projets de logiciels sont aussi prévisibles que les projets de construction. La construction bénéficie de contraintes physiques telles que la résistance des matériaux. Les logiciels ont beaucoup moins de contraintes et plus de possibilités de personnalisation.
Conception du projet FreeBalance Waterfall
Les pratiques en cascade imposées augmentent la "fortune scandaleuse". La gestion de projet agile peut-elle augmenter les taux de réussite ?

Bataillons de chagrins en cascade

"Quand les chagrins arrivent, ils n'arrivent pas seuls. Mais en bataillons !" - Hamlet de William Shakespeare
Une enquête récente menée par Accenture et NASCIO (National Association of State Chief Information Officers) a constaté que "Lorsqu'on leur demande quels résultats pourraient être évités en utilisant la méthode agile, 70 % des professionnels de l'informatique estiment qu'elle permet d'éviter le gaspillage d'argent lié à des projets informatiques inefficaces, 66 % qu'elle permet d'éviter l'échec de grands projets informatiques et 58 % qu'elle permet d'éviter les programmes qui ne répondent pas aux besoins de l'entreprise..”
Les techniques agiles telles que maigre, la réflexion sur la conception, Extrême, Kanbanet Scrum ont souvent été associées à de petits projets. Les observateurs traditionnels pensent que la méthode agile n'est pas adaptée aux grands projets informatiques. En tant que Mitre étude pour le Département de la défense des États-Unis a soulignéLes projets en cascade partent à tort du principe que les exigences sont bien définies et que les changements sont limités. En réalité, la méthode agile est beaucoup plus résistante au changement et à l'incertitude que la méthode en cascade. La méthode agile est idéale pour les initiatives importantes de planification des ressources gouvernementales (GRP). En effet, les connaissances acquises au cours de la mise en œuvre du projet permettent de mieux aligner les fonctionnalités sur les besoins réels de l'administration. La plupart des mises en œuvre de systèmes GRP font suite à la réforme et à la modernisation du gouvernement. Il ne s'agit pas seulement d'informatique, mais aussi de transformation..
C'est là que la méthode agile excelle.
Les échelles agiles. Des petits aux grands projets.

Agile ou pas agile ? Une liste de contrôle ABC

"Il y a plus de choses au ciel et sur terre, Horatio,
que ce dont rêve votre philosophie". - Hamlet de William Shakespeare
Tous les projets en cascade n'échouent pas. Tous les projets agiles ne réussissent pas. (Pour être juste, l'approche agile se concentre sur l'apprentissage, de sorte que les projets agiles ne réussissent pas tous. échouer rapidement est souvent un facteur de réussite).
Les Groupe de stratégie et d'innovation FreeBalance a analysé la littérature sur les projets et nos expériences gouvernementales. (Contrairement aux anciens fournisseurs de logiciels d'entreprise, FreeBalance participe à toutes les mises en œuvre afin de contribuer à l'amélioration des produits et des services). Cette analyse a conduit à la création de notre système A-i3+qM Elle a également conduit à une réévaluation significative des pratiques traditionnelles et de leur philosophie. Elle a également conduit à une réévaluation significative des pratiques traditionnelles et de la philosophie de ces pratiques.
Nous avons également créé une liste de contrôle en 26 points pour évaluer les facteurs. Les facteurs sont classés entre faible et élevé. Votre contexte peut être différent.
Facteurs favorisant la chute d'eau A-F
Liste de contrôle Agile ou Waterfall dans le cadre d'un PRV
Facteurs favorisant l'agilité G-Z
Facteurs favorisant l'agilité G-Z

  1. Complexité architecturaleLa nécessité de développer des architectures logicielles à partir de zéro tend à exiger de longues périodes de conception au-delà de multiples itérations. bien que cela ne s'applique pas aux architectures disponibles dans le commerce telles que le Plate-forme de responsabilisation FreeBalance
  2. Des problèmes bien comprisla connaissance approfondie des problèmes réduit la nécessité de recueillir des informations supplémentaires auprès de l'équipe agile - la connaissance approfondie des problèmes réduit la nécessité de recueillir des informations supplémentaires auprès de l'équipe agile. bien que de nombreux (la plupart ?) grands projets informatiques gouvernementaux soient axés sur les solutions et ne traitent que rarement les problèmes réels sans changements
  3. Expérience dans des circonstances similairesL'expérience de l'organisation gouvernementale dans la mise en œuvre d'initiatives similaires rend les projets plus prévisibles - Cependant, de nombreuses organisations gouvernementales considèrent l'expérience des fournisseurs hors contexte, comme l'expérience des fournisseurs dans d'autres contextes.
  4. Nombre de personnes: l'approche agile fonctionne bien avec de petites équipes motivées qui travaillent efficacement - bien qu'il faille noter que les projets en cascade nécessitent plus de personnel pour la communication, la coordination et la documentation que les projets agiles.
  5. Champ d'applicationLe champ d'application du projet : un champ d'application pleinement articulé, et une focalisation sur le champ d'application qui détermine le temps et les ressources, se prêtent aux contrôles en cascade qui réduisent le "glissement du champ d'application". bien que de nombreux projets échouent en raison de modifications incessantes du champ d'application qui privilégient les dispositions contractuelles au détriment des besoins réels des pouvoirs publics
  6. Capacité humaineLe niveau élevé des capacités humaines du gouvernement en matière de technologie, de gestion de projet et de gestion des finances publiques (PFM) permet d'atténuer bon nombre des risques associés à la chute d'eau. bien qu'une capacité élevée soit souvent associée à un excès de confiance
  7. Complexité du projetagile permet de décomposer la complexité et de structurer les activités en fonction des priorités grâce à des prototypes, à l'apport des utilisateurs et à l'analyse de la conception.
  8. Incertitude du projetL'agile est idéal lorsque l'incertitude du projet est élevée.
  9. Taux d'échec des technologies de l'informationL'agile fournit des outils de réussite aux équipes informatiques qui ont connu des résultats décevants.
  10. Fonctions interdomainesLe système agile fonctionne mieux lorsque les fonctions se croisent, par exemple les finances, les achats, la paie et l'administration fiscale.
  11. Axé sur les résultatsles projets conçus pour obtenir des résultats bénéficient de processus agiles car les projets en cascade se concentrent sur la conformité contractuelle
  12. Changement transformationnelles projets de modernisation, de réforme ou de réorganisation bénéficient de processus agiles plus transparents, plus communicatifs et plus flexibles que les projets en cascade.
  13. Développement sur mesureLes attentes en matière de développement personnalisé (développement personnalisé à l'aide d'une plate-forme technique, développement personnalisé à l'aide d'un système de gestion de l'information, etc. plate-forme de gouvernanceou le développement personnalisé à l'aide d'un ERP) bénéficie d'une approche agile qui identifie la valeur de chaque élément personnalisé.
  14. Niveau actuel de l'ancienne technologieLes organisations gouvernementales qui utilisent des technologies anciennes (ordinateurs centraux, COBOL, 4GLs) ou des technologies patrimoniales (la plupart des systèmes ERP propriétaires, y compris les systèmes de niveau 1) bénéficient du regard neuf associé à la méthode agile.
  15. Participation des utilisateursL'agile excelle lorsque les utilisateurs doivent formuler les problèmes, identifier les solutions, tester les fonctionnalités et défendre les nouveaux systèmes.
  16. Changement de fonctionnalitéagile excelle lorsqu'un grand nombre de nouvelles fonctions sont introduites par rapport au système existant.
  17. Mise en œuvre sur le terrainles mises à niveau de systèmes existants peuvent être mises en œuvre en cascade, tandis que la mise en œuvre de nouveaux logiciels bénéficie d'une approche agile.
  18. Modification des exigencesLe projet "waterfall" s'attend à ce que les exigences soient très peu modifiées, alors que le projet "agile" s'adapte aux changements en identifiant les modifications des spécifications dès le début du projet afin de réduire les coûts par rapport à l'identification des modifications nécessaires à un stade ultérieur du projet.
  19. Dépendances du systèmeles processus en cascade bénéficient de moins de dépendances, telles que les points d'intégration avec d'autres systèmes, tandis que les processus agiles sont mieux à même de s'intégrer dans de multiples domaines gouvernementaux et technologies sous-jacentes.
  20. Nouveauté produitl'agile est idéal lorsque les projets mettent en œuvre des suites de produits relativement nouvelles
  21. Résistance au changementles projets en cascade ne sont pas efficaces dans les situations où la résistance des utilisateurs et des responsables au changement est élevée, alors que les projets agiles comportent davantage de processus intégrés qui facilitent et intègrent la gestion du changement (la gestion du changement dans les projets en cascade est souvent inefficace).
  22. L'accent sur la qualitéles processus en cascade placent les tests et l'assurance qualité à un stade tardif de la méthodologie, alors que la méthode agile met l'accent sur la qualité dans chaque "histoire d'utilisateur", ce qui permet d'améliorer la qualité dès le début.
  23. Extensibilité du systèmeL'agile excelle lorsque des logiciels existants ou nouveaux doivent être étendus à des fonctions supplémentaires par le biais de la réutilisation.
  24. Rapports et tableaux de bord personnalisésl'articulation des rapports, y compris la reproduction de rapports statutaires dans de nouveaux logiciels et la création de nouveaux rapports, tableaux de bord et analyses, bénéficie d'itérations agiles car les utilisateurs reconnaissent souvent les améliorations une fois qu'ils ont vu les résultats des rapports
  25. Vitesse de mise en œuvrel'agile excelle dans la vitesse de mise en œuvre et fournit des informations sur les performances ("cadence") plus efficaces que la chute d'eau, pour prédire le temps d'achèvement d'un projet
  26. Transparence des projetsL'agile suppose une transparence constante du projet grâce à des tableaux Kanban, Scrum ou Srumban, ainsi qu'un engagement fréquent auprès des utilisateurs et des parties prenantes.

Remarques importantes

  • Les diagrammes ci-dessus montrent que l'approche agile est préférable dans les deux premières colonnes de la liste de contrôle. Ce n'est pas une erreur.
  • Il est probable que votre liste de contrôle contienne des éléments dans les trois colonnes. Utilisez cela comme un risque

Les méthodologies "agiles" des fournisseurs laissent perplexe

"La volonté est un casse-tête. - Hamlet de William Shakespeare
De nombreux fournisseurs de logiciels d'entreprise établis, y compris les fournisseurs d'ERP de niveau 1, vantent les mérites des processus agiles. Les intégrateurs de systèmes doivent prendre en charge ces processus pilotés par les fournisseurs afin d'obtenir une certification. Il est surprenant de constater à quel point ces soi-disant processus agiles ne le sont pas.
L'agilité est souvent greffée sur la chute d'eau en ajoutant de la complexité au processus. Ou en décrivant les présentations de communication d'étape comme étant agiles. Nombre de ces processus imposent des "meilleures pratiques" dans des fonctions qui sont rarement les meilleures ou les plus appropriées. L'accélération des projets dans ces méthodologies se concentre sur l'exécution de ce qui est dans le logiciel sans changement, plutôt que sur l'adaptation aux besoins réels du gouvernement. (Les implémentations "vanille" répondent rarement aux besoins des gouvernements.)

Une rose agile ?

"Une rose sous un autre nom sentirait aussi bon" - Roméo et Juliette de William Shakespeare
De nombreux fournisseurs tentent de redéfinir la chute d'eau en agile. Cela ne changera pas la nature du processus. Il ne sentira pas aussi bon que l'agile.

Sources supplémentaires

Références spécifiques aux gouvernements

Références générales

Thèmes

Contact