Cet article est rédigé par Paul Craig, développeur principal, équipe de la plateforme CDS au Service numérique canadien (SDC). Cet article a d'abord été publié sous forme de billet de blog pour le CDS , qui collabore avec les ministères fédéraux canadiens pour créer des services numériques plus simples et plus utilisables. Lisez l'article original ici.

C'est le moment idéal pour travailler dans la prestation de services numériques. Les gens sont plus connectés que jamais et s'attendent à avoir accès à des services numériques modernes. Dans le même temps, le développement « agile » - la construction et le test de prototypes en quelques semaines plutôt que de passer des années à planifier - a été largement accepté.

En tant que responsable technique au Service numérique canadien (CDS), j'ai vu bon nombre des problèmes rencontrés par les nouvelles équipes, résultant d'un affrontement culturel entre les équipes agiles axées sur le code et les processus de déclenchement en cascade lourds en paperasserie. Les départements qui expérimentent des équipes agiles (-ish) veulent toujours qu'ils travaillent avec des groupes d'approbation, ce qui signifie en fin de compte trouver un logement dans les cultures départementales existantes et faire approuver le travail comme n'importe quelle autre équipe.

La méthodologie Agile donne la priorité à l'engagement précoce des utilisateurs. Les commentaires des utilisateurs vous donnent non seulement un aperçu pour améliorer votre produit, mais ils fonctionnent également comme une documentation interne qui renforce votre crédibilité.

Dans une équipe agile, votre force est votre capacité à prototyper rapidement et à parler aux utilisateurs, mais votre faiblesse est la perception que ces pratiques introduisent des risques indus. Il est crucial de trouver un équilibre entre l'obtention rapide d'une version de produit et la rédaction de la documentation requise par les processus de déclenchement traditionnels . Les équipes agiles qui réussissent doivent se déplacer rapidement et être en sécurité.

Déplacez-vous rapidement : l'avantage de l'agilité

Les équipes agiles sont la vraie affaire. Certaines des plus grandes entreprises d'aujourd'hui sont arrivées là où elles sont parce que les flux de travail agiles sont vraiment bons pour fournir rapidement de la valeur, battant les entreprises plus établies avec des modèles de livraison plus lents.

En général, dans le cadre d'une équipe agile, vous souhaitez définir votre MVP (minimum viable product) puis le tester auprès des utilisateurs le plus tôt possible. La planification en cascade n'apporte pas une bonne réponse aux « besoins des utilisateurs ». La méthodologie Agile donne la priorité à l'engagement précoce des utilisateurs. Les commentaires des utilisateurs vous donnent non seulement un aperçu pour améliorer votre produit, mais ils fonctionnent également comme une documentation interne qui renforce votre crédibilité.

Une fois que vous êtes sûr que votre produit fonctionne, concentrez-vous sur ce que vous devez faire pour le publier. Il est de loin préférable d'avoir un service « alpha » publié qu'un prototype interne hautement perfectionné. Bien sûr, le compromis avec «rapide» est que, compris de manière conventionnelle, cela signifie compromettre la sécurité, vous devez donc trouver un équilibre entre «aller vite» et «être en sécurité».

'Être en sécurité' en agile

Pour les équipes agiles, il existe 4 principales façons dont le développement Agile est plus sûr que le développement de produits en cascade traditionnel.

  1. Agile réduit les erreurs existentielles dans la conception d'un service : l'engagement précoce des utilisateurs atténue le risque de lancer un service peu performant.
  2. Agile réduit le coût des erreurs : une itération fréquente signifie des changements plus petits plus souvent, ce qui signifie que les erreurs ont tendance à être plus petites et plus rapides à réparer.
  3. Agile réduit la probabilité d'erreurs grâce à une utilisation accrue de processus automatisés. En plus de ces arguments agiles orthodoxes, il y a un dernier point, plus philosophique, à considérer.
  4. Agile est avant tout une approche flexible qui s'adapte rapidement. Les équipes agiles sont pragmatiques dans la résolution des problèmes des utilisateurs.

Nous avons déjà discuté de la première réponse dans d'autres articles (voir les articles de blog Apprendre des personnes qui veulent utiliser notre service de création de rapports et Tests de validation : un moyen de contester vos hypothèses ), alors regardons les autres.

Agile réduit le coût des erreurs

Essayer de prévenir les problèmes en superposant les comités peut créer un cercle vicieux. Toutes ces couches de gouvernance sont créées pour éviter des erreurs coûteuses, mais les erreurs sont souvent coûteuses en raison d'une gouvernance excessive.

En revanche, le développement agile de produits réduit le coût des erreurs . Les équipes qui publient quotidiennement peuvent corriger les bogues en quelques heures, alors que vous pourriez avoir affaire à des «silos de publication» de 3 à 12 mois dans des équipes plus traditionnelles.

Agile réduit la probabilité d'erreurs

La gouvernance traditionnelle en cascade repose sur les humains pour auditer les produits avant leur sortie.

Cela coûte cher à exécuter et difficile à mettre à l'échelle 1 . Si vous voulez vous déplacer deux fois plus vite, vous devez embaucher deux fois plus de personnel. En revanche, le développement logiciel agile cherche à remplacer ce goulot d'étranglement par des tests automatisés qu'un ordinateur peut effectuer, généralement en quelques secondes. Il est très courant que la documentation de sécurité soit obsolète - une fois écrite, elle décrit comment le système fonctionnait auparavant - alors que les tests automatisés (créés par un audit dirigé par l'homme) suppriment le besoin de documentation et sont à jour par définition .

Agile est flexible

Le deuxième principe du Manifeste pour le développement logiciel agile est « un logiciel fonctionnel plutôt qu'une documentation complète », ce qui semble être une assez bonne approche : concentrons-nous sur la construction du produit plutôt que sur la rédaction de longs documents Word ou de présentations PowerPoint. Cependant, le premier principe est « les individus et les interactions plutôt que les processus et les outils », et malheureusement, la gouvernance actuelle stipule que ces équipes nécessitent une documentation complète. Les équipes de surveillance traditionnelles demandent aux équipes de produits une documentation écrite détaillée sur le fonctionnement et l'administration de leur système. Si vous ne le fournissez pas, il y a peu de chance que votre projet soit approuvé. En tant qu'équipe agile au sein du gouvernement, votre principe est « logiciel fonctionnel » et « documentation complète ».

Se déplacer plus vite ou être plus en sécurité ?

Pour récapituler, les deux considérations importantes pour les équipes agiles dans les grandes organisations sont :

  1. Offrir rapidement de la valeur , ce qui signifie mettre quelque chose entre les mains des utilisateurs rapidement, sans passer des années à planifier.
  2. Gérer le risque (perçu) , ce qui signifie se prémunir contre les erreurs et remplir des documents.

Les équipes qui se déplacent rapidement optimisent la vitesse et se construisent rapidement. Les équipes qui sont en sécurité prennent leur temps, se concentrent sur les tests de pipelines et rédigent parfois de gros documents.

Ces deux points semblent être en tension l'un avec l'autre. Si vous voulez une vitesse maximale, n'écrivez aucun test. Écrivez simplement du code, expédiez-le et testez-le en production en demandant à de vrais utilisateurs de trouver des bogues. En revanche, si vous voulez un maximum de sécurité, ne lâchez jamais rien. Un logiciel qui n'est jamais lancé n'est jamais piraté.

Alors, où devriez-vous descendre sur le continuum « rapide » contre « sûr » ? Pour répondre à cette question, déterminez ce à quoi vous êtes confronté. Si les délais de développement de produit typiques sont de 2 à 3 ans, voyez si vous pouvez obtenir un service alpha publié en 6 à 9 mois.

Conclusion

En tant que praticiens agiles, l'opportunité qui existe au sein du gouvernement est claire : les projets informatiques gouvernementaux traditionnels échouent souvent à fournir des produits qui donnent la priorité aux utilisateurs/qui répondent aux attentes des utilisateurs.

Compte tenu de ces problèmes systémiques, il semble être un slam dunk de passer à un modèle largement réussi de livraison de projet qui donne la priorité à une rétroaction rapide et à un retour sur investissement précoce. Les équipes agiles en font plus avec moins de frais généraux, et en testant avec les utilisateurs, elles sont plus confiantes dans ce qu'elles construisent.

Cependant, les équipes agiles du gouvernement canadien opèrent dans des conditions assez difficiles, devant généralement chercher à s'adapter à une culture existante d'évitement extrême des risques. La force des équipes agiles est qu'elles se concentrent sur l'expédition précoce et l'amélioration progressive, mais vous devez expédier quelque chose . Compte tenu de cela, il est extrêmement important d'équilibrer un engagement envers la sécurité avec un désir d'obtenir rapidement une version.

Mélanger deux approches opposées présentera toujours des défis, mais il est important de rester concentré sur la création de valeur réelle pour les citoyens. En fin de compte, vous devez prouver que votre approche fonctionne en la faisant fonctionner. Choisissez un produit, gardez un contrôle strict sur votre portée, mettez-le entre les mains des utilisateurs et racontez votre histoire en cours de route. Se déplacer rapidement montre ce qui est possible, tout en étant en sécurité garantit que vous êtes viable.

  1. La pratique de l'ingénierie de la fiabilité des systèmes définit ce travail répétitif de faible valeur comme du « labeur ». [revenir]

👋 Vous pouvez créer une publication comme celle-ci ! Partagez vos réflexions avec une communauté de fonctionnaires. Apprendre encore plus

(Crédit image : Unsplash)