urbanisation-si.com

urbanisation-si.com

Méthodes agiles


6/11 Projet informatique, passer du moyen âge à l'ère industrielle. Travaillez votre agilité.

méthode-agile.jpeg

 

Les méthodes agiles (Scrum, Kanban, XP, … ) ne sont pas incompatibles avec les processus d'ingénierie comme CMMI, ISO, … qui spécifient le "quoi faire" et non le "comment faire" qui relève justement de leur périmètre. La meilleure méthode sera celle que vous vous serez approprié en mixant et adaptant l'ensemble des méthodes traditionnelles ou agiles à votre propre contexte.

 

Les utilisateurs de futures applications ne savent pas ce qu'ils veulent. Mettez de côté les "mais vous m'aviez dit que le gestionnaire pouvait modifier le statut de la commande" ou bien encore "pour le calcul des indemnités on devait se baser sur les salaires des 6 derniers mois et non sur les tranches de sécurité sociale". Seulement voilà, au fur et à mesure où le développement avance et où on commence à montrer les premiers écrans opérationnels, les utilisateurs vous disent que finalement ça a changé. Avec toutes les bonnes raisons du monde du reste, ils vous diront qu'ils n'avaient pas compris ce que vous attendiez d'eux, que le concurrent a ajouté des nouveaux services clients a très fortes valeurs ajoutées ou bien encore que la nouvelle loi à plus d'impacts que prévus. Cela arrive d'autant plus que les équipes peuvent rester isoler dans leur bunker sans avoir aucune relation avec le reste du monde.

Et voilà pourquoi plus de 80% des projets explosent les budgets quand ils ne sont pas gelés ou jetés à la poubelle.

Avec les méthodes agiles on laisse de côté toutes nos vieilles habitudes.

Le facteur humain avec les aspects communication est mis en valeur par rapport aux lourdeurs des formalismes des méthodes d'ingénierie et de leurs outils. La prise de conscience que ce qui compte vraiment ce n'est pas la documentation et les spécifications mais l'exécutable réalisé. Mettre en œuvre une collaboration efficace avez le client permet la reformulation qui est le moyen le plus efficace que l'on connaisse pour savoir si on a bien compris ce qui a été formulé. Oubliez définitivement de vouloir refuser les changements sous prétexte que ce n'est pas ce qui avait été spécifié. Les bonnes pratiques sont :

• l'adoption d'un cycle itératif et incrémental

• l'implication du client permettant, toutes les 2 à 4 semaines (durée recommandée pour une itération qui doit être courte) de montrer l'avancement des réalisations. Le fameux "effet tunnel" est ainsi évité.

• définition d'objectifs atteignables à court terme permettant de maintenir une pression constante mais supportable évitant l'effet "gaz" (quelque soit le temps donné à un développeur, il aura tendance à prendre la totalité pour réaliser sa tache).

• l'intégration des équipes diminuant les tensions et contentieux qui peuvent naitre entre la MOA et les prestataires MOE

• la livraison d'une application opérationnelle et en adéquation avec les besoins exprimés grâce aux méthodes TDD (Test Driven Developpement) et TDR (Test Driven Requirement) qui mettent l'accent sur les tests et aux feedbacks réguliers avec le client.

L'acceptation et l'appropriation de ces nouvelles bonnes habitudes ne se feront que s'il y a une réelle implication et volonté de changement de la direction générale et pour cela il faudra prouver mathématiquement le retour sur investissement.

 

Voir aussi le site :

Abandonnez le classicisme, relookez votre SI


21/08/2014
0 Poster un commentaire