[ScrumDay 2013] Session Java EE, Agilité et Cloud à travers une Success Story

Logo-Scrum-Day-2013De nombreuses présentations ont eu lieu lors du Scrum Day 2013, le jeudi  11 mars dernier. Face à cette multitude de conférences, je me décide à suivre une Success Story. Comme le titre le laissait à supposer, il va être question de technique et d’Agilité, un domaine que j’affectionne.

La présentation commence, avec le plan de la session et une belle surprise : il ne va pas être question que de technique mais d’un retour d’expérience sur la mise en place de l’agilité au sein d’une StartUp. Architecture technique, contractualisation et facteurs de succès sont au rendez-vous, que je me propose de vous résumer ici.

Caractéristique du projet

Le client ouvre un service de Coaching OnDemand. L’activité étant naissante, le financement de la R&D se veut rationnel. Malgré cela, le client est conscient qu’une approche d’analyse et de faisabilité importante doit être faite.

Il est décidé, avec le prestataire, de mettre en place un Pre Game Planning ou Initial Planning. Pour rappel, cette phase a pour objectif de définir les grandes lignes fonctionnelles, identifier les risques et développer le Walking Skeleton, une implémentation de fonctionnalités essentielles de bout en bout.

Initial Planning :

Cette première phase du projet est estimée à 60 jours/homme (sur 3 mois) par le fournisseur. A l’issue de cette période, les livrables suivants ont été générés :

  • Product backlog initialisé et dimensionné
  • Prototype fonctionnel (Walking Skeleton)
  • Architecture cible

Au delà de la réalisation d’un projet fonctionnel, cette phase a eu pour effet de rassurer le client sur la faisabilité du projet, ainsi que de fournir une estimation du budget à émettre pour finaliser le produit.

Même si le résultat de cette phase n’avait pas été probant, les actions qui y avaient été menées n’auraient pas été perdues. En effet, les nombreuses réflexions menées mais également les POC (Proof Of Concept) et pratiques de travail abordées sont réutilisables.

Cette première partie du projet s’est déroulée sous la forme de Sprint de 1 semaine. Le fait de fonctionner de la sorte a permis au client de s’approprier le travail en itération et ainsi se roder à l’Agilité.

Cette première phase étant validée, place au développement.

Développement du produit

Quelques chiffres :

  • 160jours/homme sur 3 mois
  • 7 sprints de 2 semaines avec 2-3 personnes

Du coté de l’architecture technique, elle se veut classique JEE (GWT, Hibernate, Spring) et efficace.  Je ne m’étendrai pas sur ce sujet, puisque finalement ce n’est pas le propos qui nous intéresse.

Cependant, il est intéressant de noter que l’architecture cloud (ici CloudBees) offre une certaine scalabilité pour un prix avantageux.

La contractualisation

Voilà un point très intéressant, sur lequel je vais passer un peu de temps.

Aujourd’hui comme l’orateur nous le rappelle, la production de logiciel doit faire face à deux contraintes :

  • La convergence fonctionnelle, c’est à dire le fait que le besoin change durant le développement du logiciel. Plusieurs raisons à cela : il mûrit, les orientations peuvent changer, ….
  • Le Time to Market, ou la capacité à répondre à un besoin marketing au juste moment.

D’un point de vue responsabilité, les parties prenantes, fournisseur de service et client, ont souvent tenté de pousser ces risques à leur partenaires. Nous voulons, par exemple, les contractualisations suivantes qui apportent leur lot d’avantages et d’inconvénients.

Régie (à l’avantage du fournisseur) 

  • Perte de garantie
  • Produit sans vision

Forfait (à l’avantage du client)

  • Le fournisseur limite les fonctionnalités
  • Dépassement des délais

Au final pas de gagnant – gagnant dans ces modes de gestion de relation entre partenaires.

Il existe une contractualisation qui respecte les principes de l’Agilité (mettant en avant la collaboration et la transparence autour du projet) mais qui reste peu répandue en France. La proposition de contractualisation mise en place dans le projet présenté se base sur un existant exposé par Robert C. Martin.

  • Contractualisation par sprint, à la User Story
  • Une facturation variable (un taux de marché et un taux de base)
  • Paiement au sprint n+2 lorsque le sprint n est validé

Slide1

  • Un montant fixe est défini pour un fonctionnement normal. Il s’agit de définir un tarif de base, qui correspond aux charges du prestataire, auquel s’ajoute la marge du fournisseur.
  • Les risques sont partagés, tout dépassement est préjudiciable aux deux parties. En cas d’anomalies, comme le montre le schéma ci-dessus, les correctifs et les dépassement sont à la charge du fournisseur, c’est à dire une tarification sans marge pour ce dernier.
  • Dans notre étude de cas, l’expérience a amené 1 à 2 jours de correction de bugs.
  • Si bonus de User Story il y a, pas de surfacturation.

Les facteurs de succès

Cette partie présente une évidence des facteurs de succès, mais il est intéressant de les rappeler. Sans eux, le projet n’aurait pas abouti avec l’engouement présenté :

Product owner (PO)

  • Responsabilités tenues
  • Gestion du backlog
  • Arbitrage des US
  • Suivi des US
    • Questions / Réponses
    • Validation des développements

Il est à noter que durant ce projet, il a été identifié qu’en dessous de 60% de disponibilité, les deux parties devaient faire face à des frustrations. Coté client, une sensation de projet qui n’avance pas. Coté Team, une frustration liée à la perte du rythme.

Pire que cela, l’absence du PO ou ne serait-ce qu’une indisponibilité importante est contre-productive pour le projet.

ScrumMaster

  • Pas d’interférence à gérer, les règles du jeux sont contractualisées. Pas de changement du sprint-backlog en cours de Sprint.
  • Equipe petite et mature dans les pratiques et techniquement.
  • Pas de duplication de rôle, chacun avait son poste et ses responsabilités (Architecte, Développeur, PO, …).

Team

  • Un projet qui intègre des process automatisés au travers de l’Intégration Continue
  • Possibilité d’échanger avec le PO qui se trouvait dans le même espace de travail
  • Liberté de refactoring sécurisé par du code testé
    • L’équipe assure une qualité logiciel lui permettant d’ajouter de nouvelle fonctionnalité plus facilement
    • Elle se prémunit également d’anomalies liées aux mauvais codes
  • Mise en place du télétravail. Il s’agit ici d’une souplesse autorisée par la mise en place d’outils de communication au sein de l’équipe. Cette pratique n’était pas la règle mais permettait dans certain cas une certaine souplesse.

Conclusion

Une présentation qui m’a fait du bien. Dans de nombreuses discussions avec des collègues agilistes (ou pas d’ailleurs), nombreux sont ceux qui ont du faire face à un manque de disponibilité du PO, souvent lié à l’absence de contractualisation de son rôle et de son caractère “non objectivé”. Durant cette présentation, nous pouvons constater que le travail en bonne intelligence, avec le partage des risques pour le bien d’un projet entre ses différents acteurs, est quelque chose de viable et d’enrichissant pour les deux parties.

Je reste toutefois prudent sur le portage systématique de cette approche. En effet, tous les projets ne disposent pas d’une équipe aussi équilibrée d’un point de vue product ownership et de structure de travail propice à la réussite du projet (Intégration Continue, Process de validation des besoins, …) . L’Agilité a des effets des plus bienfaisants lorsque toutes les parties travaillent ensemble. Il faut, avant de pouvoir l’appliquer, que toutes les chaînes du projets soient sensibilisées et en accord avec les règles du jeu. Une phase de sensibilisation en amont du lancement d’un projet ou du changement des manières de travailler, est indispensable pour sa réussite.

Nombre de vue : 36

COMMENTAIRES 1 commentaire

AJOUTER UN COMMENTAIRE