Le cycle de développement typique d'un produit Microsoft... et les programmes de Beta test

Dans cette rubrique " Do You Speak MS? ", je vais vous parler de temps en temps de différents aspects méconnus de la vie interne de Microsoft, qu'il s'agisse de sujets techniques, de la culture d'entreprise, ou de l'énorme masse d'acronymes et de mots de Jargon qui sont tout simplement incompréhensibles pour les non-Microsofties, et auxquels vous pouvez être confrontés au cours d'une réunion de travail qui comporte plus de dexu employés de Redmond...

Pour débuter avec cette rubrique, je vais commencer par vous parler du cycle de développement typique d'un produit Microsoft. C'est là encore un aspect méconnu de ce qui se passe derrière le rideau... et au passage, vous y apprendrez quelques uns des acronymes (généralement à trois lettres, les fameux ATL) qui sont si présents dans le vocabulaire de Microsofties.

Tout d'abord, il faut savoir que parmi les populations techniques et les groupes produits, "shipper" un logiciels, ou le rendre disponible aux utilisateurs, que ce soit commercialement comme par exemple pour Office, ou en téléchargement gratuit comme le .NET Framework, c'est le but principal. Il existe même dans le jargon de la maison une insulte entre développeurs qui est "This guy never shipped anything", pour parler d'un développeur dont les travaux ne sont jamais sortis des labs de développement... C'est pour dire ;-)

Au début, tout commence par la phase de Spécification. Il s'agit alors pour un groupe de Program Managers de brainstormer en croisant différents types et différentes sources d'informations, telles que des analyses du marché cible, des visions et des priorités. Ce qui en ressort, donc ce qui est produit par tout ce jus de cerveaux, c'est une liste de fonctionnalités à implémenter, et un agenda prévisionnel du projet.

Ensuite, les développeurs entrent en jeu, et la phase de développement démarre. Elle est marquée par plusieurs étapes majeures intermédiaires, les MM pour "Major Milestones". Ces MM sont généralement au nombre de trois à cinq. Ce qui est produit est une sorte de pré-version à usage purement interne, et durant toute cette phase de développement des MM, il n'y a pas de tests sur ces builds. Les testeurs n'interviennent que plus tard. Voilà pourquoi on réserve ces MM à des utilisations internes à Microsoft.

L'étape suivante est le "ZBR1", soit la première version dans laquelle tous les bugs identifiés par les testeurs et les utilisateurs internes ont été corrigés. ZBR signifiant "Zero Bug Release". La ZBR est alors packagée et parfois localisée dans deux langues étrangères, généralement en Allemand et en Japonais. La langue Allemande permet de tester le fonctionnement correct de l'interface avec des libellés sur les contrôles de l'interface utilisateur sensiblement plus longs qu'en Anglais. Le Japonais, quant à lui permet de tester l'UI avec des langues utilisant des jeux de caractères spéciaux. Cette version packagée, pour laquelle on dispose d'une procédure d'installation automatisée en MSI, devient alors la version Beta 1, qui devient disponible aux utilisateurs et clients, et non plus seulement en interne à Microsoft.

Il peut y avoir plusieurs versions Beta, généralement moins de quatre. C'est aussi pendant cette période que l'onb décide parfois de déployer en interne ces pré-versions en production. C'est ainsi que longtemps avant la disponibilité de la version finale, tout Microsoft fonctionnait sur une version Beta de Exchange... 60 000 employés dont la messagerie est l'outil principal. Dans le jargon Microsoft, utiliser en production en interne des pré-versions s'appelle le "Dog Fooding". C'est vrai que par la taille de l'entreprise, on identifie ainsi certains disfonctionnements et on évite à nos clients d'essuyer les plâtres sur les premiers déploiements.

A la fin du développement de ces versions Beta, on obtient une version que l'on nomme "Code Complete", ou "Feature Complete". C'est une build qui comporte l'intégralité des fonctionnalités prévues sur la "Feature List". A partir de cette étape on entre donc dans la phase de Stabilisation qui va durer jusqu'à la disponibilité commerciale du produit fini.

Après la dernière version Beta, apparait donc la version RC0, ou "Release Candidate 0". Durant toute la période qui suit, il n'y a en principe plus de modifications dans la liste des fonctionnalités présentes dans le produit. Il n'y a plus alors que des corrections de bugs.

Suivant les produits, on peut avoir plus ou moins de versions RC. On peut voir alors des version RC5 ou RC7. A noter que toutes ces versions RC ne sont pas forcément disponibles pour le public et les clients de Microsoft.

La dernière version RCx donne la place à la version RTM : Release To Manufacture. C'est cette build qui sera utilisée pour réaliser les médias d'installation que vous retrouverez dans votre boite de produit. La RTM est à l'octet prêt identique au produit fini que vous pouvez obtenir dansle commerce.

A partir de la disponibilité commerciale d'une version, par exemple de la suite Office 2003, les Product Managers et les développeurs se mettent déjà à travailler sur la version suivante, et le cycle reprend...

Du point de vue du développeur, qu'il soit chez un client final (dans une société utilisatrice) ou chez un Partenaire Microsoft (Société de Service, ou Editeur de Logiciels), durant toutes ces phases de Développement et de Stabilisation, la disponibilité au plus tôt ces versions successives est souvent un facteur de réussite des projets de développement.

Pour celà, les équipes produit s'astreignent à fournir des versions intermédiaires publiques, aussi souvent que leurs ressources le leur permettent (en effet, stabiliser, localiser et packager des versions intermédiaires "jettables" entraine une charge et des coûts non négligeables...)

Autour des premières version Alpha, les groupes produits vont se rapprocher d'une cinquantaine de clients ou partenaires à travers le monde, et les intégrer dans un programme de type "Early Adopter" très en amont. Ces programmes s'appellent les TAP pour Technology Adoption Programs.

Vient ensuite aux alentours de la première version Beta, un autre programme Early Adopter prend le relai. Il s'agit des programmes nommés "Ascend". Cette fois, ce sont les Partner Account Managers et les personnes de Microsoft qui travaillent sur le terrain avec les partenaires (SSII ou Editeurs) qui proposent la participation ces société aux programmes Ascend. L'objectif est alors de recruter au niveau mondial environ 200 à 500 sociétés qui ont un réel projet de développement sur le produit ou la technologie concernée. Les groupes produit font alors une sélection parmi ces candidats proposés par les personnes de terrain et déterminent donc les participants. Les heureux élus bénéficient alors d'un lien direct avec les équipes produit, de support technique pointu via des newsgroups privés, et de formations pour les développeurs et administrateurs.

Après les programmes Ascend, et aux alentours de la version Beta 2, viennent les programmes Touchdown, qui visent à produire jusqu'à 100 000 implémentation de solutions partenaires. C'est un programme plus 'large bande" que les programmes Ascend, et les bénéfices pour les sociétés participantes sont donc nécessairement revus à la baisse. Typiquement, les programmes Touchdown n'offrent pas une formation d'une semaine aux développeurs des participants, contrairement au programme Ascend.

Pourquoi vous avoir expliqué tout ceci ? Tout simplement pour vous inciter à vous faire connaitre de Microsoft si vous êtes une société de service ou un éditeur de logiciels. En effet, les contacts locaux "du terrain" - dont je fais partie - ne peuvent proposer les candidatures que des sociétés qu'ils connaissent et avec qui ils sont en relation. En résumé : Faites vous connaitre ! Pour celà, vous pouvez utiliser la page Contact de ce blog, ou de ceux de mes collègues de Microsoft France, ou adresser un mail direct à l'un des contacts présents sur cette page.

A ce propos, nous sommes actuellement en phase de recrutement de partenaires pour trois programmes Ascend qui couvrent SQL Server 2005 "Yukon" pour le premier, Visual Studio 2005 "Whidbey" pour le second et Windows Server 2003 SP1 et Editions 64 Bits pour le dernier. Là encore, si vous êtes intéressé, prenez contact avec nous.