La demande récurrente pour la réduction du “time-to-market” et pour davantage d’agilité dans le développement informatique est aujourd’hui confrontée à une sérieuse difficulté.
En effet, la complexité, tout autant que la variété et la vitesse d’évolution des solutions mises en oeuvre demandent régulièrement la mise en place d’équipes spécialisées. Parce que leur maîtrise, j’entends par là la capacité à une mise en oeuvre réellement efficiente, est devenue quasiment impossible au sein de chaque équipe qui doit pouvoir en faire usage.
Résultat immédiat : une multiplication des équipes de support (dites quelquefois transversales).
Conséquences : une dépendance accrue des équipes de projet vis-à-vis de ces équipes de support, en profondeur (elles sont les seules à savoir, ou à pouvoir [questions d’autorisations] intervenir sur les technologies dont elles sont dépositaires), et en largeur (elles se multiplient comme déjà dit).
Inutile de dire que la multiplication des dépendances a pour corrolaire immédiat que :
– l’équipe de projet est de plus en plus souvent dans l’attente d’un délivrable (un serveur, une base de données, un jeu de données de test, un service au niveau d’un application server, un pipe sur l’ESB, un processus sur le BPM, le déploiement d’un outil, une configuration quelconque, …) ;
– l’intégration devient un cauchemar en termes organisationnels (il manque toujours quelque chose ou quelqu’un);
avec les conséquences qui s’ensuivent en termes de délai et de coûts, en développement proprement dit et souvent tout autant en maintenance.
Je vois encore deux autres facteurs d’inquiétude :
– les équipes de support sont naturellement moins impliquées que les équipes de projet sur la question de l’orientation sur le résulat pour le client (une forme d’application du principe “[plus] loin des yeux [plus] loin du coeur”) – osons le dire en des termes appropriés, la vie dans les équipes de support est souvent moins stressante que dans les équipes de projet;
– la lassitude guette les équipes de projet, avec son risque apparenté, le désengagement.
Et donc je n’hésite plus à poser la question suivante : ne faudrait-il pas en revenir, pour partie en tous les cas, à des feature teams, soit des équipes dotées de tous les moyens nécessaires à l’accomplissement de leurs missions au bénéfice de leurs clients directs?
La définition suivante (voir www.featureteamprimer.org) va dans ce sens, avec les réserves voulues sur les défauts cachés du développement agile poussé à l’extrême.
| A feature team “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, …) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, …) development cycle.sans oublier …Feature teams structure resolves many of these wastes … but also introduces change and challenges. |
Le but de ce blog n’est évidemment pas de traiter le sujet en profondeur. Je me contenterai donc de quelques premières et rapides réflexions sur le sujet, à travers l’exercice des “dix principes”.
1. La standardisation garde du sens sur les outils stratégiques.
2. La standardisation doit être plus qu’intramuros. Elle doit aussi s’appliquer entre partenaires “privilégiés”.
3. A contrario, la standardisation ne doit pas être dogmatique sur les outils non stratégiques pour tous les feature teams, sauf à réduire les coûts de licences (crise oblige). Sur le plan tactique, des zones de liberté riment avec agilité /efficacité (l’histoire militaire, par exemple, l’a amplement démontré).
4. La standardisation est un must au sein d’un feature team.
5. Sur les outils stratégiques chaque équipe doit posséder les compétences voulues. Une stricte dépendance vis-à-vis des équipes de support est à proscrire.
Dit autrement, les équipes de support doivent être et rester des équipes de support. Elles ne doivent pas nourrir les dépendances.
6. Les équipes de support n’ont pas nécessairement vocation à devenir “éternelles”. Un outil stratégique devenu banal ne mérite peut-être plus une équipe de support. Il faut savoir “nettoyer”.
Une équipe de support dans la durée n’a peut-être de sens que sur les technologies rarement utilisées par les équipes de projet, et pour lesquelles le maintien de la maîtrise dans la durée s’avère impossible par manque de pratique.
7. L’introduction d’un nouvel outil stratégique se fait via une équipe dédiée. Dans un premier temps, l’équipe de support reste seul maître de la nouvelle technologie, avec la volonté de diffuser rapidement les compétences vers les équipes de projet utilisatrices en vue de les rendre indépendantes.
8. Les “principes” évoqués ici sont valables tant pour l’infrastructure que pour le développement.
9. Le management doit s’intéresser aux approches “converged infrastructure”, en vue de réduire le besoin en spécialistes pointus induits par les architectures (trop) distribuées et faciliter la mise à disposition et la redistribution des ressources.
10. La mutualisation des moyens entre partenaires doit être encouragée. Elle contribuera à réduire les dépendances de nature technique.
En espérant que ces quelques lignes contribueront à alimenter votre réflexion sur les problématiques de la standardisation et de l’agilité.
Une lecture conseillée sur le sujet (concise et claire) : https://s3-eu-west-1.amazonaws.com/geantsduweb.com/uploads/download/downloadable/33/octo-gdw-feature
Leave a Reply