Intégration HTML/CSS en flux tendu
Attention, cet article a été déplacé dans les archives, donc le contenu peut ne plus être à jour. A vous de voir 🙂
L’intégration HTML/CSS en flux tendu consiste à fournir les pages désignées à l’intégrateur au fur et à mesure de leur disponibilité, sans que la charte graphique soit finalisée.
Inconvénients pour l’intégrateur :
- Des retours sur la DA sont fréquents.
- Les livraisons de code sont multiples, les retours arrivent non groupés.
- Pas d’estimation fiable de la durée du projet.
- Selon les aléas du planning, le projet peut être confié à une autre personne qui le continuera.
- Le projet dure plus longtemps, car des prévisions sur les comportements de blocks sont à faire en amont.
- Aucune idée de la portée et du niveau de réutilisation de code
(Typiquement : Block « pas prévu pour cette taille » à refaire ou Block « prévu pour » mais non utilisé.) - OOCSS ? « .objet-video {} ». non, mince « .objet-media {} ». non, mince. « .objet-media, .objet-video {} »
Avantages de cette solution :
- L’intégration est démarrée plus tôt.
- Le client voit que « le travail avance ».
L’enfer, quoi.
(Disclaimer : Aucun rapport avec mon employeur actuel, je relate une expérience vécue)
Bonsoir,
travailler en flux tendu a d’autres avantages :
* Repérer plus tôt les problèmes d’ergonomies, d’accessibilités…
* Mettre l’intégrateur tout de suite dans la boucle
* …et donc, pour celui-ci, mieux vivre le projet
* et aussi être force de proposition (certaine page nécessite-t-elle vraiment une maquette ?)
Ceci dit, sur des projets assez court, la différence de méthodologie est assez faible.
Nat
C’est mignon « à flux tendu » comme expression, pour parler d’un fonctionnement complètement à l’arrache.
Attention à ne pas confondre travail en « Flux tendu » et consultation en amont 🙂
(Cet article ne parle évidemment que des projets complètement en flux-tendu, pas des projets en constante évolution)
J’ai eu exactement la même réaction que Palleas.
La méthode « Flux Tendu » n’est pas très éloignée de la méthode « La Rache ».
Pour l’intégrateur (et le dev) c’est souvent une énorme perte de temps : Tu peux rien prévoir et le comportement de l’application change à chaque nouveau design livré :/
ça me parait même être le meilleur moyen pour avoir un code non maintenable et non optimisé du tout :/
Méthode certifiée ISO 1664. Pour avoir fait des projets comme ça, c’est un enfer ! Et c’est encore pire si c’est un graphiste indécis qui a je cite « besoin de voir la maquette en site pour améliorer ». J’ai vu des projets emmener tout le monde au clash en fonctionnant ainsi.
Dans un monde idéal, oui, l’intégrateur serait lié au projet tout au long du processus (la consultation en amont évoquée ci-dessus), mais en général, travailler à flux tendu, c’est « tiens, démerde-toi avec quelques miettes ».
La qualité est déplorable, la CSS est bordélique à souhait, vu qu’en général, on ne laisse pas le temps de refaire proprement les choses.
Perso, je ne m’embête plus : quand ça commence à travailler comme ça, je tire d’entrée de jeu la sonnette d’alarme « attention, cette méthode nous pose tels problèmes, on peut s’en accommoder, mais la qualité/cohérence du projet peut et risque très probablement d’en souffrir. Est-il réellement impossible d’avoir une version un peu plus finalisée pour limiter la casse ? ».
Ainsi, c’est en toute connaissance de cause qu’on continue ainsi.
Je constate aussi que ce genre de méthode génère souvent des projets que j’appelle Black-Hole : http://www.nicolas-hoffmann.net/source/1490-Les-projets-Black-Hole.html 😉
vous n’aurez pas une alternative à cet outil? puisque quand on a beaucoup de travail alors le mot enfer est faible pour décrire l’apocalypse qui se passe
J’ai régulièrement de longs projets en flux tendu à intégrer et c’est tout sauf à l’arrache.
Le zoning de 80 pages était déjà fait, le planning également, 10 gabarits PSD étaient déjà en ébauche mais pas encore totalement validés et quand ils l’ont été, ça a été livraison 3 par 3 et intégration dans la foulée. Les 70 autres gabarits même pas en brouillon au moment des premières livraisons étaient des déclinaisons de ceux-ci, le client savait très bien la perte de temps et financière qu’il se serait infligé en modifiant ses premières maquettes !
Résultat : au lieu créer des PSD pendant 3 mois puis intégrer pendant 3 mois (temps total : 6 mois), le projet peut se terminer au bout de 4 mois à peu près.
D’après mon expérience avec graphiste en interne (Alsacreations.fr) ou chez le client, il faut minimum le PSD de la Home ET d’une page de contenu. Je réserve mes règles CSS avec les sélecteurs les plus simples au contenu (styler p, h2, etc) et surcharge la Home mais dans l’immense majorité des cas la Home est créée en premier et ensuite il faut pas mal de modifs si l’on n’a pas déjà une page de contenu…
Une page de formulaire ne pose pas un tel problème puisque c’est de toute façon spécifique à form quelque chose (en substance).
Je plussoie l’anecdote de Darklg sur « OOCSS ». Le nommage est parfois plus compliqué que les règles CSS elles-mêmes ^^ (mais ça fait apprendre les synonymes de mots usuels en anglais !)
Merci pour ton commentaire, il est intéressant, car il souligne certains points qui permettent une inté en flux tendu.
Un cahier des charges / zoning complet et entièrement validé, un planning solide, les DA des modules majeurs validés (et réutilisées de manière similaire dans les declinaisons) peuvent en effet aider à tenir dans cette méthode.
Mais elle implique une gestion de projet sans faille et une très bonne préparation (CdC, etc) en amont, ce qui a trop rarement été le cas dans mes expériences passées 🙂
Edit : Je constate que tu travailles chez Alsacréations, où le travail de l’intégrateur est respecté, donc note que j’avais plus en vue ces entreprises où il est commun de devoir pisser du HTML en vitesse avant d’attaquer le PSD suivant 😉