(reprise du message précédent)
Dès qu'on fait appel à des prestataires, il est bon de se former un minimum sur le domaine considéré. L'avantage du secteur qui nous intéresse, c'est que toute l'information est aisément disponible. Par contre, elle est largement disséminée. Se former prend du temps, et en ramenant ça à des jours de travail, on explose largement les quelques centaines d'euros perdues par Extraduke.
On dispose déjà de référentiels de bonnes pratiques, je pense notamment au travail d'opquast, dont le champ d'action s'est récemment étendu (seo, opendata).
C'est pas forcément abordable pour un néophyte, donc l'initiative de STPo semble bienvenue (maintenant t'es obligé hein
)
Mais au delà de ce type de recueil 'normatif', le problème réside plus dans la méthode.
J'entends beaucoup parler de 'chef', de 'chef de projet', de 'cahier des charges'.
Pour le développement informatique, ça marche assez mal, et quand ça marche, ça entraîne de lourds inconvénients pour une des deux parties.
Le cdc, malgré l'apparente sécurité qu'il apporte, est long et couteux à écrire, est rarement lu, encore moins assimilé, et se trouve caduc au bout de quelques jours de travail.
De plus, les deux parties se retrouvent liées par des documents pénalisant toute évolution, obligeant à produire avenants et correctifs au cdc et contrat.
L'autre problème majeur et le syndrome de la boîte noire, c'est à dire le manque de contrôle et de visibilité du client sur le projet et l'absence de feed back pour l'équipe de développement.
Je sais bien que c'est ce qu'on vend aux étudiants dans pas mal d'écoles.
Les méthodes agiles apportent une alternative intéressante: on se focalise sur la développement plutôt que sur les docs lourdingues et inutiles, sur les interactions plutôt que les méthodes cabalistiques, la négo avec le client plutôt que la contractualisation, et l'évolutivité plutôt que les cahiers de charges.
En clair, on implique le client ou son représentant au cœur du processus de développement, en livrant régulièrement des versions fonctionnelles mais non finalisées du produit.
Les fonctionnalités développées au cours de chaque itération sont décidées, priorisées, puis figées pendant le développement. A chaque livraison, le client peut apprécier le fonctionnement du produit, et décider des fonctionnalités de la phase suivante. Ceci permet non seulement au client de contrôler le développement au fur et à mesure du projet, mais également son budget, en ajoutant ou retirant des fonctionnalités.
Ce ne sont pas des méthodes miracles, elles nécessitent encore plus de discipline et de compétences que les méthodes en cascade traditionnelles.
Ici, Extraduke aurait pu se rendre compte bien plus tôt de la tournure prise par le front(end) de son projet.
Dès qu'on fait appel à des prestataires, il est bon de se former un minimum sur le domaine considéré. L'avantage du secteur qui nous intéresse, c'est que toute l'information est aisément disponible. Par contre, elle est largement disséminée. Se former prend du temps, et en ramenant ça à des jours de travail, on explose largement les quelques centaines d'euros perdues par Extraduke.
On dispose déjà de référentiels de bonnes pratiques, je pense notamment au travail d'opquast, dont le champ d'action s'est récemment étendu (seo, opendata).
C'est pas forcément abordable pour un néophyte, donc l'initiative de STPo semble bienvenue (maintenant t'es obligé hein
) Mais au delà de ce type de recueil 'normatif', le problème réside plus dans la méthode.
J'entends beaucoup parler de 'chef', de 'chef de projet', de 'cahier des charges'.
Pour le développement informatique, ça marche assez mal, et quand ça marche, ça entraîne de lourds inconvénients pour une des deux parties.
Le cdc, malgré l'apparente sécurité qu'il apporte, est long et couteux à écrire, est rarement lu, encore moins assimilé, et se trouve caduc au bout de quelques jours de travail.
De plus, les deux parties se retrouvent liées par des documents pénalisant toute évolution, obligeant à produire avenants et correctifs au cdc et contrat.
L'autre problème majeur et le syndrome de la boîte noire, c'est à dire le manque de contrôle et de visibilité du client sur le projet et l'absence de feed back pour l'équipe de développement.
Je sais bien que c'est ce qu'on vend aux étudiants dans pas mal d'écoles.
Les méthodes agiles apportent une alternative intéressante: on se focalise sur la développement plutôt que sur les docs lourdingues et inutiles, sur les interactions plutôt que les méthodes cabalistiques, la négo avec le client plutôt que la contractualisation, et l'évolutivité plutôt que les cahiers de charges.
En clair, on implique le client ou son représentant au cœur du processus de développement, en livrant régulièrement des versions fonctionnelles mais non finalisées du produit.
Les fonctionnalités développées au cours de chaque itération sont décidées, priorisées, puis figées pendant le développement. A chaque livraison, le client peut apprécier le fonctionnement du produit, et décider des fonctionnalités de la phase suivante. Ceci permet non seulement au client de contrôler le développement au fur et à mesure du projet, mais également son budget, en ajoutant ou retirant des fonctionnalités.
Ce ne sont pas des méthodes miracles, elles nécessitent encore plus de discipline et de compétences que les méthodes en cascade traditionnelles.
Ici, Extraduke aurait pu se rendre compte bien plus tôt de la tournure prise par le front(end) de son projet.
).
, en tout cas ce n'est pas une bonne pratique. 
effectivement. Mais alors les experts SEO flirteraient avec les mauvaises pratiques ? Si on considère comme acquis ce que tu dis, on ne peut prétendre procurer un bon référencement sans "trichouiller" ? Je croyais que c'est justement les bonnes pratiques qui assuraient d'un bon référencement (naturel en quelque sorte). J'espère ne pas caricaturer ce que tu dis mais c'est ce que j'ai compris. 