Standard ou pas standard?

Finissant mes vacances, je repense aux dernières réunions avant de partir tant chez mon concepteur d’ERP favori qu’auprès de la Banque Privé que j’aide à passer en mode « Agile Digital Enterprise » et je m’aperçois qu’il y a de nombreux points communs.

Retour de vacances signifie amener de nouvelles propositions d’évolutions, de ce fait, je me permets d’émettre ce petit papier.

« Standard ou pas standard »?

Lors de programmes de développement d’ERP ou de CRM ou de Core Banking System, la part du développement avec du code est très limitée et l’accent est mis davantage sur la configuration.

Ces projets mettent en place des business processes (processus métiers pour l’Académie Française) , une livraison (release) et un processus de bout en bout. A cela se rajoute les tests fonctionnels principalement, de temps à autres des développement Front. Mais d’une manière générale, la complexité est dans la masse importante de processus à mettre en place.

« Standard ou pas standard ». Normalement cette question est excessive simple. Etant donné la complexité des processus à mettre en place ont va réduire la complexité technique en utilisant des standards. Donc, ici, la stratégie de développement serait « des legos et de la plomberie ». Simple!

En réalité, l’être humain dispose d’une capacité créative sans limite et l’on découvre que:

  • le standard c’est ce que l’on va livrer, donc c’est un développement standard (???)
  • le standard c’est ce qui rentre dans l’environnement de production (???)
  • le standard c’est ce que le fournisseur fournit…. selon le client
  • lorsque l’on arrive à la fin du budget (temps ou monétaire), on fait tout rentrer dans le « standard »
  • le standard c’est ce que la dernière personne te dit pour asseoir son avis
  • le standard n’est connu que des initiés
  • bref, il n’y a pas de standard….

Pas de standard est un constat, mais nous sommes loin de la vérité en fin de compte et je vais vous expliquer qu’avoir des standards peut grandement aider tant l’agilité que scrum.

Dans des systèmes expert tels que les CRM, ERP ou Core Banking vous avez une masse très importante de données à traiter en même temps et vous cherchez à avoir un système robuste et l’innovation est contextuelle dans l’adaptation à l’environnement et aux comportements du client. Dans la majeure partie des projets/programmes de ce genre, le plan de livraison ressemble de la sorte:

  • Phase 1: « Blueprint »
  • Phase 2: Développement
  • Phase 3: Tests
  • Phase 4: Déploiement en production
  • Phase 5: Réception

Et bien sûr, on n’utilise Scrum que dans la phase 2.

Quelles sont les conséquences?

  • Phase 1: le managers sont impliqués avec des conseillers en stratégie. L’objectif du Blueprint est de constituer un Product Backlog qui ne changera jamais. Cette phase peut durer jusqu’à 6 mois et comme rien de concret n’en ressort (hormis la validation du contrat), vous perdez la motivation du client.
  • Phase 2: les Products Owners entrent en jeu. Ici, vous faites la dichotomie entre Product Owner technique (côté client et côté fournisseur) qui n’ont que le nom de Product Owner mais sont où des Consultants (qui ne disent jamais Non) ou des Business Analystes (qui découpent le Product Backlog du Blueprint). Ici, toujours pas d’utilisateurs mais des managers validant les processus et un client de plus en plus agacé.
  • Phase 3: la phase de test démarre souvent en retard car il y a eu beaucoup de changements (bizarre) et les testeurs découvrent ce qu’ils ont à faire. Comme les développeurs ont passé la « patate chaude » aux testeurs, ceux-ci sont déjà partis vers d’autres projets.
  • Phase 4: comme le test est passé juste juste, le déploiement accumule les retards du développement et du test et l’équipe cherche à trouver de la documentation pour voir si c’est standard. Mais comme les testeurs sont également partis vers d’autres cieux, que les développeurs sont sur d’autres choses et que seuls des documents « standards » illisibles sont disponibles, que le client est maintenant très énervé, que les managers sont sous anti-dépresseurs, ont fait passer la chose.
  • Phase 5: les acheteurs et les vendeurs reprennent la main car la solution a été livrée avec beaucoup de retard et que l’on négocie les pénalités. On décide que c’est livrable et que l’on va assurer un support avec une autre équipe (qui sera peut être formée) et que le retard vient du développement car l’agilité cela ne marche pas!

Voilà ce que l’on aurait du faire.

Hypothèse: vous disposez de standards car vous avez déjà implémenté la solution chez un client. Ici, standard signifie:

  • nous avons un Product Backlog avec des User Stories, des Test Cases que l’on peut réutiliser avec la même équipe dès le premier jour.
  • vous ne faites pas de Blueprint mais démarrez de suite la livraison des standards en production (l’équipe fait de l’Acceptance Test Driven Development en mode Scrum avec DevOps en parallèle).
  • Pendant que l’équipe développe, le Scrum Master familiarise l’organisation du client avec la méthode, le Product Owner travaille avec les utilisateurs (ceux qui ont besoin de features) et les managers (ceux qui ont besoin de processus end-to-end).
  • Rapidement, le client et les utilisateurs disposeront d’une solution standard qui fonctionne et le Product Owner peut prendre en charge les changements pour constituer un nouveau Product Backlog adapté aux besoins du client et des utilisateurs.
  • Les tests sont fait pendant les sprints ainsi que l’intégration.
  • Les sprints livrent des features, les releases des processus end-to-end.

Lorsque le programme est fini, le client et les utilisateurs sont déjà familiarisé avec la solution et l’utilise depuis quelques temps déjà. Il n’y a plus de palabres. Le post mortem avec le client permet de définir les standards pour le client. Le post mortem fournisseur permet d’identifier les améliorations du Product Backlog « standard » et c’est la même équipe qui assure le suivi du client et éventuellement un nouveau développement.

Bref, voilà comment cela devrait être. Voilà ce que l’on ne trouve jamais!

 

la bise

 

Pierre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s