Questions sur la gestion de projet web

Bonsoir !

Je suis actuellement en train de "m’auto former" sur la gestion de projet web. Je récupère donc des informations un peu partout, mais tout est encore mélangé dans ma tête et je ne parviens pas à tout remettre en ordre.

J’ai donc ici une liste (en vrac) de choses importantes lors de la gestion de projet :

• Etude des besoins du client
• Cadrage du projet
• Etude de faisabilité
• Estimation des coûts et des risques (ça va sûrement dans l’étude de faisabilité)
• Liste des fonctionnalités
• Liste des tâches
• Définition du planning et attribution des tâches
• Cahier des charges
• Diagramme de GANTT (ça va sûrement avec la définition du planning et attribution des tâches)
• Définir et organiser les contenus
• Arborescence du site
• Charte éditoriale
• Charte graphique et ergonomique
• Spécifications fonctionnelles
• Spécifications techniques
• Zoning, Wireframe et Maquette
• Développement du site
• Gestion de l’hébergement et du NDD
• Création du design

Voilà ce que je sais actuellement des petits trucs qu’il faut faire lors de la gestion de projet.

Je sais aussi qu’il y à 5 étapes :

• Initialisation
• Lancement
• Conception
• Production
• Exploitation

J’ai donc besoin de votre aide, afin de remettre les différentes choses à faire (par exemple, cadrage du projet, étude de faisabilité, arborescence du site, …) dans les bonnes étapes (initialisation, lancement, conception, …) et dans le bon ordre (c’est à dire dans l’ordre où il faut les réaliser). J’avoue avoir essayé, mais je me mélange les pinceaux à chaque fois.

Voici le résultat que j’ai actuellement :

Je vous remercie !

Je parlerais ici de la méthodologie en cascade. Pas de méthode agile donc.

Par curiosité : pourquoi, sachant qu’en ingénierie logicielle on sait depuis au moins 10 ou 15 ans que cette méthodo n’a en pratique qu’une infime chance d’aboutir sur un produit satisfaisant dans les délais ?

D’autant plus dans le web où il est inconcevable de ne pas boucler régulièrement avec les clients ?

Et : Devis, Contrat de vente/Facturation, Accompte et Règlement.

Et bien parce que c’était pour moi le plus simple, et que cette méthodologie est tout de même adapté à certains projet web (notamment ceux qui sont prévisible). Et puis aussi parce que j’ai pu lire qu’il fallait apprendre celle-ci en premier (mais à vrai dire, je ne connais pas la raison).

Sinon, j’arrive de mieux en mieux à comprendre. Ecrire ce que j’apprend m’aide à réorganiser le tout.

J’arrive maintenant à mettre chaque élément dans la bonne phase, et je commence à apprendre la rédaction d’un cahier des charges.

tu as oublié, selon moi le plus important, les tests fonctionnels et la recette.

Et bien parce que c’était pour moi le plus simple, et que cette méthodologie est tout de même adapté à certains projet web (notamment ceux qui sont prévisible).

(Ça n’existe pas)

Et puis aussi parce que j’ai pu lire qu’il fallait apprendre celle-ci en premier (mais à vrai dire, je ne connais pas la raison).

En fait c’est ce que je pressentais dans ton message. À vrai dire c’est un point de vue qui se défend : apprendre à reconnaître toutes ces étapes et leur utilité dans la gestion macro d’un projet a du sens. Au fond, toutes ces phases sont également réalisées dans un projet en Agile, sauf qu’elles ne le sont pas toutes forcément explicitement, ni dans le même ordre, ni même en une seule fois. Dans la réalité, on calque souvent quelques unes de ces étapes du cycle en V sur un projet, au début et à la fin, même si l’on remplace tout ce qui se situe entre les deux par un processus itératif.

Je m’étonnais juste du fait que tu écartais les méthodes agiles d’emblée dans ton post, je comprends mieux.

C est un peu hors sujet, mais…

Bref. les 3 derniers années j ai dev en mode agile.

Mais je passais plus de temps en réunion a discuter de ce que ça pourrait ou pas faire, a analyser les évolutions et évaluer les contraintes … Qu’à dev.

Pour le dernier projet. Mon boss m’a contraintes a un cahier de charge précis.

Et je ne fais que dev Je fais valider mon taf 1 fois semaine en 1h.

La mode agile, on en est revenu et c est pas plus mal.

Merci pour vos réponses !

Donc si je comprend bien, aujourd’hui, il est vraiment déconseillé de travailler sans utiliser une méthode agile ?

Ouais c’est assez typique comme expérience. Puisqu’on est dans l’anecdotique, ces 3 dernières années j’ai bossé en agile dans deux contextes diamétralement opposés : le premier dans une équipe où la méthodo était un échec, et où on entendait fuser le même genre de remarques que celles que tu viens de faire (rholala beaucoup de réunions inutiles, etc.). La seconde dans ma boîte actuelle, où j’ai moi-même introduit Scrum il y a un peu plus d’un an, et où on est finalement arrivés à la phase "ultime" où la vélocité de l’équipe augmente constamment d’itération en itération.

Pour avoir beaucoup étudié ces trucs-là dans mon précédent poste (ça faisait partie de mon boulot d’optimiser les humains et leur façon de bosser, ironiquement, alors que j’étais dans une équipe qui ne fonctionnait pas), il est clair que le succès ou non de ces méthodes dépend avant tout de la culture de l’équipe (au sens large, c’est-à-dire en incluant les décideurs), de sa compréhension des enjeux et du fait qu’elle soit au diapason : si l’équipe ne ressent pas le besoin de s’approprier la gestion de son travail et préfère faire "passivement" le dev qu’on lui demande en command & control, il est évident que ça ne sert à rien de lui parler de Scrum.

Si au contraire l’équipe est demandeuse de ce genre de contrôle, sensible à sa propre capacité collective à livrer et à coopérer, et qu’elle a globalement compris le pourquoi de chaque détail/rôle dans la méthodo qu’elle applique, alors elle a toutes les chances de son côté.

Le fait de passer tout son temps en réunion pour ajuster sa propre façon de bosser en agile, c’est symptomatique d’un échec : ça se résout avec un coach, à savoir quelqu’un qui a de l’expérience là dedans (donc de l’autorité sur ce sujet d’un point de vue humain), coupe court aux digressions philosophiques en expliquant clairement les choses et pointe du doigt les problèmes concrets qu’il voit à régler en priorité… Sauf que les boîtes qui en arrivent là ont souvent tendance à ne retenir que ce qu’elles veulent des ressources sur la question, et zappent infailliblement cette étape du coach.

Et pareil, le fait de passer son temps à taper le carton sur ce que pourrait faire ou non telle ou telle feature et comment on veut qu’elle soit, c’est qu’il manque un PO (product owner), ou bien que l’équipe n’a pas compris le rôle du PO, ou bien que le PO ne fait pas son boulot, ou bien qu’il y a plusieurs PO (c’était une des principales raisons de l’échec dans l’équipe où j’étais).

Quant au fait d’appeler ça une "mode"… Ça me fait sourire, parce que cette "mode" a quand même été lancée par Toyota il y a 50 ans : le lean thinking n’a rien de nouveau.

Donc si je comprend bien, aujourd’hui, il est vraiment déconseillé de travailler sans utiliser une méthode agile ?

C’est pas aussi tranché. En termes de gestion de projet, par contre, clairement en info il est établi que le mode waterfall n’est pas viable et que le mieux reste d’itérer régulièrement avec le client pour contrôler que ce que tu fais coïncide avec ce dont il a besoin (ce qui est parfois différent ce qu’il veut et généralement différent de ce qu’il demande). Les méthodos agile vont dans ce sens mais ce ne sont pas les seules.

J appelle ça une mode parce que même si cela fait un demi siècle que ça existe ces dernières années on entends que ce mot agile.

Pourtant, une simple recherche vous listeria les défaut et le nombre d entreprises du font marche arrière .

Mon métier c est Moe pas moa.

Le mien c’est de livrer un logiciel qui réponde au besoin de mes clients, pas de m’enfermer dans une petite case.

D’expérience, les défauts principaux constatés des méthodes agiles sont de 4 types :

1. Sans doute le plus courant : le client / service commercial qui refuse de comprendre qu’avec une méthode agile, il ne peut plus payer pour avoir « les fonctionnalités X à la date Y pour le cout Z », avec X, Y et Z connus d’avance. En fait il n’a jamais pu avoir ça, mais ne l’a généralement pas compris.
2. Vient ensuite : les entreprises confondent « méthode agile » et « pouvoir faire n’importe quoi n’importe quand ». Or, une méthode agile est une méthode, qui elle est tout sauf souple : pour qu’elle fonctionne, elle doit être correctement adaptée.
3. Le travail d’équipe (superbement illustré par le dernier message de @jerome d). Avec une méthode agile, sortir un logiciel de qualité, c’est l’affaire de tous. On ne peut plus se retrancher derrière une excuse du genre « ha mais ça c’est pas mon boulot, je m’en cogne » (ce qui ne veut pas dire qu’il faut faire n’importe quel boulot, mais qu’il faut faire preuve d’une souplesse raisonnable pour que le produit avance dans la bonne direction). C’est un problème d’autant plus gros que l’équipe (au sens général) est grosse.
4. L’incompatibilité de pilotage du logiciel dans l’entreprise cliente avec une méthode agile. Je pense notamment à tous ces cas, très nombreux, où soit personne n’est capable de définir clairement ce que le logiciel doit faire en réalité¹ ; ou ceux tout aussi nombreux où plusieurs personnes décident de manière non concertée ni personne pour trancher ce que le logiciel doit faire.

Je note aussi qu’en dix ans de carrière, sur tous types de projets pour tous types de clients :

• Je n’ai jamais vu une méthode agile implémentée correctement, et donc toutes se sont cassées la gueule (avec au moins l’un des 4 points ci-dessus en cause, souvent plusieurs).
• Je n’ai jamais vu non plus une méthode de type waterfall fonctionner de manière satisfaisante… mais comme c’est ce que les gens connaissent, ils trouvent ça « normal ».

PS sur ça :

Mon métier c est Moe pas moa.

Je n’ai jamais vu un developpeur ni une MOE (quand elle est identifiée comme telle) faire correctement son métier si elle n’a pas bien compris ce qu’est censé faire le logiciel ni comment il est censé être utilisé par de vrais utilisateurs. Parce que ce qui arrive sinon, c’est qu’on a d’énormes erreurs de conception et réalisation sans même s’en rendre compte. Et c’est catastrophique.

À mes yeux, il existe une raison encore plus profonde aux échecs d’implémentation d’Agile dans le monde occidental, qui tient de la sociologie/psychologie sociale.

Ces méthodes proviennent globalement du Japon qui est une culture notoirement collectiviste. Pour résumer hyper grossièrement, qu’il s’agisse de samourais ou de salariés, dans la culture japonaise le bien collectif (l’honneur du clan, l’atteinte des objectifs par l’entreprise, la prospérité et le bien-être de la famille) est au-dessus du bien individuel. On retrouve cet aspect dans énormément de choses que l’on voit exportées du Japon (jusque dans les shonens : Seïa n’a pas le droit de perdre parce qu’il doit ça aux autres chevaliers et à leur mission).

A contrario, la culture occidentale est essentiellement individualiste : on est généralement beaucoup plus attentifs au bien-être individuel, on accorde une assez grande importance aux entretiens d’évaluation individuels dans les boîtes, et on cherche des postes où on est peinard et où on s’épanouit en tant qu’individu, quitte à changer de boîte comme de chemise (surtout en info) jusqu’à trouver la bonne.

Partant de là, il n’est pas si étonnant que l’une des difficultés que l’on éprouve avec les méthodes agile en occident, soit d’adopter un état d’esprit collectiviste : arrêter de couvrir ses miches et travailler pour le bien et la reussite de l’équipe n’est généralement pas intuitif pour des français.

Ça ne veut pas dire que c’est impossible, mais qu’il faut être conscient que c’est un véritable culture shift, faute de quoi on ne finit jamais par s’y sentir à l’aise.

Merci encore pour vos réponses !

A lire vos messages, j’ai l’impression que les méthodes agiles ne fonctionnent pas si bien que ça…

Du coup, je vais poser une question qui va peut être me permettre d’y voir un peu plus clair.

Prenons un exemple : Imaginons qu’un client me demande de lui faire un site web. Je suis le seul développeur sur le projet. Quelle méthode utiliser ? Méthode en cascade ? Méthode agile ?

Merci encore pour vos réponses !

A lire vos messages, j’ai l’impression que les méthodes agiles ne fonctionnent pas si bien que ça…

Les méthodes fonctionnent très bien. C’est juste qu’elles demandent un effort (pas forcément naturel) pour être adoptées, et qu’en France les gens s’y prennent collectivement comme des manches parce que ça bouscule une longue tradition d’ingénierie.

Ça dépend de ton client. S’il est intelligent et comprend qu’il est dans son intérêt que le dev soit itératif (une demo régulière toutes les semaines/deux semaines/mois… pour te synchroniser avec lui, ajuster, prioriser la suite), alors clairement le plus sain est de bosser à-la-agile. En bossant seul tu ne risques pas de tomber dans les écueils écrits plus haut qui sont principalement des problèmes de collaboration.

S’il t’impose au contraire un fonctionnement à la waterfall, bah t’auras pas le choix.

selon moi il n’y a pas de bonne réponse, tous les modèles ont des atouts et des défauts.

ce que tu demandes c’est 1 cas d’école, dans la vrai vie ca ne marche pas comme ca.

un client ne pourra jamais se libérer 1 fois semaine sur 6 mois parce qu’il a du travail lui aussi et toi aussi.
un client ne saura jamais ce qu’il veut, car il ne sait pas, ni ce qui est possible, ni ce que ca va donner. et la deadline en mode agile ne varie pas aussi vite que ce qu’elle devrait. même si on exprime un besoin, le client lui a aussi ses besoins.

D’ailleurs, dans la plus part de mes projets, c’est le client qui fixe la deadline et le commercial et manager qui négocient (et moi qui fait des heures supp).

Si un client ne peut pas se libérer une heure une fois par semaine, c’est qu’il ne se donne pas les moyens de son applications. Même avec le pire cycle en V du monde, si tu ne suis pas régulièrement ton projet, le projet est mort.

Un client qui ne sait pas ce qu’il veut, c’est normal mais ça s’accompagne le plus en amont possible pour éviter de développer n’importe quoi – et c’est un vrai boulot avec de vraies compétences spécifiques.

Pour résumer, dans la vraie vie le scénario le plus probable c’est que :

• Tes clients attendront de toi que tu fonctionnes en waterfall, avec le même style d’exigences irréalistes,
• Tu penseras ton travail itérativement en raisonnant avec des principes agiles parce qu’ils relèvent du bon sens et réduisent le risque de te vautrer,
• En réalité tu suivras en secret la méthode de la RACHE, comme pratiquement tout le monde.

c’est exactement ça.

https://www.monkeyuser.com/2018/applied-tdd/