Les Navigation Nodes; une approche pour la navigation web

Dans tous les projets web que j’ai eu l’occasion de développer jusqu’ici, un chose est indiscutablement présente: un plan de navigation, spécifiant quelles pages mènent à quel endroit, dans quels contextes et conditions. Ces problèmes m’ont amené à développer (avec l’aide de Stéphane) et implémenter avec succès dans deux projets une méthode que je nommerai ici “Navigation Node”. Problème:

  • La navigation est étroitement liée au design, donc difficile à maintenir
  • Les changements de flux de navigation demandent beaucoup de tests et de vérifications
  • Les URLs dynamiques sont souvent difficiles à gérer
  • Il n’y a pas d’endroit centralisé ou gérer la logique de navigation

Read more…

Le code; un simple format de spécifications?

(Cet article est un pot-pourri d’idées, qui sera probablement clarifié dans différents articles plus tard) Lors de nos nombreuses discussions errant entre la philosophie et l’interrogation technique, Stéphane et moi parlions souvent de notre conception du code et du développement logiciel en général. Certaines différences de point de vue mineures, telles que: “devrions-nous mettre des espaces entre la première parenthèse d’une méthode et son premier paramètre?”, nous ont vite fait remettre en question notre vision du code. Jusqu’ici, le code était le résultat, là ou tous les processus et l’analyse mènent. Désormais, il n’est à nos yeux qu’une vue pour l’interpréteur ou le compilateur, tout comme les fonctionnalités sont des explications au développeur ou les spécifications pour le client. La première idée issue de ce principe était de lier de manière forte les éléments des documents d’analyse à travers le code, ainsi qu’aux différents diagrammes. De cette manière, on pourrait facilement juxtaposer les différents éléments dans une vue propre aux besoin d’un rôle. On pourrait aussi aisément suivre les changements autant en amont qu’en aval. On rend donc la documentation manuelle inutile, en plus d’en fournir une exacte et à jour en tout temps, puisqu’elle implémente un ou plusieurs éléments des documents d’analyse. Cette idée serait principalement traduite par une application de collaboration impliquant une structure de contenu extrèmement rigide.

Read more…

Les équipes pop-corn

Suite à un dîner avec deux de mes collègues (soit un analyste et un architecte) touchant l’implantation de processus et méthodologies concrètes dans notre milieu de travail, un sujet intéressant s’est infiltré: dans une entreprise de taille moyenne, les équipes devraient-elles rester groupées, au point d’être considérée comme des ressources indiscociables? Tom Demarco, dans l’excellent livre “Peopleware( il est illégal de ne pas avoir lu ce livre je crois ) parle beaucoup du “Team Jell”, c’est à dire le gain immense de productivité du à une cohésion forte entre les membres d’une même équipe. En pratique, ces gains sont assez difficile à évaluer et à défendre. Les équipes pop-corn n’ont aucun ouvrage dédié, à ma connaissance, vantant les mérites incontestables sur le ROI d’une synergie d’équipe statique comme le font tant de livres sur les processus agiles, l’utilisation d’UML ou des procédures strictes de QA. Pourtant, les effets néfastes de telles méthodes d’attribution des tâches – traits d’entreprises ayant vécu avec des ressources très limitées pour un grand nombre de petits projets? – sont concrets. On pourrait à priori comparer les coûts reliés aux équipes pop-corn à une version miniature des coûts de perte/embauche d’employés. Les équipes sont après tout des mini-structures très semblables à leur conteneur.

Read more…

Categories: Management