dotNET Station

Un article de rad_hass    Pas de commentaires

On entend souvent dire que la mise en place de l’agilité doit être suivi d’une période d’adaptation du processus à celui de l’équipe et à plus large échelle à celle de l’entreprise. Mais comment savoir ce qu’il faut retenir et comment adapter ? Quelle est la quête ? Peut on mettre des objectifs et se donner un feedback…

D’abord celui de l’équipe, expérimenter et améliorer… Les rétrospectives sont là pour ça, l’amélioration continue est une des garanties de la performance dans un projet.

Mais au finale qu’elle est notre désir et ce qui pousse à adopter de nouvelle méthode ? La valeur, la motivation, la productive et la qualité. Pour que l’agilité ne reste pas qu’une promesse, il faut se fixer des objectifs élevées et les suivre.

Pour commencer, je voudrais juste dire de ce qu’est l’agilité pour moi et ce que ça représente. L’agilité est un ensemble de pratiques et de principes (cf manifeste agile) qu’on applique de manière pragmatique afin d’atteindre les objectifs projet, ce n’est pas une méthode miracle qui s’utilise de la même manière quelques soit le projet. Scrum par exemple est un Framework qui permet de donner un cadre à l’équipe de développement sans apporter de réponse quand à la phase de spécification et d’analyse. Mais ceci ne veux pas dire qu’elles ne sont pas utiles ou qu’elles n’ont pas de sens c’est juste que Scrum ne donne pas les outils pour le faire. L’agilité nous pousse à trouver des solutions à nos problèmes pour lesquels encore une fois il n’existe pas de solution miracle et pour ce faire on part du minimum, on part donc d’un processus léger (cf Scrum ou encore plus frappant avec Kanban) et on doit utiliser d’autres pratiques sans les imposer pour répondre aux éventuels problématique dans un projet cf Scrum et XP tirer les meilleurs des deux ou encore Scrum et CMMI… Le culte d’une méthode n’a plus beaucoup de sens aujourd’hui, c’est pour cette raison qu’il faut cesser de suivre aveuglement les différentes modes et tirer le meilleur de ce qui existe pour la bonne conduite de nos projets.
Donc non, agile ne veut pas dire manque de prédictibilité ou encore de documentation ou d’analyse, bien au contraire si le projet le nécessite.

La valeur

Produire de la valeur, obtenir de la valeur le plus rapidement possible, revient à développer les éléments les plus prioritaires et ceux apportant le plus de valeur tout en constituant un ensemble cohérent et livrable, à valider le plus tôt et livrer aussitôt. Il est bien question ici de Time To market.
Alors entendre dire que dans l’agilité il n’y a pas de place à l’analyse est pour moi un non sens totale, comment penser qu’on peut constituer une première liste d’éléments pour la première version du produit sans faire un énorme travail d’analyse ? Alors oui, il faut définir une liste de fonctionnalité, les priorisés, définir un plan de release (valider avec l’ensemble de l’équipe projet), être sûre que ce premier plan contient une liste cohérente et suffisante pour avoir un produit exploitable, apportant une valeur, avec l’ensemble des critères d’acceptation associés. Non seulement il y a une phase d’analyse mais en plus elle est faite à chaque incrément du produit. Voici un des défis de l’agilité, à savoir recueillir le besoin, l’exprimer et passer en production le plus rapidement possible.

La productivité

La productivité d’une équipe est étroitement lié à la quantité de valeur que l’équipe produit pendant un sprint/release livré en production. Plus l’équipe est productive, moins elle met de temps à pousser des fonctionnalité en production (donc raccourcir et améliorer les processus de livraisons) avec des fonctionnalités qui répondent au besoin de l’utilisateur/client, l’implication ici du métier dans l’équipe est vitale et la notion de test automatisé est primordiale, voir Test Driven Requierment (TDR)/Behavior Driven Development (BDD). Le test est le seul garant d’un Refactoring sans casse et le Refactoring est la seul garant d’une productivité qui ne baisse pas avec le temps.

La motivation

Une équipe productive est une équipe motivé, l’agilité a besoin d’individu motivé, investi et moteur. Une des valeurs de l’agilité est de donner de l’autonomie à l’équipe, ce qui donne le champs libre à l’épanouissement personnel et avec des individus épanouis on forme des équipes performantes. Si en plus de la motivation l’accomplissement ou le désir de l’excellence fait partie des attentes des développeurs, nous avons alors une équipe qui innovera, se souciera de la qualité et proposera des solutions d’améliorations.

Voici une excellente vidéo sur le sujet : http://www.youtube.com/watch?v=u6XAPnuFjJc

La qualité

Faire de la qualité pour de la qualité n’est pas une quête en soit, par contre faire de la qualité pour maintenir un niveau de production malgré une quantité de code grandissante est essentiel. Il faut chercher continuellement à rendre le code évolutif et facile à maintenir, en limitant les régressions avec une bonne couverture en test et une architecture/design facile à enrichir, l’ajout d’une nouvelle fonctionnalitée avec un impacte minimale sur le code existant permet d’éviter le code spaghetti.

Voici quelques facteurs importants pour garantir une productivité qui dure

Article précédent, Vers la production agile : Construire une usine logicielle .NET efficace