Résultat d’un MBO soutenu par BNP Private Equity, les 200 consultants de DNV IT Global Services ouvrent ce chapitre. Si la stratégie globale et le portefeuille global changent peu, ce nouveau départ scelle d’une part l’abandon des efforts pour pénétrer les marchés du maritime et de l’énergie mais surtout un nouveau départ en termes d’innovation technologique et la création d’un centre international d’excellence Agile et Lean qui vient compléter logiquement la palette.

Passion, enthousiasme et centrage sur la valeur délivrée au client sont au rendez-vous. Je vous donne désormais rendez-vous sur les sites inspearit.com et inspearit.fr.

La valeur de l’applicatif se dégrade progressivement principalement lorsque on privilégie le court terme au moyen terme et que les développements futurs seront de ce fait rendus plus difficiles. Une situation semblable à la dette financière qui doit être remboursée pour saluer le succès.

Pour gérer cette dette d’un genre nouveau – que la mise en œuvre de méthodes agiles à tendance à amplifier – , rien ne vaut une approche centrée sur l’architecture de l’application et la collecte de données exploitées pour prendre des décisions payantes. Ces deux éléments permettent d’ailleurs d’optimiser les coûts de développement tout en maintenant un haut niveau de valeur ajoutée client.

Parmi les 4 phases d’un chantier Lean (préparation, mise en place, vérification et amélioration, standardisation), la réussite de la mise en place est particulièrement fondamentale. Elle nécessite une grande concentration, sur environ une semaine. Il s’agit de :

• Former les participants aux principes LEAN,
• Cibler les actions d’amélioration et les solutions aux problèmes identifiés,
• Définir les standards,
• Définir le plan d’actions.

Pluridisciplinaire, l’équipe chantier comprend par exemple direction, achats, technique, qualité. Elle travaille sur le terrain avec ceux qui produisent la valeur client. La pertinence et la simplicité des solutions identifiées résulteront de l’implication de chacun : oublier une discipline, c’est s’exposer à des résultats mitigés et peu pérennes. L’implantation durable des solutions et leur adoption seront le fruit d’une collaboration initiée dès la phase de mise en place du chantier, et qui soutiendra l’amélioration jusqu’à la standardisation finale.

Faire :

Encourager la communication latérale ; Partager les retours de toutes les parties prenantes avec l’équipe ; Maximiser la « bande passante » ; Organiser des meetings journaliers très courts ; Livrer la valeur promise dans les scénarios utilisateur ; Une seule équipe, Un backlog, Un processus ; Organiser des sessions rétrospectives ; Assurer la continuité dans l’équipe

Ne pas faire :

Faire monter des membres de l’équipe distants en cours de route ; Mettre en œuvre des moyens de communication différents pour les personnes distantes ; Communiquer le minimum de retours ; Envoyer des rapports d’avancement ; Allouer le travail par composants ; Garder les scénarios difficiles et les défis pour les personnes sur site ; Réorganiser les rôles dans l’équipe.

En conclusion, une bonne camaraderie dans la discipline !

Quelques retours d’expérience commencent à être diffusés. Et force est de constater qu’entre le buzz médiatique et la réalité il y a un vrai fossé.

Beaucoup de projets développés avec des technologies agiles sont encore isolés, font partie de la sphère R&D. Le déploiement de l’agilité à de larges organisations n’a pas encore vraiment eu lieu ou bien reste confidentiel.

En revanche les valeurs portées par « l’état d’esprit » agile sont elles bien partagées : l’emphase mise sur la communication entre « client » et « réalisateur », l’établissement des priorités indispensable très en amont du cycle de vie, la place prise par l’architecture globale et structurée dans la vision globale du projet et de ses itérations sont de vrais plus.

On assiste donc à un déploiement fort et soutenu des principes soutenant l’agilité bien su-delà des équipes de développement. Ceci nécessite un vrai changement de culture qu’il faut accompagner : c’est sans doute là que réside toute la puissance de la démarche.

Comment une architecture peut-elle créer de la valeur ? Comment traduire l’efficacité du projet dans son architecture ? Par exemple, un projet avec une dette technique n’est pas un projet efficace puisqu’il n’implémente pas toute l’information disponible à un instant T. Comment ménager le court et le long terme ?

La plupart des conférenciers ont insisté sur l’importance de la communication et des synergies entre management, marketing et développeurs sur l’expertise technique. Il faut des interactions entre les différentes parties et des expérimentations pour raffiner une architecture réaliste et efficace.

La vision de la stratégie du business n’était pas toujours leur spécialité. Mais avec la nécessité pour les SI de s’adapter vite à de nouvelles demandes pour capturer en final des parts de marché, et face à la croissance des ressources globales, les priorités du Directeur des Systèmes d’information changent : comprendre les enjeux de la stratégie, optimiser la mise en œuvre des nouvelles technologies, intégrer et standardiser des process et des plateformes sont le pain quotidien.

La crise de 2008, en impactant sérieusement les budgets a encore modifié la donne : alignement du SI avec le business au meilleur ROI. La prochaine évolution sera sans nul doute liée à la capacité à canaliser l’explosion du flux d’informations à traiter.

Avant l’arrivée du modèle CMMI for Services (CMMI-SVC), les organisations qui mettaient en place CMMI devaient faire face à des choix particulièrement délicats :

• Doit-on privilégier les projets (et n’impliquer qu’une partie des collaborateurs) ou décliner le mode projet sur les autres activités (et impliquer tout le monde) ?
• Doit-on différencier projet et maintenance au risque d’être incompréhensible pour des collaborateurs qui font les deux à la fois ?
• Quel seuil se donner pour séparer la maintenance et les projets ?
• Comment traiter l’assistance aux clients ?
• Comment intégrer les SLA existants avec les clients ?

En conjuguant CMMI-DEV et CMMI-SVC, l’organisation va progressivement trouver des réponses à ces questions.

Il est généralement facile de cerner les services proposés par la fonction informatique :

• Assistance (à plusieurs niveaux)
• Corrections d’urgence
• Maintenance corrective
• Maintenance évolutive
• Petits projets.

Les petits projets sont souvent vécus comme du service :

• Nombre de fonctionnalités limité (quelques dizaines)
• Fonctionnalités exprimées par rapport à un existant (déjà plus des solutions que des besoins « purs ») ; on va alors parler de « créer une interface », « ajouter la donnée », « transmettre les données de l’appli par telle interface », « compléter le rapport avec », « se connecter au Portail », …
• Répartition sur plusieurs applicatifs avec, parfois, des livraisons désynchronisées,
• Pas ou très peu de modifications d’architecture,
• Pas ou très peu de migration de données,
• Risques limités de non régression.

Quoique déclarés « petits », les charges induites par ces projets peuvent être significatives : jusqu’à plusieurs centaines de jours.

Les services définis, CMMI-SVC devient un outil facile à mettre en œuvre :

• s’appuyant essentiellement sur l’existant,
• ne demandant qu’une mise en forme un peu plus poussée (définition de SLA sur la base de l’existant, mise en place d’outils de suivi) pour un peu plus de rigueur,
• facile éventuellement à outiller avec l’offre actuelle du marché.

Les gains associés à cette mise en forme sont :

• visibilité,
• identification des difficultés résiduelle,
• convergence entre le management (« savoir ce qui se passe ») et les équipes (« partager les problèmes »),
• et finalement un meilleur service.

Ceci cadré, on peut se concentrer sur les « vrais projets » avec CMMI for Development :

• la compréhension de CMMI devient rapidement beaucoup plus aisée ;
• les pratiques délicates prennent plus facilement du sens (par exemple appliquer la traçabilité puis détecter les incohérences dans le cadre d’un gros projet, ou revoir les estimations en cours de route, faire des revues qualité, auditer les configurations ou surveiller des indicateurs) ;
• faisant sens, la mise en place des outils et documents est plus rapidement appliquée ;
• le recours aux outils pour automatiser devient aussi plus rentable.

En étant plus adapté sur chaque activité, l’obtention des niveaux 2 puis 3 devient plus facile et plus rapide.

Quelle que soit la taille de l’entreprise, les mêmes fonctionnalités sont offertes et le prix à payer est totalement ajusté. Salesforce est comme Amazon, Google, VMware et NetApp fournisseur de cloud. Ces technologies qui au-delà des applications permettront de partager des plateformes, et pourquoi pas des produits, vont révolutionner notre mobilité.

Même si tous les aspects de cette mutation n’ont pas encore de solution, les avancées sont significatives.

Je signale une expérience intéressante menée par une communauté de 5 000 médecins indépendants de la région de San Diégo qui tire profit d’un cloud de collaboration des soins : les patients peuvent coordonner leurs soins parmi les médecins adhérents.

Il est rare de trouver sur internet un film qui raconte une expérience vécue de développement sans faire la publicité de telle SSII ou de tels outils de travail. C’est pourtant le cas de cette vidéo, qui s’est aussi affranchie des poncifs du genre. Ici, ni interviews ni dialogues, mais une succession de bancs-titres sur le rythme d’une musique des Red Hot Chili Peppers ! Nous avons décidé de vous la présenter telle quelle.

« Donnez-nous chaque matin notre Scrum quotidien »

Le film détaille les trois questions à se poser chaque jour lors de la réunion qui se tient debout : - qu’as tu fait hier ? - que vas-tu faire aujourd’hui ? - y a t-il des obstacles sur ta route ? Toutes les étapes sont évoquées : mise en place du projet, préparation du backlog, construction du tableau Scrum. Puis l’analyse des besoins utilisateurs par le concept de « user stories », l’estimation des temps à passer par la méthode des points de complexité, le planning des Sprints, la hiérarchisation des priorités parmi les user stories, le découpage des besoins en tâches… Pour l’estimation des tâches, l’équipe utilise la méthode « planning poker’, où chacune d’elles a une valeur comprise entre 1 et 8 heures.

Merci à Soulira Kerri qui a réalisé ce film, et à toute l’équipe pour cette contribution positive et constructive : Vincent Alsteen, Karl Determe, Pierre Radermecker, Laurent Van Basselaere, Bruno Sbille…

Quels sont les critères d’éligibilité des projets aux pratiques AGILES ? Quelles sont les bonnes pratiques ? Quels outils mettre en place pour la conduite du changement ? BETTER DEVELOPMENT propose une formation de deux jours à la transition vers les méthodes agiles pour vous permettre d’en savoir davantage. Plus de détails en cliquant ici.