Discussion :

[Idelways]

Google publie des slides sur sa gestion du développement de Chrome
Une approche qui pourrait devenir un cas d'école



Depuis la deuxième moitié de 2010, le rythme de développement de Google Chrome a pris une tournure inhabituelle pour un navigateur.

Suivant l'approche : « sortir tôt et sortir souvent », l'équipe du projet s'est attelée à lancer une version majeure de son navigateur toutes les six semaines.

Une approche qui rend l'évolution du navigateur difficile à suivre, d'autant plus que sa mise à jour se fait automatiquement, d'une manière transparente pour l'utilisateur.

C'est visiblement le but de Google, qui ne fait d'ailleurs plus beaucoup de bruit autour des sorties des nouvelles versions (pour faire oublier les numéros des versions ?).

Cette semaine, Google a sorti un document très intéressant sur ces méthodes de travail. La société s'est exprimée par le biais du superviseur du développement de Chrome, Anthony LaForge qui a publié des slides sur ce qui risque de devenir un cas d'école en terme de gestion de projet de développement.

Contrairement aux méthodes classiques, qui fixent les fonctionnalités à intégrer, quitte à reporter le lancement de la nouvelle version (voir les reports successifs de Firefox 4), Google considère les fonctionnalités comme un flux continu.

Il assimile son navigateur à un site Web qui offre des services. Ses services et fonctionnalités sont mises à la disposition des utilisateurs dès qu'elles sont prêtes.

D'où l'inutilité, dans ce contexte, d'un numéro de version. Ce qui comptent en revanche, ce sont les "channels". Google Chrome en propose trois : Développement, Bêta et Stable (quatre avec Canary).

Les nouveautés sont rendues disponible sur ces channels progressivement, les utilisateurs choisissant le "degré de stabilité" qui leur convient.

Ces slides, qui intéresseront aussi bien les développeurs Webs que les développeurs d'application on-premise sont disponibles sur ce lien.

Et vous ?

Quelle approche préférez-vous :le flux continu de fonctionnalités de Google Chrome ou celle traditionnelles où les nouvelles versions marque un changement profond de l'application ?

En collaboration avec Gordon Fowler

[ninfomane]

Je n'ai hélas pas tout compris de la présentation. Mais cette gestion me parait très proche de l'anarchie des développeurs. Ce que je comprends, c'est que au lieu de sortir une release à une date donnée avec un tas de fonctionnalités, ils ajoutent seulement les fonctionnalités qui sont stables périodiquement. Un des objectifs étant de ne pas presser le développeur pour qu'il bosse mieux. Certe, mais ce qui tient l'utilisateur (ou le client) en haleine est qu'à une release il aura les fonctionnalités recherchées. Avec ce système, il n'est pas certain de l'avoir avec la prochaine update.

Cela dit, je trouve cette gestion plus cool pour l'entreprise qui n'est plus oppressée par les dates. De plus, l'utilisateur ou client est bien plus certains d'avoir une solution stable. La méthode s'adapte parfaitement au produit Chrome ou tout aux autres services Web. Il serait bon de tester pour des produits plus commerciaux dont le client attend son produit à une date donnée et avec les fonctionnalités demandées.

Cette méthode serait peut-être à mélanger avec XP ?!

[abriotde]

C'est mieux pour le développeur, mais pas seulement, l'utilisateur est satisfait de ne pas avoir un système fait à la va vite mal pensé ou de ne pas disposer de fonctionnalités prêtes. Cela pousse aussi à faire évoluer les applications en permanences. Comme toujours il y a l'inconvénient de la mise en place de ce système qui demande une adaptation de chacun des acteurs. Il existe aussi des cas ou ce système n'est pas envisageable (s'il doit y avoir synchronisation de mise à jour....)

[pseudocode]

Quelle approche préférez-vous :le flux continu de fonctionnalités de Google Chrome ou celle traditionnelles où les nouvelles versions marque un changement profond de l'application ?

Le processus de Google n'a rien de révolutionnaire. C'est du timeboxing sur un cycle de 11 semaines:

- 4 semaines de développement
- feature & text freeze
- 2 semaines d'intégration (patch)
- 5 semaines de stabilisation + traduction
- code freeze
- livraison

Pour moi, le plus intéressant dans ce document c'est cette remarque :

- What would a world look like where we didn't base our marketing on releases ?

"We market features, not releases."

[Jay13mhsc]

Avec ce système, il n'est pas certain de l'avoir avec la prochaine update.

Parce qu'avec des méthodes classiques on est certain de l'avoir ??? Mais à quels couts ? Ceux fixés au départ ? Ou avec quel retard sur le délai annoncé ? Ou encore au prix de combien de défauts dissimulés ?
Ce n'est pas juste des mecs en train de se faire plaisir. C'est simplement la seule et vraie façon de livrer à temps (puisque c'est fixé) des fonctionnalités avec un niveau de qualité élevé. Ce n'est pas possible autrement...

Cela dit, je trouve cette gestion plus cool pour l'entreprise qui n'est plus oppressée par les dates.

Mais c'est justement fait pour les entreprises obnubilées par les dates !!! Il n'y a qu'à les fixer !
Maintenant, est ce si grave de livrer à l'heure, une version avec le meilleur niveau de qualité possible, sans la petite fonction qui permet de trier les onglets par nombre de caractères dans la page ? Non... De toutes façons, si c'est si important, on la verra dans 6 semaines...

[manudwarf]

Je pense que dans le milieu du Web, ça devrait être la norme de tous les navigateurs : des tests automatiques qui valident le comportement du programme par rapport à une norme (HTML), qui fait que le développeur web n'a plus à se soucier des différentes versions de navigateur puisqu'en théorie l'utilisateur a la dernière (non je n'ai pas été traumatisé par IE).

De plus, ça met en exergue la mauvaise gestion des mises à jour de Windows

[parrot]

Cette méthode serait peut-être à mélanger avec XP ?!

Cette méthode découle naturellement de XP ou de Scrum.

Dans Scrum, le développement se déroule de manière itérative, basé sur un "sprint" (cycle) de 2 à 4 semaines. Les fonctionalités sont priorisées par un "Product Owner", puis soumises à l'équipe de développement. Celle-ci doit d'une part les estimer en terme de temps de développement, puis accepter celles qu'elle estime pouvoir réaliser durant un sprint. A la fin du sprint, le produit devrait atteindre un niveau de qualité tel qu'il soit livrable. Ce qui implique que les tests fassent partie intégrante du sprint.

Mais est-il pratiquement possible d'atteindre un niveau de qualité stable à la fin d'un sprint? Je pense que cela ne l'est pas, une phase beta devant se dérouler sur plusieurs semaines afin que les utilisateurs aient le temps de donner leur avis. Google utilise donc une deuxième phase pour "monter" leur produit du niveau beta à stable.

Tout comme pseudocode, je pense que l'approche de Google est plus nouvelle dans la manière de vendre le produit au client, que dans la manière de le développer.

[Mobius]

j'aime beaucoup la conclusion :

We basically wanted to operate more like trains leaving Grand Central Station
(regularly scheduled and always on time), and less like taxis leaving the Bronx
(ad hoc and unpredictable).

Cela veut dire que la méthode n'est pas applicable en France puisque les trains ont toujours du retard (pour les taxis c'est une autre histoire)