SCRUM, MOA et MOE. Je m'y perd !
C'est parce que je cherche un job que j'évite de poster sur mon blog. Pour éviter des conflits avec de futures opportunités entre ce que j'écris et ce que je pourrais faire. Par exemple quand je compare Google a Big Brothers et qu'ils me proposent un job, c'est normal que finalement, ça ne passe pas. Mais bon, comme je n'ai pas toujours le sens de la mesure, j'évite.
Aujourd'hui, j'écris sur un sujet d'étonnement, de notion que je mélange et pourquoi. En effet, j'ai fait pas mal d'entretiens d'embauche (j'ai du mal a trouver ce que je cherche). Bref, j'ai été confronté a des DRH et des chefs de projet qui mélangent SCRUM, MOA et MOE... et j'y comprend rien.
MOA/MOE : Truc made in France...
La MOA, maitrise d'ouvrage, représente généralement les utilisateurs finaux (internes ou non). La MOE, maitrise oeuvre, représente les geeks qui construisent le truc (DSI ou autre). Cette séparation entre les utilisateurs et les concepteurs est une invention purement Française qui fonctionne plutôt bien (dans l'industrie automobile en tout cas). Le problème dans l'informatique, c'est que la séparation entre les développeurs et le métier cible n'est pas imaginable. Les développeurs ne connaissent pas toujours les métiers pour lesquels ils développent. Cela entraine des décalages entre les attentes des clients (souvent concernant des éléments implicites liées a un métier.
Ainsi, la communication entre MOA et MOE entraine la production d'une quantité importante d'informations et documents divers...
Avec les quelques stages que j'ai pu effectuer, je me trouvais dans une autre situation. En effet, l'avantage que j'ai toujours eu, c'est de travailler pour un « client interne » la plupart des temps. Ainsi, en cas de doutes, une simple question (orale) suffisait a débloquer une situation.
L'agilité et SCRUM
SCRUM est a la mode en ce moment. Cependant, a part les développeurs, je ne suis pas certains que tout le monde emploi ce terme en sachant vraiment ce qu'il signifie...
En bref, SCRUM est une méthode permettant de mettre en place un cadre général. Cela défini des interactions entre les membres d'une équipe, aussi bien les développeurs que le client (ou le représentant des clients). Cette méthode favorise la communication plutôt que les outils. Pour faire simple, l'avantage de scrum est de faire en sorte que tout le monde communique ensemble pour construire quelque chose de fini plus rapidement et de manière plus efficace. Le principe le plus connu concerne les « itérations » qui visent a obtenir a chaque fois un livrable (qui pourrait être mis en production).
Il existe d'autres méthodes dans le même genre, appelées méthodes agiles, Extreme Programming entre autre.
Pourquoi je suis perdu ?
SCRUM et MOA/MOE ne sont pas vraiment compatibles. Ce qui me perd lors des entretiens, c'est lorsque l'on me précise que l'entreprise mélange ces méthodes... Le gros truc des méthodes agiles est de rapprocher les informaticiens des clients, au contraire des MOA/MOE. J'ai peur que certains comprennent seulement le principe des itérations, qui n'est qu'une petite partie des principes et cadres définies par les méthodes agiles.
Je pense que je me trompe, mais je n'arrive pas a obtenir plus d'informations... (si vous en avez, je suis preneur !)
On me parle également de prestation au « forfait », sauf que la aussi, cela me dérange. Comment fait-on pour définir une prestation avec un périmètre fixé a l'avance en choisissant d'utiliser une méthode agile pour les développements ?
Bref, j'ai encore pas mal de chose a apprendre !
