Estimation descendante vs Estimation montante
Macro planning vs micro planning (même si ce n’est pas un planning)

Le produit est défini par User Stories, les niveaux « L1 ».
Les User Stories sont estimés par la méthode des Use Case points.
Ces estimations permettent la définition du plan d’itération, roadmap de l’application.

Des User Stories aux fonctions élémentaires, c’est l’estimation descendante.
Les User stories sont décomposés Business Scénarios :
Scénario principal (aux), scénarios alternatifs, scénarios d’exception.
Décomposition jusqu’au niveau fonction élémentaire. Affinage de l’estimation, ré-estimation indépendante à chaque étage. Cette étape peut être assimilée à l’analyse fonctionnelle, et doit s’effectuer de manière itérative aussi, en fonction du plan d’itération.

Pour l’itération à venir, on prépare l’estimation montante :
A partir des fonctions élémentaires, décomposition en tâches de « développement ». J’entends par tâche de développement, toute activité nécessaire à la production jusqu’à terme de la fonctionnalité : code, tests unitaires, revue de code, intégration, tests fonctionnels,…

La grande majorité des développements applicatifs se basant dorénavant sur un ou plusieurs frameworks, il est facile d’établir une sorte de check-list des tâches. Pour chaque fonction élémentaire, on peut choisir les tâches applicables issues de cette check-list.

A partir de là, les niveaux « L2 » sont définis, leur estimation est effectuée lors du planning game par l’équipe. C’est l’estimation montante : La somme des estimations des tâches prises en compte pour l’itération est à confronter avec la vélocité. Cela peut avoir un impact sur le plan d’itération du fait que l’estimation montante n’est pas nécessairement égale (voir jamais) à l’estimation descendante.

Pendant le sprint (l’itération), le reste à faire est mise à jour, ainsi que le consommé.
En fin d’itération, il est important de reconsidérer les trois valeurs :

• Plan estimé : estimation macroscopique, estimation descendante
• Task estimé : estimation unitaires des tâches de l’itération, estimation montante
• Effort réel : Temps réellement passé à produire les tâches

A partir de ces informations on peut évaluer l’impact sur le plan d’itération, la vie du produit.

La décomposition précise des User Stories en scénarios, puis en fonctions élémentaires, et enfin en tâches, permet à tout intervenant sur le projet

• d’identifier,
• de comprendre,
• d’adhérer

au contenu fonctionnel du produit.

Cela permet dans une certaine mesure de s’affranchir d’une documentation de spécification détaillée proche du code qui alourdi le process.
L’autre mérite est de traiter la traçabilité sans s’en rendre compte, c’est le cas de la combinaison d’utilisation des outils Rally et Eclipse Mylin et SVN (ou CVS).

Les réunions des Praticiens de Paris sont des soirées informelles où se retrouvent les personnes qui pratiquent ou veulent pratiquer l’agilité en région parisienne. La prochaine soirée aura lieu le jeudi 3 avril dans les locaux de Valtech, près des Champs Elysées.
(more…)

Jean-Marie Gouarné fait le point sur la dernière réunion BRM qui a eu lieu du 25 au 29 Février à Genève sur itrmanager.

Je partage tout à fait son point de vue et souligne les deux citations suivantes tirées de son article:

En s’acharnant prioritairement sur la normalisation d’OOXML, l’état-major de Redmond démontre en réalité les limites étroites dans lesquelles s’inscrivent ses promesses d’ouverture (récentes et anciennes).

Les responsables ultimes, ce sont les États qui réclament l’interopérabilité sans la définir, et qui exigent des formats normalisés sans imposer de pré-requis sur la qualité des normes. Cette politique pavée de bonnes intentions ne peut provoquer, de la part des éditeurs de logiciels qui se sentent visés, que des promesses sur une certaine conception de l’interopérabilité et une course aux normes de complaisance. Elle ne suffit pas pour rétablir la concurrence entre les éditeurs, et elle complique le maquis des formats.

Le format ODF est déjà une norme ISO et est largement suffisant pour répondre aux besoins de l’entreprise.

J’ai également appris aujourd’hui par linuxfr.org que selon les echos la France devrait se joindre au Brésil, à l’Inde et à Cuba pour dire « non » à Microsoft afin que OOXML ne soit pas normalisé par l’ISO. Ça c’est une bonne nouvelle pour notre avenir numérique.

Les débuts de HTML ont été difficiles. La guerre des navigateurs et les diverses implémentations ont semées une grande pagaille sur le Web, et nous en récoltons toujours de nombreux problèmes. Ces problèmes sont bien identifiés et il ne tient qu’à nous d’opter pour un standard qui les abolira définitivement.

Aujourd’hui nous connaissons l’ingrédient principale du succès de HTML et nous avons le recule suffisant pour mettre en place des technologies qui vont permettre de pérenniser les qualités du Web et supprimer ses défauts. XHTML2 est un standard qui permettra cette pérennité alors que HTML5 la met en danger, voyons ça de plus près.

Le succès de HTML (du début jusqu’à html4.1 et xhtml1.1)

Le succès du Web tel que nous le connaissons aujourd’hui est dû en grande partie grâce à HTML qui s’appuie sur un système de balisage ouvert, simple et gratuit.

Ces trois principes ont permis l’appropriation d’Internet au grand public. Parce que HTML est composé de balises simples, il est facile de mettre sur Internet des données qui sont accessibles à tout le monde via l’utilisation d’un navigateur Web. Le succès d’Internet peut se mesurer au nombre de pages publiées, aussi bien par les entreprises que par les particuliers ou autres associations, et la seule façon de pérenniser ce succès est de contrôler le format de HTML afin de garder sa simplicité.

La normalisation est donc une étape essentielle dans le succès d’une technologie libre et accessible. C’est le W3C qui est l’organisation qui a pour but de normaliser HTML. C’est elle qui contrôle son format.

Les qualités principales de HTML

La première de ses qualités est d’être suffisamment générique pour permettre aux applications de créer d’elles même de nouvelles fonctionnalités.

Cette qualité en amenant d’autres :

• Il y a peu d’éléments à connaitre pour réaliser un document.
• Peu de mises à jour de HTML. Les mises à jour n’ont été réalisées que pour restructurer le langage et orienter les programmeurs Web vers les bonnes pratiques.

C’est cette généricité qui à permis au Web 2.0 d’émerger.

Les problèmes identifiés de HTML

La fonction principale de HTML est de décrire une sémantique pour des documents. Le mélange du contenu et de la présentation est le premier gros problème. Ce défaut disparait avec XHTML1.1, qui découple la présentation du contenu en déportant la présentation entièrement dans CSS.

De ce point de vue XHTML1.1 est déjà un format de bonne qualité. XHTML2 est une continuité de XHTML1.1, en reprenant tous les bons principes, en supprimant tous ce qui est superflue et en ajoutant des composants génériques et extensibles pour les nouvelles fonctionnalités.

Les problèmes causés par une mauvaise approche du Web

L’utilisation d’attributs ou de balises spécifiques à un navigateur est une source de problèmes multiples. Ce problème est également valable pour les CSS et autre Javascript. J’ai remarqué que des programmeurs Web se demandent comment résoudre des problèmes qui ne se posent pas dans un contexte d’applications Web. Les seules solutions qu’ils trouvent passe par l’utilisation de “hacks”, des balises propriétaires non-normalisées, utilisation du caractère * au début des noms des propriétés CSS etc..

Selon moi, HTML5 répond à cet état d’esprit en ajoutant des composants non-extensibles qui ont l’avantage de répondre simplement à un problème précis. Cet avantage est accompagné d’un inconvénient de taille, qui implique une démultiplication des composants. Au final on se retrouvera avec un langage lourd et les programmeurs finiront par ne plus savoir quoi utiliser pour répondre à une problématique lambda.

XHTML2 est une bonne solution

Le W3C a une forte compétence dans les langages à balisage. Ils ne font pas les choses à la légère. Ils prennent le temps de faire aboutir leurs études afin d’apporter un haut niveau de qualité dans la norme HTML. Nous approchons d’un très bon niveau de qualité avec la prochaine version de HTML qui s’appellera XHTML2.

XHTML2 s’appuie entièrement sur XML, ce qui est une bonne chose car cela nous permet de bénéficier de toute l’artillerie existante autour de cette technologie qui est véritablement une grande avancée dans le domaine des systèmes d’information ces dernières années.

Je pense que les navigateurs devraient implémenter des parseurs XML qui soient plus souples sur la gestion des erreurs de sémantique. S’arrêter de parser sur la première erreur rencontrée dans un document XML ne fait pas partie de la recommandation du W3C. Nous en reparlerons au prochain chapitre.

le WHATWG propose une mauvaise solution

(extrait de wikipedia) Le WHATWG est une collaboration non officielle des différents développeurs de navigateurs web ayant pour but le développement de nouvelles technologies destinées à faciliter l’écriture et le déploiement d’applications à travers le Web. Il se présente notamment comme une réponse à la lenteur supposée du développement des standards par le W3C et au caractère supposé trop fermé de son processus interne d’élaboration de spécification. Cependant, de nombreux participants à ce projet sont également des membres actifs du W3C, et le nouveau groupe de travail HTML du W3C a adopté en 2007 les propositions du WHATWG comme base de travail d’un futur HTML5.

Ce groupe de travail propose une approche de HTML qui consiste à créer des éléments pour faciliter des cas particuliers.

HTML5 se veut plus pragmatique mais il pose un problème fondamentale: en implémentant des balises spécifiques pour des cas particuliers il deviendra rapidement complexe par le nombre d’éléments qui le composent.

Et enfin HTML5 se veut plus pragmatique en permettant aux utilisateurs d’abandonner XML ce qui est, nous en avons parlé au chapitre précédent, une régression importante selon moi et qui ne se justifie pas. En effet, c’est le WHATWG, composé au départ des principales firmes qui développent les navigateurs Web, qui trouve que le parsing XML est fastidieux à l’utilisation car les parseurs XML sont trop restrictifs sur les erreurs. Mais il ne tient qu’à eux, comme nous l’avons déjà vu, d’implémenter des parseurs XML qui soient plus souples.

Conclusion

L’erreur du W3C est de ne pas s’être ouvert assez aux suggestions extérieur. C’est ce qui a conduit le WHATWG à faire la proposition de HTML5. XHTML2 n’est pas parfait, mais il a de bien meilleures bases que son concurrent. Il est important de prendre partie pour le format que l’on pense être le meilleur pour notre avenir et c’est pour ça que j’ai écrit ce billet.

L’idéal serait d’abandonner HTML5 et d’écouter les suggestions comme celles qui se trouvent dans x-html-5-versus-xhtml-2 sur xhtml.com afin de finaliser XHTML2. Alors si vous avez un avis sur cette question, n’hésitez pas à le faire savoir, en laissant un commentaire sur ce billet ou en publiant un billet sur votre blog.

En savoir plus

Pour plus de détails sur ce sujet, je vous conseil de lire l’article de Eric van der Vlist référencé ci-dessous.

Références au sujet:

• HTML 5 : les documents deviennent des applications
• X/HTML 5 Versus XHTML 2
• La spécification XHTML 2
• La spécification HTML 5

Tout comme à la maison (d’après ma femme !), il est utile pour retrouver ces petits de faire un peu de rangement.
L’organisation du code source ne déroge pas à cette règle. Cela peut paraître simpliste, voir inutile de faire un papier sur ce sujet, mais l’expérience me prouve que ce sujet n’est pas toujours appliqué.

Le principe est simple :

• L’environnement de développement doit être identique à l’environnement de production.

J’entends par là que les sources, les fichiers de configuration, les scripts et tous autres artefacts qui servent à la mise en œuvre de l’application doivent être rangés dans des répertoires organisés de la même manière que ceux déployer pour exécution.
Ce principe de base d’organisation de la configuration logicielle simplifie le déploiement, les procédures d’installation en évitant les « pertes » de fichiers.

Autre avantage à cette organisation des sources et de limiter la divergence d’exécution entre la version lancée sous Eclipse et celle déployée. De permettre donc de traiter (identifier, voir reproduire) les bugs en environnement de dév, plutôt qu’en environnement d’intégration où il n’y a souvent pas de débugger.

Avec Eclipse, j’engage les développeurs à utiliser un projet par package fonctionnel mais aussi technique : 1 pour le client, 1 pour le serveur, 1 pour les tests, 1 pour les « commons ».
Cela garantie la séparation des couches et évite au développeur de tirer des classes serveurs directement dans le package client.
L’utilisation des Working Set Eclipse permet d’améliorer la vue lorsqu’il y a une multitude de projets.
Sans parler de standardisation (breeuuu…), l’organisation des sources pour le développement d’une appli web est souvent contrainte par l’organisation des conteneurs (webapps).
Répertoire WEB-INF, lib, js, conf, … Certains plugins Eclipse imposent même l’arborescence des sources.
Il est intéressant de s’inspirer de ces principes pour le développement d’application non web.

Pourquoi ces trois mots apparemment sans lien ? Pour vous parler d’une séance dont le dojo était Valtech et l’objectif était de découvrir par la pratique le langage Ruby.
La première partie de la séance fut un…

Kata Randori

Les postes de développement Ruby ont été constitués sur le vif (l’environnement Ruby pour Windows mis en place à l’aide d’un installeur). Le moins que l’on puisse dire, c’est que les configurations hétérogènes nous ont quelque peu pimenté la tâche : MacBook, PC sous XP et Linux !
Nous avons ensuite choisi le kata (i.e. l’énoncé de l’exercice) à effectuer : “Missing word in dictionnary”. Un exemple vaut mieux qu’un long discours ici : (more…)

Pourquoi ces trois mots apparemment sans lien ? Pour vous parler d’une séance dont le dojo était Valtech et l’objectif était de découvrir par la pratique le langage Ruby.
La première partie de la séance fut un…

Kata Randori

Les postes de développement Ruby ont été constitués sur le vif (l’environnement Ruby pour Windows mis en place à l’aide d’un installeur). Le moins que l’on puisse dire, c’est que les configurations hétérogènes nous ont quelque peu pimenté la tâche : MacBook, PC sous XP et Linux !
N…
lire la suite…

XP Day Paris 2008 (warning: as of March 22nd, the site still states the wrong date) was planned for May 12 & 13, but the organizers had to advance it by a week to May 5 & 6. It sounds unlikely, but I got the news (twice) directly from the source.

(more…)

Le caractère HTML de l’espace insécable est utilisé à tort et à travers. Je vois des développeurs qui l’utilisent pour aligner des données au lieu d’utiliser le padding ou le margin CSS.

Alors voilà un petit billet pour rappeler l’utilité du caractère  .

(source wikipedia) Une espace insécable est un caractère typographique que l’on intercale entre deux mots (ou un mot et une ponctuation) qui ne doivent pas être séparés par un éventuel retour à la ligne automatique. L’espace insécable permet d’éviter qu’un mot ou une ponctuation soit rejeté et isolé en début de ligne lorsque cela nuirait à la fluidité de la lecture.

Toute autre utilisation de ce caractère est donc une erreur qui entraine souvent des problèmes d’affichage et qui dégrade le niveau de maintenance des applications.

A bon entendeur

The Conference on Continuous Integration & Testing is taking place this year in Denver (April 4 & 5), Melbourne (June 27 & 28) and Amsterdam (October 3 & 4).

(more…)