Quelques règles pour les projets Agiles

Ci-dessous quelques règles à garder à l’esprit dans le cadre de projet notamment Agile.

Schema Agile Scrum

  • Impliquer les utilisateurs le plus tôt possible. Ceci est le cas lors de la définition du besoin mais aussi lors de développement de la solution. Des démonstrations régulières devront être réalisées régulièrment afin d’éviter tout effet tunel. Ces démonstrations devront être planifiées le plus tôt possible. Elles devront apparâitre dans le planning du projet dès le démarage.
  • Simplifier les solutions souhaitées. Les décideurs, les sponsors peuvent rendre le besoin plus complexe que nécéssaire. C’est une erreur commune qui est une des causes les plus importantes de l’échec des projets. Peu importe le degré de détail des spécifications, celles-ci resteront toujours incomplètes. Des modifications seront toujours nécéssaires. La solution développée devra être la plus modulaire et la plus flexible possible. Cette modularité devra permettre une adaptation au chagement et garantir la réussite du projet.
    Les points suivants doivent être gardés à l’esprit:

    • Les spécifications doivent être simples. L’objectif doit être simplement et clairement énoncé. Cet objectif doit être claire pour tous les membres de l’équipe. Les spécifications peuvent être rédigées sous forme de cas d’utilisation simple. Les grandes fonctionnalités doivent être découpée en fonctions simple.
    • Crées les cahiers de test le plus tôt possible, idéalement avant les développement des cas d’utilisation. Le cahier de test doit être fourni à l’équipe de dévloppement. Il constitue un complément des spécifications.
    • Développez de manière Agile. Réalisez un prototype dès que possible et montrez le à votre client. Laissez le client jouer avec, le tester. Faire ces retours dès que possible. Ceci permettra d’identifier la différence de compréhension entre le besoin exprimé et la compréhension de l’équipe de développement.
    • Faites évoluer les spécifications dès que possible. Intégrez les changement souhaitez le plus tôt.
    • réduire les cycles de développements à 2 ou 3 semaines réduit aussi les risques de décalage et l’effet tunnel.
  • Identifier la bonne ressource manquante à l’équipe. Cette ressource doit venir compléter les besoins identifiés au niveau de l’équipe. Inclure dans les entretiens des experts identifiés qui peuvent juger de la compétence de l’interlocuteur. Une ressources qui a un large panel de connaissances mais qui ne sont que théorique n’est pas forcément meilleure qu’une ressource spécialisée avec de l’expérience. Une ressource non expérimentée mais motivée s’avère souvent plus utile et efficace qu’une ressource expérimentée mais non motivée… Les compétences attendues ne sont pas uniquement techniques, elles doivent inclure les capacité en communication et d’adaptation à des environnements et contextes métiers différents et complexes.
  • Ne pas oublier de prendre des congés mais pensez aussi au remplaçant si nécéssaire pendant cette période. Le remplaçant doit avoir le temps, les moyens et le degré de connaissance nécéssaire.
  • Qu’est ce qui est fini? Fini / terminé veut dire que le développement réalisé correspond aux critères définis pour dire que ça soit considéré comme terminé: Critère d’acceptation vérifiés + passage du cahier de recette pour l’itération. Il faut aussi ne pas oublier de remettre chaque fonctionnalité dans son contexte globale du projet et l’a testé dans le contexte plus globale. Les enchainements entre les écrans et fonctionnalités sont à vérifier.
  • Produire en mode cyclique: des études montrent que au delà de 90 à 120 minutes la productivité baisse. Il faut donc penser à des temps de pause. Les projets doivent aussi être découpés avec des phases de livraisons toutes les 2 à 3 semaines. Cette phase de livraison doit être l’occasion de faire une communication sur les résultats et un feedback sur les difficultés et améliorations à apporter à la prochaine itération. Chaque itération doit avoir son planning, son plan d’action et de réalisation ainsi qu’un stade de “récompense“. Le manager et son équipe doivent se poser les questions suivantes: Pourquoi? quand? comment? quoi? qui?. A la fin de chaque itération, la récompense permet de reconnaitre les efforts de l’équipe et de la féliciter.
  • Communiquez: DailyScrum, Coproj + Copil sont autant d’occasion de mettre au claire les difficultés, les solutions et l’avancement. La communication est un élément essentiel sur le projet. L’équipe doit pouvoir s’exprimer. Les points de doute ou de non compréhension doivent être très vite élucidés.
  • Privilégier l’instant présent plutôt que le futur. Une application qui peut être testée, utilisée vaut beaucoup plus que plusieurs centaines de page d’un document de spécifications. Dès que vous le pouvez, mettez en place un prototype. Livrez des versions testables et utilisables. Les cycles de développement / livraison doivent être rythmés. Ajustez selon les retours effectués par les utilisateurs.
  • Servez l’équipe! Soyez un facilitateur
  • Les meilleurs estimations sont faites par ceux qui réalisent. Demandez aux membres de votre équipe d’estimer leurs tâches.